rfc-9198

Advanced Unidirectional Route Assessment (AURA)

J. Alvarez-Hamelin, A. Morton, J. Fabini, C. Pignataro, R. Geib
date2022-05 streamIETF areaops wgippm statusPROPOSED STANDARD pages23 canonicalhttps://www.rfc-editor.org/rfc/rfc9198 doi10.17487/RFC9198
This memo introduces an advanced unidirectional route assessment (AURA) metric and associated measurement methodology based on the IP Performance Metrics (IPPM) framework (RFC 2330). This memo updates RFC 2330 in the areas of path-related terminology and path description, primarily to include the possibility of parallel subpaths between a given Source and Destination pair, owing to the presence of multipath technologies.

updates

Extracted elements (31)

design-rationale §1.1

Cloud subpaths—segments containing Hosts that do not decrement Hop Limit—are acknowledged as an irreducible gap in path assessment. Tunnels and nested tunnels further hide Hops, meaning the assessment discovers only Hosts that decrement Hop Limit or cooperate with interrogation.

measurement, ip

design-rationale §4.1

Maintaining a constant ICMP checksum in IPv4 is the most challenging aspect of flow-consistent probing because ICMP sequence number and identifier fields change between probes. The solution is to use arbitrary bytes in the ICMP data field to offset these changes and hold the checksum constant.

measurement, ip

design-rationale §4.1.2

Routing Class identification is introduced to reduce measurement iterations over time: once the class C hash parameters for a Member Route are known, any packet in that class can substitute for the original probe type, enabling targeted re-measurement of ECMP-sensitive path portions only.

measurement, routing

design-rationale §6

RTD statistics use quartiles (min, Q1, Q2, Q3, max) rather than mean/variance because network traffic has a self-similar nature causing spiky queuing behavior; quartiles provide a nonparametric representation and the P² algorithm enables on-the-fly computation without storing the full dataset.

measurement

design-rationale §1.1

The Route metric explicitly incorporates parallel paths because ECMP and UCMP technologies are common in the Internet and create multiple simultaneous subpaths between the same Src-Dst pair; a metric that ignores this would be incomplete for modern networks.

measurement, routing

design-rationale §1.1

The Route metric must be assessed over a time interval (not a single instant) because active path detection methods like Paris-traceroute rely on incrementing Hop Limits and cannot discover all Hosts on a path using a single packet.

measurement

interoperability-note §2

Hybrid Type I methods (RFC 9197) for Route assessment are intended only for single administrative domains that provide a protocol for explicit interrogation of Nodes; Internet users do not typically have access to OAM capabilities of transit networks.

measurement, ip

interoperability-note §2

ICMP-based active methods are not intended to yield accurate, reproducible estimations of the Round-Trip Delay that UDP or TCP packets will experience, because the reverse ICMP path may differ and the ICMP response includes an unknown Host processing-time contribution.

measurement, ip

interoperability-note §3.6

If a Node always replies using the same network address regardless of arrival interface, multiple parallel links between that Node and its neighbor cannot be detected by traceroute-style active methods. Implementing RFC 5837 ICMP extensions for interface identification enables parallel link detection.

measurement, ip

interoperability-note §2

This memo updates Section 5 of RFC 2330 in the areas of path-related terminology and path description, primarily to include the possibility of parallel subpaths between a given Source and Destination address pair resulting from ECMP and UCMP technologies.

measurement, ip

normative-requirement §3.1 MUST

A Hop specification MUST contain a Node identity and MAY contain arrival and/or departure interface identification, Round-Trip Delay, and an arrival timestamp.

measurement

normative-requirement §3.1 SHOULD

Cooperating Nodes SHOULD provide information such as arrival/departure interface identification, arrival timestamp, and any relevant information about the Node or specific link that delivered the query.

measurement, ip

normative-requirement §3.1 MUST

Discoverable Nodes communicating with IP MUST send a Time Exceeded message (containing Node identity) to the source when discarding a packet due to TTL or Hop Limit Exceeded, per RFC 1122 Section 3.2.2.4. This also applies to routers per RFC 1812 Section 5.3.1.

measurement, ip

normative-requirement §4.1 SHOULD

For ICMP flow maintenance in IPv4, the data field SHOULD compensate variations on TTL/Hop Limit, IP identification, and IP checksum for every packet to preserve flow identity across probes. ICMPv6 only requires constant Flow Label and Source/Destination addresses.

measurement, ip

normative-requirement §4.1 SHOULD

For TCP flow maintenance: in IPv4, Src, Dst, port-Src, port-Dst, sequence number, and Diffserv SHOULD be the same across all probes for a given flow; in IPv6, Flow Label, Src, and Dst SHOULD be the same.

measurement, ip, tcp

normative-requirement §4.1 SHOULD

