draft-ietf-ippm-route-04.txt   draft-ietf-ippm-route-05.txt 
Network Working Group J. Alvarez-Hamelin Network Working Group J. Alvarez-Hamelin
Internet-Draft Universidad de Buenos Aires Internet-Draft Universidad de Buenos Aires
Updates: 2330 (if approved) A. Morton Updates: 2330 (if approved) A. Morton
Intended status: Standards Track AT&T Labs Intended status: Standards Track AT&T Labs
Expires: September 10, 2019 J. Fabini Expires: March 14, 2020 J. Fabini
TU Wien TU Wien
C. Pignataro C. Pignataro
Cisco Systems, Inc. Cisco Systems, Inc.
R. Geib R. Geib
Deutsche Telekom Deutsche Telekom
March 9, 2019 September 11, 2019
Advanced Unidirectional Route Assessment (AURA) Advanced Unidirectional Route Assessment (AURA)
draft-ietf-ippm-route-04 draft-ietf-ippm-route-05
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 RFC Performance Metrics (IPPM) Framework RFC 2330. This memo updates RFC
2330 in the areas of path-related terminology and path description, 2330 in the areas of path-related terminology and path description,
primarily to include the possibility of parallel subpaths between a primarily to include the possibility of parallel subpaths between a
given Source and Destination pair, owing to the presence of multi- given Source and Destination pair, owing to the presence of multi-
path technologies. path technologies.
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 September 10, 2019. This Internet-Draft will expire on March 14, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 33 skipping to change at page 2, line 33
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Issues with Earlier Work to define Route . . . . . . . . 3 1.1. Issues with Earlier Work to define Route . . . . . . . . 3
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Route Metric Terms and Definitions . . . . . . . . . . . . . 5 3. Route Metric Terms and Definitions . . . . . . . . . . . . . 5
3.1. Formal Name . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Formal Name . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Metric Definitions . . . . . . . . . . . . . . . . . . . 7 3.3. Metric Definitions . . . . . . . . . . . . . . . . . . . 7
3.4. Related Round-Trip Delay and Loss Definitions . . . . . . 9 3.4. Related Round-Trip Delay and Loss Definitions . . . . . . 9
3.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . 9 3.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . 9
3.6. Reporting the Metric . . . . . . . . . . . . . . . . . . 10 3.6. Reporting the Metric . . . . . . . . . . . . . . . . . . 10
4. Route Assessment Methodologies . . . . . . . . . . . . . . . 10 4. Route Assessment Methodologies . . . . . . . . . . . . . . . 11
4.1. Active Methodologies . . . . . . . . . . . . . . . . . . 10 4.1. Active Methodologies . . . . . . . . . . . . . . . . . . 11
4.1.1. Temporal Composition for Route Metrics . . . . . . . 12 4.1.1. Temporal Composition for Route Metrics . . . . . . . 13
4.1.2. Routing Class C Identification . . . . . . . . . . . 13 4.1.2. Routing Class C Identification . . . . . . . . . . . 14
4.1.3. Intermediate Observation Point Route Measurement . . 14 4.1.3. Intermediate Observation Point Route Measurement . . 15
4.2. Hybrid Methodologies . . . . . . . . . . . . . . . . . . 15 4.2. Hybrid Methodologies . . . . . . . . . . . . . . . . . . 15
4.3. Combining Different Methods . . . . . . . . . . . . . . . 15 4.3. Combining Different Methods . . . . . . . . . . . . . . . 16
5. Background on Round-Trip Delay Measurement Goals . . . . . . 16 5. Background on Round-Trip Delay Measurement Goals . . . . . . 16
6. Tools to Measure Delays in the Internet . . . . . . . . . . . 17 6. Tools to Measure Delays in the Internet . . . . . . . . . . . 17
7. RTD Measurements Statistics . . . . . . . . . . . . . . . . . 18 7. RTD Measurements Statistics . . . . . . . . . . . . . . . . . 18
8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
12. Appendix I MPLS Methods for Route Assessment . . . . . . . . 21 12. Appendix I MPLS Methods for Route Assessment . . . . . . . . 21
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
13.1. Normative References . . . . . . . . . . . . . . . . . . 22 13.1. Normative References . . . . . . . . . . . . . . . . . . 22
13.2. Informative References . . . . . . . . . . . . . . . . . 24 13.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
The IETF IP Performance Metrics (IPPM) working group first created a The IETF IP Performance Metrics (IPPM) working group first created a
framework for metric development in [RFC2330]. This framework has framework for metric development in [RFC2330]. This framework has
stood the test of time and enabled development of many fundamental stood the test of time and enabled development of many fundamental
metrics. It has been updated in the area of metric composition metrics. It has been updated in the area of metric composition
[RFC5835], and in several areas related to active stream measurement [RFC5835], and in several areas related to active stream measurement
of modern networks with reactive properties [RFC7312]. of modern networks with reactive properties [RFC7312].
skipping to change at page 5, line 29 skipping to change at page 5, line 29
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 Terms and Definitions 3. Route Metric Terms and Definitions
This section sets requirements for the following components to This section sets requirements for the following components to
support the Route Metric: support the Route Metric:
Host Identity The unique address for hosts communicating within the Host A Host as defined in [RFC2330] (a computer capable of IP
network domain. For hosts communicating on the Internet with IP, communication, includes routers), a.k.a. RFC 2330 Host.
it is the globally routable IP address(es) which the host uses
when communicating with other hosts under normal or error
conditions. The Host Identity revealed (and its connection to a
Host Name through reverse DNS) determines whether interfaces to
parallel links can be associated with a single host, or appear to
identify unique hosts.
Discoverable Host Hosts that convey their Host Identity according to Node A Node is any network function on the path capable of IP-layer
Communication, includes RFC 2330 Hosts.
Node Identity The unique address for Nodess communicating within the
network domain. For Nodes communicating on the Internet with IP,
it is the globally routable IP address(es) which the Node uses
when communicating with other Nodes under normal or error
conditions. The Node Identity revealed (and its connection to a
Node Name through reverse DNS) determines whether interfaces to
parallel links can be associated with a single Node, or appear to
identify unique Nodes.
Discoverable Node Nodes that convey their Node Identity according to
the requirements of their network domain, such as when error the requirements of their network domain, such as when error
conditions are detected by that host. For hosts communicating conditions are detected by that Node. For Nodes communicating
with IP packets, compliance with Section 3.2.2.4 of [RFC1122] when with IP packets, compliance with Section 3.2.2.4 of [RFC1122] when
discarding a packet due to TTL or Hop Limit Exceeded condition, discarding a packet due to TTL or Hop Limit Exceeded condition,
MUST result in sending the corresponding Time Exceeded message MUST result in sending the corresponding Time Exceeded message
(containing a form of host identity) to the source. This (containing a form of Node identity) to the source. This
requirement is also consistent with section 5.3.1 of [RFC1812] for requirement is also consistent with section 5.3.1 of [RFC1812] for
routers. routers.
Cooperating Host Hosts MUST respond to direct queries for their host Cooperating Node Nodes that MUST respond to direct queries for their
identity as part of a previously agreed and established Node identity as part of a previously agreed and established
interrogation protocol. Hosts SHOULD also provide information interrogation protocol. Nodes SHOULD also provide information
such as arrival/departure interface identification, arrival such as arrival/departure interface identification, arrival
timestamp, and any relevant information about the host or specific timestamp, and any relevant information about the Node or specific
link which delivered the query to the host. link which delivered the query to the Node.
Hop A Hop MUST contain a Host Identity, and MAY contain arrival and/ Hop A Hop MUST contain a Node Identity, and MAY contain arrival and/
or departure interface identification, round trip delay, and an or departure interface identification, round trip delay, and an
arrival timestamp. arrival timestamp.
3.1. Formal Name 3.1. Formal Name
Type-P-Route-Ensemble-Method-Variant, abbreviated as Route Ensemble. Type-P-Route-Ensemble-Method-Variant, abbreviated as Route Ensemble.
Note that Type-P depends heavily on the chosen method and variant. Note that Type-P depends heavily on the chosen method and variant.
3.2. Parameters 3.2. Parameters
This section lists the REQUIRED input factors to specify a Route This section lists the REQUIRED input factors to specify a Route
metric. metric.
o Src, the address of a host (such as the globally routable IP o Src, the address of a Node (such as the globally routable IP
address). address).
o Dst, the address of a host (such as the globally routable IP o Dst, the address of a Node (such as the globally routable IP
address). address).
o i, the limit on the number of Hops a specific packet may visit as o i, the limit on the number of Hops a specific packet may visit as
it traverses from the host at Src to the host at Dst (such as the it traverses from the Node at Src to the Node at Dst (such as the
TTL or Hop Limit). TTL or Hop Limit).
o MaxHops, the maximum value of i used, (i=1,2,3,...MaxHops). o MaxHops, the maximum value of i used, (i=1,2,3,...MaxHops).
o T0, a time (start of measurement interval) o T0, a time (start of measurement interval)
o Tf, a time (end of measurement interval) o Tf, a time (end of measurement interval)
o T, the host time of a packet as measured at MP(Src), meaning o T, the Node time of a packet as measured at MP(Src), meaning
Measurement Point at the Source. Measurement Point at the Source.
o Ta, the host time of a reply packet's *arrival* as measured at o Ta, the Node time of a reply packet's *arrival* as measured at
MP(Src), assigned to packets that arrive within a "reasonable" MP(Src), assigned to packets that arrive within a "reasonable"
time (see parameter below). time (see parameter below).
o Tmax, a maximum waiting time for reply packets to return to the o Tmax, a maximum waiting time for reply packets to return to the
source, set sufficiently long to disambiguate packets with long source, set sufficiently long to disambiguate packets with long
delays from packets that are discarded (lost), such that the delays from packets that are discarded (lost), such that the
distribution of round-trip delay is not truncated. distribution of round-trip delay is not truncated.
o F, the number of different flows simulated by the method and o F, the number of different flows simulated by the method and
variant. variant.
skipping to change at page 7, line 34 skipping to change at page 7, line 42
(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, define a *singleton* definition for a Hop on the path, with Next, define a *singleton* definition for a Hop on the path, with
sufficient indexes to identify all Hops identified in a measurement sufficient indexes to identify all Hops identified in a measurement
interval. interval.
A Hop, designated h(i,j), the IP address and/or identity of one of j A Hop, designated h(i,j), the IP address and/or identity of one of j
Discoverable Hosts (or Cooperating Hosts) that are i hops away from Discoverable Nodes (or Cooperating Nodes) that are i hops away from
the host with address = Src during the measurement interval, T0 to the Node with address = Src during the measurement interval, T0 to
Tf. As defined above, a Hop singleton measurement MUST contain a Tf. As defined above, a Hop singleton measurement MUST contain a
Host Identity, hid(i,j), and MAY contain one or more of the following Node Identity, hid(i,j), and MAY contain one or more of the following
attributes: attributes:
o a(i,j) Arrival Interface ID (e.g., when [RFC5837] is supported) o a(i,j) Arrival Interface ID (e.g., when [RFC5837] is supported)
o d(i,j) Departure Interface ID (e.g., when [RFC5837] is supported) o d(i,j) Departure Interface ID (e.g., when [RFC5837] is supported)
o t(i,j) Arrival Timestamp (where t(i,j) is ideally supplied by the o t(i,j) Arrival Timestamp (where t(i,j) is ideally supplied by the
hop, or approximated from the sending time of the packet that hop, or approximated from the sending time of the packet that
revealed the hop) revealed the hop)
o Measurements of Round Trip Delay (for each packet that reveals the o Measurements of Round Trip Delay (for each packet that reveals the
same Host Identity and attributes, but not timestamp of course, same Node Identity and attributes, but not timestamp of course,
see next section) see next section)
Now that Host Identities and related information can be positioned Now that Node Identities and related information can be positioned
according to their distance from the host with address Src in hops, according to their distance from the Node with address Src in hops,
we introduce two forms of Routes: we introduce two forms of Routes:
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 host at Src address to the host traversed by different flows from the Node at Src address to the Node
at Dst address. The route traversed by each flow (with addresses Src at Dst address. The route traversed by each flow (with addresses Src
and Dst, and other fields which constitute flow criteria) is a member and Dst, and other fields which constitute flow criteria) is a member
of the ensemble and called a Member Route. of the ensemble and called a Member Route.
Using h(i,j) and components and parameters, further define: 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 by 1 hop away from each other and Nj satisfying j) and h(i, j) are by 1 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
skipping to change at page 8, line 38 skipping to change at page 8, line 45
All the optional information collected to describe a Member Route, All the optional information collected to describe a Member Route,
such as the arrival interface, departure interface, and Round Trip such as the arrival interface, departure interface, and Round Trip
Delay at each Hop, turs each list item into a rich structure. There Delay at each Hop, turs each list item into a rich structure. There
may be information on the links between Hops, possibly information on may be information on the links between Hops, possibly information on
the routing (arrival int. to departure int.), an estimate of distance the routing (arrival int. to departure int.), an estimate of distance
between Hops based on Round Trip Delay measurements and calculations, between Hops based on Round Trip Delay measurements and calculations,
and a time stamp indicating when all the additional detail was valid. and a time stamp indicating when all the additional detail was valid.
The Route Ensemble from Src to Dst, during the measurement interval The Route Ensemble from Src to Dst, during the measurement interval
T0 to Tf, is the aggregate of all m distinct Member Routes discovered T0 to Tf, is the aggregate of all m distinct Member Routes discovered
between the two hosts with Src and Dst addresses. More formally, between the two Nodes with Src and Dst addresses. More formally,
with the host having address Src omitted: with the Node having address Src omitted:
Route Ensemble = { Route Ensemble = {
{h(1,1), h(2,1), h(3,1), ... h(N1,1)=Dst}, {h(1,1), h(2,1), h(3,1), ... h(N1,1)=Dst},
{h(1,2), h(2,2), h(3,2),..., h(N2,2)=Dst}, {h(1,2), h(2,2), h(3,2),..., h(N2,2)=Dst},
... ...
{h(1,m), h(2,m), h(3,m), ....h(Nm,m)=Dst} {h(1,m), h(2,m), h(3,m), ....h(Nm,m)=Dst}
} }
where the following conditions apply: i <= Nj <= Nmax (j=1..m) where the following conditions apply: i <= Nj <= Nmax (j=1..m)
skipping to change at page 9, line 15 skipping to change at page 9, line 27
h(i-1,j) and h(i,j) are the Hops on the same Member Route one hop h(i-1,j) and h(i,j) are the Hops on the same Member Route one hop
away from each other. away from each other.
Hop h(i,j) may be identical with h(k,l) for i!=k and j!=l ; which Hop h(i,j) may be identical with h(k,l) for i!=k and j!=l ; which
means there may be portions shared among different Member Routes means there may be portions shared among different Member Routes
(parts of various routes may overlap). (parts of various routes may overlap).
3.4. Related Round-Trip Delay and Loss Definitions 3.4. Related Round-Trip Delay and Loss Definitions
RTD(i,j,T) is defined as a singleton of the [RFC2681] Round-trip RTD(i,j,T) is defined as a singleton of the [RFC2681] Round-trip
Delay between the host with address = Src and the host at Hop h(i,j) Delay between the Node with address = Src and the Node at Hop h(i,j)
at time T. at time T.
RTL(i,j,T) is defined as a singleton of the [RFC6673] Round-trip Loss RTL(i,j,T) is defined as a singleton of the [RFC6673] Round-trip Loss
between the host with address = Src and the host at Hop h(i,j) at between the Node with address = Src and the Node at Hop h(i,j) at
time T. time T.
3.5. Discussion 3.5. Discussion
Depending on the way that Host Identity is revealed, it may be Depending on the way that Node Identity is revealed, it may be
difficult to determine parallel subpaths between the same pair of difficult to determine parallel subpaths between the same pair of
hosts (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 hosts. parallel subpaths involving different Nodes.
o If a pair of discovered hosts identify two different addresses, o If a pair of discovered Nodes identify two different addresses,
then they will appear to be different hosts. then they will appear to be different Nodes.
o If a pair of discovered hosts identify two different IP addresses, o If a pair of discovered Nodes identify two different IP addresses,
and the IP addresses resolve to the same host 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 hosts. then they will appear to be the same Nodes.
o If a discovered host always replies using the same network o 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
apply to other hybrid methods based on IOAM.
o If parallel links between routers are aggregated below the IP o If parallel links between routers are aggregated below the IP
layer, In other words, all links share the same pair of IP layer, In other words, all links share the same pair of IP
addresses, then the existence of these parallel links can't be addresses, then the existence of these parallel links can't be
detected at IP layer. This applies to other network domains with detected at IP layer. This applies to other network domains with
layers below them, as well. layers below them, as well.
@@@@ This paragraph on Temporal Composition moved to support a more @@@@ This paragraph on Temporal Composition moved to support a more
complete section on Methodology (section 4). complete section on Methodology (section 4).
When a route assessment employs IP packets (for example), the reality When a route assessment employs IP packets (for example), the reality
skipping to change at page 10, line 17 skipping to change at page 10, line 33
@@@@ The Temporal Measurement and Route Class C (unrelated to address @@@@ The Temporal Measurement and Route Class C (unrelated to address
classes of the past) is now partly addressed in Section 4. classes of the past) is now partly addressed in Section 4.
3.6. Reporting the Metric 3.6. Reporting the Metric
@@@@ now partly addressed, based on feedback at IETF-101: @@@@ now partly addressed, based on feedback at IETF-101:
An Information Model and an XML Data Model for Storing Traceroute An Information Model and an XML Data Model for Storing Traceroute
Measurements is available in [RFC5388]. The measured information at Measurements is available in [RFC5388]. The measured information at
each hop includes four pieces of information: a one-dimensional hop each hop includes four pieces of information: a one-dimensional hop
index, host symbolic address, host IP address, and RTD for each index, Node symbolic address, Node IP address, and RTD for each
response. response.
The description of Hop information that may be collected according to The description of Hop information that may be collected according to
this memo covers more dimensions, as defined in Section 3.3 above. this memo covers more dimensions, as defined in Section 3.3 above.
For example, the Hop index is two-dimensional to capture the For example, the Hop index is two-dimensional to capture the
complexity of a Route Ensemble, and it contains corresponding host complexity of a Route Ensemble, and it contains corresponding Node
identities at a minimum. The models need to be expanded to include identities at a minimum. The models need to be expanded to include
these features, as well as Arrival Interface ID, Departure Interface these features, as well as Arrival Interface ID, Departure Interface
ID, and Arrival Timestamp, when available. ID, and Arrival Timestamp, when available.
@@@@ can we leave updates to RFC 5388 for further work? Or, do we @@@@ can we leave updates to RFC 5388 for further work? Or, do we
need to take-on this topic in an Appendix here? need to take-on this topic in an Appendix here? IETF-105 feedback
indicates that we should collect requirements here, and punt future
work to a YANG model.
4. Route Assessment Methodologies 4. Route Assessment Methodologies
There are two classes of methods described in this section, active There are two classes of methods described in this section, active
methods relying on the reaction to TTL or Hop Limit Exceeded methods relying on the reaction to TTL or Hop Limit Exceeded
condition to discover hosts on a path, and Hybrid active-passive condition to discover Nodes on a path, and Hybrid active-passive
methods that involve direct interrogation of cooperating hosts methods that involve direct interrogation of cooperating Nodes
(usually within a single domain). Description of these methods (usually within a single domain). Description of these methods
follow. follow.
@@@@ Editor's Note: We need to incorporate description of Type-P @@@@ Editor's Note: We need to incorporate description of Type-P
packets (with the flow parameters) used in each method below (done packets (with the flow parameters) used in each method below (done
for Active). for Active).
4.1. Active Methodologies 4.1. Active Methodologies
We have chosen to describe the method based on that employed in We have chosen to describe the method based on that employed in
current open source tools, thereby providing a practical framework current open source tools, thereby providing a practical framework
for further advanced techniques to be included as method variants. for further advanced techniques to be included as method variants.
This method is applicable to use across multiple administrative This method is applicable to use across multiple administrative
domains. domains.
Paris-traceroute [PT] provides some measure of protection from path Paris-traceroute [PT] provides some measure of protection from path
variation generated by ECMP load balancing, and it ensures traceroute variation generated by ECMP load balancing, and it ensures traceroute
packets will follow the same path in 98% of cases according to packets will follow the same path in 98% of cases according to
[SCAMPER]. If it is necessary to find every path possible between [SCAMPER]. If it is necessary to find every path possible between
two hosts, Paris-traceroute provides "exhaustive" mode while scamper two Nodes, Paris-traceroute provides "exhaustive" mode while scamper
provides "tracelb" (stands for traceroute load balance). provides "tracelb" (stands for traceroute load balance).
The Type-P of packets used could be ICMP (as in the original The Type-P of packets used could be ICMP (as in the original
traceroute), UDP or TCP. The later are used when a particular traceroute), UDP or TCP. The later are used when a particular
characteristic needs to be to verified, such as filtering or traffic characteristic needs to be to verified, such as filtering or traffic
shaping on specific ports (i.e., services). [SCAMPER] supports IPv6 shaping on specific ports (i.e., services). [SCAMPER] supports IPv6
traceroute measurements, keeping the FlowLable constant in all traceroute measurements, keeping the FlowLable constant in all
packets. packets.
The advanced route assessment methods used in Paris-traceroute [PT] The advanced route assessment methods used in Paris-traceroute [PT]
skipping to change at page 15, line 17 skipping to change at page 15, line 38
assessment to each Hop on the path between the Observation Point and assessment to each Hop on the path between the Observation Point and
the Destination for the flow of interest may discover high or the Destination for the flow of interest may discover high or
variable delay on a specific link and Hop combination. variable delay on a specific link and Hop combination.
The determination of a Routing Class C which includes the flow of The determination of a Routing Class C which includes the flow of
interest is as described in the section above, aided by computation interest is as described in the section above, aided by computation
of the relevant hash function output as the target. of the relevant hash function output as the target.
@@@@ Comments on this new material are very welcome! @@@@ Comments on this new material are very welcome!
@@@@ This is a topic for investigation at the Hackfest-103
Measurements and Standards table.
4.2. Hybrid Methodologies 4.2. Hybrid Methodologies
The Hybrid Type I methods provide an alternative method for Route The Hybrid Type I methods provide an alternative method for Route
Member assessment. As mentioned in the Scope section, Member assessment. As mentioned in the Scope section,
[I-D.ietf-ippm-ioam-data] provides a possible set of data fields that [I-D.ietf-ippm-ioam-data] provides a possible set of data fields that
would support route identification. would support route identification.
In general, nodes in the measured domain would be equipped with In general, nodes in the measured domain would be equipped with
specific abilities: specific abilities:
skipping to change at page 15, line 43 skipping to change at page 16, line 14
In addition to node identity, nodes may also identify the ingress and In addition to node identity, nodes may also identify the ingress and
egress interfaces utilized by the tracing packet, the time of day egress interfaces utilized by the tracing packet, the time of day
when the packet was processed, and other generic data (as described when the packet was processed, and other generic data (as described
in section 4 of [I-D.ietf-ippm-ioam-data]). in section 4 of [I-D.ietf-ippm-ioam-data]).
4.3. Combining Different Methods 4.3. Combining Different Methods
In principle, there are advantages if the entity conducting Route In principle, there are advantages if the entity conducting Route
measurements can utilize both forms of advanced methods (active and measurements can utilize both forms of advanced methods (active and
hybrid), and combine the results. For example, if there are hosts hybrid), and combine the results. For example, if there are Nodes
involved in the path that qualify as Cooperating Hosts, but not as involved in the path that qualify as Cooperating Nodes, but not as
Discoverable Hosts, then a more complete view of hops on the path is Discoverable Nodes, then a more complete view of hops on the path is
possible when a hybrid method (or interrogation protocol) is applied possible when a hybrid method (or interrogation protocol) is applied
and the results are combined with the active method results collected and the results are combined with the active method results collected
across all other domains. across all other domains.
In order to combine the results of active and hybrid/interrogation In order to combine the results of active and hybrid/interrogation
methods, the network hosts that are part of a domain supporting an methods, the network Nodes that are part of a domain supporting an
interrogation protocol have the following attributes: interrogation protocol have the following attributes:
1. Hosts at the ingress to the domain SHOULD be both Discoverable 1. Nodes at the ingress to the domain SHOULD be both Discoverable
and Cooperating, and SHOULD reveal the same Host Identity in and Cooperating, and SHOULD reveal the same Node Identity in
response to both active and hybrid methods. response to both active and hybrid methods.
2. Any Hosts within the domain that are both Discoverable and 2. Any Nodes within the domain that are both Discoverable and
Cooperating SHOULD reveal the same Host Identity in response to Cooperating SHOULD reveal the same Node Identity in response to
both active and hybrid methods. both active and hybrid methods.
3. Hosts at the egress to the domain SHOULD be both Discoverable and 3. Nodes at the egress to the domain SHOULD be both Discoverable and
Cooperating, and SHOULD reveal the same Host Identity in response Cooperating, and SHOULD reveal the same Node Identity in response
to both active and hybrid methods. to both active and hybrid methods.
When Hosts follow these requirements, it becomes a simple matter to When Nodes follow these requirements, it becomes a simple matter to
match single domain measurements with the overlapping results from a match single domain measurements with the overlapping results from a
multidomain measurement. multidomain measurement.
In practice, Internet users do not typically have the ability to In practice, Internet users do not typically have the ability to
utilize the OAM capabilities of networks that their packets traverse, utilize the OAM capabilities of networks that their packets traverse,
so the results from a remote domain supporting an interrogation so the results from a remote domain supporting an interrogation
protocol would not normally be accessible. However, a network protocol would not normally be accessible. However, a network
operator could combine interrogation results from their access domain operator could combine interrogation results from their access domain
with other measurements revealing the path outside their domain. with other measurements revealing the path outside their domain.
5. Background on Round-Trip Delay Measurement Goals 5. Background on Round-Trip Delay Measurement Goals
The aim of this method is to use packet probes to unveil the paths The aim of this method is to use packet probes to unveil the paths
between any two end-hosts of the network. Moreover, information between any two end-Nodes of the network. Moreover, information
derived from RTD measurements might be meaningful to identify: derived from RTD measurements might be meaningful to identify:
1. Intercontinental submarine links 1. Intercontinental submarine links
2. Satellite communications 2. Satellite communications
3. Congestion 3. Congestion
4. Inter-domain paths 4. Inter-domain paths
skipping to change at page 21, line 9 skipping to change at page 21, line 31
The original 3 authors acknowledge Ruediger Geib, for his penetrating The original 3 authors acknowledge Ruediger Geib, for his penetrating
comments on the initial draft, and his initial text for the comments on the initial draft, and his initial text for the
Appendix on MPLS. Carlos Pignataro challenged the authors to Appendix on MPLS. Carlos Pignataro challenged the authors to
consider a wider scope, and applied his substantial expertise with consider a wider scope, and applied his substantial expertise with
many technologies and their measurement features in his extensive many technologies and their measurement features in his extensive
comments. Frank Brockners also shared useful comments. We thank comments. Frank Brockners also shared useful comments. We thank
them all! them all!
12. Appendix I MPLS Methods for Route Assessment 12. Appendix I MPLS Methods for Route Assessment
A host assessing an MPLS path must be part of the MPLS domain where A Node assessing an MPLS path must be part of the MPLS domain where
the path is implemented. When this condition is met, RFC 8029 the path is implemented. When this condition is met, RFC 8029
provides a powerful set of mechanisms to detect "correct operation of provides a powerful set of mechanisms to detect "correct operation of
the data plane, as well as a mechanism to verify the data plane the data plane, as well as a mechanism to verify the data plane
against the control plane" [RFC8029]. against the control plane" [RFC8029].
MPLS routing is based on the presence of a Forwarding Equivalence MPLS routing is based on the presence of a Forwarding Equivalence
Class (FEC) Stack in all visited hosts. Selecting one of several Class (FEC) Stack in all visited Nodes. Selecting one of several
Equal Cost Multi Path (ECMP) is however based on information hidden Equal Cost Multi Path (ECMP) is however based on information hidden
deeper in the stack. Early deployments may support a so called deeper in the stack. Early deployments may support a so called
"Entropy label" for this purpose. State of the art deployments base "Entropy label" for this purpose. State of the art deployments base
their choice of an ECMP member based on the IP addresses (see their choice of an ECMP member based on the IP addresses (see
Section 2.4 of [RFC7325]). Both methods allow load sharing Section 2.4 of [RFC7325]). Both methods allow load sharing
information to be decoupled from routing information. Thus, an MPLS information to be decoupled from routing information. Thus, an MPLS
traceroute is able to check how packets with a contiguous number of traceroute is able to check how packets with a contiguous number of
ECMP relevant addresses (and the same destination) are routed by a ECMP relevant addresses (and the same destination) are routed by a
particular router. The minimum number of MPLS paths traceable at a particular router. The minimum number of MPLS paths traceable at a
router should be 32. Implementations supporting more paths are router should be 32. Implementations supporting more paths are
skipping to change at page 22, line 4 skipping to change at page 22, line 21
assessment. assessment.
RFC to be 8403 (draft-ietf-spring-oam-usecase-10) explains how a RFC to be 8403 (draft-ietf-spring-oam-usecase-10) explains how a
central Path Monitoring System could be used to detect arbitrary MPLS central Path Monitoring System could be used to detect arbitrary MPLS
paths between any routers within a single MPLS domain. The paths between any routers within a single MPLS domain. The
combination of MPLS forwarding, Segment Routing and MPLS traceroute combination of MPLS forwarding, Segment Routing and MPLS traceroute
offers a simple architecture and a powerful mechanism to detect and offers a simple architecture and a powerful mechanism to detect and
validate (segment routed) MPLS paths. validate (segment routed) MPLS paths.
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-ippm-ioam-data] [I-D.ietf-ippm-ioam-data]
Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., Brockners, F., Bhandari, S., Pignataro, C., Gredler, H.,
Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov,
P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon,
"Data Fields for In-situ OAM", draft-ietf-ippm-ioam- "Data Fields for In-situ OAM", draft-ietf-ippm-ioam-
data-04 (work in progress), October 2018. data-07 (work in progress), September 2019.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981, RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/info/rfc792>. <https://www.rfc-editor.org/info/rfc792>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989, DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>. <https://www.rfc-editor.org/info/rfc1122>.
skipping to change at page 25, line 6 skipping to change at page 25, line 29
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
13.2. Informative References 13.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", In Proceedings of the 2016 ACM on Internet Networks", In Proceedings of the 2016 ACM on Internet
Measurement Conference, pp. 381-396. ACM, 2016. Measurement Conference, pp. 381-396. ACM, 2016.
[IDCong] Luckie, M., Dhamdhere, A., Clark, D., and B. Huffaker, [IDCong] Luckie, M., Dhamdhere, A., Clark, D., and B. Huffaker,
"Challenges in inferring Internet interdomain congestion", "Challenges in inferring Internet interdomain
In Proceedings of the 2014 Conference on Internet congestion", In Proceedings of the 2014 Conference on
Measurement Conference, pp. 15-22. ACM, 2014. Internet Measurement Conference, pp. 15-22. ACM, 2014.
[MLB] Augustin, B., Friedman, T., and R. Teixeira, "Measuring [MLB] Augustin, B., Friedman, T., and R. Teixeira, "Measuring
load-balanced paths in the Internet", Proceedings of the load-balanced paths in the Internet", Proceedings of the
7th ACM SIGCOMM conference on Internet measurement, pp. 7th ACM SIGCOMM conference on Internet measurement, pp.
149-160. ACM, 2007., 2007. 149-160. ACM, 2007., 2007.
[MLRM] Fontugne, R., Mazel, J., and K. Fukuda, "An empirical [MLRM] Fontugne, R., Mazel, J., and K. Fukuda, "An empirical
mixture model for large-scale RTT measurements", 2015 mixture model for large-scale RTT measurements", 2015
IEEE Conference on Computer Communications (INFOCOM), pp. IEEE Conference on Computer Communications (INFOCOM), pp.
2470-2478. IEEE, 2015., 2015. 2470-2478. IEEE, 2015., 2015.
skipping to change at page 25, line 48 skipping to change at page 26, line 22
Measurement of Broadband Performance (LMAP)", RFC 7594, Measurement of Broadband Performance (LMAP)", RFC 7594,
DOI 10.17487/RFC7594, September 2015, DOI 10.17487/RFC7594, September 2015,
<https://www.rfc-editor.org/info/rfc7594>. <https://www.rfc-editor.org/info/rfc7594>.
[RTTSub] Bischof, Z., Rula, J., and F. Bustamante, "In and out of [RTTSub] Bischof, Z., Rula, J., and F. Bustamante, "In and out of
Cuba: Characterizing Cuba's connectivity", In Proceedings Cuba: Characterizing Cuba's connectivity", In Proceedings
of the 2015 ACM Conference on Internet Measurement of the 2015 ACM Conference on Internet Measurement
Conference, pp. 487-493. ACM, 2015. Conference, pp. 487-493. ACM, 2015.
[SCAMPER] Matthew Luckie, M., "Scamper: a scalable and extensible [SCAMPER] Matthew Luckie, M., "Scamper: a scalable and extensible
packet prober for active measurement of the Internet", packet prober for active measurement of the
Proceedings of the 10th ACM SIGCOMM conference on Internet", Proceedings of the 10th ACM SIGCOMM conference
Internet measurement, pp. 239-245. ACM, 2010., 2010. on Internet measurement, pp. 239-245. ACM, 2010., 2010.
[SSNT] Park, K. and W. Willinger, "Self-Similar Network Traffic [SSNT] Park, K. and W. Willinger, "Self-Similar Network Traffic
and Performance Evaluation (1st ed.)", John Wiley & Sons, and Performance Evaluation (1st ed.)", John Wiley & Sons,
Inc., New York, NY, USA, 2000. Inc., New York, NY, USA, 2000.
Authors' Addresses Authors' Addresses
Jose Ignacio Alvarez-Hamelin Jose Ignacio Alvarez-Hamelin
Universidad de Buenos Aires Universidad de Buenos Aires
Av. Paseo Colon 850 Av. Paseo Colon 850
 End of changes. 55 change blocks. 
87 lines changed or deleted 95 lines changed or added

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