draft-ietf-ippm-route-00.txt   draft-ietf-ippm-route-01.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: July 9, 2018 J. Fabini Expires: August 20, 2018 J. Fabini
TU Wien TU Wien
C. Pignataro C. Pignataro
Cisco Systems, Inc. Cisco Systems, Inc.
January 5, 2018 February 16, 2018
Advanced Unidirectional Route Assessment (AURA) Advanced Unidirectional Route Assessment (AURA)
draft-ietf-ippm-route-00 draft-ietf-ippm-route-01
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 1, line 47 skipping to change at page 1, line 47
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 July 9, 2018. This Internet-Draft will expire on August 20, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 28 skipping to change at page 2, line 28
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
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 . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Formal Name . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Metric Definitions . . . . . . . . . . . . . . . . . . . 6 3.3. Metric Definitions . . . . . . . . . . . . . . . . . . . 7
3.4. Related Round-Trip Delay and Loss Definitions . . . . . . 8 3.4. Related Round-Trip Delay and Loss Definitions . . . . . . 8
3.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . 8 3.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . 9
3.6. Reporting the Metric . . . . . . . . . . . . . . . . . . 9 3.6. Reporting the Metric . . . . . . . . . . . . . . . . . . 10
4. Route Assessment Methodologies . . . . . . . . . . . . . . . 9 4. Route Assessment Methodologies . . . . . . . . . . . . . . . 10
4.1. Active Methodologies . . . . . . . . . . . . . . . . . . 10 4.1. Active Methodologies . . . . . . . . . . . . . . . . . . 10
4.2. Hybrid Methodologies . . . . . . . . . . . . . . . . . . 11 4.2. Hybrid Methodologies . . . . . . . . . . . . . . . . . . 12
4.3. Combining Different Methods . . . . . . . . . . . . . . . 12 4.3. Combining Different Methods . . . . . . . . . . . . . . . 12
5. Background on Round-Trip Delay Measurement Goals . . . . . . 13 5. Background on Round-Trip Delay Measurement Goals . . . . . . 13
6. Tools to Measure Delays in the Internet . . . . . . . . . . . 14 6. Tools to Measure Delays in the Internet . . . . . . . . . . . 14
7. RTD Measurements Statistics . . . . . . . . . . . . . . . . . 15 7. RTD Measurements Statistics . . . . . . . . . . . . . . . . . 15
8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
12.1. Normative References . . . . . . . . . . . . . . . . . . 17 12.1. Normative References . . . . . . . . . . . . . . . . . . 18
12.2. Informative References . . . . . . . . . . . . . . . . . 20 12.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
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
skipping to change at page 4, line 24 skipping to change at page 4, line 24
The refined definition of Route metrics begins in the sections that The refined definition of Route metrics begins in the sections that
follow. follow.
2. Scope 2. Scope
The purpose of this memo is to add new route metrics and methods of The purpose of this memo is to add new route metrics and methods of
measurement to the existing set of IPPM metrics. measurement to the existing set of IPPM metrics.
The scope is to define route metrics that can identify the path taken The scope is to define route metrics that can identify the path taken
by a packet or a flow traversing the Internet between any two hosts. by a packet or a flow traversing the Internet between two hosts.
Although primarily intended for hosts communicating on the Internet
<@@@@ or only hosts communicating at the IP layer? We would have to with IP, the definitions and metrics are constructed to be applicable
re-define the Src and Dst Parameters and Host Identity if we to other network domains, if desired.
generalize beyond IP. Should we include MPLS and the capabilities of
[RFC8029], with explicit multipath identification (section 6.2.6)? >
Also, to specify a framework for active methods of measurement which Also, to specify a framework for active methods of measurement which
use the techniques described in [PT] at a minimum, and a framework use the techniques described in [PT] at a minimum, and a framework
for hybrid active-passive methods of measurement, such as the Hybrid for hybrid active-passive methods of measurement, such as the Hybrid
Type I method [RFC7799] described in Type I method [RFC7799] described in
[I-D.ietf-ippm-ioam-data](intended only for single administrative [I-D.ietf-ippm-ioam-data](intended only for single administrative
domains), which do not rely on ICMP and provide a protocol for domains), which do not rely on ICMP and provide a protocol for
explicit interrogation of nodes on a path. Combinations of active explicit interrogation of nodes on a path. Combinations of active
methods and hybrid active-passive methods are also in-scope. methods and hybrid active-passive methods are also in-scope.
skipping to change at page 5, line 21 skipping to change at page 5, line 17
host that generates the ICMP response. Therefore, the ICMP-based host that generates the ICMP response. Therefore, the ICMP-based
active methods are not supposed to yield accurate, reproducible active methods are not supposed to yield accurate, reproducible
estimations of the round-trip delay that UDP or TCP packets will estimations of the round-trip delay that UDP or TCP packets will
experience. 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:
Note: the definitions concentrate on the IP-layer, but can be Host Identity The unique address for hosts communicating within the
extended to other layers, and follow agreements on the scope. network domain. For hosts communicating on the Internet with IP,
it is the globally routable IP address(es) which the host uses
Host Identity For hosts communicating at the IP-layer, the globally when communicating with other hosts under normal or error
routable IP address(es) which the host uses when communicating conditions. The Host Identity revealed (and its connection to a
with other hosts under normal or error conditions. The Host Host Name through reverse DNS) determines whether interfaces to
Identity revealed (and its connection to a Host Name through parallel links can be associated with a single host, or appear to
reverse DNS) determines whether interfaces to parallel links can identify unique hosts.
be associated with a single host, or appear to be unique hosts.
Discoverable Host For hosts communicating at the IP-layer, Discoverable Host Hosts that convey their Host Identity according to
compliance with Section 3.2.2.4 of [RFC1122] when discarding a the requirements of their network domain, such as when error
packet due to TTL or Hop Limit Exceeded condition, MUST result in conditions are detected by that host. For hosts communicating
sending the corresponding Time Exceeded message (containing a form with IP packets, compliance with Section 3.2.2.4 of [RFC1122] when
of host identity) to the source. This requirement is also discarding a packet due to TTL or Hop Limit Exceeded condition,
consistent with section 5.3.1 of [RFC1812] for routers. MUST result in sending the corresponding Time Exceeded message
(containing a form of host identity) to the source. This
requirement is also consistent with section 5.3.1 of [RFC1812] for
routers.
Cooperating Host Hosts MUST respond to direct queries for their host Cooperating Host Hosts MUST respond to direct queries for their host
identity as part of a previously agreed and established identity as part of a previously agreed and established
interrogation protocol. Hosts SHOULD also provide information interrogation protocol. Hosts 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 host or specific
link which delivered the query to the host. link which delivered the query to the host.
Hop A Hop MUST contain a Host Identity, and MAY contain arrival and/ Hop A Hop MUST contain a Host Identity, and MAY contain arrival and/
or departure interface identification. or departure interface identification.
skipping to change at page 6, line 10 skipping to change at page 6, line 10
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 IP address of a host o Src, the address of a host (such as the globally routable IP
address).
o Dst, the IP address of a host o Dst, the address of a host (such as the globally routable IP
address).
o i, the TTL or Hop Limit of a packet sent from the host at Src to o i, the limit on the number of Hops a packet may visit as it
the host at Dst. traverses from the host at Src to the host at Dst (such as the 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 host time of a packet as measured at MP(Src), meaning
Measurement Point at the Source. Measurement Point at the Source.
skipping to change at page 7, line 17 skipping to change at page 7, line 24
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 Hosts (or Cooperating Hosts) that are i hops away from
the host with IP address = Src during the measurement interval, T0 to the host 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 Host Identity, hid(i,j), and MAY contain one or more of the following
attributes: attributes:
o a(i,j) Arrival Interface ID o a(i,j) Arrival Interface ID
o d(i,j) Departure Interface ID o d(i,j) Departure Interface ID
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
skipping to change at page 7, line 48 skipping to change at page 8, line 7
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 host at Src address to the host
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:
A Member Route is an ordered graph {h(1,j), ... h(Nj, j)} in the A Member Route is an ordered graph {h(1,j), ... h(Nj, j)} in the
context of a single flow, where h(i-1, j) and h(i, j) are by 1 hop context of a single flow, where h(i-1, j) and h(i, j) are by 1 hop
away from each other and Nj=Dst is the minimum TTL value needed by away from each other and Nj=Dst is the minimum count of hops needed
the packet on Member Route j to reach Dst. Member Routes must be by the packet on Member Route j to reach Dst. Member Routes must be
unique. This uniqueness requires that any two Member routes j and k unique. The uniqueness property requires that any two Member routes
that are part of the same Route Ensemble differ either in terms of j and k that are part of the same Route Ensemble differ either in
minimum hop count Nj and Nk to reach the destination Dst, or, in the terms of minimum hop count Nj and Nk to reach the destination Dst,
case of identical hop count Nj=Nk, they have at least one distinct or, in the case of identical hop count Nj=Nk, they have at least one
hop: h(i,j) != h(i, k) for at least one i (i=1..Nj). distinct hop: h(i,j) != h(i, k) for at least one i (i=1..Nj).
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 hosts with Src and Dst addresses. More formally,
with the host having address Src omitted: with the host 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},
... ...
skipping to change at page 8, line 34 skipping to change at page 8, line 42
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 IP address = Src and the host at Hop Delay between the host with address = Src and the host at Hop h(i,j)
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 IP address = Src and the host at Hop h(i,j) at between the host with address = Src and the host 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 Host 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 hosts (i.e. multiple parallel links). It is easier to detect
parallel subpaths involving different hosts. parallel subpaths involving different hosts.
o If a pair of discovered hosts identify two different IP addresses, o If a pair of discovered hosts identify two different addresses,
then they will appear to be different hosts. then they will appear to be different hosts.
o If a pair of discovered hosts identify two different IP addresses, o If a pair of discovered hosts 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 host name (in the DNS),
then they will appear to be the same hosts. then they will appear to be the same hosts.
o If a discovered host always replies using the same IP address, o If a discovered host always replies using the same network
regardless of the interface a packet arrives on, then multiple address, regardless of the interface a packet arrives on, then
parallel links cannot be detected at the IP layer. multiple parallel links cannot be detected in that network domain.
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. detected at IP layer. This applies to other network domains with
layers below them, as well.
Section 9.2 of [RFC2330] describes Temporal Composition of metrics, Section 9.2 of [RFC2330] describes Temporal Composition of metrics,
and introduces the possibility of a relationship between earlier and introduces the possibility of a relationship between earlier
measurement results and the results for measurement at the current measurement results and the results for measurement at the current
time (for a given metric). If this topic is investigated further, time (for a given metric). If this topic is investigated further,
there may be some value in establishing a Temporal Composition there may be some value in establishing a Temporal Composition
relationship for Route Metrics. However, this relationship does not relationship for Route Metrics. However, this relationship does not
represent a forecast of future route conditions in any way. represent a forecast of future route conditions in any way.
When a route assessment employs packets at the IP layer (for When a route assessment employs IP packets (for example), the reality
example), the reality of flow assignment to parallel subpaths of flow assignment to parallel subpaths involves layers above IP.
involves layers above IP. Thus, the measured Route Ensemble is Thus, the measured Route Ensemble is applicable to IP and higher
applicable to IP and higher layers (as described in the methodology's layers (as described in the methodology's packet of Type-P and flow
packet of Type-P and flow parameters). parameters).
@@@@ Editor's Note: There is an opportunity to investigate and @@@@ Editor's Note: There is an opportunity to investigate and
discuss the RFC 2330 notion of equal treatment for a class of discuss the RFC 2330 notion of equal treatment for a class of
packets, "...very useful to know if a given Internet component treats packets, "...very useful to know if a given Internet component treats
equally a class C of different types of packets", as it applies to equally a class C of different types of packets", as it applies to
Route measurements. Knowledge of "class C" parameters on a path Route measurements. Knowledge of "class C" parameters on a path
potentially reduces the number of flows required for a given method. potentially reduces the number of flows required for a given method.
3.6. Reporting the Metric 3.6. Reporting the Metric
 End of changes. 23 change blocks. 
58 lines changed or deleted 62 lines changed or added

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