< draft-farrel-irtf-introduction-to-semantic-routing-02.txt   draft-farrel-irtf-introduction-to-semantic-routing-03.txt >
IRTF A. Farrel IRTF A. Farrel
Internet-Draft Old Dog Consulting Internet-Draft Old Dog Consulting
Intended status: Informational D. King Intended status: Informational D. King
Expires: 18 July 2022 Lancaster University Expires: 26 July 2022 Lancaster University
14 January 2022 22 January 2022
An Introduction to Semantic Routing An Introduction to Semantic Routing
draft-farrel-irtf-introduction-to-semantic-routing-02 draft-farrel-irtf-introduction-to-semantic-routing-03
Abstract Abstract
Many proposals have been made to add semantics to IP packets by Many proposals have been made to add semantics to IP packets by
placing additional information existing fields, by adding semantics placing additional information in existing fields, by adding
to IP addresses, or by adding fields to the packets. The intent is semantics to IP addresses themselves, or by adding fields. The
to facilitate enhanced routing decisions based on these additional intent is to facilitate enhanced routing/forwarding decisions based
semantics to provide differentiated paths for different packet flows on these additional semantics to provide differentiated forwarding
distinct from simple shortest path first routing. The process is paths for different packet flows distinct from simple shortest path
known as Semantic Routing. first routing. The process is defined as Semantic Routing.
This document provides a brief introduction to Semantic Routing. This document provides a brief introduction to Semantic Routing.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 18 July 2022. This Internet-Draft will expire on 26 July 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Objectives and Scope . . . . . . . . . . . . . . . . . . . . 4 2. Objectives and Scope . . . . . . . . . . . . . . . . . . . . 4
3. Approaches to Semantic Routing . . . . . . . . . . . . . . . 5 3. Approaches to Semantic Routing . . . . . . . . . . . . . . . 6
3.1. Packet and Service Routing . . . . . . . . . . . . . . . 7 3.1. Packet and Service Routing . . . . . . . . . . . . . . . 8
4. Semantic Routing Information . . . . . . . . . . . . . . . . 8 4. Semantic Routing Information . . . . . . . . . . . . . . . . 8
4.1. Address Space Partitioning . . . . . . . . . . . . . . . 8 4.1. Address Space Partitioning . . . . . . . . . . . . . . . 9
4.2. Prefix-based Contextual Address Usage . . . . . . . . . . 8 4.2. Prefix-based Contextual Address Usage . . . . . . . . . . 9
4.3. Semantic Addressing . . . . . . . . . . . . . . . . . . . 8 4.3. Semantic Addressing . . . . . . . . . . . . . . . . . . . 9
4.4. Flow Marking . . . . . . . . . . . . . . . . . . . . . . 9 4.4. Flow Marking . . . . . . . . . . . . . . . . . . . . . . 10
4.5. Deep Packet Inspection . . . . . . . . . . . . . . . . . 9 4.5. Extended Lookup . . . . . . . . . . . . . . . . . . . . . 10
4.6. Semantic Field Overloading . . . . . . . . . . . . . . . 9 4.6. Semantic Field Overloading . . . . . . . . . . . . . . . 10
4.7. IPv6 Extension Headers . . . . . . . . . . . . . . . . . 9 4.7. IPv6 Extension Headers . . . . . . . . . . . . . . . . . 10
4.8. New Extensions . . . . . . . . . . . . . . . . . . . . . 10 4.8. New Extensions . . . . . . . . . . . . . . . . . . . . . 11
5. Architectural Considerations . . . . . . . . . . . . . . . . 10 5. Architectural Considerations . . . . . . . . . . . . . . . . 11
5.1. Isolated Domains . . . . . . . . . . . . . . . . . . . . 10 5.1. Isolated Domains . . . . . . . . . . . . . . . . . . . . 11
5.2. Bridged Domains . . . . . . . . . . . . . . . . . . . . . 11 5.2. Bridged Domains . . . . . . . . . . . . . . . . . . . . . 12
5.3. Semantic Prefix Domains . . . . . . . . . . . . . . . . . 11 5.3. Semantic Prefix Domains . . . . . . . . . . . . . . . . . 12
6. A Brief Discussion of What Constitutes Routing . . . . . . . 11 6. A Brief Discussion of What Constitutes Routing . . . . . . . 13
6.1. Application Layer Routing . . . . . . . . . . . . . . . . 12 6.1. Application Layer Routing . . . . . . . . . . . . . . . . 13
6.2. Higher-Layer Path Selection . . . . . . . . . . . . . . . 12 6.2. Higher-Layer Path Selection . . . . . . . . . . . . . . . 13
6.3. Inter-Domain Routing . . . . . . . . . . . . . . . . . . 13 6.3. Transport Layer Routing . . . . . . . . . . . . . . . . . 14
6.4. Service Function Chaining . . . . . . . . . . . . . . . . 13 6.4. Tunnel-Based Routing . . . . . . . . . . . . . . . . . . 14
6.5. Network Layer Traffic Engineering Techniques . . . . . . 13 6.5. Inter-Domain Routing . . . . . . . . . . . . . . . . . . 14
6.6. Semantic Routing in the Network Layer . . . . . . . . . . 14 6.6. Service Function Chaining . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6.7. Network Layer Traffic Engineering Techniques . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6.8. Semantic Routing in the Network Layer . . . . . . . . . . 16
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
11. Informative References . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Informative References . . . . . . . . . . . . . . . . . 17
11.2. URL References . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
Historically, the meaning of an IP address has been to identify an Historically, the meaning of an IP address has been to identify an
interface on a network device. Network routing protocols were interface on a network device or a network to which a host is
initially designed to determine paths through the network toward attached [RFC0814]. Network routing protocols were initially
destination addresses so that IP packets with a common destination designed to determine paths through a network toward destination
address converged on that destination. Anycast and multicast addresses so that IP packets with a common destination address
addresses were also defined, and these new address semantics converged on that destination. Anycast and multicast addresses were
necessitated variations to the routing protocols, and in some cases also defined (e.g., Section 2.6.1 of [RFC4291]), and some of these
the development of new protocols. 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 Over time, routing decisions were enhanced to route packets according
to additional information carried within the packets and dependent on to additional information carried within the packets and dependent on
policy coded in, configured at, or signaled to the routers. Perhaps policy coded in, configured at, or signaled to the routers. Perhaps
the most obvious example is Equal-Cost Multipath (ECMP) where a the most obvious example is Equal-Cost Multipath (ECMP) where a
router makes a consistent choice for forwarding packets over a number 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 of parallel links or paths based on the values of a set of fields in
the packet header. 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 Upper-layer applications are placing increasingly sophisticated
demands on the network for better quality, more predictability, and demands on the network for better quality, more predictability, and
increased reliability. Some of these applications are futuristic increased reliability. Some of these applications are futuristic
predictions (for example, haptic augmented reality multiplayer 3D predictions (for example, haptic augmented reality multiplayer 3D
worlds), some are new ideas on the threshold of roll-out (such as worlds), some are new ideas on the threshold of roll-out (such as
holographic conferencing), and many are rapidly developing sectors holographic conferencing), and many are rapidly developing sectors
with established revenue streams (such as multiplayer immersive with established revenue streams (such as multiplayer immersive
gaming). gaming).
At the same time, lower-layer network technologies are advancing At the same time, lower-layer network technologies are advancing
rapidly providing increased bandwidth to the home and to mobile hand- rapidly providing increased bandwidth to the home and to mobile hand-
held devices. These advances create an environment that enables the held devices. These advances create an environment that enables the
potential of advanced applications being run by very many end-users. potential of advanced applications being run by very many end-users.
This coincides with a growing trend to extend end-to-end This coincides with a massive growth in end-to-end communications
communications to include machines and services, and to introduce that include machines and services, and to introduce routing and
routing and addressing behaviors and semantics specific to a addressing behaviors to a particular use case and set of requirements
particular use case and set of requirements applied within a limited applied within a limited region or domain of the Internet. Examples
region or domain of the Internet. Examples of these three of these three developments include 5G, predicted wireless
developments include 5G, predicted wireless evolutions, IoT and evolutions, IoT and vehicular connectivity, space-terrestrial
vehicular connectivity, space-terrestrial communication, industrial communication, industrial networks, cloud computing, service function
networks, cloud computing, service function chaining and network chaining and network functions virtualization, digital twins, and
functions virtualization, digital twins, and data-centric data data-centric data brokerage platforms.
brokerage platforms.
Despite this plurality of communication scenarios, IP-based Despite this plurality of communication scenarios, IP-based
addressing and network layer routing have remained focused on addressing and network layer routing have remained focused on
identifying locations of communication and determining paths between identifying locations of communication (i.e., "where") and
those locations. This has previously depended on higher-layer determining paths between those locations with or without specific
capabilities (e.g., for name-to-location resolution) to support those constraints (i.e., "how-to-get-there" as per [IEN23]). This has
comprehensive communication scenarios, but that approach introduces previously depended on higher-layer capabilities (e.g., for name-to-
latency and dependencies (e.g., changing locator assignments may location resolution) to support some of these communication
depend on the capabilities of the upper-layer capability that are scenarios, but that approach introduces latency and dependencies
outside the core addressing and routing system). Furthermore, multi- (e.g., changing locator assignments may depend on the capabilities of
layer lookups and interactions may impact the efficacy of the upper-layer capability that are outside the core addressing and
communication scenarios, particularly those that employ different routing system). Furthermore, multi-layer lookups and interactions
routing and addressing approaches beyond just locators. 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 Routing" places the support for advanced routing and "Semantic Routing" places the support for advanced routing,
location functions directly at the packet routing layer, such as forwarding, and location functions directly at the packet routing/
through extensions to the identification properties of addresses (so forwarding layer, such as through extensions to the identification
that the address indicates more than just the network location) or properties of addresses (so that the address indicates more than just
through performing routing functions on an extended set of inputs the network location) or through performing routing functions on an
(for example, other fields carried in packet headers). Such an extended set of inputs (for example, other fields carried in packet
approach should preserve the Internet architecture as it is today headers). Such an approach should preserve the Internet architecture
while enabling additional routing function. as it is today while enabling additional routing function.
This document provides a brief introduction to semantic routing and This document provides a brief introduction to semantic routing and
outlines the possible approaches that might be taken. A separate outlines the possible approaches that might be taken. A separate
document ([I-D.king-irtf-semantic-routing-survey]) makes a start at a document ([I-D.king-irtf-semantic-routing-survey]) makes a start at a
survey of pre-existing work in this area, while survey of pre-existing work in this area, while
[I-D.king-irtf-challenges-in-routing] sets out some of the issues [I-D.king-irtf-challenges-in-routing] sets out some of the issues
that should be considered when researching, developing, or proposing that should be considered when researching, developing, or proposing
a semantic routing scheme. a semantic routing scheme.
2. Objectives and Scope 2. Objectives and Scope
As with all advances in Internet protocols, semantic routing may be As with all advances in Internet protocols, semantic routing may be
considered for Internet-wide deployment or may be restricted considered for Internet-wide deployment or may be restricted
(possibly only initially) to well-defined and contained networks (possibly only initially) to well-defined and contained networks
referred to as "limited domains" (see [RFC8799]). The information referred to as "limited domains" (see [RFC8799]). The information
used for semantic routing may be opaque within the network (in other used for semantic routing may be opaque within the network (in other
words, the additional information is not visible to the routers), may words, the additional information is not required to be parsed by the
be transparent (so that routers may see the information, but their routers and might not even be visible to them), may be transparent
processing does not need to be changed to accommodate the information (so that routers may see the information, but their processing does
or its encoding), or may be active (so that semantic routing is fully not need to be changed to accommodate the information or its
encoding), or may be active (so that semantic routing is fully
enabled). enabled).
Semantic routing may select paths in one domain that are not When building an end-to-end path across multiple domains, semantic
consistent with the paths selected in other domains. routing 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 routing decisions
within a domain are potentially isolated from knowledge about the
other domains.
In any case, concern and consideration must be coexistence with, and In any case, concern and consideration must be coexistence with, and
backward compatibility to, existing routing and addressing schemes backward compatibility to, existing routing and addressing schemes
that are widely deployed. that are widely deployed.
Further understanding of the scope of semantic routing applied to the Further understanding of the scope of semantic routing applied to the
routing of packets at the network layer may be gained by reading 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 Section 6 to see how various other concepts of routing are out of
scope of this work. scope of this work.
A strategic objective of semantic routing, and associated semantic A strategic objective of semantic routing, and associated semantic
enhancements, is to enable Service Providers to modify the default enhancements, is to enable Service Providers to modify the default
forwarding behaviour to be based on other information present in the forwarding behaviour to be based on other information present in the
packet and policy configured or dynamically programmed into the packet and policy configured or dynamically programmed into the
routers and devices. This is aimed to cause new and alternative path routers and devices. This is aimed to cause new and alternative path
processing by routers, including: processing by routers, including:
* Determinism of quality of delivery in terms of throughput, * Determinism of quality of delivery in terms of throughput,
latency, jitter, drop precedence. latency, jitter, and drop precedence.
* Determinism of resilience in terms of survival of network failures * Determinism of resilience in terms of survival of network failures
and delivery degradation. and delivery degradation.
* Determinism of routing performance in terms of the volume of data * Determinism of routing performance in terms of the volume of data
that has to be exchanged both to establish and to maintain the that has to be exchanged both to establish and to maintain the
routing tables. routing tables.
* Deployability in terms of configuration, training, development of * Deployability in terms of configuration, training, development of
new hardware/software, and interaction with the pre-existing new hardware/software, and interaction with the pre-existing
skipping to change at page 5, line 30 skipping to change at page 6, line 10
2. management of Service KPIs with/without guarantees 2. management of Service KPIs with/without guarantees
3. dynamic and controlled instantiation of management information 3. dynamic and controlled instantiation of management information
in the packets. in the packets.
Issues of security and privacy have been largely overlooked within Issues of security and privacy have been largely overlooked within
the routing systems. However, there is increasing concern that the routing systems. However, there is increasing concern that
attacks on routing systems can not only be disruptive (for example, attacks on routing systems can not only be disruptive (for example,
causing traffic to be dropped), but may cause traffic to be routed causing traffic to be dropped), but may cause traffic to be routed
via inspection points that can breach the security or privacy of the via inspection points that can breach the security or privacy of the
payloads. While semantic routing may offer tools for increasing payloads (e.g., BGP hijack attacks). While semantic routing might
security and privacy, it is possible that semantic routing and the offer tools for increasing security and privacy, it is possible that
additional information that may be carried in packets to enable semantic routing and the additional information that may be carried
semantic routing may provide vectors for attacks or compromise in packets to enable semantic routing may provide vectors for attacks
privacy. This must be examined by any semantic routing proposals. or compromise privacy. This must be examined by any semantic routing
proposals. For example, means to control entities that are entitled
to access supplied semantic routing information should be considered.
3. Approaches to Semantic Routing 3. Approaches to Semantic Routing
Typically, in an IP-based network packets are forwarded using the Typically, in an IP-based network packets are forwarded using the
least-cost path to the destination IP address. Service Providers may least-cost path to the destination IP address. Service Providers may
also use techniques to modify the default forwarding behavior based also use techniques to modify the default forwarding behavior based
on other information present in the packet and configured or on other information present in the packet and configured or
programmed into the routers. These mechanisms, sometimes called programmed into the routers. These mechanisms, sometimes called
semantic routing techniques include "Preferential Routing", "Policy- semantic routing techniques include "Preferential Routing", "Policy-
based Routing", and "Flow Steering". based Routing", and "Flow Steering".
skipping to change at page 6, line 13 skipping to change at page 6, line 42
traffic may be handled differently [SEMANTICRTG]. traffic may be handled differently [SEMANTICRTG].
* Expressing how a packet should be handled, prioritized, or * Expressing how a packet should be handled, prioritized, or
allocated network resources as it is forwarded through the network allocated network resources as it is forwarded through the network
[TERASTREAMref]. [TERASTREAMref].
* Deriving IP addresses from the lower layer identifiers and using * Deriving IP addresses from the lower layer identifiers and using
addresses depending on the underlying connectivity (for example, addresses depending on the underlying connectivity (for example,
[RFC6282]. [RFC6282].
* Building IP addresses from the transport layer identifiers (for
example, [RFC7597]).
* Indicating the application or network function on a destination * Indicating the application or network function on a destination
device or at a specific location; or enable Service Function device or at a specific location, or enable Service Function
Chaining (SFC). Chaining (SFC) [RFC7665].
* Providing semantics specific to mobile networks so that a user or * Providing semantics specific to mobile networks so that a user or
device may move through the network without disruption to their device may move through the network without disruption to their
service [CONTENT-RTG-MOBILEref]. service [CONTENT-RTG-MOBILEref].
* Enabling optimized multicast traffic distribution by encoding * Enabling optimized multicast traffic distribution by encoding
multicast tree and replication instructions within addresses multicast tree and replication instructions within addresses
[MULTICAST-SRref]. [MULTICAST-SRref].
* Content-based routing (CBR), forwarding of the packet based on * Content-based routing (CBR), forwarding of the packet based on
skipping to change at page 6, line 45 skipping to change at page 7, line 29
* Using cryptographic algorithms to mask the identity of the source * Using cryptographic algorithms to mask the identity of the source
or destination, masking routing tables within the domain, while or destination, masking routing tables within the domain, while
still enabling packet forwarding across the network still enabling packet forwarding across the network
[BLIND-FORWARDINGref]. [BLIND-FORWARDINGref].
A more comprehensive list of existing implementations and research A more comprehensive list of existing implementations and research
projects can be found in [I-D.king-irtf-semantic-routing-survey]. projects can be found in [I-D.king-irtf-semantic-routing-survey].
Semantic routing, operates to forward packets dependent on Semantic routing, operates to forward packets dependent on
information carried in the packets and rules present in the routers. information carried in the packets and rules present in the routers.
Those rules could be: Those rules could be any combination of:
* Built into the routers * Built into the routers
* Configured network-wide in the routers * Configured network-wide in the routers
* Configured per-router in a relatively static way * Configured per-router in a relatively static way
* Programmed to the routers in a dynamic way, for example, through * Programmed to the routers in a dynamic way, for example, through
software defined networking (SDN) software defined networking (SDN)
* Distributed dynamically through the network using routing or * Distributed dynamically through the network using routing or
signalling protocols signalling protocols
Semantic routing will also require information about network state Semantic routing will also require information about network state
and capabilities just as existing shortest path first routing systems and capabilities just as existing shortest path first routing systems
do. That may require information (such as link delays or other do. That may require information (such as link delays or other
qualitative attributes) to be collected by network nodes and qualitative attributes) to be collected by network nodes and
distributed between routers by routing protocols. Alternatively, distributed between routers by routing protocols. Alternatively,
this information could be collected centrally by a network controller this information could be collected (centrally) by a set of network
and used to derive the rules installed in the routers. controllers and used to derive the rules installed in the routers.
Forwarding by the router is based on a look-up of the semantic Forwarding by a router is based on a look-up that also considers the
routing information carried in the packet (see Section 4) and semantic routing information carried in the packet (see Section 4)
forwarding instructions programmed into the forwarding element. The and forwarding instructions programmed into the forwarding element.
actions to perform may be derived by the router based on the rules Some semantic routing proposals may generate the semantic information
and information that the router has collected, or may be programmed (e.g., a hash) rather than using information that is directly
directly from the network controller. 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.
3.1. Packet and Service Routing 3.1. Packet and Service Routing
Routing is the process of selecting a path for traffic in a network Routing is the process of selecting a path for traffic in a network
or between or across multiple networks. For example, IP routing uses or between or across multiple networks. For example, IP routing uses
IP addresses for source and destination identification and is IP addresses for source and destination identification and is
typically used for packet networks, such as the Internet. IP routing typically used for packet networks, such as the Internet. IP routing
assumes that network addresses are structured and facilitates routing assumes that network addresses are structured and facilitates routing
entries in a routing table entry to represent a group of IP capable entries in a routing table entry to represent a group of IP-capable
devices. devices.
While service routing and information-centric networking (ICN) can While service routing and information-centric networking (ICN) can
operate directly on top of layer 2 protocols (for example, operate directly on top of layer 2 protocols (for example,
[RFC9139]), in the context of this document, we are concerned with [RFC9139]), in the context of this document, we are concerned with
the function of service routing and ICN in IP networks. Like any new the function of service routing and ICN in IP networks. Like any new
spanning-layer style protocol, deployment considerations for ICN on spanning-layer style protocol, deployment considerations for ICN on
the Internet make tunneling through IP a required part of any co- the Internet make tunneling through IP a required part of any co-
existence or transition. The approach taken in this case, is to existence or transition. The approach taken in this case, is to
create an overlay layer on top of the IP network. Control of the create an overlay layer on top of the IP network. Control of the
skipping to change at page 8, line 6 skipping to change at page 8, line 43
entirely new discovery, propagation and resource management protocols entirely new discovery, propagation and resource management protocols
and procedures. and procedures.
By contrast, explicit service-based IP routing By contrast, explicit service-based IP routing
[I-D.jiang-service-oriented-ip] abstracts the service actions that [I-D.jiang-service-oriented-ip] abstracts the service actions that
the network can provide into a number of classes called Service the network can provide into a number of classes called Service
Action Types (SATs). Each packet is marked with the relevant SAT, Action Types (SATs). Each packet is marked with the relevant SAT,
and the packets are routed to the next available SAT provider (not and the packets are routed to the next available SAT provider (not
the destination IP address). In this approach, a distinct the destination IP address). In this approach, a distinct
encapsulation is needed and may carry native IP packets as payload, encapsulation is needed and may carry native IP packets as payload,
while transition experiments may utilise an overlay on top of IP. while transition experiments may utilize an overlay on top of IP.
IP Routing and service routing are not the same thing. IP Routing and service routing are not the same thing.
4. Semantic Routing Information 4. Semantic Routing Information
The subsections below describe some of the common techniques to The subsections below describe some of the common techniques to
enable semantic routing in more detail. The sections are unordered enable semantic routing in more detail. The sections are unordered
and no meaning should be assigned to how one approach is presented and no meaning should be assigned to how one approach is presented
before another. They are not a complete list of possible approaches. before another. They are not a complete list of possible approaches.
skipping to change at page 8, line 29 skipping to change at page 9, line 17
appropriate, and so those advantages and disadvantages are not appropriate, and so those advantages and disadvantages are not
discussed. The reader will inevitably have a preference and see discussed. The reader will inevitably have a preference and see
drawbacks. drawbacks.
4.1. Address Space Partitioning 4.1. Address Space Partitioning
In some cases, an address prefix is assigned a special purpose and In some cases, an address prefix is assigned a special purpose and
meaning. When such an address appears in the packet's address field, meaning. When such an address appears in the packet's address field,
a router can know from the prefix that particular routing/forwarding a router can know from the prefix that particular routing/forwarding
actions are required. An example of this approach is seen in actions are required. An example of this approach is seen in
multicast addressing. 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].
4.2. Prefix-based Contextual Address Usage 4.2. Prefix-based Contextual Address Usage
The owner of a prefix to use the low-order bits of an address for The owner of a prefix to use the low-order bits of an address for
their own purposes. their own purposes.
The semantics of such an approach might be coordinated between prefix The semantics of such an approach might be coordinated between prefix
owners, or could be indicated through information that is part of the owners, or could be indicated through information that is part of the
encoding, and is standardised. encoding, and is standardized. An example of such approach is in
IPv4/IPv6 Translators [RFC6052].
4.3. Semantic Addressing 4.3. Semantic Addressing
Semantic addressing is a term applied to any approach that adds Semantic addressing is a term applied to any approach that adds
semantics to IP addresses. This includes the mechanisms described in semantics to IP addresses. This includes the mechanisms described in
Section 4.1 and Section 4.2. Other semantic addressing proposals Section 4.1 and Section 4.2. Other semantic addressing proposals
suggest variable address lengths, hierarchical addresses, or a suggest variable address lengths, hierarchical addresses, or a
structure to addresses so that they can carry additional information structure to addresses so that they can carry additional information
in a common way. in a common way.
In any case, semantic addressing intends to facilitate routing In any case, semantic addressing that intends to facilitate routing
decisions based solely on the address and without the need to find decisions is based solely on the address and without the need to find
and process information carried in other fields within the packets. 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.
4.4. Flow Marking 4.4. Flow Marking
Flow marking is a way of indicating, in a simple field in the packet Flow marking is a way of indicating, in a specific field in the
header, the treatment that the packet should receive in the network. packet header, the treatment that the packet should receive in the
In IPv4 the six-bit DSCP field is commonly used for this purpose. In network. In IPv4 the six-bit DSCP field is commonly used for this
IPv6, while the Traffic Class field could be used, it is generally purpose. In IPv6, while the Traffic Class field could be used, it is
recommended that the Flow Label field should serve this and a more generally recommended that the Flow Label field should serve this and
general purpose. a more general purpose.
4.5. Deep Packet Inspection 4.5. Extended Lookup
The term "deep packet inspection" (DPI) is used here to mean that the Routers may also examine fields in the packet other than those in the
router examines various packet fields, including those beyond the IP IP header. For example, many router processes may look at the "five-
packet header. For example, many router processes may look at the tuple" consisting of:
"five-tuple" consisting of:
* source address * source address
* destination address * destination address
* next protocol * next protocol
* transport protocol source port * transport protocol source port
* transport protocol destination port * transport protocol destination port
skipping to change at page 10, line 10 skipping to change at page 11, line 10
destination address, or by the ultimate destination of the packet. destination address, or by the ultimate destination of the packet.
Extension headers may carry any information to enable semantic Extension headers may carry any information to enable semantic
routing. routing.
4.8. New Extensions 4.8. New Extensions
Another approach is to define a new protocol extension to carry Another approach is to define a new protocol extension to carry
information on which semantic routing can be performed. Such an information on which semantic routing can be performed. Such an
extension could be in the form of a new extension header (see extension could be in the form of a new extension header (see
Section 4.7) or as a new shim encapsulation immediately after the IP Section 4.7) or as a new shim encapsulation (e.g., [RFC7665]).
header.
5. Architectural Considerations 5. Architectural Considerations
Some semantic routing proposals are intended to be deployed in Some semantic routing proposals are intended to be deployed in
limited domains [RFC8799] (networks) that are IP-based, while other limited domains [RFC8799] (networks) that are IP-based, while other
proposals are intended for use across the Internet. The impact the proposals are intended for use across the Internet. The impact that
proposals have on routing systems may require clean-slate solutions, the proposals have on routing systems may require clean-slate
hybrid solutions, extensions to existing routing protocols, or solutions, hybrid solutions, extensions to existing routing
potentially no changes at all. protocols, or potentially no changes at all.
Semantic data may be applied in several ways to integrate with Semantic data may be applied in several ways to integrate with
existing routing architectures. The most obvious is to build an existing routing architectures. The most obvious is to build an
overlay such that IP is used only to route packets between network overlay such that IP is used only to route packets between network
nodes that utilize the semantics at a higher layer. An overlay may nodes that utilize the semantics at a higher layer. An overlay may
be achieved in a higher protocol layer, or may be performed using 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 tunneling techniques (such as IP-in-IP [RFC1853]) to traverse the
IP network that cannot parse additional semantics thereby joining areas of the IP network that cannot parse additional semantics
together those nodes that use the semantic data. thereby joining together those nodes that use the semantic data.
The application of semantics may also be constrained to within a The application of semantics may also be constrained to within a
limited domain. In some cases, such a domain will use IP, but be limited domain. In some cases, such a domain will use IP, but be
disconnected from Internet (see Section 5.1). In other cases, disconnected from Internet (see Section 5.1). In other cases,
traffic from within the domain is exchanged with other domains that traffic from within the domain is exchanged with other domains that
are connected together across an IP-based network using tunnels or are connected together across an IP-based network using tunnels or
via application gateways (see Section 5.2). And in still another via application gateways (see Section 5.2). And in still another
case traffic from the domain is routed across the Internet to other case traffic from the domain is routed across the Internet to other
nodes and this requires backward-compatible routing approaches (see nodes and this requires backward-compatible routing approaches (see
Section 5.3). Section 5.3).
5.1. Isolated Domains 5.1. Isolated Domains
Some IP network domains are entirely isolated from the Internet and Some IP network domains are entirely isolated from the Internet and
other IP-based networks. In these cases, there is no risk to other IP-based networks. In these cases, there is no risk to
external networks from any semantic routing schemes carried out external networks from any semantic routing schemes carried out
within the domain. within the domain.
Many approaches in isolated domains will utilize environment-specific Many approaches in isolated domains will utilize environment-specific
routing protocols. For example, those suited to constrained routing protocols. For example, those suited to constrained
environments (for IoT) or mobile environments (for smart vehicles). environments (for IoT) or mobile environments (for autonomous
Such routing protocols can be optimized for the exchange of vehicles). Such routing protocols can be optimized for the exchange
information specific to semantic routing. of information specific to semantic routing. 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.
5.2. Bridged Domains 5.2. Bridged Domains
In some deployments, it will be desirable to connect a number of In some deployments, it will be desirable to connect a number of
isolated domains to build a larger network. These domains may be isolated domains to build a larger network. These domains may be
connected (or bridged) over an IP network or even over the Internet. connected (or bridged) over an IP network or even over the Internet.
Ideally, the function of the bridged domains should not be impeded by Ideally, the function of the bridged domains should not be impeded by
how they are connected, and the operation of the IP network providing how they are connected, and the operation of the IP network providing
the connectivity should not be compromised by the act of carrying the connectivity should not be compromised by the act of carrying
skipping to change at page 11, line 43 skipping to change at page 13, line 11
without encountering or having to use any semantic addressing. Once without encountering or having to use any semantic addressing. Once
delivered to the semantic prefix domain, a packet can be subjected to delivered to the semantic prefix domain, a packet can be subjected to
whatever semantic routing is enabled in the domain. whatever semantic routing is enabled in the domain.
6. A Brief Discussion of What Constitutes Routing 6. A Brief Discussion of What Constitutes Routing
This section provides an overview of what is considered as "routing" This section provides an overview of what is considered as "routing"
in the scope of this document. There are many functions in the in the scope of this document. There are many functions in the
Internet that contain the concept of routing, but not all of them Internet that contain the concept of routing, but not all of them
apply to the scope of this document which is concerned with routing apply to the scope of this document which is concerned with routing
packets at the network layer. A more throrough catalogue of packets at the network layer. A more thorough catalogue of
approaches to routing and the applications of semantic routing can be approaches to routing and the applications of semantic routing can be
found in [I-D.king-irtf-semantic-routing-survey]. found in [I-D.king-irtf-semantic-routing-survey].
6.1. Application Layer Routing 6.1. Application Layer Routing
Routing in the application layer concerns the choice of application- Routing in the application layer concerns the choice of application-
level components that are distributed across the network. The choice level components that are distributed across the network. The choice
may be dependent on the services being delivered, knowledge about the may be dependent on the services being delivered, knowledge about the
locations in the network that can provide the services, knowledge of locations in the network that can provide the services, knowledge of
the network capabilities, and preferences expressed by an application the network capabilities, and preferences expressed by an application
skipping to change at page 12, line 39 skipping to change at page 13, line 49
impractical to scale the network reporting all available paths to all impractical to scale the network reporting all available paths to all
destinations to every client, or for the network edge to be able to destinations to every client, or for the network edge to be able to
answer queries from their clients. answer queries from their clients.
6.2. Higher-Layer Path Selection 6.2. Higher-Layer Path Selection
There is another high-level path selection scenario that is more There is another high-level path selection scenario that is more
concerned with selecting outbound paths from the source than in concerned with selecting outbound paths from the source than in
determining destinations or next application-layer hops (as described determining destinations or next application-layer hops (as described
in Section 6.1. For example, consider a mobile phone that is in Section 6.1. For example, consider a mobile phone that is
connected to WiFi and 5G. Further, consider that the WiFi network is connected to Wi-Fi and 5G. Further, consider that the Wi-Fi network
dual-homed to two different ISPs. This gives an application a choice is dual-homed to two different ISPs. This gives an application a
of three different paths depending on the known (or advertised) choice of three different paths depending on the known (or
capabilities of the networks. advertised) capabilities of the networks.
This type of scenario is being examined by the Path Aware Networking This type of scenario is being examined by the Path Aware Networking
Research Group (PANRG) where, rather than consulting a server to Research Group (PANRG) where, rather than consulting a server to
supply the most appropriate path, the source host or application supply the most appropriate path, the source host or application
should learn about the potential paths and pick between them. should learn about the potential paths and pick between them.
6.3. Inter-Domain Routing 6.3. Transport Layer Routing
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 Routing.
6.4. Tunnel-Based Routing
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 Routing.
6.5. Inter-Domain Routing
A lot of effort has been devoted to consideration of end-to-end paths A lot of effort has been devoted to consideration of end-to-end paths
for IP traffic across multiple autonomous systems (ASes). For for IP traffic across multiple autonomous systems (ASes). For
example, the BGP Add-Paths feature [RFC7911] allows the advertisement example, the BGP Add-Paths feature [RFC7911] allows the advertisement
of multiple paths so that a single, "best" path can be determined. of multiple paths so that a single, "best" path can be determined.
These approaches, however, are principally concerned with overall These approaches, however, are principally concerned with overall
reachability, and then with selecting the path with the fewest reachability, and then with selecting the path with the fewest
transit autonomous systems. They are less capable of selecting an transit autonomous systems. They are less capable of selecting an
overall least cost path or of considering other traffic engineering overall least cost path or of considering other traffic engineering
constraints in the selection of end-to-end paths. Such path constraints in the selection of end-to-end paths. Such path
computation requires the features outlined in Section 6.5 as computation requires the features outlined in Section 6.7 as
assembled into an architectural solution in [RFC7926]. assembled into an architectural solution in [RFC7926].
Thus, routing in this scenario is about the selection of the next AS Many approaches have been suggested [RFC6115] for improving inter-
along the path, and possibly a choice of the right AS border router domain routing performance and scaling using address partitioning
(ASBR) to facilitate that route. 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 Routing, but packets flowing between these
ASBRs are routed and forwarded within the domains as normal packets
without the use of Semantic Routing.
6.4. Service Function Chaining 6.6. Service Function Chaining
Service Function Chaining (SFC) [RFC7665] is applied at the network Service Function Chaining (SFC) [RFC7665] is applied at the network
layer to steer packet flows through network functions (such as layer to steer packet flows through network functions (such as
security or load balancing). A chain of services to be delivered security or load balancing). A chain of services to be delivered
(the service function chain) is realised as sequence of service (the service function chain) is realized as sequence of service
instances (the service function path). Packets are tunneled between instances (the service function path). Packets are tunneled between
the service instances using encapsulation so that the end-to-end the service instances using encapsulation so that the end-to-end
payload packet is unchanged. A variety of network layer payload packet is unchanged. A variety of network layer
encapsulation have been considered including the Network Service encapsulation have been considered including the Network Service
Header (NSH) [RFC8300], MPLS [RFC8595], and Segment Routing Header (NSH) [RFC8300], MPLS [RFC8595], and Segment Routing
[I-D.li-spring-sr-sfc-control-plane-framework]. [I-D.li-spring-sr-sfc-control-plane-framework].
The Segment Routing concept of Network Programming [RFC8986], offers The Segment Routing concept of Network Programming [RFC8986], offers
a similar approach to SFC, but may be more widely applicable. a similar approach to SFC, but may be more widely applicable.
The tunneled packets can be freely routed in the network using The tunneled packets can be freely routed in the network using
conventional shortest path techniques or the mechanisms described in conventional shortest path techniques or the mechanisms described in
Section 6.5 and Section 6.6. Section 6.7 and Section 6.8, thus this approach is not Semantic
Routing.
6.5. Network Layer Traffic Engineering Techniques 6.7. Network Layer Traffic Engineering Techniques
Techniques for achieving packet-level traffic engineering in the Techniques for achieving packet-level traffic engineering in the
network layer are described in [I-D.ietf-teas-rfc3272bis]. Traffic network layer are described in [I-D.ietf-teas-rfc3272bis]. Traffic
engineering (TE) is the process of selecting an end-to-end path that 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 considers many attributes of metrics of the links in the network in
order to satisfy a set of constraints or requirements imposed by the 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 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 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 may need at least a specific end-to-end latency, or indeed any
combination of this type of constraint. combination of this type of constraint.
skipping to change at page 14, line 17 skipping to change at page 16, line 16
(for example, by computing a path at the sender or by using a tool (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, such as the Path Computation Element (PCE) [RFC4655]. In this case,
some form of encapsulation is needed to bind the traffic flow to the some form of encapsulation is needed to bind the traffic flow to the
selected route: MPLS or Segment Routing may be used. selected route: MPLS or Segment Routing may be used.
Alternatively, the network may be tuned through appropriate use of Alternatively, the network may be tuned through appropriate use of
routing protocol metrics, routing algorithms, and statically routing protocol metrics, routing algorithms, and statically
configured routes, so that packets will be forwarded along traffic configured routes, so that packets will be forwarded along traffic
engineered paths. engineered paths.
6.6. Semantic Routing in the Network Layer 6.8. Semantic Routing in the Network Layer
Semantic routing, as already explained, is about taking routing Semantic routing, as already explained, is about taking routing
decisions based on "additional" information carried in packets in decisions based on "additional" information carried in packets in
order to provide the behavior and network services most suited to the order to provide the behavior and network services most suited to the
traffic. This approach builds on the techniques described in traffic. This approach builds on the techniques described in
Section 6.5 but frees up the network to make individual decisions for Section 6.7 but frees up the network to make individual decisions for
each packet based on changing network conditions as well as the each packet based on changing network conditions as well as the
information in the packets. information in the packets.
A raft of potential solutions have been proposed for caryring the A raft of potential solutions have been proposed for carrying the
necessary information in the packets, and it is not the purpose of necessary information in the packets, and it is not the purpose of
this document to examine them in detail or make suggestions about this document to examine them in detail or make suggestions about
which is better. The solutions vary from simply using existing which is better. The solutions vary from simply using existing
fields in the IP header (such as the ToS field), or examining fields fields in the IP header (such as the ToS field), or examining fields
below the IP header (such as the transport ports), through below the IP header (such as the transport ports), through
"overloading" existing fields in the packet header (such as the "overloading" existing fields in the packet header (such as the
destination address), all the way to adding new information in an destination address), all the way to adding new information in an
additional encapsulation as proposed by the Application-aware additional encapsulation as proposed by the Application-aware
Networking (APN) effort [I-D.li-apn-framework]. Networking (APN) effort [I-D.li-apn-framework].
skipping to change at page 15, line 14 skipping to change at page 17, line 18
header or found deeper in the packet. This may render some semantic header or found deeper in the packet. This may render some semantic
routing techniques impractical and may dictate other methods of routing techniques impractical and may dictate other methods of
carrying the necessary information to enable semantic routing. carrying the necessary information to enable semantic routing.
8. IANA Considerations 8. IANA Considerations
This document makes no requests for IANA action. This document makes no requests for IANA action.
9. Acknowledgements 9. Acknowledgements
Thanks to Brian Carpenter and Dave Oran for helpful discussions and Thanks to Brian Carpenter, Dave Oran, and Luigi Iannone for helpful
clarifications. discussions and clarifications.
10. Contributors 10. Contributors
TBD Mohamed Boucadair
Email: mohamed.boucadair@orange.com
11. Informative References 11. References
11.1. Informative References
[BLIND-FORWARDINGref] [BLIND-FORWARDINGref]
Simsek, I., "On-Demand Blind Packet Forwarding", Simsek, I., "On-Demand Blind Packet Forwarding",
Paper 30th International Telecommunication Networks and Paper 30th International Telecommunication Networks and
Applications Conference (ITNAC), 2020, 2020, Applications Conference (ITNAC), 2020, 2020,
<https://www.computer.org/csdl/proceedings-article/ <https://www.computer.org/csdl/proceedings-article/
itnac/2020/09315187/1qmfFPPggrC>. itnac/2020/09315187/1qmfFPPggrC>.
[CONTENT-RTG-MOBILEref] [CONTENT-RTG-MOBILEref]
Liu, H. and W. He, "Rich Semantic Content-oriented Routing Liu, H. and W. He, "Rich Semantic Content-oriented Routing
skipping to change at page 16, line 27 skipping to change at page 18, line 33
jiang-semantic-prefix-06.txt>. jiang-semantic-prefix-06.txt>.
[I-D.jiang-service-oriented-ip] [I-D.jiang-service-oriented-ip]
Carpenter, B., Jiang, S., and G. Li, "Service Oriented Carpenter, B., Jiang, S., and G. Li, "Service Oriented
Internet Protocol", Work in Progress, Internet-Draft, Internet Protocol", Work in Progress, Internet-Draft,
draft-jiang-service-oriented-ip-03, 14 May 2020, draft-jiang-service-oriented-ip-03, 14 May 2020,
<https://www.ietf.org/archive/id/draft-jiang-service- <https://www.ietf.org/archive/id/draft-jiang-service-
oriented-ip-03.txt>. oriented-ip-03.txt>.
[I-D.king-irtf-challenges-in-routing] [I-D.king-irtf-challenges-in-routing]
King, D. and A. Farrel, "Challenges for the Internet King, D., Farrel, A., and C. Jacquenet, "Challenges for
Routing Infrastructure Introduced by Semantic Routing", the Internet Routing Infrastructure Introduced by Semantic
Work in Progress, Internet-Draft, draft-king-irtf- Routing", Work in Progress, Internet-Draft, draft-king-
challenges-in-routing-04, 8 November 2021, irtf-challenges-in-routing-06, 22 January 2022,
<https://www.ietf.org/archive/id/draft-king-irtf- <https://www.ietf.org/archive/id/draft-king-irtf-
challenges-in-routing-04.txt>. challenges-in-routing-06.txt>.
[I-D.king-irtf-semantic-routing-survey] [I-D.king-irtf-semantic-routing-survey]
King, D. and A. Farrel, "A Survey of Semantic Internet King, D. and A. Farrel, "A Survey of Semantic Internet
Routing Techniques", Work in Progress, Internet-Draft, Routing Techniques", Work in Progress, Internet-Draft,
draft-king-irtf-semantic-routing-survey-03, 26 November draft-king-irtf-semantic-routing-survey-03, 26 November
2021, <https://www.ietf.org/archive/id/draft-king-irtf- 2021, <https://www.ietf.org/archive/id/draft-king-irtf-
semantic-routing-survey-03.txt>. semantic-routing-survey-03.txt>.
[I-D.li-apn-framework] [I-D.li-apn-framework]
Li, Z., Peng, S., Voyer, D., Li, C., Liu, P., Cao, C., Li, Z., Peng, S., Voyer, D., Li, C., Liu, P., Cao, C.,
skipping to change at page 17, line 8 skipping to change at page 19, line 21
apn-framework-04.txt>. apn-framework-04.txt>.
[I-D.li-spring-sr-sfc-control-plane-framework] [I-D.li-spring-sr-sfc-control-plane-framework]
Li, C., Sawaf, A. E., Hu, R., and Z. Li, "A Framework for Li, C., Sawaf, A. E., Hu, R., and Z. Li, "A Framework for
Constructing Service Function Chaining Systems Based on Constructing Service Function Chaining Systems Based on
Segment Routing", Work in Progress, Internet-Draft, draft- Segment Routing", Work in Progress, Internet-Draft, draft-
li-spring-sr-sfc-control-plane-framework-05, 21 October li-spring-sr-sfc-control-plane-framework-05, 21 October
2021, <https://www.ietf.org/archive/id/draft-li-spring-sr- 2021, <https://www.ietf.org/archive/id/draft-li-spring-sr-
sfc-control-plane-framework-05.txt>. sfc-control-plane-framework-05.txt>.
[IEN23] Cohen, D., "IEN 23: On Names, Addresses and Routings",
Internet Experiment Note IEN 23, Notebook Section 2.3.3.7,
1978, <https://www.rfc-editor.org/ien/ien23.pdf>.
[MULTICAST-SRref] [MULTICAST-SRref]
Jia, W. and W. He, "A Scalable Multicast Source Routing Jia, W. and W. He, "A Scalable Multicast Source Routing
Architecture for Data Center Networks", Paper IEEE Journal Architecture for Data Center Networks", Paper IEEE Journal
on Selected Areas in Communications, vol. 32, no. 1, pp. on Selected Areas in Communications, vol. 32, no. 1, pp.
116-123, January 2014, 2014, 116-123, January 2014, 2014,
<https://ieeexplore.ieee.org/document/6799682>. <https://ieeexplore.ieee.org/document/6799682>.
[OPENSRNref] [OPENSRNref]
Ren, P., Wang, X., Zhao, B., Wu, C., and H. Sun, "OpenSRN: Ren, P., Wang, X., Zhao, B., Wu, C., and H. Sun, "OpenSRN:
A Software-defined Semantic Routing Network Architecture", A Software-defined Semantic Routing Network Architecture",
Paper IEEE Conference on Computer Communications Workshops Paper IEEE Conference on Computer Communications Workshops
(INFOCOM WKSHPS), Hong Kong, 2015, 2015, (INFOCOM WKSHPS), Hong Kong, 2015, 2015,
<https://www.researchgate.net/ <https://www.researchgate.net/
publication/308827498_OpenSRN_A_software- publication/308827498_OpenSRN_A_software-
defined_semantic_routing_network_architecture>. defined_semantic_routing_network_architecture>.
[RFC0814] Clark, D., "Name, addresses, ports, and routes", RFC 814,
DOI 10.17487/RFC0814, July 1982,
<https://www.rfc-editor.org/info/rfc814>.
[RFC1853] Simpson, W., "IP in IP Tunneling", RFC 1853,
DOI 10.17487/RFC1853, October 1995,
<https://www.rfc-editor.org/info/rfc1853>.
[RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z.
Shelby, "Performance Enhancing Proxies Intended to
Mitigate Link-Related Degradations", RFC 3135,
DOI 10.17487/RFC3135, June 2001,
<https://www.rfc-editor.org/info/rfc3135>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655, Computation Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006, DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>. <https://www.rfc-editor.org/info/rfc4655>.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
DOI 10.17487/RFC6052, October 2010,
<https://www.rfc-editor.org/info/rfc6052>.
[RFC6115] Li, T., Ed., "Recommendation for a Routing Architecture",
RFC 6115, DOI 10.17487/RFC6115, February 2011,
<https://www.rfc-editor.org/info/rfc6115>.
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
DOI 10.17487/RFC6282, September 2011, DOI 10.17487/RFC6282, September 2011,
<https://www.rfc-editor.org/info/rfc6282>. <https://www.rfc-editor.org/info/rfc6282>.
[RFC6992] Cheng, D., Boucadair, M., and A. Retana, "Routing for
IPv4-Embedded IPv6 Packets", RFC 6992,
DOI 10.17487/RFC6992, July 2013,
<https://www.rfc-editor.org/info/rfc6992>.
[RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,
Previdi, S., Roome, W., Shalunov, S., and R. Woundy, Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
"Application-Layer Traffic Optimization (ALTO) Protocol", "Application-Layer Traffic Optimization (ALTO) Protocol",
RFC 7285, DOI 10.17487/RFC7285, September 2014, RFC 7285, DOI 10.17487/RFC7285, September 2014,
<https://www.rfc-editor.org/info/rfc7285>. <https://www.rfc-editor.org/info/rfc7285>.
[RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S.,
Murakami, T., and T. Taylor, Ed., "Mapping of Address and
Port with Encapsulation (MAP-E)", RFC 7597,
DOI 10.17487/RFC7597, July 2015,
<https://www.rfc-editor.org/info/rfc7597>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665, Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015, DOI 10.17487/RFC7665, October 2015,
<https://www.rfc-editor.org/info/rfc7665>. <https://www.rfc-editor.org/info/rfc7665>.
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
2016, <https://www.rfc-editor.org/info/rfc7761>.
[RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder,
"Advertisement of Multiple Paths in BGP", RFC 7911, "Advertisement of Multiple Paths in BGP", RFC 7911,
DOI 10.17487/RFC7911, July 2016, DOI 10.17487/RFC7911, July 2016,
<https://www.rfc-editor.org/info/rfc7911>. <https://www.rfc-editor.org/info/rfc7911>.
[RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G.,
Ceccarelli, D., and X. Zhang, "Problem Statement and Ceccarelli, D., and X. Zhang, "Problem Statement and
Architecture for Information Exchange between Architecture for Information Exchange between
Interconnected Traffic-Engineered Networks", BCP 206, Interconnected Traffic-Engineered Networks", BCP 206,
RFC 7926, DOI 10.17487/RFC7926, July 2016, RFC 7926, DOI 10.17487/RFC7926, July 2016,
skipping to change at page 19, line 14 skipping to change at page 22, line 22
[TERASTREAMref] [TERASTREAMref]
Zaluski, B., Rajtar, B., Habjani, H., Baranek, M., Slibar, Zaluski, B., Rajtar, B., Habjani, H., Baranek, M., Slibar,
N., Petracic, R., and T. Sukser, "Terastream N., Petracic, R., and T. Sukser, "Terastream
implementation of all IP new architecture", Paper 36th implementation of all IP new architecture", Paper 36th
International Convention on Information and Communication International Convention on Information and Communication
Technology, Electronics and Microelectronics (MIPRO), Technology, Electronics and Microelectronics (MIPRO),
2013, 2013, 2013, 2013,
<https://ieeexplore.ieee.org/document/6596297>. <https://ieeexplore.ieee.org/document/6596297>.
11.2. URL References
[ONION] The Tor Project, Inc., "The Onion Routing Project :
Anonymity Online", 2022, <https://torproject.org/>.
Authors' Addresses Authors' Addresses
Adrian Farrel Adrian Farrel
Old Dog Consulting Old Dog Consulting
United Kingdom United Kingdom
Email: adrian@olddog.co.uk Email: adrian@olddog.co.uk
Daniel King Daniel King
Lancaster University Lancaster University
 End of changes. 59 change blocks. 
152 lines changed or deleted 279 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/