| Internet-Draft | Semantic Networking | May 2023 |
| Farrel & King | Expires 6 November 2023 | [Page] |
Many proposals have been made to add semantics to IP packets by placing additional information in existing fields, by adding semantics to IP addresses themselves, or by adding fields. The intent is to facilitate enhanced routing/forwarding decisions based on these additional semantics to provide differentiated forwarding paths for different packet flows distinct from simple shortest path first routing. The process is defined as Semantic Networking.¶
This document provides a brief introduction to Semantic Networking.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 6 November 2023.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Historically, the meaning of an IP address has been to identify an interface on a network device or a network to which a host is attached [RFC0814]. Network routing protocols were initially designed to determine paths through a network toward destination addresses so that IP packets with a common destination address converged on that destination. Anycast and multicast addresses were also defined (e.g., Section 2.6.1 of [RFC4291]), and some of these new address semantics necessitated variations to the routing protocols (e.g., [RFC6992]), and in some cases the development of new routing protocols (e.g., Protocol Independent Multicast - Sparse Mode [RFC7761]).¶
Over time, routing decisions were enhanced to route packets according to additional information carried within the packets and dependent on policy coded in, configured at, or signaled to the routers. Perhaps the most obvious example is Equal-Cost Multipath (ECMP) where a router makes a consistent choice for forwarding packets over a number of parallel links or paths based on the values of a set of fields in the packet header. Another example is Constraint-based Shortest Path First (CSPF) where additional constraints are considered when performing route computation and selection.¶
Upper-layer applications are placing increasingly sophisticated demands on the network for better quality, more predictability, and increased reliability. Some of these applications are futuristic predictions (for example, haptic augmented reality multiplayer 3D worlds), some are new ideas on the threshold of roll-out (such as holographic conferencing), and many are rapidly developing sectors with established revenue streams (such as multiplayer immersive gaming).¶
At the same time, lower-layer network technologies are advancing rapidly providing increased bandwidth to the home and to mobile hand-held devices. These advances create an environment that enables the potential of advanced applications being run by very many end-users. This coincides with a massive growth in end-to-end communications that include machines and services, and to introduce routing and addressing behaviors to a particular use case and set of requirements applied within a limited region or domain of the Internet. Examples of these three developments include 5G, predicted wireless evolutions, IoT and vehicular connectivity, space-terrestrial communication, industrial networks, cloud computing, service function chaining and network functions virtualization, digital twins, and data-centric data brokerage platforms.¶
Despite this plurality of communication scenarios, IP-based addressing and network layer routing have remained focused on identifying locations of communication (i.e., "where") and determining paths between those locations with or without specific constraints (i.e., "how-to-get-there" as per [IEN23]). This has previously depended on higher-layer capabilities (e.g., for name-to-location resolution) to support some of these communication scenarios, but that approach introduces latency and dependencies (e.g., changing locator assignments may depend on the capabilities of the upper-layer capability that are outside the core addressing and routing system). Furthermore, multi-layer lookups and interactions may impact the efficacy of some of the communication scenarios mentioned here, particularly those that employ different routing and addressing approaches beyond just locators.¶
"Semantic Networking" places the support for advanced routing, forwarding, and location functions directly at the packet routing/forwarding layer, such as through extensions to the identification properties of addresses (so that the address indicates more than just the network location) or through performing routing functions on an extended set of inputs (for example, other fields carried in packet headers). Such an approach should preserve the Internet architecture as it is today while enabling additional routing function.¶
This document provides a brief introduction to Semantic Networking and outlines the possible approaches that might be taken. A separate document ([I-D.king-irtf-semantic-routing-survey]) makes a start at a survey of pre-existing work in this area, while [I-D.king-rtgwg-challenges-in-routing] sets out some of the issues that should be considered when researching, developing, or proposing a routing scheme for Semantic Networking.¶
As with all advances in Internet protocols, Semantic Networking may be considered for Internet-wide deployment or may be restricted (possibly only initially) to well-defined and contained networks referred to as "limited domains" (see [RFC8799]). The information used for Semantic Networking may be opaque within the network (in other words, the additional information is not required to be parsed by the routers and might not even be visible to them), may be transparent (so that routers may see the information, but their processing does not need to be changed to accommodate the information or its encoding), or may be active (so that Semantic Networking is fully enabled).¶
When building an end-to-end path across multiple domains, Semantic Networking may select a path in one domain that is not consistent with the paths selected in other domains in terms of constructing the "best" end-to-end path. That is, the Semantic Networking decisions within a domain are potentially isolated from knowledge about the other domains.¶
In any case, concern and consideration must be coexistence with, and backward compatibility to, existing routing and addressing schemes that are widely deployed.¶
Further understanding of the scope of Semantic Networking applied to the routing of packets at the network layer may be gained by reading Section 6 to see how various other concepts of routing are out of scope of this work.¶
A strategic objective of Semantic Networking, and associated semantic enhancements, is to enable Service Providers to modify the default forwarding behaviour to be based on other information present in the packet and policy configured or dynamically programmed into the routers and devices. This is aimed to cause new and alternative path processing by routers, including:¶
Efficiency of manageability in terms of:¶
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 (e.g., BGP hijack attacks). While Semantic Networking might offer tools for increasing security and privacy, it is possible that Semantic Networking and the additional information that may be carried in packets to enable Semantic Networking may provide vectors for attacks or compromise privacy. This must be examined by any Semantic Networking proposals. For example, means to control entities that are entitled to access supplied Semantic Networking information should be considered.¶
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 mechanisms, sometimes called Semantic Networking techniques include "Preferential Routing", "Policy-based Routing", and "Flow Steering".¶
Examples of existing Semantic Networking usage in IP-based networks include the following.¶
A more comprehensive list of existing implementations and research projects can be found in [I-D.king-irtf-semantic-routing-survey].¶
Semantic Networking, operates to forward packets dependent on information carried in the packets and rules present in the routers. Those rules could be any combination of:¶
Semantic Networking will also require information about network state and capabilities just as existing shortest path first routing systems do. That may require information (such as link delays or other qualitative attributes) to be collected by network nodes and distributed between routers by routing protocols. Alternatively, this information could be collected (centrally) by a set of network controllers and used to derive the rules installed in the routers.¶
Forwarding by a router is based on a look-up that also considers the Semantic Networking information carried in the packet (see Section 4) and forwarding instructions programmed into the forwarding element. Some Semantic Networking proposals may generate the semantic information (e.g., a hash) rather than using information that is directly extracted from the packet. The actions to perform may be derived by the router based on the rules and information that the router has collected, or may be programmed directly from the network controller.¶
Routing is the process of selecting a path for traffic in a network or between or across multiple networks. For example, IP routing uses IP addresses for source and destination identification and is typically used for packet networks, such as the Internet. IP routing assumes that network addresses are structured and facilitates routing entries in a routing table entry to represent a group of IP-capable devices.¶
While service routing and information-centric networking (ICN) can operate directly on top of layer 2 protocols (for example, [RFC9139]), in the context of this document, we are concerned with the function of service routing and ICN in IP networks. Like any new spanning-layer style protocol, deployment considerations for ICN on the Internet make tunneling through IP a required part of any co- existence or transition. The approach taken in this case, is to create an overlay layer on top of the IP network. Control of the overlay necessitates augmentation of existing routing mechanisms, or entirely new discovery, propagation and resource management protocols and procedures.¶
By contrast, explicit service-based IP routing [I-D.jiang-service-oriented-ip] abstracts the service actions that the network can provide into a number of classes called Service Action Types (SATs). Each packet is marked with the relevant SAT, and the packets are routed to the next available SAT provider (not the destination IP address). In this approach, a distinct encapsulation is needed and may carry native IP packets as payload, while transition experiments may utilize an overlay on top of IP.¶
IP Routing and service routing are not the same thing.¶
The subsections below describe some of the common techniques to enable Semantic Networking in more detail. The sections are unordered and no meaning should be assigned to how one approach is presented before another. They are not a complete list of possible approaches.¶
The approaches described here have many advantages and disadvantages. The purpose here is not to determine which approach is best or most appropriate, and so those advantages and disadvantages are not discussed. The reader will inevitably have a preference and see drawbacks.¶
In some cases, an address prefix is assigned a special purpose and meaning. When such an address appears in the packet's address field, a router can know from the prefix that particular routing/forwarding actions are required. An example of this approach is seen in multicast addressing. Another example is the handling of anycast in IPv6 where the nodes to which the address is assigned must be explicitly configured to know that it is an anycast address [RFC4291].¶
The owner of a prefix to use the low-order bits of an address for their own purposes.¶
The semantics of such an approach might be coordinated between prefix owners, or could be indicated through information that is part of the encoding, and is standardized. An example of such approach is in IPv4/IPv6 Translators [RFC6052].¶
Semantic Addressing is a term applied to any approach that adds semantics to IP addresses. This includes the mechanisms described in Section 4.1 and Section 4.2. Other Semantic Addressing proposals suggest variable address lengths, hierarchical addresses, or a structure to addresses so that they can carry additional information in a common way.¶
In any case, Semantic Addressing that intends to facilitate routing decisions is based solely on the address and without the need to find and process information carried in other fields within the packets.¶
Note that not all Semantic Addressing schemes exist to facilitate routing (for example, content addressing where the interface ID of the address identifies a chunk of the content to be retrieved), but such schemes are naturally out of scope of this document.¶
Flow marking is a way of indicating, in a specific field in the packet header, the treatment that the packet should receive in the network. In IPv4 the six-bit DSCP field is commonly used for this purpose. In IPv6, while the Traffic Class field could be used, it is generally recommended that the Flow Label field should serve this and a more general purpose.¶
Routers may also examine fields in the packet other than those in the IP header. For example, many router processes may look at the "five-tuple" consisting of:¶
"Overloading" is a term applied to placing additional semantics on the contents of a field beyond how it is specified. This is relatively hard to do in an IPv6 header because the number of fields is small, and all fields have specific meanings that are needed in all cases. In IPv4 there may be more opportunity to use some fields in very controlled situations to carry additional semantics that can be used for Semantic Networking.¶
IPv6 defines extension headers explicitly for carrying information that may be used by routers along the path. This information can be used to instruct all routers, only the router indicated by the destination address, or by the ultimate destination of the packet.¶
Extension headers may carry any information to enable Semantic Networking.¶
Another approach is to define a new protocol extension to carry information on which Semantic Networking can be performed. Such an extension could be in the form of a new extension header (see Section 4.7) or as a new shim encapsulation (e.g., [RFC7665]).¶
Some Semantic Networking 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 that the proposals have on routing systems may require clean-slate solutions, hybrid solutions, extensions to existing routing protocols, or potentially no changes at all.¶
Semantic data may be applied in several 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. An overlay may be achieved in a higher protocol layer, or may be performed using tunneling techniques (such as IP-in-IP [RFC1853]) 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 5.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 5.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 5.3).¶
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 Networking schemes carried out within the domain.¶
Many approaches in isolated domains will utilize environment-specific routing protocols. For example, those suited to constrained environments (for IoT) or mobile environments (for autonomous vehicles). Such routing protocols can be optimized for the exchange of information specific to Semantic Networking. However, gateways to provide external connectivity are usually deployed in such networks. Appropriate means should be supported in these means to prevent leaking semantic information beyond the boundaries of these domains.¶
In some deployments, it will be desirable to connect 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 Networking used by the domains.¶
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.¶
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 Networking is enabled in the domain.¶
This section provides an overview of what is considered as "routing" in the scope of this document. There are many functions in the Internet that contain the concept of routing, but not all of them apply to the scope of this document which is concerned with routing packets at the network layer. A more thorough catalogue of approaches to routing and the applications of Semantic Networking can be found in [I-D.king-irtf-semantic-routing-survey].¶
Routing in the application layer concerns the choice of application-level components that are distributed across the network. The choice may be dependent on the services being delivered, knowledge about the locations in the network that can provide the services, knowledge of the network capabilities, and preferences expressed by an application or user. In this sense, the routing choice consists of constructing an "application layer path" and may be performed at the head end or along the path. Packets are carried between components across the underlying network, using normal transport and network layer protocols that may, themselves, involve routing. Thus, application layer routing is concerned with selecting a series of components based on the potential to carry traffic between them, but without concern for how the packets are routed within the network.¶
Application layer routing may be used in concepts such as Content Distribution Networking (CDN) and computation in the network (COIN) (see Section 6.9).¶
The ALTO architecture and protocol [RFC7285] is intended to allow the network to answer queries about the availability and characteristics of paths between application-level components to enable choices to be made by providers of function or content about which components to select. This is a server-based approach because it would be impractical to scale the network reporting all available paths to all destinations to every client, or for the network edge to be able to answer queries from their clients.¶
There is another high-level path selection scenario that is more concerned with selecting outbound paths from the source than in determining destinations or next application-layer hops (as described in Section 6.1. For example, consider a mobile phone that is connected to Wi-Fi and 5G. Further, consider that the Wi-Fi network is dual-homed to two different ISPs. This gives an application a choice of three different paths depending on the known (or advertised) capabilities of the networks.¶
This type of scenario is being examined by the Path Aware Networking Research Group (PANRG) where, rather than consulting a server to supply the most appropriate path, the source host or application should learn about the potential paths and pick between them.¶
Some transport layer load balancing schemes and proxy-based connection or discovery mechanisms use a mechanism that looks somewhat like routing, but exists in the transport layer. For example, section 2.1.1 of [RFC3135] describes how a transport layer Performance Enhancing Proxy (PEP) may use a concept called TCP spoofing to terminate a TCP connection and initiate a new connection to the next proxy on the transport layer path towards the destination. The IP addresses of the packets are rewritten at the proxies so that the packets can be routed/forwarded to the next proxy, but no change to the underlying routing system is implied, and this is not Semantic Networking.¶
Tunnel-based routing schemes, like those in the transport layer (see Section 6.3), are achieved through an overlay. a tunnel-based scheme relies on encapsulating packets so that they can be sent through the normal routing and forwarding network for delivery to an interim node. That node decapsulates the packet and then either continues to forward the contents or encapsulates the contents in another tunnel. Some approaches, such as onion routing in the Tor project (see [ONION]) use a scheme of multiply-nested encapsulation, with each layer being peeled off at the end of a tunnel.¶
The packets in a tunnel-based approach are routed and forwarded in the packet network as normal packets and so this approach is not Semantic Networking.¶
A lot of effort has been devoted to consideration of end-to-end paths for IP traffic across multiple autonomous systems (ASes). For example, the BGP Add-Paths feature [RFC7911] allows the advertisement of multiple paths so that a single, "best" path can be determined. These approaches, however, are principally concerned with overall reachability, and then with selecting the path with the fewest transit autonomous systems. They are less capable of selecting an overall least cost path or of considering other traffic engineering constraints in the selection of end-to-end paths. Such path computation requires the features outlined in Section 6.7 as assembled into an architectural solution in [RFC7926].¶
Many approaches have been suggested [RFC6115] for improving inter-domain routing performance and scaling using address partitioning schemes including tunneling across domains (see also Section 6.4). However, routing in this inter-domain scenario is about the selection of the next AS along the path, and possibly a choice of the right AS border router (ASBR) to facilitate that route. This choice of ASBRs might be based on additional information carried in the packets so could qualify as Semantic Networking, but packets flowing between these ASBRs are routed and forwarded within the domains as normal packets without the use of Semantic Networking.¶
Service Function Chaining (SFC) [RFC7665] is applied at the network layer to steer packet flows through network functions (such as security or load balancing). A chain of services to be delivered (the service function chain) is realized as sequence of service instances (the service function path). Packets are tunneled between the service instances using encapsulation so that the end-to-end payload packet is unchanged. A variety of network layer encapsulation have been considered including the Network Service Header (NSH) [RFC8300], MPLS [RFC8595], and Segment Routing [I-D.li-spring-sr-sfc-control-plane-framework].¶
The Segment Routing concept of Network Programming [RFC8986], offers a similar approach to SFC, but may be more widely applicable.¶
The tunneled packets can be freely routed in the network using conventional shortest path techniques or the mechanisms described in Section 6.7 and Section 6.8, thus this approach is not Semantic Networking.¶
Techniques for achieving packet-level traffic engineering in the network layer are described in [I-D.ietf-teas-rfc3272bis]. Traffic engineering (TE) is the process of selecting an end-to-end path that considers many attributes of metrics of the links in the network in order to satisfy a set of constraints or requirements imposed by the sender of the traffic. For example, the sender may want to use only secure links, or may know the bandwidth requirements of the flow, or may need at least a specific end-to-end latency, or indeed any combination of this type of constraint.¶
Routing for TE may be performed in advance of sending the traffic (for example, by computing a path at the sender or by using a tool such as the Path Computation Element (PCE) [RFC4655]. In this case, some form of encapsulation is needed to bind the traffic flow to the selected route: MPLS or Segment Routing may be used.¶
Alternatively, the network may be tuned through appropriate use of routing protocol metrics, routing algorithms, and statically configured routes, so that packets will be forwarded along traffic engineered paths.¶
Semantic Networking, as already explained, is about taking routing decisions based on "additional" information carried in packets in order to provide the behavior and network services most suited to the traffic. This approach builds on the techniques described in Section 6.7 but frees up the network to make individual decisions for each packet based on changing network conditions as well as the information in the packets.¶
A raft of potential solutions have been proposed for carrying the necessary information in the packets, and it is not the purpose of this document to examine them in detail or make suggestions about which is better. The solutions vary from simply using existing fields in the IP header (such as the ToS field), or examining fields below the IP header (such as the transport ports), through "overloading" existing fields in the packet header (such as the destination address), all the way to adding new information in an additional encapsulation as proposed by the Application-aware Networking (APN) effort [I-D.li-apn-framework].¶
The use of semantic enhancements as a key aspect to Semantic Networking (as described in this document) links the development of Semantic Networking solutions to data plane programmability. Novel approaches to Semantic Networking may inform the evolution of more complex in-network operations, aiding specific Semantic Networking solutions. Further, progress in routing protocols (e.g., on multi-optimality routing [SOBRINHO]) may be seen as a key input into the more general problem within an emerging framework to distribute state needed for in-network computing operations, e.g., through utilizing insights from routing protocols to distribute routing state for more limited routing operations.¶
As per its charter, the Computation In The Network (COIN) Research Group [COINRG] combines the idea of computing with the programmability of the data plane. Hence, network operations, such as those previously used for routing and forwarding, may be key to the programmability aspects of "computing in the network" within the scope of COIN. Ultimately, as stated in the COIN charter, "The goal is to investigate how to harness and to benefit from this emerging disruption to the Internet architecture to improve network and application performance as well as user experience." From this, we can conclude that data plane programmability and its impact on existing and emerging areas of communication are key to COIN.¶
The COIN charter further states, "COIN specifically will focus on the evolution necessary for networking to move beyond packet interception as the basis of network operation and into computation." This envisions that data plane programmability is not limited to packet interception, but may evolve towards more complex operations on data flowing across the network. The analysis of use cases and the identification of key areas of study can drive the understanding of what those additional operations may be and how to program them, particularly across several participating network elements and at the endpoints. With this, we can conclude that the areas for applying COIN ideas will ultimately drive the evolution of COIN technologies by identifying emerging requirements and uses for data plane programmability, particularly those beyond simple packet processing, such as packet forwarding and local buffer management.¶
Given the focus on steering traffic between micro-services instantiated at computational elements within networks and at endpoints, the COIN use cases identify aspects of what is now amed Semantic Networking. Thus Semantic Networking is one possible applicability area for COIN.¶
Conversely, the availability of emerging data plane programmability may enable new capabilities for Semantic Networking. As a distributed problem, Semantic Networking could be enabled by emerging programming frameworks that may be developed within the work of COIN, possibly leading to new ways of orchestrating and deploying distributed routing programs. Thus, the relationship between Semantic Networking and the COIN Research Group can be characterized as a symbiotic process of informing and enabling that may benefit both work areas.¶
Semantic Networking must give full consideration to the security and privacy issues that are introduced by these mechanisms. Placing additional information into packet header fields might reveal details of what the packet is for, what function the user is performing, who the user is, etc. Furthermore, in-flight modification of the additional information might not directly change the destination of the packet, but might change how the packet is handled within the network and at the destination.¶
It should also be considered how packet encryption techniques that are increasingly popular for end-to-end or edge-to-edge security may obscure the semantic information carried in some fields of the packet header or found deeper in the packet. This may render some Semantic Networking techniques impractical and may dictate other methods of carrying the necessary information to enable Semantic Networking.¶
This document makes no requests for IANA action.¶
Thanks to Brian Carpenter, Dave Oran, and Luigi Iannone for helpful discussions and clarifications.¶
Mohamed Boucadair Email: [email protected] Dirk Trossen Email: [email protected]¶