draft-ietf-ippm-route-03.txt   draft-ietf-ippm-route-04.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: April 25, 2019 J. Fabini Expires: September 10, 2019 J. Fabini
TU Wien TU Wien
C. Pignataro C. Pignataro
Cisco Systems, Inc. Cisco Systems, Inc.
R. Geib R. Geib
Deutsche Telekom Deutsche Telekom
October 22, 2018 March 9, 2019
Advanced Unidirectional Route Assessment (AURA) Advanced Unidirectional Route Assessment (AURA)
draft-ietf-ippm-route-03 draft-ietf-ippm-route-04
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 April 25, 2019. This Internet-Draft will expire on September 10, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 43 skipping to change at page 2, line 43
4. Route Assessment Methodologies . . . . . . . . . . . . . . . 10 4. Route Assessment Methodologies . . . . . . . . . . . . . . . 10
4.1. Active Methodologies . . . . . . . . . . . . . . . . . . 10 4.1. Active Methodologies . . . . . . . . . . . . . . . . . . 10
4.1.1. Temporal Composition for Route Metrics . . . . . . . 12 4.1.1. Temporal Composition for Route Metrics . . . . . . . 12
4.1.2. Routing Class C Identification . . . . . . . . . . . 13 4.1.2. Routing Class C Identification . . . . . . . . . . . 13
4.1.3. Intermediate Observation Point Route Measurement . . 14 4.1.3. Intermediate Observation Point Route Measurement . . 14
4.2. Hybrid Methodologies . . . . . . . . . . . . . . . . . . 15 4.2. Hybrid Methodologies . . . . . . . . . . . . . . . . . . 15
4.3. Combining Different Methods . . . . . . . . . . . . . . . 15 4.3. Combining Different Methods . . . . . . . . . . . . . . . 15
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 . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
12. Appendix I MPLS Methods for Route Assessment . . . . . . . . 20 12. Appendix I MPLS Methods for Route Assessment . . . . . . . . 21
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
13.1. Normative References . . . . . . . . . . . . . . . . . . 21 13.1. Normative References . . . . . . . . . . . . . . . . . . 22
13.2. Informative References . . . . . . . . . . . . . . . . . 24 13.2. Informative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 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 7, line 8 skipping to change at page 7, line 8
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.
o flow, the stream of packets with the same n-tuple of designated o flow, the stream of packets with the same n-tuple of designated
header fields that (when held constant) result in identical header fields that (when held constant) result in identical
treatment in a multi-path decision (such as the decision taken in treatment in a multi-path decision (such as the decision taken in
load balancing). load balancing). Note: The IPv6 flow label MAY be included in the
flow definition when routers have complied with [RFC6438]
guidelines at the Tunnel End Points (TEP), and the source of the
measurement is a TEP.
o Type-P, the complete description of the packets for which this o Type-P, the complete description of the packets for which this
assessment applies (including the flow-defining fields). assessment applies (including the flow-defining fields).
3.3. Metric Definitions 3.3. Metric Definitions
This section defines the REQUIRED measurement components of the Route This section defines the REQUIRED measurement components of the Route
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.
skipping to change at page 7, line 37 skipping to change at page 7, line 40
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 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 (e.g., when [RFC5837] is supported)
o d(i,j) Departure Interface ID 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 Host 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 Host Identities and related information can be positioned
skipping to change at page 14, line 49 skipping to change at page 14, line 51
@@@@ Comments on this material are very welcome! Especially @@@@ Comments on this material are very welcome! Especially
suggestions for tools that might lend themselves to support these suggestions for tools that might lend themselves to support these
measurements. measurements.
4.1.3. Intermediate Observation Point Route Measurement 4.1.3. Intermediate Observation Point Route Measurement
There are many examples where passive monitoring of a flow at an There are many examples where passive monitoring of a flow at an
Observation Point within the network can detect unexpected Round Trip Observation Point within the network can detect unexpected Round Trip
Delay or Delay Variation. But how can the cause of the anomolous Delay or Delay Variation. But how can the cause of the anomolous
dely be investigated further --from the Observation Point -- possibly dely be investigated further --from the Observation Point -- possibly
located at an intermediate poin on the path? located at an intermediate point on the path?
In this case, knowledge that the flow of interest belongs to a In this case, knowledge that the flow of interest belongs to a
specific Routing Class C will enable mesurement of the route where specific Routing Class C will enable mesurement of the route where
anomolous delay has been observed. Specifically, Round Trip Delay anomolous delay has been observed. Specifically, Round Trip Delay
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.
skipping to change at page 15, line 28 skipping to change at page 15, line 30
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:
o Support of the "Loopback" Flag (L-bit), where a copy of the packet
is returned to the source, and the packet is processed like any
other IOAM packet on the return transfer.
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 hosts
skipping to change at page 16, line 40 skipping to change at page 16, line 48
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
This categorization is widely accepted in the literature and among This categorization is widely accepted in the literature and among
operators alike, and it can be trusted with empirical data and operators alike, and it can be trusted with empirical data and
several sources as ground of truth (e.g., [RTTSub] [bdrmap][IDCong]). several sources as ground of truth (e.g., [RTTSub] ) but it is an
inference measurement nonetheless [bdrmap][IDCong].
The first two categories correspond to the physical distance The first two categories correspond to the physical distance
dependency on Round Trip Delay (RTD) while the last one binds RTD dependency on Round Trip Delay (RTD) while the last one binds RTD
with queueing delay on routers. Due to the significant contribution with queueing delay on routers. Due to the significant contribution
of propagation delay in long distance hops, RTD will be at least of propagation delay in long distance hops, RTD will be on the order
100ms on transatlantic hops, depending on the geolocation of the of 100ms on transatlantic hops, depending on the geolocation of the
vantage points. Moreover, RTD is typically greater than 480ms when vantage points. Moreover, RTD is typically greater than 480ms when
two hops are connected using geostationary satellite technology two hops are connected using geostationary satellite technology
(i.e., their orbit is at 36000km). Detecting congestion with latency (i.e., their orbit is at 36000km). Detecting congestion with latency
implies deeper mathematical understanding since network traffic load implies deeper mathematical understanding since network traffic load
is not stationary. Nonetheless, as the first approach, a link seems is not stationary. Nonetheless, as the first approach, a link seems
to be congested if after sending several traceroute probes, it is to be congested if after sending several traceroute probes, it is
possible to detect congestion observing different statistics possible to detect congestion observing different statistics
parameters (e.g., see [IDCong]). parameters (e.g., see [IDCong]).
6. Tools to Measure Delays in the Internet 6. Tools to Measure Delays in the Internet
skipping to change at page 23, line 24 skipping to change at page 23, line 34
[RFC5644] Stephan, E., Liang, L., and A. Morton, "IP Performance [RFC5644] Stephan, E., Liang, L., and A. Morton, "IP Performance
Metrics (IPPM): Spatial and Multicast", RFC 5644, Metrics (IPPM): Spatial and Multicast", RFC 5644,
DOI 10.17487/RFC5644, October 2009, DOI 10.17487/RFC5644, October 2009,
<https://www.rfc-editor.org/info/rfc5644>. <https://www.rfc-editor.org/info/rfc5644>.
[RFC5835] Morton, A., Ed. and S. Van den Berghe, Ed., "Framework for [RFC5835] Morton, A., Ed. and S. Van den Berghe, Ed., "Framework for
Metric Composition", RFC 5835, DOI 10.17487/RFC5835, April Metric Composition", RFC 5835, DOI 10.17487/RFC5835, April
2010, <https://www.rfc-editor.org/info/rfc5835>. 2010, <https://www.rfc-editor.org/info/rfc5835>.
[RFC5837] Atlas, A., Ed., Bonica, R., Ed., Pignataro, C., Ed., Shen,
N., and JR. Rivers, "Extending ICMP for Interface and
Next-Hop Identification", RFC 5837, DOI 10.17487/RFC5837,
April 2010, <https://www.rfc-editor.org/info/rfc5837>.
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
DOI 10.17487/RFC6282, September 2011, DOI 10.17487/RFC6282, September 2011,
<https://www.rfc-editor.org/info/rfc6282>. <https://www.rfc-editor.org/info/rfc6282>.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", RFC 6437, "IPv6 Flow Label Specification", RFC 6437,
DOI 10.17487/RFC6437, November 2011, DOI 10.17487/RFC6437, November 2011,
<https://www.rfc-editor.org/info/rfc6437>. <https://www.rfc-editor.org/info/rfc6437>.
[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label
for Equal Cost Multipath Routing and Link Aggregation in
Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011,
<https://www.rfc-editor.org/info/rfc6438>.
[RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and
M. Bhatia, "A Uniform Format for IPv6 Extension Headers", M. Bhatia, "A Uniform Format for IPv6 Extension Headers",
RFC 6564, DOI 10.17487/RFC6564, April 2012, RFC 6564, DOI 10.17487/RFC6564, April 2012,
<https://www.rfc-editor.org/info/rfc6564>. <https://www.rfc-editor.org/info/rfc6564>.
[RFC6673] Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673, [RFC6673] Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673,
DOI 10.17487/RFC6673, August 2012, DOI 10.17487/RFC6673, August 2012,
<https://www.rfc-editor.org/info/rfc6673>. <https://www.rfc-editor.org/info/rfc6673>.
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing
 End of changes. 18 change blocks. 
17 lines changed or deleted 34 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/