Skip to main content

Challenges for the Internet Routing Infrastructure Introduced by Changes in Address Semantics

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Daniel King , Joanna Dang , Adrian Farrel
Last updated 2021-02-11
Replaced by draft-king-rtgwg-challenges-in-routing
RFC stream (None)
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
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


   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

   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
   ( 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

      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

      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

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

   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

   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

   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

   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

   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

   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

   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

   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

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

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

   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

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

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

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

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

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

   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

       *  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

   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


   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


12.  Informative References

              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,

              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

              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,

              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,

              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.

              Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
              Separation Protocol (LISP) Map-Versioning", draft-ietf-
              lisp-6834bis-07 (work in progress), October 2020.

              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

              Jia, Y., Li, G., and S. Jiang, "Scenarios for Flexible
              Address Structure", draft-jia-scenarios-flexible-address-
              structure-00 (work in progress), October 2020.

              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

              Muscariello, L., Carofiglio, G., Auge, J., Papalini, M.,
              and M. Sardara, "Hybrid Information-Centric Networking",
              draft-muscariello-intarea-hicn-04 (work in progress), May

   [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,

              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, <

              "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

              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.

              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,

              "Path Aware Networking Research Group", RG Path Aware
              Networking Research Group,

              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.

              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,

              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


   Joanna Dang
   Huawei Technologies


   Adrian Farrel
   Old Dog Consulting


King, et al.             Expires August 15, 2021               [Page 26]