When a path-aware network exposes path properties to endpoints or other entities, these entities may use this information to achieve different goals. This section lists several use cases for path properties.
Note that this is not an exhaustive list; as with every new technology and protocol, novel use cases may emerge, and new path properties may become relevant. Moreover, for any particular technology, entities may have visibility of and control over different path elements and path properties and consider them on different levels of abstraction. Therefore, a new technology may implement an existing use case related to different path elements or on a different level of abstraction.
Nodes may be able to send flows via one (or a subset) out of multiple possible paths, and an entity may be able to influence the decision about which path(s) to use. Path selection may be feasible if there are several paths to the same destination (e.g., in case of a mobile device with two wireless interfaces, both providing a path) or if there are several destinations, and thus several paths, providing the same service (e.g., Application-Layer Traffic Optimization (ALTO) [RFC 5693
], an application layer peer-to-peer protocol allowing endpoints a better-than-random peer selection). Entities can express their intent to achieve a specific goal by specifying target properties for their paths, e.g., related to performance or security. Then, paths can be selected that best meet the target properties, e.g., the entity can select these paths from all available paths or express the target properties to the network and rely on the network to select appropriate paths.
Target properties relating to network performance typically refer to observed properties, such as one-way delay, one-way packet loss, and link capacity. Entities then select paths based on their target property and the assessed property of the available paths that best match the application requirements. For such performance-related target properties, the observed property is similar to a Service Level Indicator (SLI), and the assessed property is similar to a Service Level Objective (SLO) for IETF Network Slices [NETWORK-SLICES
]. As an example path-selection strategy, an entity may select a path with a short one-way delay for sending a small delay-sensitive query, while it may select a path with high link capacities on all links for retrieving a large file.
It is also possible for an entity to set target properties that it cannot (directly) observe, similar to Service Level Expectations (SLEs) for IETF Network Slices [NETWORK-SLICES
]. This may apply to security-related target properties (e.g., to mandate that all enterprise traffic goes through a specific firewall) and path selection (e.g., to enforce traffic policies by allowing or disallowing sending flows over paths that involve specific networks or nodes).
Care needs to be taken when selecting paths based on observed path properties, as path properties that were previously measured may not be helpful in predicting current or future path properties, and such path selection may lead to unintended feedback loops. Also, there may be trade-offs between path properties (e.g., one-way delay and link capacity), and entities may influence these trade-offs with their choices. Finally, path selection may impact fairness. For example, if multiple entities concurrently attempt to meet their target properties using the same network resources, one entity's choices may influence the conditions on the path as experienced by flows of another entity.
As a baseline, a path-selection algorithm should aim to do a better job of meeting the target properties, and consequently accommodating the user's requirements, than the default case of not selecting a path most of the time.
Path selection can be done either by the communicating node(s) or by other entities within the network. A network (e.g., an AS) can adjust its path selection for internal or external routing based on path properties. In BGP, the Multi-Exit Discriminator (MED) attribute is used in the decision-making process to select which path to choose among those having the same AS path length and origin [RFC 4271
]; in a path-aware network, instead of using this single MED value, other properties such as link capacity or link usage could additionally be used to improve load balancing or performance [PERFORMANCE-ROUTING
Before sending data over a specific path, an entity may select an appropriate protocol or configure protocol parameters depending on path properties. For example, an endpoint may cache state if a path allows the use of QUIC [RFC 9000
]; if so, it may first attempt to connect using QUIC before falling back to another protocol when connecting over this path again. A video-streaming application may choose an (initial) video quality based on the achievable data rate or the monetary cost of sending data (e.g., volume-based or flat-rate cost model).
In addition to path or protocol selection, an entity may choose to invoke additional functions in the context of Service Function Chaining [RFC 7665
], which may influence which nodes are on the path. For example, a 0-RTT Transport Converter [RFC 8803
] will be involved in a path only when invoked by an endpoint; such invocation will lead to the use of Multipath TCP (MPTCP) [RFC 8684
] or tcpcrypt [RFC 8548
] capabilities, while such use is not supported via the default forwarding path. Another example is a connection that is composed of multiple streams where each stream has specific service requirements. An endpoint may decide to invoke a given service function (e.g., transcoding) only for some streams while others are not processed by that service function.