For UDP flow maintenance: in IPv4, Src, Dst, port-Src, port-Dst, and Diffserv should be the same, and the UDP checksum SHOULD change to keep the IP checksum of the ICMP Time Exceeded reply constant; in IPv6, Flow Label and Source/Destination addresses SHOULD be the same.

measurement, ip, udp

normative-requirement §4.1.1 REQUIRED

Repetitive active Route measurement systems SHALL trigger reassessment of the complete path and Route Ensemble if any change in Hops is observed for a specific, previously tested flow.

measurement

normative-requirement §4.1.1 SHOULD

Repetitive active Route measurement systems SHOULD occasionally check path portions that have exhibited stable results over time (e.g., daily) and SHOULD continue testing portions that have previously exhibited ECMP load balancing.

measurement

normative-requirement §4.1 SHOULD

Use of IPv6 Extension Headers in Route Ensemble measurement packets may add critical fields to the flow definition and SHOULD be avoided to maintain consistent flow identification across all probes.

measurement, ip

normative-requirement §4.3 SHOULD

When combining active and hybrid methods, Nodes at ingress and egress of a domain supporting an interrogation protocol SHOULD be both Discoverable and Cooperating, and SHOULD reveal the same Node identity in response to both active and hybrid interrogation methods.

measurement, ip

protocol-element §3.1

A Cooperating Node responds to direct queries for its Node identity as part of a previously established interrogation protocol (such as IOAM per RFC 9197). Cooperating Nodes SHOULD provide arrival/departure interface identification, arrival timestamp, and relevant link information.

measurement, ip

protocol-element §3.1

A Discoverable Node is one that conveys its Node identity when error conditions are detected; for IP, compliance with RFC 1122 Section 3.2.2.4 when discarding a packet due to TTL or Hop Limit Exceeded MUST result in sending the corresponding Time Exceeded message containing Node identity to the source.

measurement, ip

protocol-element §3.4

A Hop singleton h(i,j) identifies Discoverable or Cooperating Nodes i Hops from Src on Route j during the measurement interval. It MUST contain a Node identity hid(i,j) and MAY contain arrival interface ID a(i,j), departure interface ID d(i,j), arrival timestamp t(i,j), and Round-Trip Delay measurements.

measurement, ip

protocol-element §3.4

A Member Route j is an ordered list {h(1,j), ..., h(Nj,j)} where consecutive Hops are exactly one Hop apart and h(Nj,j)=Dst. Member Routes must be unique: any two Member Routes in the same Ensemble differ either in minimum Hop count or have at least one distinct Hop h(i,j) != h(i,k).

measurement, ip

protocol-element §3.4

A Route Ensemble is the combination of all Routes traversed by different flows from Src to Dst during measurement interval T0 to Tf, aggregating all m distinct Member Routes. Formally: Route Ensemble = {{h(1,1),...,h(N1,1)=Dst}, ..., {h(1,m),...,h(Nm,m)=Dst}} where i <= Nj <= Nmax.

measurement, ip

protocol-element §3.1

Node Identity is the unique globally routable IP address a Node uses when communicating with other Nodes under normal or error conditions. The identity and its DNS reverse resolution determines whether parallel-link interfaces map to a single Node or appear as distinct Nodes.

measurement, ip

protocol-element §3.1

Routing Class is a Route that treats a class of different packet types equally (designated 'C'). Knowledge of such a class allows any packet type within the class to be used for subsequent Route measurement, and is determined primarily by the hash functions used at each ECMP instance on the path.

measurement, routing

protocol-element §3.5

RTD(i,j,T) is a singleton of the RFC 2681 Round-Trip Delay between Src and Hop h(i,j) at time T; RTL(i,j,T) is a singleton of the RFC 6673 Round-Trip Loss between Src and Hop h(i,j) at time T. Both are optional attributes of a Hop specification.

measurement, ip

protocol-element §3.2

The formal metric name is Type-P-Route-Ensemble-Method-Variant, abbreviated Route Ensemble. Type-P depends heavily on the chosen method and variant, and covers the complete description of packets including all flow-defining header fields.

measurement

security-consideration §7

ICMP does not provide cryptographic protection for requested/returned data, exposing risks when processing untrusted data; these are limitations of the underlying protocols. Active measurement techniques greatly reduce exposure of sensitive user-traffic information compared to passive monitoring; the LMAP Framework (RFC 7594) covers relevant privacy considerations.

security, privacy, measurement

security-consideration §7

Security considerations from RFC 4656 (OWAMP) and RFC 5357 (TWAMP) apply to active measurement of live paths. The technique of varying packet fields to maintain a constant checksum does not introduce additional security concerns as it is part of normal synthetic traffic generation with minimal network-processing impact.

security, measurement