idnits 2.17.1 draft-ietf-tictoc-multi-path-synchronization-00.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 (July 27, 2014) is 3532 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: January 2015 C. Schelp 5 PMC-Sierra 6 T. Mizrahi 7 Marvell 8 July 27, 2014 10 Multi-Path Time Synchronization 11 draft-ietf-tictoc-multi-path-synchronization-00.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 protection. 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 January 27, 2015. 60 Copyright Notice 62 Copyright (c) 2014 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 ....................... 5 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 6.1. Averaging .............................................. 13 99 6.2. Switching / Dynamic Algorithm .......................... 13 100 6.3. NTP-like Filtering-Clustering-Combining Algorithm ...... 13 101 7. Security Considerations ..................................... 14 102 8. IANA Considerations ......................................... 14 103 9. Acknowledgments ............................................. 14 104 10. References ................................................. 14 105 10.1. Normative References .................................. 14 106 10.2. Informative References ................................ 15 108 1. Introduction 110 The two most common time synchronization protocols in IP networks are 111 the Network Time Protocol [NTP], and the Precision Time Protocol 112 (PTP), defined in the IEEE 1588 standard [IEEE1588]. 113 The accuracy of the time synchronization protocols directly depends 114 on the stability and the symmetry of propagation delays on both 115 directions between the master and slave clocks. Depending on the 116 nature of the underlying network, time synchronization protocol 117 packets can be subject to variable network latency or path asymmetry 118 (e.g. [ASSYMETRY], [ASSYMETRY2]). As time sensitive applications 119 evolve, accuracy requirements are becoming increasingly stringent. 121 Using a single network path in a clock synchronization protocol 122 closely ties the slave clock accuracy to the behavior of the specific 123 path, which may suffer from temporal congestion, faults or malicious 124 attacks. Relying on multiple clock servers as in NTP solves these 125 problems, but requires active maintenance of multiple accurate 126 sources in the network, which is not always possible. The usage of 127 Transparent Clocks (TC) in PTP solves the congestion problem by 128 eliminating the queueing time from the delay calculations, but 129 requires the intermediate routers and switches to support the TC 130 functionality, which is not always the case. 132 ____ 133 ______/ \_____ 134 ___/ \____ 135 ____/ \ 136 ____ / path 1 / ___ 137 / \ / ________________________ \ / \ 138 /Master\____\___/ \____\________/Slave\ 139 \Clock / / \________ _______________/ \ \Clock/ 140 \____/ \ / \__ / 141 \____ path 2 __/ 142 \_______ ______/ 143 \_________/ 145 Figure 1 Multi-Path Connection 147 Since master and slave clocks are often connected through more than 148 one path in the network, as shown in Figure 1, [SLAVEDIV] suggested 149 that a time synchronization protocol can be run over multiple paths, 150 providing several advantages. First, it can significantly increase 151 the clock accuracy as shown in [SLAVEDIV]. Second, this approach 152 provides additional security, allowing to mitigate man-in-the-middle 153 attacks against the time synchronization protocol [DELAY-ATT]. Third, 154 using multiple paths concurrently provides an inherent failure 155 protection mechanism. 157 This document introduces Multi-Path PTP (MPPTP) and Multi-Path NTP 158 (MPNTP), respectively. These extensions are defined at the network 159 layer and do not require any changes in the PTP or in the NTP 160 protocols. 162 MPPTP and MPNTP are defined over IP networks. As IP networks 163 typically combine ECMP routing, this property is leveraged for the 164 multiple paths used in MPPTP and MPNTP. The key property of the 165 multi-path extension is that clocks in the network can use more than 166 one IP address. Each {master IP, slave IP} address pair defines a 167 path. Depending on the network topology and configuration, the IP 168 combination pairs can form multiple diverse paths used by the multi- 169 path synchronization protocols. 171 This document introduces two variants for each of the two multi-path 172 protocols; a variant that requires both master and slave nodes to 173 support the multi-path protocol, referred to as the dual-ended 174 variant, and a backward compatible variant that allows a multi-path 175 clock to connect to a conventional single-path clock, referred to as 176 the single-ended variant. 178 2. Conventions Used in this Document 180 2.1. Abbreviations 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 192 PTP Precision Time Protocol 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. This document surveys several 286 combining methods in Section 5.4. The output of the combining 287 algorithm is the accurate time offset. 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. This section discusses the algorithm used to combine this 550 information into a single accurate time estimate. Note that the 551 choice of the combining algorithm is local to the slave, and does not 552 affect the interoperability of the protocol. 553 Several combining methods are examined next. 555 6.1. Averaging 557 In the first method the slave performs an autonomous time computation 558 for each of the master-slave paths, and obtains the combined time by 559 simply averaging the separate instances. This method can be further 560 enhanced by adding weights to each of the paths. For example, a 561 reasonable weighting choice is to use an inverse of the round-trip 562 delay between the peers. Another option is to use the inverse of the 563 path delay variance, which is approximately the maximum likelihood 564 estimator under certain assumptions [WEIGHT-MEAN]. 566 6.2. Switching / Dynamic Algorithm 568 The switching and dynamic algorithms are presented in [SLAVEDIV]. The 569 switching algorithm periodically chooses a primary path, and performs 570 all time computations based on the protocol packets received through 571 the primary path. The primary path is defined as the path with the 572 minimal distance between the sampled delay and the average delay. The 573 dynamic algorithm dynamically chooses between the result of the 574 switching algorithm and the averaging. 575 6.3. NTP-like Filtering-Clustering-Combining Algorithm 577 NTP ([NTP], [NTP2]) provides an efficient algorithm of combining 578 offset samples from multiple peers. The same approach can be used in 579 MPPTP and MPNTP. 581 In the MPNTP, the selection and combining algorithms treat the offset 582 samples from multiple paths as NTP treats samples from distinct 583 peers. The rest of the selection and combining algorithms, as well as 584 clock control logic is the same as in conventional NTP. In MPPTP, a 585 similar approach to NTP can be adopted. 587 The combining algorithm [NTP3] contains three steps: filtering, 588 selection and clustering. 590 In the filtering step, the best of the last n (usually n=8) samples 591 of each peer is chosen. The choice criterion is the combination of a 592 round trip delay estimate of the sample and the distance from the 593 average offset of all n samples of a peer. 595 In the selection step the peers are divided into two groups: true- 596 chimers and false tickers. 598 The clustering step chooses a subset of the true-chimers, whose peer 599 jitter (the variance of peer offset samples) is smaller than the 600 total select jitter of all selected peer offsets (the variance of the 601 best offset of the selected peers). 603 The offset samples that passed through the three steps are combined 604 by a weighted average into a single offset estimate. Detailed 605 explanations are provided in [NTP2],[NTP3]. 607 7. Security Considerations 609 The security aspects of time synchronization protocols are discussed 610 in detail in [TICTOCSEC]. The methods describe in this document 611 propose to run a time synchronization protocol through redundant 612 paths, and thus allow to detect and mitigate man-in-the-middle 613 attacks, as described in [DELAY-ATT]. 615 8. IANA Considerations 617 There are no IANA actions required by this document. 619 RFC Editor: please delete this section before publication. 621 9. Acknowledgments 623 The authors gratefully acknowledge the useful comments provided by 624 Peter Meyer and Doug Arnold, as well as other comments received from 625 the TICTOC working group participants. 627 This document was prepared using 2-Word-v2.0.template.dot. 629 10. References 631 10.1. Normative References 633 [IEEE1588] IEEE Instrumentation and Measurement Society, "IEEE 634 Standard for a Precision Clock Synchronization 635 Protocol for Networked Measurement and Control 636 Systems", IEEE Std 1588, 2008. 638 [NTP] D. Mills, J. Martin, J. Burbank, W. Kasch, "Network 639 Time Protocol Version 4: Protocol and Algorithms 640 Specification", IETF, RFC 5905, 2010. 642 10.2. Informative References 644 [ASSYMETRY] Yihua He and Michalis Faloutsos and Srikanth 645 Krishnamurthy and Bradley Huffaker, "On routing 646 asymmetry in the internet", IEEE Globecom, 2005. 648 [ASSYMETRY2] Abhinav Pathak, Himabindu Pucha, Ying Zhang, Y. 649 Charlie Hu, and Z. Morley Mao, "A measurement study of 650 internet delay asymmetry", PAM'08, 2008. 652 [DELAY-ATT] T. Mizrahi, "A Game Theoretic Analysis of Delay 653 Attacks against Time Synchronization Protocols", 654 ISPCS, 2012. 656 [NTP2] Mills, D.L., "Internet time synchronization: the 657 Network Time Protocol", IEEE Trans. Communications 658 COM-39, 10 (October 1991), 1482-1493. 660 [NTP3] Mills, D.L., "Improved algorithms for synchronizing 661 computer network clocks", IEEE/ACM Trans. Networks 3, 662 3(June 1995), 245-254. 664 [PARIS] Brice Augustin, Timur Friedman and Renata Teixeira, 665 "Measuring Load-balanced Paths in the Internet", IMC, 666 2007. 668 [PARIS2] B. Augustin, T. Friedman, and R. Teixeira, "Measuring 669 Multipath Routing in the Internet", IEEE/ACM 670 Transactions on Networking, 19(3), p. 830 - 840, June 671 2011. 673 [SLAVEDIV] T. Mizrahi, "Slave Diversity: Using Multiple Paths to 674 Improve the Accuracy of Clock Synchronization 675 Protocols", ISPCS, 2012. 677 [TICTOCSEC] T. Mizrahi, K. O'Donoghue, "Security Requirements of 678 Time Protocols in Packet Switched Networks", IETF, 679 draft-ietf-tictoc-security-requirements, work in 680 progress, 2013. 682 [TRACEFLOW] J. Narasimhan, B. V. Venkataswami, R. Groves and P. 683 Hoose, "Traceflow", IETF, draft-janapath-intarea- 684 traceflow, work in progress, 2012. 686 [WEIGHT-MEAN] http://en.wikipedia.org/wiki/Weighted_mean#Dealing_wi 687 th_variance 689 Authors' Addresses 691 Alex Shpiner 692 Department of Electrical Engineering 693 Technion - Israel Institute of Technology 694 Haifa, 32000 Israel 696 Email: shalex@tx.technion.ac.il 698 Richard Tse 699 PMC-Sierra 700 8555 Baxter Place 701 Burnaby, BC 702 Canada 703 V5A 4V7 705 Email: Richard.Tse@pmcs.com 707 Craig Schelp 708 PMC-Sierra 709 8555 Baxter Place 710 Burnaby, BC 711 Canada 712 V5A 4V7 714 Email: craig.schelp@pmcs.com 716 Tal Mizrahi 717 Marvell 718 6 Hamada St. 719 Yokneam, 20692 Israel 721 Email: talmi@marvell.com