idnits 2.17.1 draft-ietf-tictoc-multi-path-synchronization-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 18, 2016) is 2902 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Shpiner 2 Internet Draft Technion - Israel Institute of Technology 3 Intended status: Experimental R. Tse 4 Expires: October 2016 C. Schelp 5 PMC-Sierra 6 T. Mizrahi 7 Marvell 8 April 18, 2016 10 Multi-Path Time Synchronization 11 draft-ietf-tictoc-multi-path-synchronization-04.txt 13 Abstract 15 Clock synchronization protocols are very widely used in IP-based 16 networks. The Network Time Protocol (NTP) has been commonly deployed 17 for many years, and the last few years have seen an increasingly 18 rapid deployment of the Precision Time Protocol (PTP). As time- 19 sensitive applications evolve, clock accuracy requirements are 20 becoming increasingly stringent, requiring the time synchronization 21 protocols to provide high accuracy. Slave Diversity is a recently 22 introduced approach, where the master and slave clocks (also known as 23 server and client) are connected through multiple network paths, and 24 the slave combines the information received through all paths to 25 obtain a higher clock accuracy compared to the conventional one-path 26 approach. This document describes a multi-path approach to PTP and 27 NTP over IP networks, allowing the protocols to run concurrently over 28 multiple communication paths between the master and slave clocks. The 29 multi-path approach can significantly contribute to clock accuracy, 30 security and fault tolerance. The Multi-Path Precision Time Protocol 31 (MPPTP) and Multi-Path Network Time Protocol (MPNTP) define an 32 additional layer that extends the existing PTP and NTP without the 33 need to modify these protocols. MPPTP and MPNTP also allow backward 34 compatibility with nodes that do not support the multi-path 35 extension. 37 Status of this Memo 39 This Internet-Draft is submitted to IETF in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF), its areas, and its working groups. Note that 44 other groups may also distribute working documents as Internet- 45 Drafts. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 The list of current Internet-Drafts can be accessed at 53 http://www.ietf.org/ietf/1id-abstracts.txt. 55 The list of Internet-Draft Shadow Directories can be accessed at 56 http://www.ietf.org/shadow.html. 58 This Internet-Draft will expire on October 18, 2016. 60 Copyright Notice 62 Copyright (c) 2016 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (http://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the Simplified BSD License. 75 Table of Contents 77 1. Introduction...................................................3 78 2. Conventions Used in this Document..............................5 79 2.1. Abbreviations.............................................5 80 2.2. Terminology...............................................5 81 3. Multiple Paths in IP Networks..................................5 82 3.1. Load Balancing............................................5 83 3.2. Using Multiple Paths Concurrently.........................6 84 3.3. Two-Way Paths.............................................6 85 4. Solution Overview..............................................6 86 4.1. Path Configuration and Identification.....................6 87 4.2. Combining.................................................7 88 5. Multi-Path Time Synchronization Protocols over IP Networks.....7 89 5.1. Single-Ended Multi-Path Synchronization...................8 90 5.1.1. Single-Ended MPPTP Synchronization Message Exchange..8 91 5.1.2. Single-Ended MPNTP Synchronization Message Exchange..9 92 5.2. Dual-Ended Multi-Path Synchronization....................10 93 5.2.1. Dual-Ended MPPTP Synchronization Message Exchange...10 94 5.2.2. Dual-Ended MPNTP Synchronization Message Exchange...11 95 5.3. Using Traceroute for Path Discovery......................12 96 5.4. Using Unicast Discovery for MPPTP........................12 97 6. Combining Algorithm...........................................13 98 7. Security Considerations.......................................13 99 8. IANA Considerations...........................................13 100 9. Acknowledgments...............................................13 101 10. References...................................................13 102 10.1. Normative References....................................13 103 10.2. Informative References..................................14 105 1. Introduction 107 The two most common time synchronization protocols in IP networks are 108 the Network Time Protocol [NTP], and the Precision Time Protocol 109 (PTP), defined in the IEEE 1588 standard [IEEE1588]. 110 The accuracy of the time synchronization protocols directly depends 111 on the stability and the symmetry of propagation delays on both 112 directions between the master and slave clocks. Depending on the 113 nature of the underlying network, time synchronization protocol 114 packets can be subject to variable network latency or path asymmetry 115 (e.g. [ASSYMETRY], [ASSYMETRY2]). As time sensitive applications 116 evolve, accuracy requirements are becoming increasingly stringent. 118 Using a single network path in a clock synchronization protocol 119 closely ties the slave clock accuracy to the behavior of the specific 120 path, which may suffer from temporal congestion, faults or malicious 121 attacks. Relying on multiple clock servers as in NTP solves these 122 problems, but requires active maintenance of multiple accurate 123 sources in the network, which is not always possible. The usage of 124 Transparent Clocks (TC) in PTP solves the congestion problem by 125 eliminating the queueing time from the delay calculations, but does 126 not address security or fault-tolerance aspects. 128 ____ 129 ______/ \_____ 130 ___/ \____ 131 ____/ \ 132 ____ / path 1 / ___ 133 / \ / ________________________ \ / \ 134 /Master\____\___/ \____\________/Slave\ 135 \Clock / / \________ _______________/ \ \Clock/ 136 \____/ \ / \__ / 137 \____ path 2 __/ 138 \_______ ______/ 139 \_________/ 141 Figure 1 Multi-Path Connection 143 Since master and slave clocks are often connected through more than 144 one path in the network, as shown in Figure 1, [SLAVEDIV] suggested 145 that a time synchronization protocol can be run over multiple paths, 146 providing several advantages. First, it can significantly increase 147 the clock accuracy as shown in [SLAVEDIV]. Second, this approach 148 provides additional security, allowing to mitigate man-in-the-middle 149 attacks against the time synchronization protocol [DELAY-ATT]. Third, 150 using multiple paths concurrently provides an inherent failure 151 protection mechanism. 153 This document introduces Multi-Path PTP (MPPTP) and Multi-Path NTP 154 (MPNTP), respectively. These extensions are defined at the network 155 layer and do not require any changes in the PTP or in the NTP 156 protocols. 158 MPPTP and MPNTP are defined over IP networks. As IP networks 159 typically combine ECMP routing, this property is leveraged for the 160 multiple paths used in MPPTP and MPNTP. The key property of the 161 multi-path extension is that clocks in the network can use more than 162 one IP address. Each {master IP, slave IP} address pair defines a 163 path. Depending on the network topology and configuration, the IP 164 combination pairs can form multiple diverse paths used by the multi- 165 path synchronization protocols. It has been shown [MULTI] that using 166 multiple IP addresses over the wide Internet indeed allows two end- 167 points to attain multiple diverse paths. 169 This document introduces two variants for each of the two multi-path 170 protocols; a variant that requires both master and slave nodes to 171 support the multi-path protocol, referred to as the dual-ended 172 variant, and a backward compatible variant that allows a multi-path 173 clock to connect to a conventional single-path clock, referred to as 174 the single-ended variant. 176 2. Conventions Used in this Document 178 2.1. Abbreviations 180 BMC Best Master Clock [IEEE1588] 182 ECMP Equal Cost Multiple Path 184 LAN Local Area Network 186 MPNTP Multi-Path Network Time Protocol 188 MPPTP Multi-Path Precision Time Protocol 190 NTP Network Time Protocol [NTP] 192 PTP Precision Time Protocol [IEEE1588] 194 2.2. Terminology 196 In the NTP terminology, a time synchronization protocol is run 197 between a client and a server, while PTP uses the terms master and 198 slave. Throughout this document, the sections that refer to both PTP 199 and NTP generically use the terms master and slave. 201 3. Multiple Paths in IP Networks 203 3.1. Load Balancing 205 Traffic sent across IP networks is often load balanced across 206 multiple paths. The load balancing decisions are typically based on 207 packet header fields: source and destination addresses, Layer 4 208 ports, the Flow Label field in IPv6, etc. 209 Three common load balancing criteria are per-destination, per-flow 210 and per-packet. The per-destination load balancers take a load 211 balancing decision based on the destination IP address. Per-flow load 212 balancers use various fields in the packet header, e.g., IP addresses 213 and Layer 4 ports, for the load balancing decision. Per-packet load 214 balancers use flow-blind techniques such as round-robin without 215 basing the choice on the packet content. 217 3.2. Using Multiple Paths Concurrently 219 To utilize the diverse paths that traverse per-destination load- 220 balancers or per-flow load-balancers, the packet transmitter can vary 221 the IP addresses in the packet header. The analysis in [PARIS2] shows 222 that a significant majority of the flows on the internet traverse 223 per-destination or per-flow load-balancing. It presents statistics 224 that 72% of the flows traverse per-destination load balancing and 39% 225 of the flows traverse per-flow load-balancing, while only a 226 negligible part of the flows traverse per-packet load balancing. 227 These statistics show that the vast majority of the traffic on the 228 internet is load balanced based on packet header fields. 230 The approaches in this draft are based on varying the source and 231 destination IP addresses in the packet header. Possible extensions 232 have been considered that also vary the UDP ports. However some of 233 the existing implementations of PTP and NTP use fixed UDP port values 234 in both the source and destination UDP port fields, and thus do not 235 allow this approach. 237 3.3. Two-Way Paths 239 A key property of IP networks is that packets forwarded from A to B 240 do not necessarily traverse the same path as packets from B to A. 241 Thus, we define a two-way path for a master-slave connection as a 242 pair of one-way paths: the first from master to slave and the second 243 from slave to master. 245 If possible, a traffic engineering approach can be used to verify 246 that time synchronization traffic is always forwarded through 247 bidirectional two-way paths, i.e., that each two-way path uses the 248 same route on the forward and reverse directions, thus allowing 249 propagation time symmetry. However, in the general case two-way paths 250 do not necessarily use the same path for the forward and reverse 251 directions. 253 4. Solution Overview 255 The multi-path time synchronization protocols we present are 256 comprised of two building blocks; one is the path configuration and 257 identification, and the other is the algorithm used by the slave to 258 combine the information received from the various paths. 260 4.1. Path Configuration and Identification 262 The master and slave clocks must be able to determine the path of 263 transmitted protocol packets, and to identify the path of incoming 264 protocol packets. A path is determined by a {master IP, slave IP} 265 address pair. The synchronization protocol message exchange is run 266 independently through each path. 268 Each IP address pair defines a two-way path, and thus allows the 269 clocks to bind a transmitted packet to a specific path, or to 270 identify the path of an incoming packet. 272 If possible, the routing tables across the network should be 273 configured with multiple traffic engineered paths between the pair of 274 clocks. By carefully configuring the routers in such networks it is 275 possible to create diverse paths for each of the IP address pairs 276 between two clocks in the network. However, in public and provider 277 networks the load balancing behavior is hidden from the end users. In 278 this case the actual number of paths may be less than the number of 279 IP address pairs, since some of the address pairs may share common 280 paths. 282 4.2. Combining 284 Various methods can be used for combining the time information 285 received from the different paths. The output of the combining 286 algorithm is the accurate time offset. Combining methods are further 287 discussed in Section 6. 289 5. Multi-Path Time Synchronization Protocols over IP Networks 291 This section presents two variants of MPPTP and MPNTP; single-ended 292 multi-path time synchronization and dual-ended multi-path time 293 synchronization. In the first variant, the multi-path protocol is run 294 only by the slave and the master is not aware of its usage. In the 295 second variant, all clocks must support the multi-path protocol. 297 The dual-ended protocol provides higher path diversity by using 298 multiple IP addresses at both ends, the master and slave, while the 299 single-ended protocol only uses multiple addresses at the slave. On 300 the other hand, the dual-ended protocol can only be deployed when 301 both the master and the slave support this protocol. Dual-ended and 302 single-ended protocols can co-exist in the same network. Each slave 303 selects the connection(s) it wants to make with the available 304 masters. A dual-ended slave could switch to single-ended mode if it 305 does not see any dual-ended masters available. A single-ended slave 306 could connect to a single IP address of a dual-ended master. 308 Multi-path time synchronization, in both variants, requires clocks to 309 use multiple IP addresses. If possible, the set of IP addresses for 310 each clock should be chosen in a way that enables the establishment 311 of paths that are the most different. It is applicable if the load 312 balancing rules in the network are known. Using multiple IP addresses 313 introduces a tradeoff. A large number of IP addresses allows a large 314 number of diverse paths, providing the advantages of slave diversity 315 discussed in Section 1. On the other hand, a large number of IP 316 addresses is more costly, requires the network topology to be more 317 redundant, and exacts extra management overhead. 319 The descriptions in this section refer to the end-to-end scheme of 320 PTP, but are similarly applicable to the peer-to-peer scheme. The 321 MPNTP protocol described in this document refers to the NTP client- 322 server mode, although the concepts described here can be extended to 323 include the symmetric variant as well. 325 Multi-path synchronization protocols by nature require protocol 326 messages to be sent as unicast. Specifically in PTP, the following 327 messages must be sent as unicast in MPPTP: Sync, Delay_Req, 328 Delay_Resp, PDelay_Req, PDelay_Resp, Follow_Up, and 329 PDelay_Resp_Follow_Up. Note that [IEEE1588] allows these messages to 330 be sent either as multicast or as unicast. 332 5.1. Single-Ended Multi-Path Synchronization 334 In the single-ended approach, only the slave is aware of the fact 335 that multiple paths are used, while the master is agnostic to the 336 usage of multiple paths. This approach allows a hybrid network, where 337 some of the clocks are multi-path clocks, and others are conventional 338 one-path clocks. A single-ended multi-path clock presents itself to 339 the network as N independent clocks, using N IP addresses, as well as 340 N clock identity values (in PTP). Thus, the usage of multiple slave 341 identities by a slave clock is transparent from the master's point of 342 view, such that it treats each of the identities as a separate slave 343 clock. 345 5.1.1. Single-Ended MPPTP Synchronization Message Exchange 347 The single-ended MPPTP message exchange procedure is as follows. 349 o Each single-ended MPPTP clock has a fixed set of N IP addresses 350 and N corresponding clockIdentities. Each clock arbitrarily 351 defines one of its IP addresses and clockIdentity values as the 352 clock primary identity. 354 o A single-ended MPPTP port sends Announce messages only from its 355 primary identity, according to the BMC algorithm. 357 o The BMC algorithm at each clock determines the master, based on 358 the received Announce messages. 360 o A single-ended MPPTP port that is in the 'slave' state uses 361 unicast negotiation to request the master to transmit unicast 362 messages to each of the N slave clock identities. The slave port 363 periodically sends N Signaling messages to the master, using each 364 of its N identities. The Signaling message includes the 365 REQUEST_UNICAST_TRANSMISSION_TLV. 367 o The master periodically sends unicast Sync messages from its 368 primary identity, identified by the sourcePortIdentity and IP 369 address, to each of the slave identities. 371 o The slave, upon receiving a Sync message, identifies its path 372 according to the destination IP address. The slave sends a 373 Delay_Req unicast message to the primary identity of the master. 374 The Delay_Req is sent using the slave identity corresponding to 375 the path the Sync was received through. Note that the rate of 376 Delay_Req messages may be lower than the Sync message rate, and 377 thus a Sync message is not necessarily followed by a Delay_Req. 379 o The master, in response to a Delay_Req message from the slave, 380 responds with a Delay_Resp message using the IP address and 381 sourcePortIdentity from the Delay_Req message. 383 o Upon receiving the Delay_Resp message, the slave identifies the 384 path using the destination IP address and the 385 requestingPortIdentity. The slave can then compute the 386 corresponding path delay and the offset from the master. 388 o The slave combines the information from all negotiated paths. 390 5.1.2. Single-Ended MPNTP Synchronization Message Exchange 392 The single-ended MPNTP message exchange procedure is as follows. 394 o A single-ended MPNTP client has N separate identities, i.e., N IP 395 addresses. The assumption is that the server information, 396 including its IP address is known to the NTP clients. 398 o A single-ended MPNTP client initiates the NTP protocol with an NTP 399 server N times, using each of its N identities. 401 o The NTP protocol is maintained between the server and each of the 402 N client identities. 404 o The client sends NTP messages to the master using each of its N 405 identities. 407 o The server responds to the client's NTP messages using the IP 408 address from the received NTP packet. 410 o The client, upon receiving an NTP packet, uses the IP destination 411 address to identify the path it came through, and uses the time 412 information accordingly. 414 o The client combines the information from all paths. 416 5.2. Dual-Ended Multi-Path Synchronization 418 In dual-ended multi-path synchronization each clock has N IP 419 addresses. Time synchronization messages are exchanged between some 420 of the combinations of {master IP, slave IP} addresses, allowing 421 multiple paths between the master and slave. Note that the actual 422 number of paths between the master and slave may be less than the 423 number of chosen {master, slave} IP address pairs. 425 Once the multiple two-way connections are established, a separate 426 synchronization protocol exchange instance is run through each of 427 them. 429 5.2.1. Dual-Ended MPPTP Synchronization Message Exchange 431 The dual-ended MPPTP message exchange procedure is as follows. 433 o Every clock has N IP addresses, but uses a single clockIdentity. 435 o The BMC algorithm at each clock determines the master. The master 436 is identified by its clockIdentity, allowing other clocks to know 437 the multiple IP addresses it uses. 439 o When a clock sends an Announce message, it sends it from each of 440 its IP addresses with its clockIdentity. 442 o A dual-ended MPPTP port that is in the 'slave' state uses unicast 443 negotiation to request the master to transmit unicast messages to 444 some or all of its N_s IP addresses. This negotiation is done 445 individually between a slave IP address and the corresponding 446 master IP address that the slave desires a connection with. The 447 slave port periodically sends Signaling messages to the master, 448 using some or all of its N_s IP addresses as source, to the 449 corresponding master's N_m IP addresses. The Signaling message 450 includes the REQUEST_UNICAST_TRANSMISSION_TLV. 452 o The master periodically sends unicast Sync messages from each of 453 its IP addresses to the corresponding slave IP addresses for which 454 a unicast connection was negotiated. 456 o The slave, upon receiving a Sync message, identifies its path 457 according to the {source, destination} IP addresses. The slave 458 sends a Delay_Req unicast message, swapping the source and 459 destination IP addresses from the Sync message. Note that the rate 460 of Delay_Req messages may be lower than the Sync message rate, and 461 thus a Sync message is not necessarily followed by a Delay_Req. 463 o The master, in response to a Delay_Req message from the slave, 464 responds with a Delay_Resp message using the sourcePortIdentity 465 from the Delay_Req message, and swapping the IP addresses from the 466 Delay_Req. 468 o Upon receiving the Delay_Resp message, the slave identifies the 469 path using the {source, destination} IP address pair. The slave 470 can then compute the corresponding path delay and the offset from 471 the master. 473 o The slave combines the information from all negotiated paths. 475 5.2.2. Dual-Ended MPNTP Synchronization Message Exchange 477 The MPNTP message exchange procedure is as follows. 479 o Each NTP clock has a set of N IP addresses. The assumption is that 480 the server information, including its multiple IP addresses is 481 known to the NTP clients. 483 o The MPNTP client chooses N_svr of the N server IP addresses and 484 N_c of the N client IP addresses and initiates the N_svr*N_c 485 instances of the protocol, one for each {server IP, client IP} 486 pair, allowing the client to combine the information from the 487 N_s*N_c paths. 488 (N_svr and N_c indicate the number of IP addresses of the server 489 and client, respectively, which a client chooses to connect with) 491 o The client sends NTP messages to the master using each of the 492 source-destination address combinations. 494 o The server responds to the client's NTP messages using the IP 495 address combination from the received NTP packet. 497 o Using the {source, destination} IP address pair in the received 498 packets, the client identifies the path, and performs its 499 computations for each of the paths accordingly. 501 o The client combines the information from all paths. 503 5.3. Using Traceroute for Path Discovery 505 The protocols presented above use multiple IP addresses in a single 506 clock to create multiple paths. However, although each two-way path 507 is defined by a different {master, slave} address pair, some of the 508 IP address pairs may traverse exactly the same network path, making 509 them redundant. Traceroute-based path discovery can be used for 510 filtering only the IP addresses that obtain diverse paths. 'Paris 511 Traceroute' [PARIS] and 'TraceFlow' [TRACEFLOW] are examples of tools 512 that discover the paths between two points in the network. 514 The Traceroute-based filtering can be implemented by both master and 515 slave nodes, or it can be restricted to run only on slave nodes to 516 reduce the overhead on the master. For networks that guarantee the 517 path of the timing packets in the forward and reverse direction are 518 the same, path discovery should only be performed at the slave. 520 5.4. Using Unicast Discovery for MPPTP 522 As presented above, MPPTP uses Announce messages and the BMC 523 algorithm to discover the master. The unicast discovery option of PTP 524 can be used as an alternative. 526 When using unicast discovery the MPPTP slave ports maintain a list of 527 the IP addresses of the master. The slave port uses unicast 528 negotiation to request unicast service from the master, as follows: 530 o In single-ended MPPTP, the slave uses unicast negotiation from 531 each of its identities to the master's (only) identity. 533 o In dual-ended MPPTP, the slave uses unicast negotiation from its 534 IP addresses, each to a corresponding master IP address to request 535 unicast synchronization messages. 537 Afterwards, the message exchange continues as described in sections 538 5.1.1. and 5.2.1. 540 The unicast discovery option can be used in networks that do not 541 support multicast or in networks in which the master clocks are known 542 in advance. In particular, unicast discovery avoids multicasting 543 Announce messages. 545 6. Combining Algorithm 547 Previous sections discussed the methods of creating the multiple 548 paths and obtaining the time information required by the slave 549 algorithm. Once the time information is received through each of the 550 paths, the slave should use a combining algorithm, which consolidates 551 the information from the different paths into a single clock. 552 Various methods have been suggested for combining information from 553 different paths or from different clocks, e.g., [NTP], [SLAVEDIV], 554 [HIGH-AVAI], [KALMAN]. The choice of the combining algorithm is local 555 to the slave, and does not affect the interoperability of the 556 protocol. Hence, this document does not define a specific method to 557 be used by the slave. 558 7. Security Considerations 560 The security aspects of time synchronization protocols are discussed 561 in detail in [TICTOCSEC]. The methods describe in this document 562 propose to run a time synchronization protocol through redundant 563 paths, and thus allow to detect and mitigate man-in-the-middle 564 attacks, as described in [DELAY-ATT]. 566 8. IANA Considerations 568 There are no IANA actions required by this document. 570 RFC Editor: please delete this section before publication. 572 9. Acknowledgments 574 The authors gratefully acknowledge the useful comments provided by 575 Peter Meyer and Doug Arnold, as well as other comments received from 576 the TICTOC working group participants. 578 This document was prepared using 2-Word-v2.0.template.dot. 580 10. References 582 10.1. Normative References 584 [IEEE1588] IEEE Instrumentation and Measurement Society, "IEEE 585 Standard for a Precision Clock Synchronization 586 Protocol for Networked Measurement and Control 587 Systems", IEEE Std 1588, 2008. 589 [NTP] D. Mills, J. Martin, J. Burbank, W. Kasch, "Network 590 Time Protocol Version 4: Protocol and Algorithms 591 Specification", IETF, RFC 5905, 2010. 593 10.2. Informative References 595 [ASSYMETRY] Yihua He and Michalis Faloutsos and Srikanth 596 Krishnamurthy and Bradley Huffaker, "On routing 597 asymmetry in the internet", IEEE Globecom, 2005. 599 [ASSYMETRY2] Abhinav Pathak, Himabindu Pucha, Ying Zhang, Y. 600 Charlie Hu, and Z. Morley Mao, "A measurement study of 601 internet delay asymmetry", PAM'08, 2008. 603 [DELAY-ATT] T. Mizrahi, "A Game Theoretic Analysis of Delay 604 Attacks against Time Synchronization Protocols", 605 ISPCS, 2012. 607 [HIGH-AVAI] P. Ferrari, A. Flammini, S. Rinaldi, G. Prytz, "High 608 availability IEEE 1588 nodes over IEEE 802.1 aq 609 Shortest Path Bridging networks" ISPCS, 2013. 611 [KALMAN] G. Giorgi, C. Narduzzi, "Kalman filtering for multi- 612 path network synchronization" ISPCS, 2014. 614 [MULTI] A. Shpiner, Y. Revah, T. Mizrahi, "Multi-path Time 615 Protocols" ISPCS, 2013. 617 [PARIS] Brice Augustin, Timur Friedman and Renata Teixeira, 618 "Measuring Load-balanced Paths in the Internet", IMC, 619 2007. 621 [PARIS2] B. Augustin, T. Friedman, and R. Teixeira, "Measuring 622 Multipath Routing in the Internet", IEEE/ACM 623 Transactions on Networking, 19(3), p. 830 - 840, June 624 2011. 626 [SLAVEDIV] T. Mizrahi, "Slave Diversity: Using Multiple Paths to 627 Improve the Accuracy of Clock Synchronization 628 Protocols", ISPCS, 2012. 630 [TICTOCSEC] T. Mizrahi, "Security Requirements of Time Protocols 631 in Packet Switched Networks", IETF, RFC 7384, 2014. 633 [TRACEFLOW] J. Narasimhan, B. V. Venkataswami, R. Groves and P. 634 Hoose, "Traceflow", IETF, draft-janapath-intarea- 635 traceflow, work in progress, 2012. 637 Authors' Addresses 639 Alex Shpiner 640 Department of Electrical Engineering 641 Technion - Israel Institute of Technology 642 Haifa, 32000 Israel 644 Email: shalex@tx.technion.ac.il 646 Richard Tse 647 PMC-Sierra 648 8555 Baxter Place 649 Burnaby, BC 650 Canada 651 V5A 4V7 653 Email: Richard.Tse@pmcs.com 655 Craig Schelp 656 PMC-Sierra 657 8555 Baxter Place 658 Burnaby, BC 659 Canada 660 V5A 4V7 662 Email: craig.schelp@pmcs.com 664 Tal Mizrahi 665 Marvell 666 6 Hamada St. 667 Yokneam, 20692 Israel 669 Email: talmi@marvell.com