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

Internet-Draft	Routing Challenges	May 2021
King, et al.	Expires 7 November 2021	[Page]

Abstract

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

Many proposals have been made to add semantics to IP addresses. The intent is usually to facilitate routing decisions based solely on the address and without the need to find and process information carried in other fields within the packets.¶

This document describes the challenges to the existing routing system that are introduced by the addition of semantics to IP addresses. It then summarizes the opportunities for research into new or modified routing protocols to make use of new address semantics.¶

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

1. Introduction

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

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

There are many approaches to Semantic Addressing. These range from assigning a prefix to have a special purpose and meaning (such as is done for multicast addressing) through allowing the owner of a prefix to use the low-order bits of an address for their own purposes. Some Semantic Adressing proposals suggest variable address lengths, others offer hierarchical addresses, and some introduce a structure to addresses so that they can carry additional information in a common way.¶

A survey of ways in which routing decisions have been made based on additional information carried in packets, and a catalogue of proposals for Semantic Addressing can be found in [I-D.king-irtf-semantic-routing-survey].¶

Some Semantic Addressing proposals are intended to be deployed in limited domains [RFC8799] (networks) that are IP-based, while other proposals are intended for use across the Internet. The impact the proposals have on routing systems may require clean-slate solutions, hybrid solutions, extensions to existing routing protocols, or potentially no changes at all.¶

This document describes some of the key challenges to routing that are present in today's IP networks. It then defines the concept of "Semantic Routing" and presents some of the challenges to the existing routing system that Semantic Addressing may present. Finally, this document presents a list of releated research questions that offer opportunities for future research into new or modified routing protocols that make use of Semantic Addressing.¶

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

This document draws on surveys and analysis performed in "Survey of Semantic Internet Routing Techniques" [I-D.king-irtf-semantic-routing-survey].¶

2. Current Challenges to IP Routing

Today's IP routing faces several significant challenges which are a consequence of the architectural design decisions and exponential growth. These challenges include mobility, multihoming, programmable paths, scalability and security, and were not the focus of the original design of the Internet. Nevertheless, IP-based networks have, in general, coped well in an incremental manner as each new challenge has evolved. This list is presented to give context to the continuing requirements that routing protocols must meet as new semantics are applied to IP addresses.¶

Mobility - Mobility introduces several challenges, including maintaining a relationship between a sender and a receiver in cases where sender and/or receiver changes their point of network attachment. The original network must always be informed about the mobile node's current location, to allow continuity of services. Mobility users may also consume resources, while physical moving. The mobile user service instances and attachments will also change due to varying load or latency, e.g., in Multi-access Edge Computing (MEC) scenarios.¶
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 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. Current, IP-based networks topologies facilitate 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 an IP-based network. 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. (Note that this discussion is distinct from Equal Cost Multi-path (ECMP) where packets are directed onto two "parallel" paths of identical least cost using a hash algorithm operated on some of the packets' header fields.)¶
Multicast - Delivering the same packet to multiple destinations can place considerable load on a network. Solutions that replicate the packet at the source or at the network edge may obviously see multiple copies of the packet flowing along the same network links. A number of solutions have been tried over the years to move replication into the network to make more optimal use of the network resources, but these approaches are complex to set up and manage requiring sophisticated protocols that can determine the best multicast delivery topologies, as well as hardware that can replicate packets. In order that packets can be addressed to a group of destinations and not be routed using the normal unicast approcaches, parts of the addressing space (that is, address prefixes) have been reserved to indicate multicast.¶
Programmable Paths - The ability to decouple IP-based network paths from routing protocols and agreements between Service Providers, would allow users and applications to configure and select network 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.¶
End-Point Selection - As compute resources and content storage moves closer to the edge of the network, there are often multiple points in the network that can satisfy user requests. In order to make best use of these distributed services and so to not overload parts of the network, user traffic needs to be steered to appropriate servers or data centres. In many cases, this function may be achieved in the application layer (such as through DNS) or in the transport layer (such as using ALTO). The challenge is to balance higher-layer decisions about which application layer resources to use with information from the lower layers about the availability and load of network resources.¶
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 an IP-based network must maintain and exchange with their peers. As the number of devices attached to the network 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 there applicability of certain routing protocols. It may be noted that scaling issues are exacerbated by multihoming practices if a host that is multihomed is allocated a different address for each point of attachment.¶
Security - Issues of security and privacy have been largely overlooked within the routing systems. However, there is increasing concern that attacks on routing systems can not only be disruptive (for example, causing traffic to be dropped), but may cause traffic to be routed via inspection points that can breach the security or privacy of the payloads.¶

Some of the challenges outlined here were previously considered within the IETF by the IABs "Routing and Addressing Workshop" held in Amsterdam, The Netherlands on October 18-19, 2006 [RFC4984]. Several architectures and protocols have since been developed and worked on within and outside the IETF, and these are examined in [I-D.king-irtf-semantic-routing-survey].¶

3. What is Semantic Routing?

Typically, in an IP-based network packets are forwarded using the least cost path to the destination IP address. Service Providers may also use techniques to modify the default forwarding behavior based on other information present in the packet and configured or programmed into the routers. These mechansims, sometimes called semantic routing techniques include "Preferential Routing", "Policy-based Routing", and "Flow steering".¶

Examples of semantic routing usuage for IP-based networks include the following:¶

Using addresses to identify different device types so that their traffic may be handled differently [SEMANTICRTG].¶
Expressing how a packet should be handled, prioritized, or allocated network resources as it is forwarded through the network [TERASTREAMref].¶
Deriving IP addresses from the physical layer identifiers and using addresses depending on the underlying connectivity.¶
Indicating the application or network function on a destination device or at a specific location; or enable Service Function Chaining (SFC).¶
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].¶
Enabling optimized multicast traffic distribution by encoding multicast tree and replication instructions within addresses [MULTICAST-SRref].¶
Content-based routing (CBR), forwarding of the packet based on message content rather than the destination addresses [OPENSRNref].¶
Identifying hierarchical connectivity so that routing can be simplified [EIBPref].¶
Providing geographic location information within addresses [GEO-IPref].¶
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].¶

