draft-ietf-ippm-route-06.txt   draft-ietf-ippm-route-07.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: May 6, 2020 J. Fabini Expires: June 13, 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
November 3, 2019 December 11, 2019
Advanced Unidirectional Route Assessment (AURA) Advanced Unidirectional Route Assessment (AURA)
draft-ietf-ippm-route-06 draft-ietf-ippm-route-07
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 May 6, 2020. This Internet-Draft will expire on June 13, 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 45 skipping to change at page 2, line 45
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 . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . 21 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 18, line 16 skipping to change at page 18, line 16
maintain constant checksum in every packet. On the other hand, when maintain constant checksum in every packet. On the other hand, when
UDP probes are generated, the expected variation in the checksum of UDP probes are generated, the expected variation in the checksum of
each packet is again compensated by manipulating the payload. each packet is again compensated by manipulating the payload.
Paris-traceroute allows its users to measure RTD in every hop of the Paris-traceroute allows its users to measure RTD in every hop of the
path for a particular flow. Furthermore, either Paris-traceroute or path for a particular flow. Furthermore, either Paris-traceroute or
Scamper is capable of unveiling the many available paths between a Scamper is capable of unveiling the many available paths between a
source and destination (which are visible to this method). This task source and destination (which are visible to this method). This task
is accomplished by repeating complete traceroute measurements with is accomplished by repeating complete traceroute measurements with
different flow parameters for each measurement. The Framework for IP different flow parameters for each measurement. The Framework for IP
Performance Metrics (IPPM) ([RFC2330] updated by[RFC7312]) has the Performance Metrics (IPPM) ([RFC2330] updated by [RFC7312]) has the
flexibility to require that the Round-Trip Delay measurement flexibility to require that the Round-Trip Delay measurement
[RFC2681] uses packets with the constraints to assure that all [RFC2681] uses packets with the constraints to assure that all
packets in a single measurement appear as the same flow. This packets in a single measurement appear as the same flow. This
flexibility covers ICMP, UDP, and TCP. The accompanying methodology flexibility covers ICMP, UDP, and TCP. The accompanying methodology
of [RFC2681] needs to be expanded to report the sequential hop of [RFC2681] needs to be expanded to report the sequential hop
identifiers along with RTD measurements, but no new metric definition identifiers along with RTD measurements, but no new metric definition
is needed. is needed.
7. RTD Measurements Statistics 7. RTD Measurements Statistics
skipping to change at page 19, line 17 skipping to change at page 19, line 17
methods of computing quartiles because they need to use the whole methods of computing quartiles because they need to use the whole
dataset to compute the values. This way of calculus provides savings dataset to compute the values. This way of calculus provides savings
in memory and computing time. in memory and computing time.
To sum up, the proposed measurement procedure consists in performing To sum up, the proposed measurement procedure consists in performing
traceroutes several times to obtain samples of the RTD in every hop traceroutes several times to obtain samples of the RTD in every hop
from a path, during a time window (W) and compute the quantiles for from a path, during a time window (W) and compute the quantiles for
every hop. This could be done for a single Member Route flow or for every hop. This could be done for a single Member Route flow or for
every detected Route Ensemble flow. every detected Route Ensemble flow.
Even though a particular hop may be understood as the amount of hops The identification of a specific Hop in traceroute is based on the IP
away from the source, a more detailed classification could be used. origin address of the returned ICMP Time Exceeded packet, and on the
For example, a possible classification may be identify ICMP Time distance identified by the value set in the TTL field inserted by
Exceeded packets coming from the same routers to those who have the traceroute. As this specific Hop can be reached by different paths,
same hop distance, IP address of the router which is replying and TTL also the IP source and destination addresses of the traceroute packet
or Hop Limit value of the received ICMP packet. need to be recorded. Finally, different return paths are
distinguished by evaluating the ICMP Time Exceeded TTL (of the reply
message): if this TTL is constant for different paths containing the
same Hop, the return paths have the same distance. Moreover, this
distance can be estimated considering that the TTL value is normally
initialized with values 64, 128, or 255. The 5-tuple (origin IP,
destination IP, reply IP, distance, response TTL) univocally
identifies every measurement.
Thus, the proposed methodology is based on this algorithm: This algorithm below runs in the origin of the traceroute. It
returns the Qs quartiles for every Hop and Alt (alternative paths
because of balancing). The following parameters are used: W window
time of the measurement, i_t time between two measurements, Dst
destination IP address.
================================================================ ================================================================
1 input: W (window time of the measurement) 1 input: W (window time of the measurement)
2 i_t (time between two measurements) 2 i_t (time between two measurements)
3 E (True: exhaustive, False: a single path) 3 E (True: exhaustive, False: a single path)
4 Dst (destination IP address) 4 Dst (destination IP address)
5 output: Qs (quartiles for every hop and alt in the path(s) to Dst) 5 output: Qs (quartiles for every Hop and Alt)
---------------------------------------------------------------- ----------------------------------------------------------------
6 T <? start_timer(W) 6 T := start_timer(W)
7 while T is not finished do: 7 while T is not finished do:
8 | start_timer(i_t) 8 | start_timer(i_t)
9 | RTD(hop,alt) = advanced-traceroute(Dst,E) 9 | RTD(Hop,Alt) = advanced-traceroute(Dst,E)
10 | for each hop and alt in RTD do: 10 | for each Hop and Alt in RTD do:
11 | | Qs[Dst,hop,alt] <? ComputeQs(RTD(hop,alt)) 11 | | Qs[Dst,Hop,Alt] := ComputeQs(RTD(Hop,Alt))
12 | done 12 | done
13 | wait until i_t timer is expired 13 | wait until i_t timer is expired
14 done 14 done
15 return (Qs) 15 return (Qs)
================================================================ ================================================================
In line 9 the advance-traceroute could be either Paris-traceroute or During the time W, lines 6 and 7 assure that the measurement loop is
Scamper, which will use "exhaustive" mode or "tracelb" option if E is made. Line 8 and 13 set a timer for each cycle of measurements. A
set True, respectively. The procedure returns a list of tuples cycle comprises the traceroutes packets, considering every possible
(m,Q1,Q2,Q3,M) for each intermediate hop in the path towards the Dst. Hop and the alternatives paths in the Alt variable (ensured in lines
Additionally, it could also return path variations using "alt" 9-12). In line 9 the advance-traceroute could be either Paris-
variable. traceroute or Scamper, which will use "exhaustive" mode or "tracelb"
option if E is set True, respectively. The procedure returns a list
of tuples (m,Q1,Q2,Q3,M) for each intermediate hop in the path
towards the Dst. Additionally, it could also return path variations
using "alt" variable.Finally, lines 10 and 12 stores each measurement
into the real-time quartiles computation.
8. Conclusions 8. Conclusions
Combining the method proposed in Section 4 and statistics in Combining the method proposed in Section 4 and statistics in
Section 7, we can measure the performance of paths interconnecting Section 7, we can measure the performance of paths interconnecting
two endpoints in Internet, and attempt the categorization of link two endpoints in Internet, and attempt the categorization of link
types and congestion presence based on RTD. types and congestion presence based on RTD.
9. Security Considerations 9. Security Considerations
 End of changes. 11 change blocks. 
41 lines changed or deleted 57 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/