IRTF D. King Internet-Draft Lancaster University Intended status: Informational J. Dang Expires: August 15, 2021 Huawei Technologies A. Farrel Old Dog Consulting February 11, 2021 Challenges for the Internet Routing Infrastructure Introduced by Changes in Address Semantics draft-king-irtf-challenges-in-routing-00 Abstract Historically, the meaning of an IP address has been to identify an interface on a network device. Routing protocols have been developed based on the assumption that a destination address has this semantic. Many proposals have been made to add semantics to IPv6 addresses. These proposals may set the meaning of an address within the scope of a limited domain, or suggest an address semantic that is meaningful at specific points in the network (such as the source and destination), but which can continue to be used without special interpretation at transit points. Such proposals include providing semantics specific to mobile networks, multicast traffic, different device types, different underlying connectivity, hierarchical connectivity, geographic location, application or network function usage, or connectivity requirements. Some new IP address semantics may have implications for how network routing is performed. Some proposals might not be supported by existing routing protocols and so would require changes. Other proposals might enable advanced routing features or offer benefits in scaling and management of routing systems. This document presents a brief survey of technologies related to IP address semantic proposals and describes the challenges to the existing routing system that they present. It then summarises the opportunities for research into new or modified routing protocols to make use of new address semantics. This document is presented as research to clarify and understand the issues without directly proposing technical solutions that are ready for productisation or deployment. King, et al. Expires August 15, 2021 [Page 1] Internet-Draft Routing Challenges February 2021 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 August 15, 2021. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Challenges to Current Internet Routing . . . . . . . . . . . 4 3. Network Path Selection . . . . . . . . . . . . . . . . . . . 6 3.1. Path Aware Routing . . . . . . . . . . . . . . . . . . . 7 4. What is Semantic Routing? . . . . . . . . . . . . . . . . . . 7 4.1. Semantic Prefix Domains . . . . . . . . . . . . . . . . . 9 5. Existing Approaches to Traffic Differentiation . . . . . . . 10 5.1. Deep Packet Inspection . . . . . . . . . . . . . . . . . 10 5.2. Differentiated Services . . . . . . . . . . . . . . . . . 11 5.3. Segment Routing . . . . . . . . . . . . . . . . . . . . . 11 5.4. Information-Centric Networking . . . . . . . . . . . . . 12 5.5. Locator/ID Separation Protocol (LISP) . . . . . . . . . . 13 5.6. Identifier-Locator Network Protocol . . . . . . . . . . . 13 5.7. Application-Layer Traffic Optimization . . . . . . . . . 13 King, et al. Expires August 15, 2021 [Page 2] Internet-Draft Routing Challenges February 2021 5.8. Multipath TCP . . . . . . . . . . . . . . . . . . . . . . 14 5.9. Path Computation Element . . . . . . . . . . . . . . . . 14 5.10. Connectionless Network Protocol . . . . . . . . . . . . . 14 6. Overview of Current Routing Research Work . . . . . . . . . . 15 6.1. Clean Slate Approaches . . . . . . . . . . . . . . . . . 15 6.1.1. Recursive InterNetwork Architecture . . . . . . . . . 15 6.1.2. Scalability, Control, and Isolation on Next- Generation Networks . . . . . . . . . . . . . . . . . 16 6.1.3. Expedited Internet Bypass Protocol . . . . . . . . . 16 6.2. Hybrid Approaches . . . . . . . . . . . . . . . . . . . . 17 6.3. Approaches that Modify Existing Routing Protocols . . . . 17 6.4. No Changes Needed . . . . . . . . . . . . . . . . . . . . 17 7. Challenges for Internet Routing Research . . . . . . . . . . 17 7.1. Routing Research Questions to be Addressed . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21 12. Informative References . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 1. Introduction The Internet continues to expand rapidly. At the same time, there are increasingly varied classes and types of service. Some services require a differentiated set traffic characteristics for successful delivery and to guarantee user and application experience. This places significant pressure on Service Providers to be aware of the type of services being delivered, and to have access to detailed information about how individual packets should be treated to meet the user and application requirements. Internet Protocol (IP) addressing facilitates how a device is attached to the Internet and distinguished from every other device. Addresses are used to direct packets to a destination (destination address) and indicate to where replies should be sent (source address). An IP address may be assigned to each device connected to a network that uses IP. An IP address is used to both identify a host and to indicate the location of the host. The meaning of a unicast IPv6 address is defined as "An identifier for a single interface." [RFC4291]. That document goes on to say, "A packet sent to a unicast address is delivered to the interface identified by that address." Network routing protocols have been developed based on the assumption that a destination address has this meaning. The protocols are designed to determine paths through the network toward destination King, et al. Expires August 15, 2021 [Page 3] Internet-Draft Routing Challenges February 2021 addresses so that IP packets with a common destination address converge on that destination. This document presents a brief survey of proposals to extend the semantics of IP addresses by assigning additional meanings to some parts of the address, or by partitioning the address into a set of subfields that give scoped addressing instructions. Some of these proposals are intended to be deployed in limited domains (networks) that are based on IP, while other proposals are intended for use across the Internet. The impact the proposals have on the routing system may require clean-slate solutions, hybrid solutions, extensions to existing routing protocols, or potentially no changes at all. This document also presents some of the challenges to the existing routing system that these changes in semantics may present. It then summarises the existing research and opportunities for future research into new or modified routing protocols to make use of new address semantics. This document draws on surveys and analysis already performed in "A Survey of the Research on Future Internet Architectures" [RESEARCHFIAref], and "ITU-T FG-NET2030 Architecture Framework" [ITUNET2030ref], and work related to specific Internet technologies, such as the Internet of Things (IOT) "Overview of Existing Routing Protocols for Low Power and Lossy Networks" [IOTSURVEYref]. 2. Challenges to Current Internet Routing Today's Internet faces several significant challenges which are a consequence of the architectural design decisions and exponential growth. These challenges include mobility, multihoming, programmable paths, and scalability, and were not the focus of the original design of the Internet. Nevertheless, the Internet has, in general, coped well in an incremental manner as each new challenge has evolved. This list is presented to give context to the continuing requirements that routing protocols must meet as new semantics are applied to IP addresses. Mobility - It is helpful to maintain an association between the mobile station and its original IP address even after the mobile node changes the network to which it is attached. This allows continuity of services, but requires that the original network must always be informed about the mobile nodes current location. Multihoming - Multihomed stations or multihomed networks are connected to the Internet via more than one access network and therefore, may be assigned multiple IP addresses from different King, et al. Expires August 15, 2021 [Page 4] Internet-Draft Routing Challenges February 2021 pools of addresses. There are challenges concerning how traffic is routed back to the source if the source has originated its traffic using the wrong address for a particular connection, or if one of the connections to the Internet is degraded. Multi-path - The Internet was initially designed to find the single, "best" path to a destination using a distributed routing algorithm. The current Internet topology facilitates multiple paths each with different characteristics and with different failure likelihoods. It may be beneficial to send traffic over multiple paths to achieve reliability and enhance throughput, and it may be desirable to select one path or another in order to provide delivery qualities or to avoid transiting specific areas of the Internet. However, the way in which packets are routed using the best or shortest path means that distinguishing these alternate paths and directing traffic to them can be hard. Further, problems concerning scalability, commercial agreements among Service Providers, and the design of BGP make the utilization of multi-path techniques difficult for inter-domain routing. Programmable paths - The ability to decouple Internet paths from routing protocols and agreements between Service Providers, would allow users and applications to configure and select Internet paths themselves, based on required path (that is, traffic- delivery) characteristics. Currently, user and application packets follow the path selected by routing protocols and the way traffic is routed through a network is under the exclusive control of the Service Provider that owns the network. Scalability - There are many scaling concerns that pose critical challenges to the Internet. Not least among these challenges is the size of the routing tables that routers in the Internet must maintain and exchange with their peers. As the number of devices attached to the Internet grows, so the number of addresses in use also grows, and because of the address allocation schemes, the mobility of devices, and the various connectivity options between networks, the routing table sizes also grow and are not amenable to aggregation. This problem exists even in limited domains (such as IoT), where the size of the routing table - as more devices are added to the network - may be a gating factor in ther applicability of certain routing protocols. The challenges outlined here were considered within the IETF by the IABs "Routing and Addressing Workshop" held in Amsterdam, The Netherlands on October 18-19, 2006 [RFC4984]. Several architectures and protocols have since been developed and worked on within and outside the IETF, and these are briefly examined in Section 5. King, et al. Expires August 15, 2021 [Page 5] Internet-Draft Routing Challenges February 2021 3. Network Path Selection Two approaches are typically used for network path selection. Firstly, a priori assessment by having the feasible paths and constraints computed in advance. Secondly, real-time computation in response to changing network conditions. The first scenario may be conducted offline and allows for concurrent or global optimization based on constraints and policy. As network size and complexity increases, the required computing power may increase exponentially. The second approach must consider the speed of calculation. The response processing may delay the service setup or the responsiveness to changes (such as failures) in the network. Path selection filters may be applied to reduce the complexity of the network data and the computation algorithm, however, the path computation accuracy and optimality may be negatively affected. In both scenarios, the amount of information that needs to be imported and processed can become very large (e.g., in large networks, with many possible paths and route metrics), which might impede the scalability of either method. In the last decade, significant research has been conducted into the architectural of the future Internet. During this research, several techniques emerged, highlighting the benefits of path awareness and path selection for end-hosts during this research, and multiple path- aware network architectures have been proposed, including SCION and RINA, and the work of the Path Aware Networking Research Gorup as discussed later in this document. When choosing the best paths or topology structures, the following criteria may need to be considered: o Method by which a path, or set of paths, is to be calculated. For example, a path may be selected automatically by the routing protocol or may imposed (perhaps for traffic engineering reasons) by a central controller or management entity. o Criteria used for selecting the best path. For example, classic route preference, or administrative policies such as economic costs, resilience, security, and if requested, applying geopolitical considerations. King, et al. Expires August 15, 2021 [Page 6] Internet-Draft Routing Challenges February 2021 3.1. Path Aware Routing The current Internet architecture is built using a best-effort philosophy. There are techniques discussed in this document that attempt better-than-best-effort delivery. The start-point and end- point of a path are identified using IP addresses, but the path might not run all the way from a packet's source to its destination. The assumption is that a packet reaching the end of a path is forwarded to its destination using best-effort techniques. The IRTF's Path Aware Networking Research Group [PANRGref] aims to support research in bringing path aware techniques into use in the Internet. This research overlaps with many past and existing IETF and IRTF efforts including multipath transport protocols, congestion control in multiply-connected environments, and alternate routing architectures. 4. What is Semantic Routing? Networks are often divided into addressing regions for various administrative or technological reasons. Different routing paradigms may be applied in each region, and within a single region specific "private" semantics may be applied to the IP addresses. This is not new, but has been a pragmatic solution for achieving network function in a limited domain (see Section 4.1). These address semantics are established using customer types, customer connections, topological constraints, performance groups, and security, etc. Service Provides or network operators will apply local policies to user and application packets as they enter the network possibly mapping addresses or possibly encapsulating them with an additional IP header. In some case, the packet has its source and destination within a single network and the network operator can apply address semantics policies across the whole network. In other cases (such as general Internet traffic), a packet will require a path across multiple networks, and each may apply its own set of traffic forwarding policies. In these cases, there is often no consistency or guaranteed performance unless a Service Level Agreement (SLA) is applied to traffic traversing multiple networks. Many proposals have been made to add semantics to IPv6 addresses beyond the simple identification of the source and destination [I-D.jia-scenarios-flexible-address-structure]. These proposals may set the meaning of an address within the scope of a limited domain, or suggest an address semantic that is meaningful at specific points in the network. In this context, a "limited domain" means that the interpretation of the address is only applicable to a well-defined set of network nodes, and if a packet bearing an address with a King, et al. Expires August 15, 2021 [Page 7] Internet-Draft Routing Challenges February 2021 modified semantic were to escape from the domain, the special meaning of the address would be lost. Additionally, the meaning of "specific points in the network" is generally applied to the source and destination nodes of a packet, while all transit nodes are unaware of the special semantic, however it could be the case that some key transit nodes are able to access the meaning of the address and so apply special routing or other functions to the packet. Such proposals include the following: o Providing semantics specific to mobile networks so that a user or device may move through the network without disruption to their service [CONTENT-RTG-MOBILEref]. o Enabling optimized multicast traffic distribution by encoding multicast tree and replication instructions within addresses [MULTICAST-SRref]. o Using addresses to identify different device types so that their traffic may be handled differently [SEMANTICRTG]. o Content-based routing (CBR), forwarding of the packet based on message content rather than the destination addresses [OPENSRNref]. o Deriving IP addresses from the physical layer identifiers and using addresses depending on the underlying connectivity. o Identifying hierarchical connectivity so that routing can be simplified [EIBPref]. o Providing geographic location information within addresses [GEO-IPref]. o Indicating the application or network function on a destination device or at a specific location. o Expressing how a packet should be handled, prioritised, or allocated network resources as it is forwarded through the network. o Using cryptographic algorithms to mask the identity of the source or destination, masking routing tables within the domain, while still enabling packet forwarding across the network [BLIND-FORWARDINGref]. In many cases, it may be argued that existing mechanisms applied on top of the common address semantic defined in RFC 4291 can deliver King, et al. Expires August 15, 2021 [Page 8] Internet-Draft Routing Challenges February 2021 the correct functionality for these scenarios. That is, packets may be tunneled over IP using a number of existing encapsulation techniques. Nevertheless, there is pressure to reduce the amount of encapsulation (partly to resist reduction in the maximum transmission unit (MTU) over the network, and partly to achiever a flatter and more transparent network architecture). This leads to investigations into whether the current IP addresses can be "overloaded" (without any negative connotations being attached to that word) by adding semantics to the addresses. Bringing new semantics to IP addresses may have implications for how network routing is performed. Some proposals might not be supported by existing routing protocols and so would require changes. Other proposals might enable advanced routing features or offer benefits in scaling and management of routing systems. The purpose of this document is to coordinate research into the consequences for routing of the various semantic addressing proposals, and to collect references to research work on routing solutions. Several technical challenges existing for semantic routing, these include: o Address consumption caused by lower address utility rate. The wastage is mainly comes from aligning. o Finite allocation for semantic address blocks. o Encoding too many semantics into prefixes will require evaluation of which to prioritise. o Risk of privacy/information leakage. o Burdening the user, application or prefix assignment node. o Source address spoofing preventing mechanism may be required. o Backwards compatibility with the existing Internet. 4.1. Semantic Prefix Domains A semantic prefix domain [I-D.jiang-semantic-prefix] is a portion of the Internet over which a consistent set of semantic-based policies are administered in a coordinated fashion. Examples of semantic prefix domains include: o Administrative domains o Applications King, et al. Expires August 15, 2021 [Page 9] Internet-Draft Routing Challenges February 2021 o Autonomous systems o Hosts o Network types o Routers o Trust regions o User groups A semantic prefix domain has a set of pre-established semantic definitions which are only meaningful locally. Without an efficient mechanism for notification, exchange, or configuration of semantics, the definitions of semantics are only meaningful within the local semantic prefix domain, and the addresses on a packet from within a domain risk being misinterpreted by hosts and routers outside the domain. While, sharing semantic definitions among semantic prefix domains would enable wider semantic-based network function, such approaches run the risk of complexity caused by overlapping semantics, and require a significant trust model between network operators. More successful approaches to multi-domain semantics might be to rely either on backwards-compatible techniques or on standardised semantics. A semantic prefix domain may also span several physical networks and traverse multiple service provider networks. However, when an interim network is traversed (such as when an intermediary network is used for interconnectivity) the relevance of the semantics is limited to network domains that share a common semantic policy, and tunneling may be needed to traverse transit domains. 5. Existing Approaches to Traffic Differentiation Within the IETF, several existing approaches have been developed to allow service providers to identify and mark IP traffic to enable differentiated policy-based handling of the traffic by transit routers (queuing, dropping, forwarding, etc.). 5.1. Deep Packet Inspection Deep Packet Inspection (DPI) may be used by a router to learn the characteristics of packets and so handle them differently. This involves looking into the packet beyond the top-level network-layer header to identify the payload. Once identified, the traffic type can be used as an input for marking the packets for network handling, or for performing specific policies on the packets. King, et al. Expires August 15, 2021 [Page 10] Internet-Draft Routing Challenges February 2021 However, DPI may be expensive both in processing costs and latency. The processing costs means that dedicated infrastructure is necessary to carry out the function and this may have an associated financial cost. The latency incurred may be too much for use with any delay/ jitter sensitive applications. As a result, DPI is difficult for large-scale deployment and its usage is often limited to specific functions at the edge of the network. 5.2. Differentiated Services Quality of Service (QoS) based on and Differentiated Services [RFC2474] is a widely deployed framework specifying a simple and scalable coarse-grained mechanism for classifying and managing network traffic. However, in a service providers network, DiffServ codepoint (DSCP) values cannot be trusted when they are set by the customer, and may have different meanings as packets are passed between networks. In real-world scenarios, Service Providers deploy "remarking" points at the edges of their network, re-classifying received packets by rewriting the DSCP field according to local policy using information such as the source/destination address, IP protocol number, transport layer source/destination ports, and possibly applying DPI as described in Section 5.1. The traffic classification process and node-by-node processing leads to increased packet processing overhead and complexity at the edge of the Service Providers network. 5.3. Segment Routing Segment Routing (SR) [RFC8402] leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain. In SR for IPv6 networks (SRv6) segment routing functions are used to achieve a networking objective that goes beyond packet routing, in order to provide "network programming" [I-D.ietf-spring-srv6-network-programming]. The network program is expressed as a list of instructions, which are represented as 128-bit segments, called Segment Identifiers (SID) - encoded and presented in the form of an IPv6 address. The first instruction of the network program is placed in the Destination Address field of the packet. If King, et al. Expires August 15, 2021 [Page 11] Internet-Draft Routing Challenges February 2021 the network program requires more than one instruction, the remaining list of instructions is placed in the Segment Routing Extension Header (SRH)[RFC8754]. An SRv6 instruction can represent any topological or service-based instruction. The SRv6 domain is the service provider domain where SRv6 services are built to transport any kind of customer traffic including IPv4, IPv6, or frames. SRv6 is the instantiation of Segment Routing deployed on the IPv6 data plane. Therefore, in order to support SRv6, the network must first be enabled for IPv6. For nodes forwarding traffic, the SRH in the IPv6 header is only processed if the destination address identifies the local node. In this case, the node must take several actions, including reading the SRH, performing any node-specific actions identified by the destination address or the next SIDs in the SRH, and re-writing the IPv6 destination address field using information from the SRH before forwarding the packet. 5.4. Information-Centric Networking Information-Centric Networking (ICN) [ICNref] is an approach to evolve the Internet infrastructure away from a host-centric paradigm, based on perpetual connectivity and the end-to-end principle, to a network architecture in which the focal point is information (or content or data) that is assigned specific identifiers. Several scenarios exist for semantic-based networking, providing reachability based on Content Routing [CONTENTref] and Name Data Networking [NDNref]. The technology area of ICN is now reaching maturity, after many years of research and commercial investigation. A technical discussion into the deployment and operation of ICNs continues in the IETF: [RFC8763] provides several important deployment considerations for facilitating ICN and practical deployments. More recently the concept of Hybrid-Information-Centric Networking (hICN) has been introduced [HICNref]. In an hICN environment the ICN aspect is integrated into the IPv6 architecture, reusing existing IPv6 packet formats with the intention of maintaining compatibility with existing and deployed IP network technology without creating overlays that might require a new packet format or additional encapsulations. The work is described in [I-D.muscariello-intarea-hicn]. This document does not promote or endorse specific ICN solutions: we focus on the potential routing challenges faced by these types of new networks, and highlight key areas of research interest. King, et al. Expires August 15, 2021 [Page 12] Internet-Draft Routing Challenges February 2021 5.5. Locator/ID Separation Protocol (LISP) The Locator/ID Separation Protocol (LISP) [RFC6830] was published by the IETF as an Experimental RFC in 2013 and is now being moved to the Standards Track [I-D.ietf-lisp-6834bis]. LISP separates IP addresses into two numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). IP packets addressed with EIDs are encapsulated with RLOCs for routing and forwarding in the network. LISP divides the address space into local edge networks and inter- domain routers. Routers from edge ASes have interfaces that are configured with RLOCs. Stations, on the other hand, are assigned an EID, with a scope limited to their access networks. As end-to-end packet forwarding includes both EIDs and RLOCs, a mapping system is required. Multihoming becomes easier because one EID can be associated to more than one RLOC or even to a local network address prefix. 5.6. Identifier-Locator Network Protocol The Identifier-Locator Network Protocol (ILNP) [RFC6740] is an experimental network protocol designed to separate the two functions of network addresses: identification of network endpoints, topology or location information. Upon reaching the destination network, a cache is used to find the corresponding node. Furthermore, DNS can be dynamically updated, which is essential for mobility and also for provider-independent addresses. Similar to LISP, multihoming can be set by assigning multiple locators to the same identifier. In addition, identifiers can also be encrypted for privacy reasons. It was intended that ILNP should be backwards-compatible with existing IP, and is incrementally-deployable. 5.7. Application-Layer Traffic Optimization Application-Layer Traffic Optimization (ALTO) [RFC7285] is an architecture and protocol. ALTO defines abstractions and services to provide simplified network views and network services to guide the application usage of network resources, including cost. An ALTO server gathers information about the network and answers queries from an ALTO client that wants to find a suitable path for traffic. ALTO responses are typically used to route whole flows (not individual packets) either to suitable destinations (such as network functions) or onto paths that have specific qualities. King, et al. Expires August 15, 2021 [Page 13] Internet-Draft Routing Challenges February 2021 5.8. Multipath TCP Multipath TCP (MPTCP) [RFC8684] enables the use of TCP in a multipath network using multiple host addresses. A Multipath TCP connection provides a bidirectional bytestream between two hosts communicating like normal TCP and thus does not require any change to the applications. However, Multipath TCP enables the hosts to use different paths with different IP addresses to exchange packets belonging to the MPTCP connection. MPTCP it increases the available bandwidth, and so provides shorter delays; it increases fault tolerance, by allowing the use of other routes when one or more routes become unavailable; and it enables traffic engineering and load balancing. 5.9. Path Computation Element The Path Computation Element (PCE) [RFC4655] is an architecture and protocol [RFC5440] that can be used to assist with network path selection. A PCE is an entity capable of computing paths for a single or set of services. A PCE might be a network node, network management station, or dedicated computational platform that is resource-aware and has the ability to consider multiple constraints for sophisticated path computation. PCE applications compute label switched paths for MPLS and GMPLS traffic engineering, but the PCE has been extended for a variety of additional traffic engineering problems. 5.10. Connectionless Network Protocol The Connectionless Network Service (CLNP) [CLNPref] is a network layer encoding that supports variable length, hierarchical addressing. It is widely deployed in many communications networks and is the ITU-T's standardised encoding for packets in the management plane for Synchronous Digital Hierarchy (SDH) networks. For a while, CLNP was considered in competition with IP as the network layer encoding for the Internet, but IP (in conjunction with TCP) won out. Many of the considerations for semantic addressing can be handled using CLNP, and it is particularly well suited to applications that demand variable length addresses or that structure addresses hierarchically for routing or geo-political reasons. Routing for CLNP can be achieved using the IS-IS routing protocol in its full form as documented in [ISISref] rather than its IP-only form [RFC1195]. While this may make it possible to use CLNP alongside IP in some routed networks, it does not integrate the use of IP King, et al. Expires August 15, 2021 [Page 14] Internet-Draft Routing Challenges February 2021 addresses with additional semantics with the historic use of IP addresses except in "ships that pass in the night" fashion. Alternatively, [RFC1069] explains how to carry regular IP addresses in CLNP. 6. Overview of Current Routing Research Work Several recent techniques for improving Internet routing have been proposed, some of these are highlighted below. 6.1. Clean Slate Approaches Incremental updates to the current Internet is seen as suboptimal and an undesirable long-term solution. A clean slate redesign of inter- domain routing would provide many benefits and could reuse existing legacy routing protocols for intra-domain communication. The following subsections outline current proposals for clean slate inter-domain Internet routing. 6.1.1. Recursive InterNetwork Architecture Recursive Inter Network Architecture (RINA) [RINAref] builds upon the principle that applications communicate through Inter-process Communication (IPC) facilities. For an application to communicate through the distributed IPC facility, it only needs to know the name of the destination application and to use the IPC interface to request communication. By leveraging IPC concepts RINA allows two processes to communicate, IPC requires certain functions such as locating processes, determining permission, passing information, scheduling, and managing memory. Similarly, two applications on different end-hosts should communicate by utilizing the services of a distributed IPC facility (DIF). A DIF is an organizing structure, generally referred to as a "layer". The scope and functions provided by the different IPC facilities may vary given the different type of network and performance goals. Moreover, an IPC layer may recursively request services from other IPC layers. The idea of recursively using multiple inter-process communication services creates a multilayer structure repeated until an IPC facility can fit well for physical technologies, e.g., wired or wireless networks. King, et al. Expires August 15, 2021 [Page 15] Internet-Draft Routing Challenges February 2021 6.1.2. Scalability, Control, and Isolation on Next-Generation Networks The SCION (Scalability, Control, and Isolation on Next-Generation Networks) [SCIONref] inter-domain network architecture has been designed to address security and scalability issues and provides an alternative current Border Gateway Protocol (BGP) solutions. The SCION proposal combines a globally distributed public key infrastructure, a way to efficiently derive symmetric keys between any network entities, and the forwarding approach of packet-carried forwarding state. SCION End-hosts fetch viable path segments from the path server infrastructure, and construct the exact forwarding route themselves by combining those path segments. The architecture ensures that a variety of combinations among the path segments are feasible, while cryptographic protections prevent unauthorized combinations or path- segment alteration. The architecture further enables path validation, providing per-packet verifiable guarantees on the path traversed. 6.1.3. Expedited Internet Bypass Protocol The Expedited Internet Bypass Protocol (EIBP) [EIBPref] is a clean slate approach to routing and forwarding in the Internet using the Internet infrastructure, but bypassing the Internet Protocol (IP). The EIBP method may be deployed in current routers and when invoked for a specific end to end IP hosts or networks, EIBP bypasses the heavy traffic and security challenges faced at Layer-3. EIBP does not require routing protocols, instead it abstracts network structural (physical or logical) information into intelligent forwarding addresses that are acquired by EIBP routers automatically. The Forwarding tables used by EIBP are proportional to the connectivity (degree) at a routing device making the protocol scalable. The EIBP routing system does not require network-wide dissemination. Topology change impacts are local and thus instabilities on topology changes are minimal. EIBP is a low configuration protocol, which can be deployed in an AS and extended to multiple ASes independently. EIBP evaluations were conducted using GENI testbeds and compared to IP using Open Shortest Path First and Border Gateway Protocol. Significant performance improvements in terms of convergence and churn rates highlight the capabilities of EIBP. King, et al. Expires August 15, 2021 [Page 16] Internet-Draft Routing Challenges February 2021 6.2. Hybrid Approaches Some research work is engaged in examining the emerging set of new requirements that exceed the network and transport services of the current Internet, which only delivers "best effort" service. This work aims to determine what features can be built on top of existing solutions by adding additional new components or features. A starting point for this discussion can be found in [I-D.bryant-arch-fwd-layer-ps]. 6.3. Approaches that Modify Existing Routing Protocols Some routing solutions to support semantic addressing may be possible by applying small changes to existing routing protocols. These modifications may be: o Backward compatible with the pre-existing protocol enabling insertion into existing networks. o Compatible with forwarding existing IP packets enabling support of legacy traffic. o Applicable only to deployment within a limited domain (Section 4.1). 6.4. No Changes Needed It is entirely possible that some forms of modified address semantic will work perfectly well with existing routing protocols and mechanisms either across the whole Internet or within limited and carefully controlled domains. Claims for this sort of functionality need to be the subject of careful research and analysis as the existing protocols were developed with a different view of the meaning of IP addresses, and because routing systems are notoriously fragile. 7. Challenges for Internet Routing Research The techniques and architectures discussed in this document have established very different strategies for semantic routing, and the evolution of the Internet. The first being with incremental updates and deployment, the second is based on clean slate proposals. If applied to the Internet as a whole, the later strategy faces the considerable challenge of how to drastically change the Internet with minimal or no service disruption, while if applied to specific controlled domains it raises the question of how nodes in those domains can communicate across the Internet to nodes that are outside the domain. King, et al. Expires August 15, 2021 [Page 17] Internet-Draft Routing Challenges February 2021 It may not be possible to embrace all emerging scenarios outlined in this document with a single approach or solution. Requirements such as 5G mobility, near-space-networking, and networking for outer- space, may need to be handled using separate network technologies. Therefore, developing a new Internet architecture that is both economically feasible and which has the support of the networking equipment vendors, is a significant challenge in the immediate future of the Internet. Improving Internet capabilities and capacity to scale, and address a set of growing requirements presents significant research challenges, and will require contributions from the networking research community. 7.1. Routing Research Questions to be Addressed As research into the scenarios and possible uses of semantic addressing progresses, a number of questions need to be addressed in the scope of routing. These questions go beyond "Why do we need this function?" and "What could we achieve by carrying this additional semantic in an IP address?" The questions are also distinct from issues of how the additional semantics can be encoded within an IP address. All of those issues are, of course, important considerations in the debate about semantic addressing, but they form part of the essential groundwork of research into semantic addressing itself. This section sets out some of the concerns about how the routing system might be impacted by the use of semantic addressing. These questions need to be addressed in separate research work or folded into the discussion of each semantic addressing proposal. 1. What is the scope of the semantic address proposal? This question may answered as: * Global: It is intended to apply to all uses of IP addresses. * Backbone: It is intended to apply to Internet connectivity. * Overlay: It is to be used as an overlay network over previous uses of IP or other underlay technologies using tunneling. * Gateway: The semantic addressing will be used within a limited domain, and communications with the wider internet will be handled by a protocol or application gateway. * Domain: The use of the semantic addressing is entirely limited to within a domain or private network. King, et al. Expires August 15, 2021 [Page 18] Internet-Draft Routing Challenges February 2021 Underlying this issue is a broader question about the boundaries of the use of IP, and the limit of "the Internet". If a limited domain is used, is it a semantic prefix domain Section 4.1 where a part of the IP address space identifies the domain so that an address is routable to the domain but the additional semantics are used only within the domain, or is the address used exclusively within the domain so that the external impact of the routability of the address that carries additional semantics is not important? 2. What will be the impact on existing routing systems? What would happen if an address with additional semantics was released according to normal operations, accidentally, or maliciously? How would the existing routing systems react? For example: how are cryptographically generated addresses made routable; how are the semantic parts of an address distinguished from the routable parts; is there an impact on the size and maintenance of routing tables due to the addition of semantics to addresses? 3. What path characteristics are needed for the routed paths? Since one of the purposes of adding semantics to IP addresses is to cause special processing by routers, it is important to understand what behaviors are wanted. Such path characteristics include (but are not limited to): * Quality: expressed in terms of throughput, latency, jitter, drop precedence, etc. * Resilience: expressed in terms of survival of network failures and delivery guarantees. In these cases, how do the routing protocols utilise the address semantics to determine the desired characteristics? What additional information about the network does the protocol need to gather? What changes to the routing algorithm is needed to deliver packets according to the desired characteristics? 4. Can we solve these routing challenges with existing routing tools and methods? We can break this question into more detailed questions. * Is new hardware needed? Existing deployed hardware has certain assumptions about how forwarding is carried out based on IP addresses and routing tables. * Do we need new routing protocols? We might ask some subsidiary questions: King, et al. Expires August 15, 2021 [Page 19] Internet-Draft Routing Challenges February 2021 + Can we make do with existing protocols, possibly by tuning configuration parameters or using them out of the box? + Can we make simple backward-compatible modifications to existing protocols such that they work for today's IP addresses as well as enhanced-semantic addresses? + Do we need entirely new protocols or radically evolutions of existing protocols in order to deliver the functions that we need? + Should we focus on the benefits of optimized routing solutions, or should we attempt to generalize to enable wider applicability? Do we need new management tools and techniques? Management of the routing system (especially diagnostic management) is a crucial and often neglected part of the problem space. 5. What is the scalability impact for routing systems? Scalability can be measured as: * Routing table size. How many entries need to be maintained in the routing table? Some approaches to semantic addressing may be explicitly intended to address this problem. * Routing performance. Routing performance may be considered in terms of the volume of data that has to be exchanged both to establish and to maintain the routing tables at the participating routers. It may also be measured in terms of how much processing is required to derive new routes when there is a change in the network routing information. * Routing convergence is the time that it takes for a routing protocol to discover changes (especially faults) in the network, to distribute the information about any changes to the network, and to reach a stable state across the network such that packets are routed consistently. For all questions of routing scalability, research that presents real numbers based on credible example networks is highly desirable. 6. What aspects need to be standardised? It is really important to understand the necessity of standardisaation 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 standardisation would King, et al. Expires August 15, 2021 [Page 20] Internet-Draft Routing Challenges February 2021 be meaningless? Is the application so narrow (for example, in niche hardware environments) such that interoperability is best handled by agreements among small groups of vendors such as in industry consortia? 8. Security Considerations TBD This section should summarise the novel security issues raised for routing by semantic routing. It does not need to cover all other security considerations for semantic routing. 9. IANA Considerations This document makes no requests for IANA action. 10. Acknowledgements Thanks to Stewart Bryant for useful conversations. This work is partially supported by the European Commission under Horizon 2020 grant agreement no. 101015857 Secured autonomic traffic management for a Tera of SDN flows (Teraflow). 11. Contributors TBD 12. Informative References [BLIND-FORWARDINGref] Simsek, I., "On-Demand Blind Packet Forwarding", Paper 30th International Telecommunication Networks and Applications Conference (ITNAC), 2020, 2020, . [CLNPref] "Protocol for providing the connectionless-mode network service: Protocol specification - Part 1", standard ISO/IEC 8473-1:1998, 1998, . [CONTENT-RTG-MOBILEref] Liu, H. and W. He, "Rich Semantic Content-oriented Routing for mobile Ad Hoc Networks", Paper The International Conference on Information Networking (ICOIN2014), 2014, 2014, . King, et al. Expires August 15, 2021 [Page 21] Internet-Draft Routing Challenges February 2021 [CONTENTref] Choi, J., Han, J., and E. Cho, "A survey on content- oriented networking for efficient content delivery", Paper IEEE Communications Magazine, 49(3): 121-127, May 2011., 2011, . [EIBPref] Shenoy, N., "Can We Improve Internet Performance? An Expedited Internet Bypass Protocol", Presentation 28th IEEE International Conference on Network Protocols, 2020, . [GEO-IPref] Dasu, T., Kanza, Y., and D. Srivastava, "Geotagging IP Packets for Location-Aware Software-Defined Networking in the Presence of Virtual Network Functions", Paper 25th ACM SIGSPATIAL International Conference on Advances in Geographic Information Systems (ACM SIGSPATIAL 2017), 2017, . [HICNref] Carofiglio, G., Muscariello, L., Auge, J., Papalini, M., Sardara, M., and A. Compagno, "Enabling ICN in the Internet Protocol: Analysis and Evaluation of the Hybrid- ICN Architecture", Paper Proceedings of the 6th ACM Conference on Information-Centric Networking, 2019., 2019, . [I-D.bryant-arch-fwd-layer-ps] Bryant, S., Chunduri, U., Eckert, T., and A. Clemm, "Forwarding Layer Problem Statement", draft-bryant-arch- fwd-layer-ps-02 (work in progress), January 2021. [I-D.ietf-lisp-6834bis] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Map-Versioning", draft-ietf- lisp-6834bis-07 (work in progress), October 2020. [I-D.ietf-spring-srv6-network-programming] Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "SRv6 Network Programming", draft-ietf-spring-srv6-network-programming-28 (work in progress), December 2020. King, et al. Expires August 15, 2021 [Page 22] Internet-Draft Routing Challenges February 2021 [I-D.jia-scenarios-flexible-address-structure] Jia, Y., Li, G., and S. Jiang, "Scenarios for Flexible Address Structure", draft-jia-scenarios-flexible-address- structure-00 (work in progress), October 2020. [I-D.jiang-semantic-prefix] Jiang, S., Qiong, Q., Farrer, I., Bo, Y., and T. Yang, "Analysis of Semantic Embedded IPv6 Address Schemas", draft-jiang-semantic-prefix-06 (work in progress), July 2013. [I-D.muscariello-intarea-hicn] Muscariello, L., Carofiglio, G., Auge, J., Papalini, M., and M. Sardara, "Hybrid Information-Centric Networking", draft-muscariello-intarea-hicn-04 (work in progress), May 2020. [ICNref] Barbera, D., Xylomenos, G., Ververidis, C., Siris, V., and N. Fotiou, "A Survey of information-centric networking research", Paper IEEE Communications Surveys and Tutorials, vol. 16, Iss. 2, Q2 2014, 2014, . [IOTSURVEYref] Sheng, Z., Yang, S., Vasilakos, A., Mccann, J., and K. Leung, "A Survey on the IETF Protocol Suite for the Internet of Things: standards, challenges, and opportunities", Paper IEEE Wireless Communications, vol. 20, no. 6, Dec 2013, 2014, . [ISISref] "Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service", standard ISO/IEC 10589, 2002, . [ITUNET2030ref] "Network 2030 Architecture Framework", Technical Specification ITU-T Focus Group on Technologies for Network 2030, 2020, . King, et al. Expires August 15, 2021 [Page 23] Internet-Draft Routing Challenges February 2021 [MULTICAST-SRref] Jia, W. and W. He, "A Scalable Multicast Source Routing Architecture for Data Center Networks", Paper IEEE Journal on Selected Areas in Communications, vol. 32, no. 1, pp. 116-123, January 2014, 2014, . [NDNref] Zhang, L., Afanasyev, A., and J. Burke, "Named Data Networking", Paper ACM SIGCOMM Computer Communication, Review 44(3): 66-73, 2014, 2014. [OPENSRNref] Ren, P., Wang, X., Zhao, B., Wu, C., and H. Sun, "OpenSRN: A Software-defined Semantic Routing Network Architecture", Paper IEEE Conference on Computer Communications Workshops (INFOCOM WKSHPS), Hong Kong, 2015, 2015, . [PANRGref] "Path Aware Networking Research Group", RG Path Aware Networking Research Group, . [RESEARCHFIAref] Pan, J., Paul, S., and R. Jain, "A Survey of the Research on Future Internet Architectures", Paper IEEE Communications Magazine, vol. 49, no. 7, July 2011, 2014, . [RFC1069] Callon, R. and H. Braun, "Guidelines for the use of Internet-IP addresses in the ISO Connectionless-Mode Network Protocol", RFC 1069, DOI 10.17487/RFC1069, February 1989, . [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, DOI 10.17487/RFC1195, December 1990, . [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, . King, et al. Expires August 15, 2021 [Page 24] Internet-Draft Routing Challenges February 2021 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, . [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, . [RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report from the IAB Workshop on Routing and Addressing", RFC 4984, DOI 10.17487/RFC4984, September 2007, . [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, . [RFC6740] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network Protocol (ILNP) Architectural Description", RFC 6740, DOI 10.17487/RFC6740, November 2012, . [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013, . [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., Previdi, S., Roome, W., Shalunov, S., and R. Woundy, "Application-Layer Traffic Optimization (ALTO) Protocol", RFC 7285, DOI 10.17487/RFC7285, September 2014, . [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . [RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. Paasch, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March 2020, . King, et al. Expires August 15, 2021 [Page 25] Internet-Draft Routing Challenges February 2021 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, . [RFC8763] Rahman, A., Trossen, D., Kutscher, D., and R. Ravindran, "Deployment Considerations for Information-Centric Networking (ICN)", RFC 8763, DOI 10.17487/RFC8763, April 2020, . [RINAref] Day, J., "Patterns in Network Architecture: A Return to Fundamentals", Book Prentice Hall, 2008. [SCIONref] Barbera, D., Chaut, L., Perrig, A., Reischuk, R., and P. Szalachowski, "Patterns in Network Architecture: A Return to Fundamentals", Paper The ACM, vol. 60, no. 6, June 2017, 2017, . [SEMANTICRTG] Strassner, J., Sung-Su, K., and J. Won-Ki, "Semantic Routing for Improved Network Management in the Future Internet", Book Chapter Springer, Recent Trends in Wireless and Mobile Networks, 2010, 2010, . Authors' Addresses Daniel King Lancaster University Email: d.king@lancaster.ac.uk Joanna Dang Huawei Technologies Email: dangjuanna@huawei.com Adrian Farrel Old Dog Consulting Email: adrian@olddog.co.uk King, et al. Expires August 15, 2021 [Page 26]