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/ |