A detailed description of IP-based semantic routing, and a survey of semantic routing proposals research projects can be found in [I-D.king-irtf-semantic-routing-survey].¶

Several technical challenges exist for semantic routing in IP-based network. These include:¶

Address consumption caused by lower address utility rate. The wastage mainly comes from aligning finite allocation for semantic address blocks.¶
Encoding too many semantics into prefixes will require evaluation of which to prioritize.¶
Risk of privacy/information leakage.¶
Burdening the user, application, or prefix assignment node.¶
Source address spoofing preventing mechanisms may be required.¶
Overloading of routing protocols causing stability and scaling problems.¶
Depending on encoding mechansims, there may be challenges for data planes to scale the processes of finding, reading, and looking up semantic data in order to forward packets at line speed.¶
Backwards compatibility with existing IP-based networking.¶

3.1. Architectural Considerations

Semantic data may be applied in a number of ways to integrate with existing routing architectures. The most obvious is to build an overlay such that IP is used only to route packets between network nodes that utilize the semantics at a higher layer. There are a number of existing uses of this approach including Service Function Chaining (SFC) [RFC7665] and Information Centric Networking (ICN) [RFC8763]. An overlay may be achieved in a higher protocol layer, or may be performed using tunneling techniques (such as IP-in-IP) to traverse the areas of the IP network that cannot parse additional semantics thereby joining together those nodes that use the semantic data.¶

The application of semantics may also be constrained to within a limited domain. In some cases, such a domain will use IP, but be disconnected from Internet (see Section 3.1.1). In other cases, traffic from within the domain is exchanged with other domains that are connected together across an IP-based network using tunnels or via application gateways (see Section 3.1.2). And in still another case traffic from the domain is routed across the Internet to other nodes and this requires backward-compatible routing approaches (see Section 3.1.3).¶

3.1.1. Isolated Domains

Some IP network domains are entirely isolated from the Internet and other IP-based networks. In these cases, there is no risk to external networks from any semantic addressing or routing schemes carried out within the domain. Thus, the challenges are limited to enabling the desired function within the domain.¶

All of the challenges could exist even in a limited domain, but the impact may be significantly reduced both because of the limited size of the domain, and because there is no need to interact with native IP routers.¶

Many approaches in isolated domains will utilize environment-specific routing protocols. For example, those suited to constrained environments (for IoT) or mobile environments (for smart vehicles). Such routing protocols can be optimized for the exchange of information specific to semantic routing.¶

3.1.2. Bridged Domains

In some deployments, it will be desireable to connect together a number of isolated domains to build a larger network. These domains may be connected (or bridged) over an IP network or even over the Internet.¶

Ideally, the function of the bridged domains should not be impeded by how they are connected, and the operation of the IP network providing the connectivity should not be compromised by the act of carrying traffic between the domains. This can generally be achieved by tunneling the packets between domains using any tunneling technique, and this will not require the IP network to know about the semantic routing used by the domains. The challenges in this scenario are very similar to those for Section 3.1.1 except that the network created from the set of domains may be larger, and some routing mechanism must be applied to know in wich remote domain a destination is situated.¶

An alternative to tunneling is achieved using gateway functionality where packets from a domain are mapped at the domain boundary to produce regular IP packets that are sent across the IP network to the boundary of the destination domain where they are mapped back into packets for use within that domain. Such an approach presents additional challenges especially at the boundary of the destination domain where some mechanism must enable the mapping back into semantic-enabled packets.¶

3.1.3. 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. This is achieved by assigning a routable address prefix (or a set of prefixes) for use with semantic addressing and routing so that packets may be routed through the regular IP network (or the Internet) using the prefix and without encountering or having to use any semantic addressing. Once delivered to the semantic prefix domain, a packet can be subjected to whatever semantic routing is enabled in the domain.¶

Examples of semantic prefix domains include:¶

Administrative domains¶
Applications¶
Autonomous systems¶
Hosts¶
Network types¶
Routers¶
Trust regions¶
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.¶

Examples of prefix-partitioned semantic addressesing that already exist include:¶

