idnits 2.17.1 draft-ietf-tictoc-multi-path-synchronization-05.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 (August 25, 2016) is 2801 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 6824 (ref. 'MPTCP') (Obsoleted by RFC 8684) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Shpiner 2 Internet Draft Mellanox 3 Intended status: Experimental R. Tse 4 Expires: February 2017 C. Schelp 5 PMC-Sierra 6 T. Mizrahi 7 Marvell 8 August 25, 2016 10 Multi-Path Time Synchronization 11 draft-ietf-tictoc-multi-path-synchronization-05.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 February 25, 2017. 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. Overview..................................................7 90 5.2. Single-Ended Multi-Path Synchronization...................9 91 5.2.1. Single-Ended MPPTP Synchronization Message Exchange..9 92 5.2.2. Single-Ended MPNTP Synchronization Message Exchange.10 93 5.3. Dual-Ended Multi-Path Synchronization....................10 94 5.3.1. Dual-Ended MPPTP Synchronization Message Exchange...11 95 5.3.2. Dual-Ended MPNTP Synchronization Message Exchange...12 96 5.4. Using Traceroute for Path Discovery......................12 97 5.5. Using Unicast Discovery for MPPTP........................13 98 6. Combining Algorithm...........................................13 99 7. Security Considerations.......................................14 100 8. IANA Considerations...........................................14 101 9. Acknowledgments...............................................14 102 10. References...................................................14 103 10.1. Normative References....................................14 104 10.2. Informative References..................................14 106 1. Introduction 108 The two most common time synchronization protocols in IP networks are 109 the Network Time Protocol [NTP], and the Precision Time Protocol 110 (PTP), defined in the IEEE 1588 standard [IEEE1588]. 111 The accuracy of the time synchronization protocols directly depends 112 on the stability and the symmetry of propagation delays on both 113 directions between the master and slave clocks. Depending on the 114 nature of the underlying network, time synchronization protocol 115 packets can be subject to variable network latency or path asymmetry 116 (e.g. [ASSYMETRY], [ASSYMETRY2]). As time sensitive applications 117 evolve, accuracy requirements are becoming increasingly stringent. 119 Using a single network path in a clock synchronization protocol 120 closely ties the slave clock accuracy to the behavior of the specific 121 path, which may suffer from temporal congestion, faults or malicious 122 attacks. Relying on multiple clock servers as in NTP solves these 123 problems, but requires active maintenance of multiple accurate 124 sources in the network, which is not always possible. The usage of 125 Transparent Clocks (TC) in PTP solves the congestion problem by 126 eliminating the queueing time from the delay calculations, but does 127 not address security or fault-tolerance aspects. 129 ____ 130 ______/ \_____ 131 ___/ \____ 132 ____/ \ 133 ____ / path 1 / ___ 134 / \ / ________________________ \ / \ 135 /Master\____\___/ \____\________/Slave\ 136 \Clock / / \________ _______________/ \ \Clock/ 137 \____/ \ / \__ / 138 \____ path 2 __/ 139 \_______ ______/ 140 \_________/ 142 Figure 1 Multi-Path Connection 144 Since master and slave clocks are often connected through more than 145 one path in the network, as shown in Figure 1, [SLAVEDIV] suggested 146 that a time synchronization protocol can be run over multiple paths, 147 providing several advantages. First, it can significantly increase 148 the clock accuracy as shown in [SLAVEDIV]. Second, this approach 149 provides additional security, allowing to mitigate man-in-the-middle 150 attacks against the time synchronization protocol [DELAY-ATT]. Third, 151 using multiple paths concurrently provides an inherent failure 152 protection mechanism. 154 This document introduces Multi-Path PTP (MPPTP) and Multi-Path NTP 155 (MPNTP), respectively. These extensions are defined at the network 156 layer and do not require any changes in the PTP or in the NTP 157 protocols. 159 MPPTP and MPNTP are defined over IP networks. As IP networks 160 typically combine ECMP routing, this property is leveraged for the 161 multiple paths used in MPPTP and MPNTP. The key property of the 162 multi-path extension is that clocks in the network can use more than 163 one IP address. Each {master IP, slave IP} address pair defines a 164 path. Depending on the network topology and configuration, the IP 165 combination pairs can form multiple diverse paths used by the multi- 166 path synchronization protocols. It has been shown [MULTI] that using 167 multiple IP addresses over the wide Internet indeed allows two end- 168 points to attain multiple diverse paths. 170 This document introduces two variants for each of the two multi-path 171 protocols; a variant that requires both master and slave nodes to 172 support the multi-path protocol, referred to as the dual-ended 173 variant, and a backward compatible variant that allows a multi-path 174 clock to connect to a conventional single-path clock, referred to as 175 the single-ended variant. 177 2. Conventions Used in this Document 179 2.1. Abbreviations 181 BMC Best Master Clock [IEEE1588] 183 ECMP Equal Cost Multiple Path 185 LAN Local Area Network 187 MPNTP Multi-Path Network Time Protocol 189 MPPTP Multi-Path Precision Time Protocol 191 NTP Network Time Protocol [NTP] 193 PTP Precision Time Protocol [IEEE1588] 195 2.2. Terminology 197 In the NTP terminology, a time synchronization protocol is run 198 between a client and a server, while PTP uses the terms master and 199 slave. Throughout this document, the sections that refer to both PTP 200 and NTP generically use the terms master and slave. 202 3. Multiple Paths in IP Networks 204 3.1. Load Balancing 206 Traffic sent across IP networks is often load balanced across 207 multiple paths. The load balancing decisions are typically based on 208 packet header fields: source and destination addresses, Layer 4 209 ports, the Flow Label field in IPv6, etc. 210 Three common load balancing criteria are per-destination, per-flow 211 and per-packet. The per-destination load balancers take a load 212 balancing decision based on the destination IP address. Per-flow load 213 balancers use various fields in the packet header, e.g., IP addresses 214 and Layer 4 ports, for the load balancing decision. Per-packet load 215 balancers use flow-blind techniques such as round-robin without 216 basing the choice on the packet content. 218 3.2. Using Multiple Paths Concurrently 220 To utilize the diverse paths that traverse per-destination load- 221 balancers or per-flow load-balancers, the packet transmitter can vary 222 the IP addresses in the packet header. The analysis in [PARIS2] shows 223 that a significant majority of the flows on the internet traverse 224 per-destination or per-flow load-balancing. It presents statistics 225 that 72% of the flows traverse per-destination load balancing and 39% 226 of the flows traverse per-flow load-balancing, while only a 227 negligible part of the flows traverse per-packet load balancing. 228 These statistics show that the vast majority of the traffic on the 229 internet is load balanced based on packet header fields. 231 The approaches in this draft are based on varying the source and 232 destination IP addresses in the packet header. Possible extensions 233 have been considered that also vary the UDP ports. However some of 234 the existing implementations of PTP and NTP use fixed UDP port values 235 in both the source and destination UDP port fields, and thus do not 236 allow this approach. 238 3.3. Two-Way Paths 240 A key property of IP networks is that packets forwarded from A to B 241 do not necessarily traverse the same path as packets from B to A. 242 Thus, we define a two-way path for a master-slave connection as a 243 pair of one-way paths: the first from master to slave and the second 244 from slave to master. 246 If possible, a traffic engineering approach can be used to verify 247 that time synchronization traffic is always forwarded through 248 bidirectional two-way paths, i.e., that each two-way path uses the 249 same route on the forward and reverse directions, thus allowing 250 propagation time symmetry. However, in the general case two-way paths 251 do not necessarily use the same path for the forward and reverse 252 directions. 254 4. Solution Overview 256 The multi-path time synchronization protocols we present are 257 comprised of two building blocks; one is the path configuration and 258 identification, and the other is the algorithm used by the slave to 259 combine the information received from the various paths. 261 4.1. Path Configuration and Identification 263 The master and slave clocks must be able to determine the path of 264 transmitted protocol packets, and to identify the path of incoming 265 protocol packets. A path is determined by a {master IP, slave IP} 266 address pair. The synchronization protocol message exchange is run 267 independently through each path. 269 Each IP address pair defines a two-way path, and thus allows the 270 clocks to bind a transmitted packet to a specific path, or to 271 identify the path of an incoming packet. 273 If possible, the routing tables across the network should be 274 configured with multiple traffic engineered paths between the pair of 275 clocks. By carefully configuring the routers in such networks it is 276 possible to create diverse paths for each of the IP address pairs 277 between two clocks in the network. However, in public and provider 278 networks the load balancing behavior is hidden from the end users. In 279 this case the actual number of paths may be less than the number of 280 IP address pairs, since some of the address pairs may share common 281 paths. 283 4.2. Combining 285 Various methods can be used for combining the time information 286 received from the different paths. The output of the combining 287 algorithm is the accurate time offset. Combining methods are further 288 discussed in Section 6. 290 5. Multi-Path Time Synchronization Protocols over IP Networks 292 5.1. Overview 294 This section presents two variants of MPPTP and MPNTP; single-ended 295 multi-path time synchronization and dual-ended multi-path time 296 synchronization. In the first variant, the multi-path protocol is run 297 only by the slave and the master is not aware of its usage. In the 298 second variant, all clocks must support the multi-path protocol. 300 The dual-ended protocol provides higher path diversity by using 301 multiple IP addresses at both ends, the master and slave, while the 302 single-ended protocol only uses multiple addresses at the slave. On 303 the other hand, the dual-ended protocol can only be deployed when 304 both the master and the slave support this protocol. Dual-ended and 305 single-ended protocols can co-exist in the same network. Each slave 306 selects the connection(s) it wants to make with the available 307 masters. A dual-ended slave could switch to single-ended mode if it 308 does not see any dual-ended masters available. A single-ended slave 309 could connect to a single IP address of a dual-ended master. 311 Multi-path time synchronization, in both variants, requires clocks to 312 use multiple IP addresses. Using multiple IP addresses introduces a 313 tradeoff. A large number of IP addresses allows a large number of 314 diverse paths, providing the advantages of slave diversity discussed 315 in Section 1. On the other hand, a large number of IP addresses is 316 more costly, requires the network topology to be more redundant, and 317 exacts extra management overhead. 319 If possible, the set of IP addresses for each clock should be chosen 320 in a way that enables the establishment of paths that are the most 321 different. If the load balancing rules in the network are known, it 322 is possible to choose the IP addresses in a way that enforces path 323 diversity. However, even if the load balancing scheme is not known, a 324 careful choice of the IP addresses can increase the probability of 325 path diversity. For example, choosing multiple addresses with 326 different prefixes is likely to produce higher path diversity, as BGP 327 routers are more likely to route these different prefixes through 328 different routes. 330 The use of Network Address Translation (NAT) may significantly reduce 331 the effectiveness of multi-path synchronization in some cases. For 332 example, if a master uses multiple IP addresses that are translated 333 to a single IP address, the path diversity can be dramatically 334 reduced compared to a network that does not use NAT. Thus, path 335 discovery should be used to identify the possible paths between the 336 master and slave. Path discovery is further discussed in Section 5.4. 338 The concept of using multiple IP addresses or multiple interfaces is 339 a well-established concept that is being used today by various 340 applications and protocols, e.g., [MPTCP]. Using multiple interfaces 341 introduces some challenges and issues, which were presented and 342 discussed in [MIF]. 344 The descriptions in this section refer to the end-to-end scheme of 345 PTP, but are similarly applicable to the peer-to-peer scheme. The 346 MPNTP protocol described in this document refers to the NTP client- 347 server mode, although the concepts described here can be extended to 348 include the symmetric variant as well. 350 Multi-path synchronization protocols by nature require protocol 351 messages to be sent as unicast. Specifically in PTP, the following 352 messages must be sent as unicast in MPPTP: Sync, Delay_Req, 353 Delay_Resp, PDelay_Req, PDelay_Resp, Follow_Up, and 354 PDelay_Resp_Follow_Up. Note that [IEEE1588] allows these messages to 355 be sent either as multicast or as unicast. 357 5.2. Single-Ended Multi-Path Synchronization 359 In the single-ended approach, only the slave is aware of the fact 360 that multiple paths are used, while the master is agnostic to the 361 usage of multiple paths. This approach allows a hybrid network, where 362 some of the clocks are multi-path clocks, and others are conventional 363 one-path clocks. A single-ended multi-path clock presents itself to 364 the network as N independent clocks, using N IP addresses, as well as 365 N clock identity values (in PTP). Thus, the usage of multiple slave 366 identities by a slave clock is transparent from the master's point of 367 view, such that it treats each of the identities as a separate slave 368 clock. 370 5.2.1. Single-Ended MPPTP Synchronization Message Exchange 372 The single-ended MPPTP message exchange procedure is as follows. 374 o Each single-ended MPPTP clock has a fixed set of N IP addresses 375 and N corresponding clockIdentities. Each clock arbitrarily 376 defines one of its IP addresses and clockIdentity values as the 377 clock primary identity. 379 o A single-ended MPPTP port sends Announce messages only from its 380 primary identity, according to the BMC algorithm. 382 o The BMC algorithm at each clock determines the master, based on 383 the received Announce messages. 385 o A single-ended MPPTP port that is in the 'slave' state uses 386 unicast negotiation to request the master to transmit unicast 387 messages to each of the N slave clock identities. The slave port 388 periodically sends N Signaling messages to the master, using each 389 of its N identities. The Signaling message includes the 390 REQUEST_UNICAST_TRANSMISSION_TLV. 392 o The master periodically sends unicast Sync messages from its 393 primary identity, identified by the sourcePortIdentity and IP 394 address, to each of the slave identities. 396 o The slave, upon receiving a Sync message, identifies its path 397 according to the destination IP address. The slave sends a 398 Delay_Req unicast message to the primary identity of the master. 399 The Delay_Req is sent using the slave identity corresponding to 400 the path the Sync was received through. Note that the rate of 401 Delay_Req messages may be lower than the Sync message rate, and 402 thus a Sync message is not necessarily followed by a Delay_Req. 404 o The master, in response to a Delay_Req message from the slave, 405 responds with a Delay_Resp message using the IP address and 406 sourcePortIdentity from the Delay_Req message. 408 o Upon receiving the Delay_Resp message, the slave identifies the 409 path using the destination IP address and the 410 requestingPortIdentity. The slave can then compute the 411 corresponding path delay and the offset from the master. 413 o The slave combines the information from all negotiated paths. 415 5.2.2. Single-Ended MPNTP Synchronization Message Exchange 417 The single-ended MPNTP message exchange procedure is as follows. 419 o A single-ended MPNTP client has N separate identities, i.e., N IP 420 addresses. The assumption is that the server information, 421 including its IP address is known to the NTP clients. 423 o A single-ended MPNTP client initiates the NTP protocol with an NTP 424 server N times, using each of its N identities. 426 o The NTP protocol is maintained between the server and each of the 427 N client identities. 429 o The client sends NTP messages to the master using each of its N 430 identities. 432 o The server responds to the client's NTP messages using the IP 433 address from the received NTP packet. 435 o The client, upon receiving an NTP packet, uses the IP destination 436 address to identify the path it came through, and uses the time 437 information accordingly. 439 o The client combines the information from all paths. 441 5.3. Dual-Ended Multi-Path Synchronization 443 In dual-ended multi-path synchronization each clock has N IP 444 addresses. Time synchronization messages are exchanged between some 445 of the combinations of {master IP, slave IP} addresses, allowing 446 multiple paths between the master and slave. Note that the actual 447 number of paths between the master and slave may be less than the 448 number of chosen {master, slave} IP address pairs. 450 Once the multiple two-way connections are established, a separate 451 synchronization protocol exchange instance is run through each of 452 them. 454 5.3.1. Dual-Ended MPPTP Synchronization Message Exchange 456 The dual-ended MPPTP message exchange procedure is as follows. 458 o Every clock has N IP addresses, but uses a single clockIdentity. 460 o The BMC algorithm at each clock determines the master. The master 461 is identified by its clockIdentity, allowing other clocks to know 462 the multiple IP addresses it uses. 464 o When a clock sends an Announce message, it sends it from each of 465 its IP addresses with its clockIdentity. 467 o A dual-ended MPPTP port that is in the 'slave' state uses unicast 468 negotiation to request the master to transmit unicast messages to 469 some or all of its N_s IP addresses. This negotiation is done 470 individually between a slave IP address and the corresponding 471 master IP address that the slave desires a connection with. The 472 slave port periodically sends Signaling messages to the master, 473 using some or all of its N_s IP addresses as source, to the 474 corresponding master's N_m IP addresses. The Signaling message 475 includes the REQUEST_UNICAST_TRANSMISSION_TLV. 477 o The master periodically sends unicast Sync messages from each of 478 its IP addresses to the corresponding slave IP addresses for which 479 a unicast connection was negotiated. 481 o The slave, upon receiving a Sync message, identifies its path 482 according to the {source, destination} IP addresses. The slave 483 sends a Delay_Req unicast message, swapping the source and 484 destination IP addresses from the Sync message. Note that the rate 485 of Delay_Req messages may be lower than the Sync message rate, and 486 thus a Sync message is not necessarily followed by a Delay_Req. 488 o The master, in response to a Delay_Req message from the slave, 489 responds with a Delay_Resp message using the sourcePortIdentity 490 from the Delay_Req message, and swapping the IP addresses from the 491 Delay_Req. 493 o Upon receiving the Delay_Resp message, the slave identifies the 494 path using the {source, destination} IP address pair. The slave 495 can then compute the corresponding path delay and the offset from 496 the master. 498 o The slave combines the information from all negotiated paths. 500 5.3.2. Dual-Ended MPNTP Synchronization Message Exchange 502 The MPNTP message exchange procedure is as follows. 504 o Each NTP clock has a set of N IP addresses. The assumption is that 505 the server information, including its multiple IP addresses is 506 known to the NTP clients. 508 o The MPNTP client chooses N_svr of the N server IP addresses and 509 N_c of the N client IP addresses and initiates the N_svr*N_c 510 instances of the protocol, one for each {server IP, client IP} 511 pair, allowing the client to combine the information from the 512 N_s*N_c paths. 513 (N_svr and N_c indicate the number of IP addresses of the server 514 and client, respectively, which a client chooses to connect with) 516 o The client sends NTP messages to the master using each of the 517 source-destination address combinations. 519 o The server responds to the client's NTP messages using the IP 520 address combination from the received NTP packet. 522 o Using the {source, destination} IP address pair in the received 523 packets, the client identifies the path, and performs its 524 computations for each of the paths accordingly. 526 o The client combines the information from all paths. 528 5.4. Using Traceroute for Path Discovery 530 The protocols presented above use multiple IP addresses in a single 531 clock to create multiple paths. However, although each two-way path 532 is defined by a different {master, slave} address pair, some of the 533 IP address pairs may traverse exactly the same network path, making 534 them redundant. 536 Traceroute-based path discovery can be used for filtering only the IP 537 addresses that obtain diverse paths. 'Paris Traceroute' [PARIS] and 538 'TraceFlow' [TRACEFLOW] are examples of tools that discover the paths 539 between two points in the network. It should be noted that this 540 filtering approach is effective only if the Traceroute implementation 541 uses the same IP addresses and UDP ports as the synchronization 542 protocol packets. Since some Traceroute implementations vary the UDP 543 ports, they may not be effective in identifying and filtering 544 redundant paths in synchronization protocols. 546 The Traceroute-based filtering can be implemented by both master and 547 slave nodes, or it can be restricted to run only on slave nodes to 548 reduce the overhead on the master. For networks that guarantee that 549 the path of the timing packets in the forward and reverse direction 550 are the same, path discovery should only be performed at the slave. 552 Since network routes change over time, path discovery and redundant 553 path filtering should be performed periodically. Two {master,slave} 554 pairs that produce two diverse paths may be rerouted to use the same 555 paths. Thus, the set of addresses that are used by each clock should 556 be reassessed regularly. 558 5.5. Using Unicast Discovery for MPPTP 560 As presented above, MPPTP uses Announce messages and the BMC 561 algorithm to discover the master. The unicast discovery option of PTP 562 can be used as an alternative. 564 When using unicast discovery the MPPTP slave ports maintain a list of 565 the IP addresses of the master. The slave port uses unicast 566 negotiation to request unicast service from the master, as follows: 568 o In single-ended MPPTP, the slave uses unicast negotiation from 569 each of its identities to the master's (only) identity. 571 o In dual-ended MPPTP, the slave uses unicast negotiation from its 572 IP addresses, each to a corresponding master IP address to request 573 unicast synchronization messages. 575 Afterwards, the message exchange continues as described in sections 576 5.2.1. and 5.3.1. 578 The unicast discovery option can be used in networks that do not 579 support multicast or in networks in which the master clocks are known 580 in advance. In particular, unicast discovery avoids multicasting 581 Announce messages. 583 6. Combining Algorithm 585 Previous sections discussed the methods of creating the multiple 586 paths and obtaining the time information required by the slave 587 algorithm. Once the time information is received through each of the 588 paths, the slave should use a combining algorithm, which consolidates 589 the information from the different paths into a single clock. 590 Various methods have been suggested for combining information from 591 different paths or from different clocks, e.g., [NTP], [SLAVEDIV], 593 [HIGH-AVAI], [KALMAN]. The choice of the combining algorithm is local 594 to the slave, and does not affect the interoperability of the 595 protocol. Hence, this document does not define a specific method to 596 be used by the slave. 597 7. Security Considerations 599 The security aspects of time synchronization protocols are discussed 600 in detail in [TICTOCSEC]. The methods describe in this document 601 propose to run a time synchronization protocol through redundant 602 paths, and thus allow to detect and mitigate man-in-the-middle 603 attacks, as described in [DELAY-ATT]. 605 8. IANA Considerations 607 There are no IANA actions required by this document. 609 RFC Editor: please delete this section before publication. 611 9. Acknowledgments 613 The authors gratefully acknowledge the useful comments provided by 614 Peter Meyer, Doug Arnold, Joe Abley, and Zhen Cao, as well as other 615 comments received from the TICTOC working group participants. 617 This document was prepared using 2-Word-v2.0.template.dot. 619 10. References 621 10.1. Normative References 623 [IEEE1588] IEEE Instrumentation and Measurement Society, "IEEE 624 Standard for a Precision Clock Synchronization 625 Protocol for Networked Measurement and Control 626 Systems", IEEE Std 1588, 2008. 628 [NTP] D. Mills, J. Martin, J. Burbank, W. Kasch, "Network 629 Time Protocol Version 4: Protocol and Algorithms 630 Specification", IETF, RFC 5905, 2010. 632 10.2. Informative References 634 [ASSYMETRY] Yihua He and Michalis Faloutsos and Srikanth 635 Krishnamurthy and Bradley Huffaker, "On routing 636 asymmetry in the internet", IEEE Globecom, 2005. 638 [ASSYMETRY2] Abhinav Pathak, Himabindu Pucha, Ying Zhang, Y. 639 Charlie Hu, and Z. Morley Mao, "A measurement study of 640 internet delay asymmetry", PAM'08, 2008. 642 [DELAY-ATT] T. Mizrahi, "A Game Theoretic Analysis of Delay 643 Attacks against Time Synchronization Protocols", 644 ISPCS, 2012. 646 [HIGH-AVAI] P. Ferrari, A. Flammini, S. Rinaldi, G. Prytz, "High 647 availability IEEE 1588 nodes over IEEE 802.1 aq 648 Shortest Path Bridging networks" ISPCS, 2013. 650 [KALMAN] G. Giorgi, C. Narduzzi, "Kalman filtering for multi- 651 path network synchronization" ISPCS, 2014. 653 [MIF] Blanchet, M. and P. Seite, "Multiple Interfaces and 654 Provisioning Domains Problem Statement", RFC 6418, DOI 655 10.17487/RFC6418, November 2011, . 658 [MPTCP] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 659 "TCP Extensions for Multipath Operation with Multiple 660 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 661 2013, . 663 [MULTI] A. Shpiner, Y. Revah, T. Mizrahi, "Multi-path Time 664 Protocols" ISPCS, 2013. 666 [PARIS] Brice Augustin, Timur Friedman and Renata Teixeira, 667 "Measuring Load-balanced Paths in the Internet", IMC, 668 2007. 670 [PARIS2] B. Augustin, T. Friedman, and R. Teixeira, "Measuring 671 Multipath Routing in the Internet", IEEE/ACM 672 Transactions on Networking, 19(3), p. 830 - 840, June 673 2011. 675 [SLAVEDIV] T. Mizrahi, "Slave Diversity: Using Multiple Paths to 676 Improve the Accuracy of Clock Synchronization 677 Protocols", ISPCS, 2012. 679 [TICTOCSEC] T. Mizrahi, "Security Requirements of Time Protocols 680 in Packet Switched Networks", IETF, RFC 7384, 2014. 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 Authors' Addresses 688 Alex Shpiner 689 Mellanox Technologies, Ltd. 690 Hakidma 26 691 Ofer Industrial Park 692 Yokneam, 2069200, Israel 694 Email: alexshp@mellanox.com 696 Richard Tse 697 PMC-Sierra 698 8555 Baxter Place 699 Burnaby, BC 700 Canada 701 V5A 4V7 703 Email: Richard.Tse@pmcs.com 705 Craig Schelp 706 PMC-Sierra 707 8555 Baxter Place 708 Burnaby, BC 709 Canada 710 V5A 4V7 712 Email: craig.schelp@pmcs.com 714 Tal Mizrahi 715 Marvell 716 6 Hamada St. 717 Yokneam, 20692, Israel 719 Email: talmi@marvell.com