draft-ietf-ippm-route-02.txt   draft-ietf-ippm-route-03.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: January 3, 2019 J. Fabini Expires: April 25, 2019 J. Fabini
TU Wien TU Wien
C. Pignataro C. Pignataro
Cisco Systems, Inc. Cisco Systems, Inc.
July 2, 2018 R. Geib
Deutsche Telekom
October 22, 2018
Advanced Unidirectional Route Assessment (AURA) Advanced Unidirectional Route Assessment (AURA)
draft-ietf-ippm-route-02 draft-ietf-ippm-route-03
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 48 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 January 3, 2019.
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 29 skipping to change at page 2, line 30
Table of Contents Table of Contents
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 . . . . . . 8 3.4. Related Round-Trip Delay and Loss Definitions . . . . . . 9
3.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . 9 3.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . 9
3.6. Reporting the Metric . . . . . . . . . . . . . . . . . . 9 3.6. Reporting the Metric . . . . . . . . . . . . . . . . . . 10
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.2. Hybrid Methodologies . . . . . . . . . . . . . . . . . . 14 4.1.3. Intermediate Observation Point Route Measurement . . 14
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 . . . . . . . . . . . 16 6. Tools to Measure Delays in the Internet . . . . . . . . . . . 17
7. RTD Measurements Statistics . . . . . . . . . . . . . . . . . 18 7. RTD Measurements Statistics . . . . . . . . . . . . . . . . . 18
8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 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 . . . . . . . . 20
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
13.1. Normative References . . . . . . . . . . . . . . . . . . 21 13.1. Normative References . . . . . . . . . . . . . . . . . . 21
13.2. Informative References . . . . . . . . . . . . . . . . . 24 13.2. Informative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
skipping to change at page 6, line 8 skipping to change at page 6, line 8
routers. 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, round trip delay, and an
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
skipping to change at page 8, line 13 skipping to change at page 8, line 13
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 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 When considering the set of Hops in the context of a single flow, a
context of a single flow, where h(i-1, j) and h(i, j) are by 1 hop Member Route j is an ordered list {h(1,j), ... h(Nj, j)} where h(i-1,
away from each other and Nj=Dst is the minimum count of hops needed j) and h(i, j) are by 1 hop away from each other and Nj satisfying
by the packet on Member Route j to reach Dst. Member Routes must be h(Nj,j)=Dst is the minimum count of hops needed by the packet on
unique. The uniqueness property requires that any two Member routes Member Route j to reach Dst. Member Routes must be unique. The
j and k that are part of the same Route Ensemble differ either in uniqueness property requires that any two Member routes j and k that
terms of minimum hop count Nj and Nk to reach the destination Dst, are part of the same Route Ensemble differ either in terms of minimum
or, in the case of identical hop count Nj=Nk, they have at least one hop count Nj and Nk to reach the destination Dst, or, in the case of
distinct hop: h(i,j) != h(i, k) for at least one i (i=1..Nj). identical hop count Nj=Nk, they have at least one distinct hop:
h(i,j) != h(i, k) for at least one i (i=1..Nj).
All the optional information collected to describe a Member Route,
such as the arrival interface, departure interface, and Round Trip
Delay at each Hop, turs each list item into a rich structure. There
may be information on the links between Hops, possibly information on
the routing (arrival int. to departure int.), an estimate of distance
between Hops based on Round Trip Delay measurements and calculations,
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 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 13, line 30 skipping to change at page 13, line 40
stable results over time, particularly ingress and egress stable results over time, particularly ingress and egress
portions of the path. portions of the path.
2. SHOULD continue testing portions of the path that have previously 2. SHOULD continue testing portions of the path that have previously
exhibited ECMP load balancing. exhibited ECMP load balancing.
3. SHALL trigger re-assessment of the complete path and Route 3. SHALL trigger re-assessment of the complete path and Route
Ensemble, if any change in hops is observed for a specific (and Ensemble, if any change in hops is observed for a specific (and
previously tested) flow. previously tested) flow.
@@@@ Comments on this new material are very welcome! @@@@ Comments on this material are very welcome!
4.1.2. Routing Class C Identification 4.1.2. Routing Class C Identification
There is an opportunity to apply the [RFC2330] notion of equal There is an opportunity to apply the [RFC2330] notion of equal
treatment for a class of packets, "...very useful to know if a given treatment for a class of packets, "...very useful to know if a given
Internet component treats equally a class C of different types of Internet component treats equally a class C of different types of
packets", as it applies to Route measurements. Knowledge of "class packets", as it applies to Route measurements. Knowledge of "class
C" parameters (unrelated to address classes of the past) on a path C" parameters (unrelated to address classes of the past) 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
to assess a Route Ensemble over time. to assess a Route Ensemble over time.
skipping to change at page 14, line 24 skipping to change at page 14, line 36
o a priori knowledge of the possible types of hash functions in use o a priori knowledge of the possible types of hash functions in use
also helps to design the flows for testing (major router vendors also helps to design the flows for testing (major router vendors
publish information about these hash functions, examples are here publish information about these hash functions, examples are here
https://www.researchgate.net/ https://www.researchgate.net/
publication/281571413_COMPARISON_OF_HASH_STRATEGIES_FOR_FLOW- publication/281571413_COMPARISON_OF_HASH_STRATEGIES_FOR_FLOW-
BASED_LOAD_BALANCING ). BASED_LOAD_BALANCING ).
o ability to direct the emphasis of current measurements on ECMP o ability to direct the emphasis of current measurements on ECMP
portions of the path, based on recent past measurement results portions of the path, based on recent past measurement results
(the Class C of some portions of the path is essentially "all (the Routing Class C of some portions of the path is essentially
packets"). "all packets").
@@@@ Comments on this new 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
There are many examples where passive monitoring of a flow at an
Observation Point within the network can detect unexpected Round Trip
Delay or Delay Variation. But how can the cause of the anomolous
dely be investigated further --from the Observation Point -- possibly
located at an intermediate poin on the path?
In this case, knowledge that the flow of interest belongs to a
specific Routing Class C will enable mesurement of the route where
anomolous delay has been observed. Specifically, Round Trip Delay
assessment to each Hop on the path between the Observation Point and
the Destination for the flow of interest may discover high or
variable delay on a specific link and Hop combination.
The determination of a Routing Class C which includes the flow of
interest is as described in the section above, aided by computation
of the relevant hash function output as the target.
@@@@ 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:
1. The ingress node adds one or more fields to the measurement
packets, and identifies to other nodes in the domain that a route
assessment will be conducted using one or more specific packets.
The packets typically originate from a host outside the domain,
and constitute normal traffic on the domain.
2. Each node visited by the specific packet within in the domain
identifies itself in a data field of the packet (the field has
been added for this purpose).
3. When a measurement packet reaches the edge node of the domain,
the edge node adds its identity to the list, removes all the
identities from the packet, forwards the packet onward, and
communicates the ordered list of node identities to the intended
receiver.
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 20, line 42 skipping to change at page 21, line 7
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 hosts. 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. Both their choice of an ECMP member based on the IP addresses (see
methods allow load sharing information to be decoupled from routing Section 2.4 of [RFC7325]). Both methods allow load sharing
information. Thus, an MPLS traceroute is able to check how packets information to be decoupled from routing information. Thus, an MPLS
with a contiguous number of ECMP relevant addresses (and the same traceroute is able to check how packets with a contiguous number of
destination) are routed by a particular router. The minimum number ECMP relevant addresses (and the same destination) are routed by a
of MPLS paths traceable at a router should be 32. Implementations particular router. The minimum number of MPLS paths traceable at a
supporting more paths are available. router should be 32. Implementations supporting more paths are
available.
The MPLS echo request and reply messages offering this feature must The MPLS echo request and reply messages offering this feature must
support the Downstream Detailed Mapping TLV (was Downstream Mapping support the Downstream Detailed Mapping TLV (was Downstream Mapping
initially, but the latter has been deprecated). The MPLS echo initially, but the latter has been deprecated). The MPLS echo
response includes the incoming interface where a router received the response includes the incoming interface where a router received the
MPLS Echo request. The MPLS Echo reply further informs which of the MPLS Echo request. The MPLS Echo reply further informs which of the
n addresses relevant for the load sharing decision results in a n addresses relevant for the load sharing decision results in a
particular next hop interface and contains the next hop's interface particular next hop interface and contains the next hop's interface
address (if available). This ensures that the next hop will receive address (if available). This ensures that the next hop will receive
a properly coded MPLS Echo request in the next step route of a properly coded MPLS Echo request in the next step route of
skipping to change at page 21, line 28 skipping to change at page 21, line 43
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-03 (work in progress), June 2018. data-04 (work in progress), October 2018.
[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 24, line 12 skipping to change at page 24, line 32
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
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.
[I-D.brockners-inband-oam-data]
Brockners, F., Bhandari, S., Pignataro, C., Gredler, H.,
Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov,
P., Chang, R., and d. daniel.bernier@bell.ca, "Data Fields
for In-situ OAM", draft-brockners-inband-oam-data-07 (work
in progress), July 2017.
[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 congestion",
In Proceedings of the 2014 Conference on Internet In Proceedings of the 2014 Conference on Internet
Measurement Conference, pp. 15-22. ACM, 2014. 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.
skipping to change at page 24, line 45 skipping to change at page 25, line 11
calculation of quantiles and histograms without storing calculation of quantiles and histograms without storing
observations", Communications of the ACM 28.10 (1985): observations", Communications of the ACM 28.10 (1985):
1076-1085, 2015. 1076-1085, 2015.
[PT] Augustin, B., Cuvellier, X., Orgogozo, B., Viger, F., [PT] Augustin, B., Cuvellier, X., Orgogozo, B., Viger, F.,
Friedman, T., Latapy, M., Magnien, C., and R. Teixeira, Friedman, T., Latapy, M., Magnien, C., and R. Teixeira,
"Avoiding traceroute anomalies with Paris traceroute", "Avoiding traceroute anomalies with Paris traceroute",
Proceedings of the 6th ACM SIGCOMM conference on Internet Proceedings of the 6th ACM SIGCOMM conference on Internet
measurement, pp. 153-158. ACM, 2006., 2006. measurement, pp. 153-158. ACM, 2006., 2006.
[RFC7325] Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A.,
and C. Pignataro, "MPLS Forwarding Compliance and
Performance Requirements", RFC 7325, DOI 10.17487/RFC7325,
August 2014, <https://www.rfc-editor.org/info/rfc7325>.
[RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T.,
Aitken, P., and A. Akhter, "A Framework for Large-Scale Aitken, P., and A. Akhter, "A Framework for Large-Scale
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.
skipping to change at page 26, line 4 skipping to change at page 26, line 24
Joachim Fabini Joachim Fabini
TU Wien TU Wien
Gusshausstrasse 25/E389 Gusshausstrasse 25/E389
Vienna 1040 Vienna 1040
Austria Austria
Phone: +43 1 58801 38813 Phone: +43 1 58801 38813
Fax: +43 1 58801 38898 Fax: +43 1 58801 38898
Email: Joachim.Fabini@tuwien.ac.at Email: Joachim.Fabini@tuwien.ac.at
URI: http://www.tc.tuwien.ac.at/about-us/staff/joachim-fabini/ URI: http://www.tc.tuwien.ac.at/about-us/staff/joachim-fabini/
Carlos Pignataro Carlos Pignataro
Cisco Systems, Inc. Cisco Systems, Inc.
7200-11 Kit Creek Road 7200-11 Kit Creek Road
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
USA USA
Email: cpignata@cisco.com Email: cpignata@cisco.com
Ruediger Geib
Deutsche Telekom
Heinrich Hertz Str. 3-7
Darmstadt 64295
Germany
Phone: +49 6151 5812747
Email: Ruediger.Geib@telekom.de
 End of changes. 22 change blocks. 
55 lines changed or deleted 75 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/