Documentation addresses¶
Loopback addresses¶
Multicast address space¶
Private use addresses¶
IPv4-IPv6 encoding¶
Routers¶
Trust regions¶
User groups¶

4. Challenges for Internet Routing Research

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 IP-based network capabilities and capacity to scale, and address a set of growing requirements presents significant research challenges, and will require contributions from the networking research community.¶

4.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.¶

What is the scope of the semantic address proposal? This question may be answered as:¶
- Global: It is intended to apply to all uses of IP addresses.¶
- Backbone: It is intended to apply to IP-based network 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.¶
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 [RFC8799] where a part of the IP address space identifies the domain so that an address is routable to the domain but the additional semantics are used only within the domain, or is the address used exclusively within the domain so that the external impact of the routability of the address that carries additional semantics is not important?¶
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?¶
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;¶
- Destination: How is a destination address to be interpreted if it encodes a choice of actual destinations?¶
In these cases, how do the routing protocols utilize 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?¶
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:¶
  - 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.¶
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.¶
To what extent can multicast be developed:¶
- To support programmable SDN systems such as P4 [BIER-P4]?¶
- To satisfy end-to-end applications?¶
- To apply per-packet multicasting to develop new services?¶
- As a separate network layer distinct from IP or by encoding group destinations into IP addresses?¶
What aspects need to be standardised? It is really important to understand the necessity of standardization within this research. What degree of interoperability is expected between devices and networks? Is the limited domain so constrained (for example, to a single equipment vendor) that standardization would be meaningless? Is the application so narrow (for example, in niche hardware environments) such that interoperability is best handled by agreements among small groups of vendors such as in industry consortia?¶

9. Informative References

[BIER-P4]: Merling, D., Lindner, S., and M. Menth, "Hardware Based Evaluation of Scalable and Resilient Multicast with BIER in P4", Presentation IETF-108 BIER Working Group Online Meeting, 2020, <https://datatracker.ietf.org/meeting/108/materials/slides-108-bier-05-bier-in-p4-00>.
[BLIND-FORWARDINGref]: Simsek, I., "On-Demand Blind Packet Forwarding", Paper 30th International Telecommunication Networks and Applications Conference (ITNAC), 2020, 2020, <https://www.computer.org/csdl/proceedings-article/itnac/2020/09315187/1qmfFPPggrC>.
[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, <https://ieeexplore.ieee.org/document/6799682>.
[EIBPref]: Shenoy, N., "Can We Improve Internet Performance? An Expedited Internet Bypass Protocol", Presentation 28th IEEE International Conference on Network Protocols, 2020, <https://icnp20.cs.ucr.edu/Slides/NIPAA/D-3_invited.pptx>.
[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, <https://about.att.com/ecms/dam/sites/labs_research/content/publications/AI_Geotagging_IP_Packets_for_Location.pdf>.
[I-D.jiang-semantic-prefix]: Jiang, S., Sun, Q., Farrer, I., Bo, Y., and T. Yang, "Analysis of Semantic Embedded IPv6 Address Schemas", Work in Progress, Internet-Draft, draft-jiang-semantic-prefix-06, 15 July 2013, <https://www.ietf.org/archive/id/draft-jiang-semantic-prefix-06.txt>.
[I-D.king-irtf-semantic-routing-survey]: Farrel, A., King, D., and J. Dang, "A Survey of Semantic Internet Routing Techniques", Work in Progress, Internet-Draft, draft-king-irtf-semantic-routing-survey-00, March 2021, <https://tools.ietf.org/html/draft-king-irtf-semantic-routing-survey-00>.
[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, <https://ieeexplore.ieee.org/document/6799682>.
[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, <https://www.researchgate.net/publication/308827498_OpenSRN_A_software-defined_semantic_routing_network_architecture>.
[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, <https://www.rfc-editor.org/info/rfc4984>.
[RFC7665]: Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, <https://www.rfc-editor.org/info/rfc7665>.
[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, <https://www.rfc-editor.org/info/rfc8763>.
[RFC8799]: Carpenter, B. and B. Liu, "Limited Domains and Internet Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, <https://www.rfc-editor.org/info/rfc8799>.
[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, <https://link.springer.com/chapter/10.1007/978-3-642-14171-3_14>.
[TERASTREAMref]: Zaluski, B., Rajtar, B., Habjani, H., Baranek, M., Slibar, N., Petracic, R., and T. Sukser, "Terastream implementation of all IP new architecture", Paper 36th International Convention on Information and Communication Technology, Electronics and Microelectronics (MIPRO), 2013, 2013, <https://ieeexplore.ieee.org/document/6596297>.

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

Abstract

Status of This Memo

Copyright Notice

Table of Contents

1. Introduction

2. Current Challenges to IP Routing

3. What is Semantic Routing?

3.1. Architectural Considerations

3.1.1. Isolated Domains

3.1.2. Bridged Domains

3.1.3. Semantic Prefix Domains

4. Challenges for Internet Routing Research

4.1. Routing Research Questions to be Addressed

5. Security Considerations

6. IANA Considerations

7. Acknowledgements

8. Contributors

9. Informative References

Authors' Addresses