rfc9198v3.txt   rfc9198.txt 
skipping to change at line 12 skipping to change at line 12
Internet Engineering Task Force (IETF) J. Alvarez-Hamelin Internet Engineering Task Force (IETF) J. Alvarez-Hamelin
Request for Comments: 9198 Universidad de Buenos Aires Request for Comments: 9198 Universidad de Buenos Aires
Updates: 2330 A. Morton Updates: 2330 A. Morton
Category: Standards Track AT&T Labs Category: Standards Track AT&T Labs
ISSN: 2070-1721 J. Fabini ISSN: 2070-1721 J. Fabini
TU Wien TU Wien
C. Pignataro C. Pignataro
Cisco Systems, Inc. Cisco Systems, Inc.
R. Geib R. Geib
Deutsche Telekom Deutsche Telekom
April 2022 May 2022
Advanced Unidirectional Route Assessment (AURA) Advanced Unidirectional Route Assessment (AURA)
Abstract Abstract
This memo introduces an advanced unidirectional route assessment This memo introduces an advanced unidirectional route assessment
(AURA) metric and associated measurement methodology based on the IP (AURA) metric and associated measurement methodology based on the IP
Performance Metrics (IPPM) framework (RFC 2330). This memo updates Performance Metrics (IPPM) framework (RFC 2330). This memo updates
RFC 2330 in the areas of path-related terminology and path RFC 2330 in the areas of path-related terminology and path
description, primarily to include the possibility of parallel description, primarily to include the possibility of parallel
skipping to change at line 212 skipping to change at line 212
delay will be that experienced by ICMP packets (in active methods) delay will be that experienced by ICMP packets (in active methods)
and may be different from delays experienced by UDP or TCP packets. and may be different from delays experienced by UDP or TCP packets.
Also, the Round-Trip Delay will include an unknown contribution of Also, the Round-Trip Delay will include an unknown contribution of
processing time at the Host that generates the ICMP response. processing time at the Host that generates the ICMP response.
Therefore, the ICMP-based active methods are not supposed to yield Therefore, the ICMP-based active methods are not supposed to yield
accurate, reproducible estimations of the Round-Trip Delay that UDP accurate, reproducible estimations of the Round-Trip Delay that UDP
or TCP packets will experience. or TCP packets will experience.
3. Route Metric Specifications 3. Route Metric Specifications
This section sets requirements for the components of the oute metric. This section sets requirements for the components of the route
metric.
3.1. Terms and Definitions 3.1. Terms and Definitions
Host Host
A Host (as defined in [RFC2330]) is a computer capable of IP A Host (as defined in [RFC2330]) is a computer capable of IP
communication, including routers (aka an RFC 2330 Host). communication, including routers (aka an RFC 2330 Host).
Node Node
A Node is any network function on the path capable of IP-layer A Node is any network function on the path capable of IP-layer
Communication, including RFC 2330 Hosts. Communication, including RFC 2330 Hosts.
skipping to change at line 338 skipping to change at line 339
metrics (unless otherwise indicated): metrics (unless otherwise indicated):
M: the total number of packets sent between T0 and Tf. M: the total number of packets sent between T0 and Tf.
N: the smallest value of i needed for a packet to be received at Dst N: the smallest value of i needed for a packet to be received at Dst
(sent between T0 and Tf). (sent between T0 and Tf).
Nmax: the largest value of i needed for a packet to be received at Nmax: the largest value of i needed for a packet to be received at
Dst (sent between T0 and Tf). Nmax may be equal to N. Dst (sent between T0 and Tf). Nmax may be equal to N.
Next defines a *singleton* for a Node on the path with sufficient Next, define a *singleton* for a Node on the path with sufficient
indexes to identify all Nodes identified in a measurement interval indexes to identify all Nodes identified in a measurement interval
(where *singleton* is part of the IPPM Framework [RFC2330]). (where *singleton* is part of the IPPM Framework [RFC2330]).
singleton: A Hop specification, designated h(i,j), the IP address singleton: A Hop specification, designated h(i,j), the IP address
and/or identity of Discoverable Nodes (or Cooperating Nodes) that and/or identity of Discoverable Nodes (or Cooperating Nodes) that
are i Hops away from the Node with address = Src and part of Route are i Hops away from the Node with address = Src and part of Route
j during the measurement interval T0 to Tf. As defined here, a j during the measurement interval T0 to Tf. As defined here, a
Hop singleton measurement MUST contain a Node identity, hid(i,j), Hop singleton measurement MUST contain a Node identity, hid(i,j),
and MAY contain one or more of the following attributes: and MAY contain one or more of the following attributes:
skipping to change at line 373 skipping to change at line 374
distance from the Node with address Src in Hops h(i,j). Based on distance from the Node with address Src in Hops h(i,j). Based on
this, two forms of Routes are distinguished: this, two forms of Routes are distinguished:
A Route Ensemble is defined as the combination of all Routes A Route Ensemble is defined as the combination of all Routes
traversed by different flows from the Node at Src address to the Node traversed by different flows from the Node at Src address to the Node
at Dst address. A single Route traversed by a single flow at Dst address. A single Route traversed by a single flow
(determined by an unambiguous tuple of addresses Src and Dst and (determined by an unambiguous tuple of addresses Src and Dst and
other identical flow criteria) is a member of the Route Ensemble and other identical flow criteria) is a member of the Route Ensemble and
called a Member Route. called a Member Route.
Using h(i,j) and components and parameters is further defined: Using h(i,j) and components and parameters further define:
When considering the set of Hops in the context of a single flow, a When considering the set of Hops in the context of a single flow, a
Member Route j is an ordered list {h(1,j), ... h(Nj, j)} where h(i-1, Member Route j is an ordered list {h(1,j), ... h(Nj, j)} where h(i-1,
j) and h(i, j) are one Hop away from each other and Nj satisfying j) and h(i, j) are one Hop away from each other and Nj satisfying
h(Nj,j)=Dst is the minimum count of Hops needed by the packet on h(Nj,j)=Dst is the minimum count of Hops needed by the packet on
member Route j to reach Dst. Member Routes must be unique. The member Route j to reach Dst. Member Routes must be unique. The
uniqueness property requires that any two Member Routes, j and k, uniqueness property requires that any two Member Routes, j and k,
that are part of the same Route Ensemble differ either in terms of that are part of the same Route Ensemble differ either in terms of
minimum Hop count Nj and Nk to reach the destination Dst or, in the minimum Hop count Nj and Nk to reach the destination Dst or, in the
case of identical Hop count Nj=Nk, they have at least one distinct case of identical Hop count Nj=Nk, they have at least one distinct
skipping to change at line 442 skipping to change at line 443
difficult to determine parallel subpaths between the same pair of difficult to determine parallel subpaths between the same pair of
Nodes (i.e., multiple parallel links). It is easier to detect Nodes (i.e., multiple parallel links). It is easier to detect
parallel subpaths involving different Nodes. parallel subpaths involving different Nodes.
* If a pair of discovered Nodes identify two different addresses (IP * If a pair of discovered Nodes identify two different addresses (IP
or not), then they will appear to be different Nodes. See item or not), then they will appear to be different Nodes. See item
below. below.
* If a pair of discovered Nodes identify two different IP addresses * If a pair of discovered Nodes identify two different IP addresses
and the IP addresses resolve to the same Node name (in the DNS), and the IP addresses resolve to the same Node name (in the DNS),
then they will appear to be the same Nodes. then they will appear to be the same Node.
* If a discovered Node always replies using the same network * If a discovered Node always replies using the same network
address, regardless of the interface a packet arrives on, then address, regardless of the interface a packet arrives on, then
multiple parallel links cannot be detected in that network domain. multiple parallel links cannot be detected in that network domain.
This condition may apply to traceroute-style methods but may not This condition may apply to traceroute-style methods but may not
apply to other hybrid methods based on In situ Operations, apply to other hybrid methods based on In situ Operations,
Administration, and Maintenance (IOAM). For example, if the ICMP Administration, and Maintenance (IOAM). For example, if the ICMP
extension mechanism described in [RFC5837] is implemented, then extension mechanism described in [RFC5837] is implemented, then
parallel links can be detected with the discovery traceroute-style parallel links can be detected with the discovery traceroute-style
methods. methods.
skipping to change at line 1039 skipping to change at line 1040
[RFC8468] Morton, A., Fabini, J., Elkins, N., Ackermann, M., and V. [RFC8468] Morton, A., Fabini, J., Elkins, N., Ackermann, M., and V.
Hegde, "IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for Hegde, "IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for
the IP Performance Metrics (IPPM) Framework", RFC 8468, the IP Performance Metrics (IPPM) Framework", RFC 8468,
DOI 10.17487/RFC8468, November 2018, DOI 10.17487/RFC8468, November 2018,
<https://www.rfc-editor.org/info/rfc8468>. <https://www.rfc-editor.org/info/rfc8468>.
[RFC9197] Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi, [RFC9197] Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi,
Ed., "Data Fields for In Situ Operations, Administration, Ed., "Data Fields for In Situ Operations, Administration,
and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197, and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197,
March 2022, <https://www.rfc-editor.org/info/rfc9197>. May 2022, <https://www.rfc-editor.org/info/rfc9197>.
9.2. Informative References 9.2. Informative References
[bdrmap] Luckie, M., Dhamdhere, A., Huffaker, B., Clark, D., and [bdrmap] Luckie, M., Dhamdhere, A., Huffaker, B., Clark, D., and
KC. Claffy, "bdrmap: Inference of Borders Between IP KC. Claffy, "bdrmap: Inference of Borders Between IP
Networks", Proceedings of the 2016 ACM on Internet Networks", Proceedings of the 2016 ACM on Internet
Measurement Conference, pp. 381-396, Measurement Conference, pp. 381-396,
DOI 10.1145/2987443.2987467, November 2016, DOI 10.1145/2987443.2987467, November 2016,
<https://doi.org/10.1145/2987443.2987467>. <https://doi.org/10.1145/2987443.2987467>.
 End of changes. 6 change blocks. 
6 lines changed or deleted 7 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/