draft-ietf-tictoc-multi-path-synchronization-04.txt   draft-ietf-tictoc-multi-path-synchronization-05.txt 
Network Working Group A. Shpiner Network Working Group A. Shpiner
Internet Draft Technion - Israel Institute of Technology Internet Draft Mellanox
Intended status: Experimental R. Tse Intended status: Experimental R. Tse
Expires: October 2016 C. Schelp Expires: February 2017 C. Schelp
PMC-Sierra PMC-Sierra
T. Mizrahi T. Mizrahi
Marvell Marvell
April 18, 2016 August 25, 2016
Multi-Path Time Synchronization Multi-Path Time Synchronization
draft-ietf-tictoc-multi-path-synchronization-04.txt draft-ietf-tictoc-multi-path-synchronization-05.txt
Abstract Abstract
Clock synchronization protocols are very widely used in IP-based Clock synchronization protocols are very widely used in IP-based
networks. The Network Time Protocol (NTP) has been commonly deployed networks. The Network Time Protocol (NTP) has been commonly deployed
for many years, and the last few years have seen an increasingly for many years, and the last few years have seen an increasingly
rapid deployment of the Precision Time Protocol (PTP). As time- rapid deployment of the Precision Time Protocol (PTP). As time-
sensitive applications evolve, clock accuracy requirements are sensitive applications evolve, clock accuracy requirements are
becoming increasingly stringent, requiring the time synchronization becoming increasingly stringent, requiring the time synchronization
protocols to provide high accuracy. Slave Diversity is a recently protocols to provide high accuracy. Slave Diversity is a recently
skipping to change at page 2, line 16 skipping to change at page 2, line 16
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 18, 2016. This Internet-Draft will expire on February 25, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 47 skipping to change at page 2, line 47
2.1. Abbreviations.............................................5 2.1. Abbreviations.............................................5
2.2. Terminology...............................................5 2.2. Terminology...............................................5
3. Multiple Paths in IP Networks..................................5 3. Multiple Paths in IP Networks..................................5
3.1. Load Balancing............................................5 3.1. Load Balancing............................................5
3.2. Using Multiple Paths Concurrently.........................6 3.2. Using Multiple Paths Concurrently.........................6
3.3. Two-Way Paths.............................................6 3.3. Two-Way Paths.............................................6
4. Solution Overview..............................................6 4. Solution Overview..............................................6
4.1. Path Configuration and Identification.....................6 4.1. Path Configuration and Identification.....................6
4.2. Combining.................................................7 4.2. Combining.................................................7
5. Multi-Path Time Synchronization Protocols over IP Networks.....7 5. Multi-Path Time Synchronization Protocols over IP Networks.....7
5.1. Single-Ended Multi-Path Synchronization...................8 5.1. Overview..................................................7
5.1.1. Single-Ended MPPTP Synchronization Message Exchange..8 5.2. Single-Ended Multi-Path Synchronization...................9
5.1.2. Single-Ended MPNTP Synchronization Message Exchange..9 5.2.1. Single-Ended MPPTP Synchronization Message Exchange..9
5.2. Dual-Ended Multi-Path Synchronization....................10 5.2.2. Single-Ended MPNTP Synchronization Message Exchange.10
5.2.1. Dual-Ended MPPTP Synchronization Message Exchange...10 5.3. Dual-Ended Multi-Path Synchronization....................10
5.2.2. Dual-Ended MPNTP Synchronization Message Exchange...11 5.3.1. Dual-Ended MPPTP Synchronization Message Exchange...11
5.3. Using Traceroute for Path Discovery......................12 5.3.2. Dual-Ended MPNTP Synchronization Message Exchange...12
5.4. Using Unicast Discovery for MPPTP........................12 5.4. Using Traceroute for Path Discovery......................12
5.5. Using Unicast Discovery for MPPTP........................13
6. Combining Algorithm...........................................13 6. Combining Algorithm...........................................13
7. Security Considerations.......................................13 7. Security Considerations.......................................14
8. IANA Considerations...........................................13 8. IANA Considerations...........................................14
9. Acknowledgments...............................................13 9. Acknowledgments...............................................14
10. References...................................................13 10. References...................................................14
10.1. Normative References....................................13 10.1. Normative References....................................14
10.2. Informative References..................................14 10.2. Informative References..................................14
1. Introduction 1. Introduction
The two most common time synchronization protocols in IP networks are The two most common time synchronization protocols in IP networks are
the Network Time Protocol [NTP], and the Precision Time Protocol the Network Time Protocol [NTP], and the Precision Time Protocol
(PTP), defined in the IEEE 1588 standard [IEEE1588]. (PTP), defined in the IEEE 1588 standard [IEEE1588].
The accuracy of the time synchronization protocols directly depends The accuracy of the time synchronization protocols directly depends
on the stability and the symmetry of propagation delays on both on the stability and the symmetry of propagation delays on both
directions between the master and slave clocks. Depending on the directions between the master and slave clocks. Depending on the
skipping to change at page 7, line 31 skipping to change at page 7, line 31
4.2. Combining 4.2. Combining
Various methods can be used for combining the time information Various methods can be used for combining the time information
received from the different paths. The output of the combining received from the different paths. The output of the combining
algorithm is the accurate time offset. Combining methods are further algorithm is the accurate time offset. Combining methods are further
discussed in Section 6. discussed in Section 6.
5. Multi-Path Time Synchronization Protocols over IP Networks 5. Multi-Path Time Synchronization Protocols over IP Networks
5.1. Overview
This section presents two variants of MPPTP and MPNTP; single-ended This section presents two variants of MPPTP and MPNTP; single-ended
multi-path time synchronization and dual-ended multi-path time multi-path time synchronization and dual-ended multi-path time
synchronization. In the first variant, the multi-path protocol is run synchronization. In the first variant, the multi-path protocol is run
only by the slave and the master is not aware of its usage. In the only by the slave and the master is not aware of its usage. In the
second variant, all clocks must support the multi-path protocol. second variant, all clocks must support the multi-path protocol.
The dual-ended protocol provides higher path diversity by using The dual-ended protocol provides higher path diversity by using
multiple IP addresses at both ends, the master and slave, while the multiple IP addresses at both ends, the master and slave, while the
single-ended protocol only uses multiple addresses at the slave. On single-ended protocol only uses multiple addresses at the slave. On
the other hand, the dual-ended protocol can only be deployed when the other hand, the dual-ended protocol can only be deployed when
both the master and the slave support this protocol. Dual-ended and both the master and the slave support this protocol. Dual-ended and
single-ended protocols can co-exist in the same network. Each slave single-ended protocols can co-exist in the same network. Each slave
selects the connection(s) it wants to make with the available selects the connection(s) it wants to make with the available
masters. A dual-ended slave could switch to single-ended mode if it masters. A dual-ended slave could switch to single-ended mode if it
does not see any dual-ended masters available. A single-ended slave does not see any dual-ended masters available. A single-ended slave
could connect to a single IP address of a dual-ended master. could connect to a single IP address of a dual-ended master.
Multi-path time synchronization, in both variants, requires clocks to Multi-path time synchronization, in both variants, requires clocks to
use multiple IP addresses. If possible, the set of IP addresses for use multiple IP addresses. Using multiple IP addresses introduces a
each clock should be chosen in a way that enables the establishment tradeoff. A large number of IP addresses allows a large number of
of paths that are the most different. It is applicable if the load diverse paths, providing the advantages of slave diversity discussed
balancing rules in the network are known. Using multiple IP addresses in Section 1. On the other hand, a large number of IP addresses is
introduces a tradeoff. A large number of IP addresses allows a large more costly, requires the network topology to be more redundant, and
number of diverse paths, providing the advantages of slave diversity exacts extra management overhead.
discussed in Section 1. On the other hand, a large number of IP
addresses is more costly, requires the network topology to be more If possible, the set of IP addresses for each clock should be chosen
redundant, and exacts extra management overhead. in a way that enables the establishment of paths that are the most
different. If the load balancing rules in the network are known, it
is possible to choose the IP addresses in a way that enforces path
diversity. However, even if the load balancing scheme is not known, a
careful choice of the IP addresses can increase the probability of
path diversity. For example, choosing multiple addresses with
different prefixes is likely to produce higher path diversity, as BGP
routers are more likely to route these different prefixes through
different routes.
The use of Network Address Translation (NAT) may significantly reduce
the effectiveness of multi-path synchronization in some cases. For
example, if a master uses multiple IP addresses that are translated
to a single IP address, the path diversity can be dramatically
reduced compared to a network that does not use NAT. Thus, path
discovery should be used to identify the possible paths between the
master and slave. Path discovery is further discussed in Section 5.4.
The concept of using multiple IP addresses or multiple interfaces is
a well-established concept that is being used today by various
applications and protocols, e.g., [MPTCP]. Using multiple interfaces
introduces some challenges and issues, which were presented and
discussed in [MIF].
The descriptions in this section refer to the end-to-end scheme of The descriptions in this section refer to the end-to-end scheme of
PTP, but are similarly applicable to the peer-to-peer scheme. The PTP, but are similarly applicable to the peer-to-peer scheme. The
MPNTP protocol described in this document refers to the NTP client- MPNTP protocol described in this document refers to the NTP client-
server mode, although the concepts described here can be extended to server mode, although the concepts described here can be extended to
include the symmetric variant as well. include the symmetric variant as well.
Multi-path synchronization protocols by nature require protocol Multi-path synchronization protocols by nature require protocol
messages to be sent as unicast. Specifically in PTP, the following messages to be sent as unicast. Specifically in PTP, the following
messages must be sent as unicast in MPPTP: Sync, Delay_Req, messages must be sent as unicast in MPPTP: Sync, Delay_Req,
Delay_Resp, PDelay_Req, PDelay_Resp, Follow_Up, and Delay_Resp, PDelay_Req, PDelay_Resp, Follow_Up, and
PDelay_Resp_Follow_Up. Note that [IEEE1588] allows these messages to PDelay_Resp_Follow_Up. Note that [IEEE1588] allows these messages to
be sent either as multicast or as unicast. be sent either as multicast or as unicast.
5.1. Single-Ended Multi-Path Synchronization 5.2. Single-Ended Multi-Path Synchronization
In the single-ended approach, only the slave is aware of the fact In the single-ended approach, only the slave is aware of the fact
that multiple paths are used, while the master is agnostic to the that multiple paths are used, while the master is agnostic to the
usage of multiple paths. This approach allows a hybrid network, where usage of multiple paths. This approach allows a hybrid network, where
some of the clocks are multi-path clocks, and others are conventional some of the clocks are multi-path clocks, and others are conventional
one-path clocks. A single-ended multi-path clock presents itself to one-path clocks. A single-ended multi-path clock presents itself to
the network as N independent clocks, using N IP addresses, as well as the network as N independent clocks, using N IP addresses, as well as
N clock identity values (in PTP). Thus, the usage of multiple slave N clock identity values (in PTP). Thus, the usage of multiple slave
identities by a slave clock is transparent from the master's point of identities by a slave clock is transparent from the master's point of
view, such that it treats each of the identities as a separate slave view, such that it treats each of the identities as a separate slave
clock. clock.
5.1.1. Single-Ended MPPTP Synchronization Message Exchange 5.2.1. Single-Ended MPPTP Synchronization Message Exchange
The single-ended MPPTP message exchange procedure is as follows. The single-ended MPPTP message exchange procedure is as follows.
o Each single-ended MPPTP clock has a fixed set of N IP addresses o Each single-ended MPPTP clock has a fixed set of N IP addresses
and N corresponding clockIdentities. Each clock arbitrarily and N corresponding clockIdentities. Each clock arbitrarily
defines one of its IP addresses and clockIdentity values as the defines one of its IP addresses and clockIdentity values as the
clock primary identity. clock primary identity.
o A single-ended MPPTP port sends Announce messages only from its o A single-ended MPPTP port sends Announce messages only from its
primary identity, according to the BMC algorithm. primary identity, according to the BMC algorithm.
skipping to change at page 9, line 38 skipping to change at page 10, line 16
responds with a Delay_Resp message using the IP address and responds with a Delay_Resp message using the IP address and
sourcePortIdentity from the Delay_Req message. sourcePortIdentity from the Delay_Req message.
o Upon receiving the Delay_Resp message, the slave identifies the o Upon receiving the Delay_Resp message, the slave identifies the
path using the destination IP address and the path using the destination IP address and the
requestingPortIdentity. The slave can then compute the requestingPortIdentity. The slave can then compute the
corresponding path delay and the offset from the master. corresponding path delay and the offset from the master.
o The slave combines the information from all negotiated paths. o The slave combines the information from all negotiated paths.
5.1.2. Single-Ended MPNTP Synchronization Message Exchange 5.2.2. Single-Ended MPNTP Synchronization Message Exchange
The single-ended MPNTP message exchange procedure is as follows. The single-ended MPNTP message exchange procedure is as follows.
o A single-ended MPNTP client has N separate identities, i.e., N IP o A single-ended MPNTP client has N separate identities, i.e., N IP
addresses. The assumption is that the server information, addresses. The assumption is that the server information,
including its IP address is known to the NTP clients. including its IP address is known to the NTP clients.
o A single-ended MPNTP client initiates the NTP protocol with an NTP o A single-ended MPNTP client initiates the NTP protocol with an NTP
server N times, using each of its N identities. server N times, using each of its N identities.
skipping to change at page 10, line 17 skipping to change at page 10, line 42
o The server responds to the client's NTP messages using the IP o The server responds to the client's NTP messages using the IP
address from the received NTP packet. address from the received NTP packet.
o The client, upon receiving an NTP packet, uses the IP destination o The client, upon receiving an NTP packet, uses the IP destination
address to identify the path it came through, and uses the time address to identify the path it came through, and uses the time
information accordingly. information accordingly.
o The client combines the information from all paths. o The client combines the information from all paths.
5.2. Dual-Ended Multi-Path Synchronization 5.3. Dual-Ended Multi-Path Synchronization
In dual-ended multi-path synchronization each clock has N IP In dual-ended multi-path synchronization each clock has N IP
addresses. Time synchronization messages are exchanged between some addresses. Time synchronization messages are exchanged between some
of the combinations of {master IP, slave IP} addresses, allowing of the combinations of {master IP, slave IP} addresses, allowing
multiple paths between the master and slave. Note that the actual multiple paths between the master and slave. Note that the actual
number of paths between the master and slave may be less than the number of paths between the master and slave may be less than the
number of chosen {master, slave} IP address pairs. number of chosen {master, slave} IP address pairs.
Once the multiple two-way connections are established, a separate Once the multiple two-way connections are established, a separate
synchronization protocol exchange instance is run through each of synchronization protocol exchange instance is run through each of
them. them.
5.2.1. Dual-Ended MPPTP Synchronization Message Exchange 5.3.1. Dual-Ended MPPTP Synchronization Message Exchange
The dual-ended MPPTP message exchange procedure is as follows. The dual-ended MPPTP message exchange procedure is as follows.
o Every clock has N IP addresses, but uses a single clockIdentity. o Every clock has N IP addresses, but uses a single clockIdentity.
o The BMC algorithm at each clock determines the master. The master o The BMC algorithm at each clock determines the master. The master
is identified by its clockIdentity, allowing other clocks to know is identified by its clockIdentity, allowing other clocks to know
the multiple IP addresses it uses. the multiple IP addresses it uses.
o When a clock sends an Announce message, it sends it from each of o When a clock sends an Announce message, it sends it from each of
skipping to change at page 11, line 28 skipping to change at page 12, line 7
from the Delay_Req message, and swapping the IP addresses from the from the Delay_Req message, and swapping the IP addresses from the
Delay_Req. Delay_Req.
o Upon receiving the Delay_Resp message, the slave identifies the o Upon receiving the Delay_Resp message, the slave identifies the
path using the {source, destination} IP address pair. The slave path using the {source, destination} IP address pair. The slave
can then compute the corresponding path delay and the offset from can then compute the corresponding path delay and the offset from
the master. the master.
o The slave combines the information from all negotiated paths. o The slave combines the information from all negotiated paths.
5.2.2. Dual-Ended MPNTP Synchronization Message Exchange 5.3.2. Dual-Ended MPNTP Synchronization Message Exchange
The MPNTP message exchange procedure is as follows. The MPNTP message exchange procedure is as follows.
o Each NTP clock has a set of N IP addresses. The assumption is that o Each NTP clock has a set of N IP addresses. The assumption is that
the server information, including its multiple IP addresses is the server information, including its multiple IP addresses is
known to the NTP clients. known to the NTP clients.
o The MPNTP client chooses N_svr of the N server IP addresses and o The MPNTP client chooses N_svr of the N server IP addresses and
N_c of the N client IP addresses and initiates the N_svr*N_c N_c of the N client IP addresses and initiates the N_svr*N_c
instances of the protocol, one for each {server IP, client IP} instances of the protocol, one for each {server IP, client IP}
skipping to change at page 12, line 11 skipping to change at page 12, line 35
o The server responds to the client's NTP messages using the IP o The server responds to the client's NTP messages using the IP
address combination from the received NTP packet. address combination from the received NTP packet.
o Using the {source, destination} IP address pair in the received o Using the {source, destination} IP address pair in the received
packets, the client identifies the path, and performs its packets, the client identifies the path, and performs its
computations for each of the paths accordingly. computations for each of the paths accordingly.
o The client combines the information from all paths. o The client combines the information from all paths.
5.3. Using Traceroute for Path Discovery 5.4. Using Traceroute for Path Discovery
The protocols presented above use multiple IP addresses in a single The protocols presented above use multiple IP addresses in a single
clock to create multiple paths. However, although each two-way path clock to create multiple paths. However, although each two-way path
is defined by a different {master, slave} address pair, some of the is defined by a different {master, slave} address pair, some of the
IP address pairs may traverse exactly the same network path, making IP address pairs may traverse exactly the same network path, making
them redundant. Traceroute-based path discovery can be used for them redundant.
filtering only the IP addresses that obtain diverse paths. 'Paris
Traceroute' [PARIS] and 'TraceFlow' [TRACEFLOW] are examples of tools Traceroute-based path discovery can be used for filtering only the IP
that discover the paths between two points in the network. addresses that obtain diverse paths. 'Paris Traceroute' [PARIS] and
'TraceFlow' [TRACEFLOW] are examples of tools that discover the paths
between two points in the network. It should be noted that this
filtering approach is effective only if the Traceroute implementation
uses the same IP addresses and UDP ports as the synchronization
protocol packets. Since some Traceroute implementations vary the UDP
ports, they may not be effective in identifying and filtering
redundant paths in synchronization protocols.
The Traceroute-based filtering can be implemented by both master and The Traceroute-based filtering can be implemented by both master and
slave nodes, or it can be restricted to run only on slave nodes to slave nodes, or it can be restricted to run only on slave nodes to
reduce the overhead on the master. For networks that guarantee the reduce the overhead on the master. For networks that guarantee that
path of the timing packets in the forward and reverse direction are the path of the timing packets in the forward and reverse direction
the same, path discovery should only be performed at the slave. are the same, path discovery should only be performed at the slave.
5.4. Using Unicast Discovery for MPPTP Since network routes change over time, path discovery and redundant
path filtering should be performed periodically. Two {master,slave}
pairs that produce two diverse paths may be rerouted to use the same
paths. Thus, the set of addresses that are used by each clock should
be reassessed regularly.
5.5. Using Unicast Discovery for MPPTP
As presented above, MPPTP uses Announce messages and the BMC As presented above, MPPTP uses Announce messages and the BMC
algorithm to discover the master. The unicast discovery option of PTP algorithm to discover the master. The unicast discovery option of PTP
can be used as an alternative. can be used as an alternative.
When using unicast discovery the MPPTP slave ports maintain a list of When using unicast discovery the MPPTP slave ports maintain a list of
the IP addresses of the master. The slave port uses unicast the IP addresses of the master. The slave port uses unicast
negotiation to request unicast service from the master, as follows: negotiation to request unicast service from the master, as follows:
o In single-ended MPPTP, the slave uses unicast negotiation from o In single-ended MPPTP, the slave uses unicast negotiation from
each of its identities to the master's (only) identity. each of its identities to the master's (only) identity.
o In dual-ended MPPTP, the slave uses unicast negotiation from its o In dual-ended MPPTP, the slave uses unicast negotiation from its
IP addresses, each to a corresponding master IP address to request IP addresses, each to a corresponding master IP address to request
unicast synchronization messages. unicast synchronization messages.
Afterwards, the message exchange continues as described in sections Afterwards, the message exchange continues as described in sections
5.1.1. and 5.2.1. 5.2.1. and 5.3.1.
The unicast discovery option can be used in networks that do not The unicast discovery option can be used in networks that do not
support multicast or in networks in which the master clocks are known support multicast or in networks in which the master clocks are known
in advance. In particular, unicast discovery avoids multicasting in advance. In particular, unicast discovery avoids multicasting
Announce messages. Announce messages.
6. Combining Algorithm 6. Combining Algorithm
Previous sections discussed the methods of creating the multiple Previous sections discussed the methods of creating the multiple
paths and obtaining the time information required by the slave paths and obtaining the time information required by the slave
skipping to change at page 13, line 35 skipping to change at page 14, line 26
8. IANA Considerations 8. IANA Considerations
There are no IANA actions required by this document. There are no IANA actions required by this document.
RFC Editor: please delete this section before publication. RFC Editor: please delete this section before publication.
9. Acknowledgments 9. Acknowledgments
The authors gratefully acknowledge the useful comments provided by The authors gratefully acknowledge the useful comments provided by
Peter Meyer and Doug Arnold, as well as other comments received from Peter Meyer, Doug Arnold, Joe Abley, and Zhen Cao, as well as other
the TICTOC working group participants. comments received from the TICTOC working group participants.
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
10. References 10. References
10.1. Normative References 10.1. Normative References
[IEEE1588] IEEE Instrumentation and Measurement Society, "IEEE [IEEE1588] IEEE Instrumentation and Measurement Society, "IEEE
Standard for a Precision Clock Synchronization Standard for a Precision Clock Synchronization
Protocol for Networked Measurement and Control Protocol for Networked Measurement and Control
skipping to change at page 14, line 30 skipping to change at page 15, line 20
Attacks against Time Synchronization Protocols", Attacks against Time Synchronization Protocols",
ISPCS, 2012. ISPCS, 2012.
[HIGH-AVAI] P. Ferrari, A. Flammini, S. Rinaldi, G. Prytz, "High [HIGH-AVAI] P. Ferrari, A. Flammini, S. Rinaldi, G. Prytz, "High
availability IEEE 1588 nodes over IEEE 802.1 aq availability IEEE 1588 nodes over IEEE 802.1 aq
Shortest Path Bridging networks" ISPCS, 2013. Shortest Path Bridging networks" ISPCS, 2013.
[KALMAN] G. Giorgi, C. Narduzzi, "Kalman filtering for multi- [KALMAN] G. Giorgi, C. Narduzzi, "Kalman filtering for multi-
path network synchronization" ISPCS, 2014. path network synchronization" ISPCS, 2014.
[MIF] Blanchet, M. and P. Seite, "Multiple Interfaces and
Provisioning Domains Problem Statement", RFC 6418, DOI
10.17487/RFC6418, November 2011, <http://www.rfc-
editor.org/info/rfc6418>.
[MPTCP] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
"TCP Extensions for Multipath Operation with Multiple
Addresses", RFC 6824, DOI 10.17487/RFC6824, January
2013, <http://www.rfc-editor.org/info/rfc6824>.
[MULTI] A. Shpiner, Y. Revah, T. Mizrahi, "Multi-path Time [MULTI] A. Shpiner, Y. Revah, T. Mizrahi, "Multi-path Time
Protocols" ISPCS, 2013. Protocols" ISPCS, 2013.
[PARIS] Brice Augustin, Timur Friedman and Renata Teixeira, [PARIS] Brice Augustin, Timur Friedman and Renata Teixeira,
"Measuring Load-balanced Paths in the Internet", IMC, "Measuring Load-balanced Paths in the Internet", IMC,
2007. 2007.
[PARIS2] B. Augustin, T. Friedman, and R. Teixeira, "Measuring [PARIS2] B. Augustin, T. Friedman, and R. Teixeira, "Measuring
Multipath Routing in the Internet", IEEE/ACM Multipath Routing in the Internet", IEEE/ACM
Transactions on Networking, 19(3), p. 830 - 840, June Transactions on Networking, 19(3), p. 830 - 840, June
skipping to change at page 15, line 8 skipping to change at page 16, line 8
[TICTOCSEC] T. Mizrahi, "Security Requirements of Time Protocols [TICTOCSEC] T. Mizrahi, "Security Requirements of Time Protocols
in Packet Switched Networks", IETF, RFC 7384, 2014. in Packet Switched Networks", IETF, RFC 7384, 2014.
[TRACEFLOW] J. Narasimhan, B. V. Venkataswami, R. Groves and P. [TRACEFLOW] J. Narasimhan, B. V. Venkataswami, R. Groves and P.
Hoose, "Traceflow", IETF, draft-janapath-intarea- Hoose, "Traceflow", IETF, draft-janapath-intarea-
traceflow, work in progress, 2012. traceflow, work in progress, 2012.
Authors' Addresses Authors' Addresses
Alex Shpiner Alex Shpiner
Department of Electrical Engineering Mellanox Technologies, Ltd.
Technion - Israel Institute of Technology Hakidma 26
Haifa, 32000 Israel Ofer Industrial Park
Yokneam, 2069200, Israel
Email: shalex@tx.technion.ac.il Email: alexshp@mellanox.com
Richard Tse Richard Tse
PMC-Sierra PMC-Sierra
8555 Baxter Place 8555 Baxter Place
Burnaby, BC Burnaby, BC
Canada Canada
V5A 4V7 V5A 4V7
Email: Richard.Tse@pmcs.com Email: Richard.Tse@pmcs.com
skipping to change at page 15, line 35 skipping to change at page 16, line 36
8555 Baxter Place 8555 Baxter Place
Burnaby, BC Burnaby, BC
Canada Canada
V5A 4V7 V5A 4V7
Email: craig.schelp@pmcs.com Email: craig.schelp@pmcs.com
Tal Mizrahi Tal Mizrahi
Marvell Marvell
6 Hamada St. 6 Hamada St.
Yokneam, 20692 Israel Yokneam, 20692, Israel
Email: talmi@marvell.com Email: talmi@marvell.com
 End of changes. 25 change blocks. 
50 lines changed or deleted 99 lines changed or added

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