Internet Engineering Task Force (IETF) A. Shpiner
Request for Comments: 8039 Mellanox
Category: Experimental R. Tse
ISSN: 2070-1721 Microsemi
C. Schelp
Oracle
T. Mizrahi
Marvell
December 2016
Internet Engineering Task Force (IETF) A. Shpiner
Request for Comments: 8039 Mellanox
Category: Experimental R. Tse
ISSN: 2070-1721 Microsemi
C. Schelp
Oracle
T. Mizrahi
Marvell
December 2016
Multipath Time Synchronization
多径时间同步
Abstract
摘要
Clock synchronization protocols are very widely used in IP-based networks. The Network Time Protocol (NTP) has been commonly deployed for many years, and the last few years have seen an increasingly rapid deployment of the Precision Time Protocol (PTP). As time-sensitive applications evolve, clock accuracy requirements are becoming increasingly stringent, requiring the time synchronization protocols to provide high accuracy. This memo describes a multipath approach to PTP and NTP over IP networks, allowing the protocols to run concurrently over multiple communication paths between the master and slave clocks, without modifying these protocols. The multipath approach can significantly contribute to clock accuracy, security, and fault tolerance. The multipath approach that is presented in this document enables backward compatibility with nodes that do not support the multipath functionality.
时钟同步协议在基于IP的网络中应用非常广泛。网络时间协议（NTP）已普遍部署多年，而在过去几年中，精确时间协议（PTP）的部署速度越来越快。随着时间敏感应用的发展，时钟精度要求越来越严格，要求时间同步协议提供高精度。本备忘录描述了通过IP网络实现PTP和NTP的多路径方法，允许协议在主时钟和从时钟之间的多条通信路径上并发运行，而无需修改这些协议。多路径方法可以显著提高时钟精度、安全性和容错性。本文档中介绍的多路径方法实现了与不支持多路径功能的节点的向后兼容性。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8039.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8039.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................4
2.1. Abbreviations ..............................................4
2.2. Terminology ................................................4
3. Multiple Paths in IP Networks ...................................5
3.1. Load Balancing .............................................5
3.2. Using Multiple Paths Concurrently ..........................5
3.3. Two-Way Paths ..............................................5
4. Solution Overview ...............................................6
4.1. Path Configuration and Identification ......................6
4.2. Combining ..................................................6
5. Multipath Time Synchronization over IP Networks .................7
5.1. Overview ...................................................7
5.2. Single-Ended Multipath Synchronization .....................8
5.2.1. Single-Ended MPPTP Synchronization Message
Exchange ............................................8
5.2.2. Single-Ended MPNTP Synchronization Message
Exchange ............................................9
5.3. Dual-Ended Multipath Synchronization ......................10
5.3.1. Dual-Ended MPPTP Synchronization Message Exchange ..10
5.3.2. Dual-Ended MPNTP Synchronization Message Exchange ..11
5.4. Using Traceroute for Path Discovery .......................12
5.5. Using Unicast Discovery for MPPTP .........................13
6. Combining Algorithm ............................................13
7. Security Considerations ........................................14
8. Scope of the Experiment ........................................14
9. References .....................................................15
9.1. Normative References ......................................15
9.2. Informative References ....................................15
Acknowledgments ...................................................17
Authors' Addresses ................................................17
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................4
2.1. Abbreviations ..............................................4
2.2. Terminology ................................................4
3. Multiple Paths in IP Networks ...................................5
3.1. Load Balancing .............................................5
3.2. Using Multiple Paths Concurrently ..........................5
3.3. Two-Way Paths ..............................................5
4. Solution Overview ...............................................6
4.1. Path Configuration and Identification ......................6
4.2. Combining ..................................................6
5. Multipath Time Synchronization over IP Networks .................7
5.1. Overview ...................................................7
5.2. Single-Ended Multipath Synchronization .....................8
5.2.1. Single-Ended MPPTP Synchronization Message
Exchange ............................................8
5.2.2. Single-Ended MPNTP Synchronization Message
Exchange ............................................9
5.3. Dual-Ended Multipath Synchronization ......................10
5.3.1. Dual-Ended MPPTP Synchronization Message Exchange ..10
5.3.2. Dual-Ended MPNTP Synchronization Message Exchange ..11
5.4. Using Traceroute for Path Discovery .......................12
5.5. Using Unicast Discovery for MPPTP .........................13
6. Combining Algorithm ............................................13
7. Security Considerations ........................................14
8. Scope of the Experiment ........................................14
9. References .....................................................15
9.1. Normative References ......................................15
9.2. Informative References ....................................15
Acknowledgments ...................................................17
Authors' Addresses ................................................17
The two most common time synchronization protocols in IP networks are (1) the Network Time Protocol [NTP] and (2) the Precision Time Protocol (PTP) as defined in the IEEE 1588 standard [IEEE1588].
IP网络中最常见的两种时间同步协议是（1）网络时间协议[NTP]和（2）IEEE 1588标准[IEEE1588]中定义的精确时间协议（PTP）。
The accuracy of the time synchronization protocols directly depends on the stability and the symmetry of propagation delays in both directions between the master and slave clocks. Depending on the nature of the underlying network, time synchronization protocol packets can be subject to variable network latency or path asymmetry (e.g., [ASYMMETRY] [ASYMMETRY2]). As time-sensitive applications evolve, accuracy requirements are becoming increasingly stringent. Using a single network path in a clock synchronization protocol closely ties the slave clock accuracy to the behavior of the specific path, which may suffer from temporal congestion, faults, or malicious attacks. Relying on multiple clock servers, as in NTP, solves these problems but requires active maintenance of multiple accurate sources in the network, which is not always possible. The usage of Transparent Clocks (TCs) in PTP solves the congestion problem by eliminating the queuing time from the delay calculations but does not address security or fault-tolerance aspects.
时间同步协议的准确性直接取决于主时钟和从时钟之间双向传播延迟的稳定性和对称性。根据基础网络的性质，时间同步协议数据包可能受到可变网络延迟或路径不对称的影响（例如，[不对称][不对称2]）。随着时间敏感应用程序的发展，精度要求变得越来越严格。在时钟同步协议中使用单个网络路径将从时钟精度与特定路径的行为紧密联系在一起，该路径可能会遭受时间拥塞、故障或恶意攻击。依靠多个时钟服务器（如NTP）可以解决这些问题，但需要主动维护网络中的多个精确源，这并不总是可能的。在PTP中使用透明时钟（TCs）通过从延迟计算中消除排队时间来解决拥塞问题，但没有解决安全性或容错方面的问题。
____
______/ \_____
___/ \____
____/ \
____ / path 1 / ___
/ \ / ________________________ \ / \
/Master\____\___/ \____\________/Slave\
\Clock / / \________ _______________/ \ \Clock/
\____/ \ / \__ /
\____ path 2 __/
\_______ ______/
\_________/
____
______/ \_____
___/ \____
____/ \
____ / path 1 / ___
/ \ / ________________________ \ / \
/Master\____\___/ \____\________/Slave\
\Clock / / \________ _______________/ \ \Clock/
\____/ \ / \__ /
\____ path 2 __/
\_______ ______/
\_________/
Figure 1: Multipath Connection
图1：多路径连接
Since master and slave clocks are often connected through more than one path in the network, as shown in Figure 1, [SLAVEDIV] suggested that a time synchronization protocol can be run over multiple paths, providing several advantages. First, it can significantly increase the clock accuracy as shown in [SLAVEDIV]. Second, this approach provides additional security, allowing the mitigation of man-in-the-middle attacks against the time synchronization protocol [DELAY-ATT]. Third, using multiple paths concurrently provides an inherent failure protection mechanism.
由于主时钟和从时钟通常通过网络中的多条路径连接，如图1所示，[SLAVEDIV]建议时间同步协议可以在多条路径上运行，从而提供了一些优势。首先，它可以显著提高时钟精度，如[SLAVEDIV]所示。其次，这种方法提供了额外的安全性，允许缓解针对时间同步协议[DELAY-ATT]的中间人攻击。第三，同时使用多条路径提供了固有的故障保护机制。
This document introduces Multipath PTP (MPPTP) and Multipath NTP (MPNTP). The functionality of the multipath approach is defined at the network layer and does not require any changes in PTP or NTP.
本文档介绍多路径PTP（MPPTP）和多路径NTP（MPNTP）。多路径方法的功能在网络层定义，不需要对PTP或NTP进行任何更改。
MPPTP and MPNTP are defined over IP networks. As IP networks typically combine ECMP routing, this property is leveraged for the multiple paths used in MPPTP and MPNTP. The key property of the multipath approach is that clocks in the network can use more than one IP address. Each {master IP, slave IP} address pair defines a path. Depending on the network topology and configuration, the IP combination pairs can form multiple diverse paths used by the multipath synchronization protocols. It has been shown [MULTI] that using multiple IP addresses over the wide Internet indeed allows two endpoints to attain multiple diverse paths.
MPPTP和MPNTP是通过IP网络定义的。由于IP网络通常结合ECMP路由，因此此属性可用于MPPTP和MPNTP中使用的多条路径。多路径方法的关键特性是网络中的时钟可以使用多个IP地址。每个{主IP，从IP}地址对定义一条路径。根据网络拓扑和配置，IP组合对可以形成多路径同步协议使用的多条不同路径。已经证明[MULTI]在广域互联网上使用多个IP地址确实允许两个端点获得多个不同的路径。
This document introduces two variants of the multipath approach: (1) a variant that requires both master and slave nodes to support the multipath functionality, referred to as the dual-ended variant, and (2) a backward-compatible variant that allows a multipath clock to connect to a conventional single-path clock, referred to as the single-ended variant.
本文档介绍了多路径方法的两种变体：（1）要求主节点和从节点都支持多路径功能的变体，称为双端变体；（2）允许多路径时钟连接到传统单路径时钟的向后兼容变体，称为单端变体。
BMC Best Master Clock [IEEE1588]
BMC最佳主时钟[IEEE1588]
ECMP Equal-Cost Multipath
等成本多路径
LAN Local Area Network
局域网
MPNTP Multipath Network Time Protocol
多路径网络时间协议
MPPTP Multipath Precision Time Protocol
多路径精确时间协议
NTP Network Time Protocol [NTP]
网络时间协议
PTP Precision Time Protocol [IEEE1588]
PTP精确时间协议[IEEE1588]
In the NTP terminology, a time synchronization protocol is run between a client and a server, while PTP uses the terms 'master' and 'slave'. Throughout this document, the sections that refer to both PTP and NTP generically use the terms 'master' and 'slave'.
在NTP术语中，时间同步协议在客户端和服务器之间运行，而PTP使用术语“主”和“从”。在本文件中，涉及PTP和NTP的章节通常使用术语“主”和“从”。
Traffic sent across IP networks is often load-balanced across multiple paths. The load-balancing decisions are typically based on packet header fields: source and destination addresses, Layer 4 ports, the Flow Label field in IPv6, etc.
通过IP网络发送的流量通常通过多条路径进行负载平衡。负载平衡决策通常基于数据包头字段：源地址和目标地址、第4层端口、IPv6中的流标签字段等。
Three common load-balancing criteria are per-destination, per-flow, and per-packet. The per-destination load balancers take a load-balancing decision based on the destination IP address. Per-flow load balancers use various fields in the packet header, e.g., IP addresses and Layer 4 ports, for the load-balancing decision. Per-packet load balancers use flow-blind techniques such as round-robin without basing the choice on the packet content.
三个常见的负载平衡标准是每个目的地、每个流和每个数据包。每个目标负载均衡器根据目标IP地址做出负载平衡决策。每流负载均衡器使用数据包报头中的各种字段（例如，IP地址和第4层端口）进行负载平衡决策。每包负载均衡器使用流盲技术，例如循环，而不基于包内容进行选择。
To utilize the diverse paths that traverse per-destination load balancers or per-flow load balancers, the packet transmitter can vary the IP addresses in the packet header. The analysis in [PARIS2] shows that a significant majority of the flows on the Internet traverse per-destination or per-flow load balancing. It presents statistics that 72% of the flows traverse per-destination load balancing and 39% of the flows traverse per-flow load balancing, while only a negligible part of the flows traverse per-packet load balancing. These statistics show that the vast majority of the traffic on the Internet is load-balanced based on packet header fields.
为了利用遍历每个目的地负载平衡器或每个流负载平衡器的不同路径，分组发送器可以改变分组报头中的IP地址。[PARIS2]中的分析表明，互联网上的绝大多数流都是通过每个目的地或每个流负载平衡进行的。它提供的统计数据表明，72%的流遍历每个目标负载平衡，39%的流遍历每个流负载平衡，而只有一小部分流遍历每个数据包负载平衡。这些统计数据表明，互联网上的绝大多数流量是基于数据包头字段的负载平衡的。
The approaches in this document are based on varying the source and destination IP addresses in the packet header. Possible extensions have been considered that also vary the UDP ports. However, some of the existing implementations of PTP and NTP use fixed UDP port values in both the source and destination UDP port fields and thus do not allow this approach.
本文档中的方法基于改变数据包报头中的源和目标IP地址。已经考虑了可能的扩展，这些扩展也会改变UDP端口。但是，PTP和NTP的一些现有实现在源和目标UDP端口字段中都使用固定的UDP端口值，因此不允许这种方法。
A key property of IP networks is that packets forwarded from A to B do not necessarily traverse the same path as packets from B to A. Thus, we define a two-way path for a master-slave connection as a pair of one-way paths: the first from master to slave and the second from slave to master.
IP网络的一个关键特性是，从A转发到B的数据包不一定要通过与从B到A的数据包相同的路径。因此，我们将主从连接的双向路径定义为一对单向路径：第一条从主到从，第二条从从主到主。
If possible, a traffic engineering approach can be used to verify that time synchronization traffic is always forwarded through bidirectional two-way paths, i.e., that each two-way path uses the same route in the forward and reverse directions, thus allowing propagation time symmetry. However, in the general case, two-way paths do not necessarily use the same path for the forward and reverse directions.
如果可能，可以使用流量工程方法来验证时间同步流量始终通过双向双向路径转发，即，每个双向路径在正向和反向使用相同的路由，从而允许传播时间对称。然而，在一般情况下，双向路径不一定在正向和反向使用相同的路径。
The multipath time synchronization protocols we present here are comprised of two building blocks: one is the path configuration and identification, and the other is the algorithm used by the slave to combine the information received from the various paths.
我们在这里介绍的多径时间同步协议由两个构建块组成：一个是路径配置和标识，另一个是从机用于组合从各种路径接收的信息的算法。
The master and slave clocks must be able to determine the path of transmitted protocol packets and to identify the path of incoming protocol packets. A path is determined by a {master IP, slave IP} address pair. The synchronization protocol message exchange is run independently through each path.
主时钟和从时钟必须能够确定传输协议包的路径，并识别传入协议包的路径。路径由{主IP，从IP}地址对确定。同步协议消息交换通过每个路径独立运行。
Each IP address pair defines a two-way path and thus allows the clocks to bind a transmitted packet to a specific path or to identify the path of an incoming packet.
每个IP地址对定义了一个双向路径，从而允许时钟将传输的数据包绑定到特定路径，或识别传入数据包的路径。
If possible, the routing tables across the network should be configured with multiple traffic-engineered paths between the pair of clocks. By carefully configuring the routers in such networks, it is possible to create diverse paths for each of the IP address pairs between two clocks in the network. However, in public and provider networks, the load-balancing behavior is hidden from the end users. In this case, the actual number of paths may be less than the number of IP address pairs, since some of the address pairs may share common paths.
如果可能，网络上的路由表应在时钟对之间配置多个流量工程路径。通过仔细配置此类网络中的路由器，可以在网络中的两个时钟之间为每个IP地址对创建不同的路径。然而，在公共网络和提供商网络中，负载平衡行为对最终用户是隐藏的。在这种情况下，路径的实际数量可能小于IP地址对的数量，因为一些地址对可能共享公共路径。
Various methods can be used for combining the time information received from the different paths. The output of the combining algorithm is the accurate time offset. Combining methods are further discussed in Section 6.
可以使用各种方法来组合从不同路径接收的时间信息。合并算法的输出是精确的时间偏移。第6节将进一步讨论组合方法。
This section presents two variants of MPPTP and MPNTP: single-ended multipath time synchronization and dual-ended multipath time synchronization. In the first variant, the multipath approach is only implemented by the slave, and the master is not aware of its usage. In the second variant, all clocks use multiple paths.
本节介绍MPPTP和MPNTP的两种变体：单端多路径时间同步和双端多路径时间同步。在第一种变体中，多路径方法仅由从机实现，而主机不知道其用法。在第二种变体中，所有时钟都使用多条路径。
The dual-ended variant provides higher path diversity by using multiple IP addresses at both ends, the master and slave, while the single-ended variant only uses multiple addresses at the slave. Consequently, the single-ended approach can interoperate with existing implementations that do not use multiple paths. The dual-ended and single-ended approaches can coexist in the same network; each slave selects the connection(s) it wants to make with the available masters. A dual-ended slave could switch to single-ended mode if it does not see any dual-ended masters available. A single-ended slave could connect to a single IP address of a dual-ended master.
双端变体通过在主机和从机两端使用多个IP地址提供更高的路径分集，而单端变体仅在从机上使用多个地址。因此，单端方法可以与不使用多条路径的现有实现进行互操作。双端和单端方法可以在同一网络中共存；每个从机选择要与可用主机建立的连接。如果看不到任何可用的双端主设备，双端从设备可以切换到单端模式。单端从机可以连接到双端主机的单个IP地址。
Multipath time synchronization, in both variants, requires clocks to use multiple IP addresses. Using multiple IP addresses introduces a trade-off. A large number of IP addresses allows a large number of diverse paths, providing the advantages of slave diversity discussed in Section 1. On the other hand, a large number of IP addresses is more costly, requires the network topology to be more redundant, and exacts extra management overhead.
在这两种变体中，多路径时间同步都要求时钟使用多个IP地址。使用多个IP地址会带来折衷。大量的IP地址允许大量不同的路径，提供了第1节中讨论的从机多样性的优点。另一方面，大量IP地址成本更高，要求网络拓扑结构更冗余，并且需要额外的管理开销。
If possible, the set of IP addresses for each clock should be chosen in a way that enables the establishment of paths that are the most different. If the load-balancing rules in the network are known, it is possible to choose the IP addresses in a way that enforces path diversity. However, even if the load-balancing scheme is not known, a careful choice of the IP addresses can increase the probability of path diversity. For example, choosing multiple addresses with different prefixes is likely to produce higher path diversity, as BGP routers are more likely to route these different prefixes through different routes.
如果可能，每个时钟的IP地址集的选择方式应确保能够建立差异最大的路径。如果网络中的负载平衡规则是已知的，则可以以强制路径多样性的方式选择IP地址。然而，即使负载平衡方案未知，仔细选择IP地址也会增加路径多样性的概率。例如，选择具有不同前缀的多个地址可能会产生更高的路径多样性，因为BGP路由器更可能通过不同的路由路由这些不同的前缀。
The use of Network Address Translation (NAT) may significantly reduce the effectiveness of multipath synchronization in some cases. For example, if a master uses multiple IP addresses that are translated to a single IP address, the path diversity can be dramatically reduced compared to a network that does not use NAT. Thus, path
在某些情况下，使用网络地址转换（NAT）可能会显著降低多径同步的有效性。例如，如果主机使用多个IP地址并将其转换为单个IP地址，则与不使用NAT的网络相比，路径多样性可以显著降低。因此，路径
discovery should be used to identify the possible paths between the master and slave. Path discovery is further discussed in Section 5.4.
应使用发现来确定主设备和从设备之间的可能路径。第5.4节将进一步讨论路径发现。
The concept of using multiple IP addresses or multiple interfaces is well established and is being used today by various applications and protocols, e.g., [MPTCP]. Using multiple interfaces introduces some challenges and issues, which were presented and discussed in [MIF].
使用多个IP地址或多个接口的概念已经很好地确立，并且目前正被各种应用程序和协议使用，例如[MPTCP]。使用多个接口会带来一些挑战和问题，这些在[MIF]中介绍和讨论。
The descriptions in this section refer to the end-to-end scheme of PTP but are similarly applicable to the peer-to-peer scheme. MPNTP, as described in this document, refers to the NTP client-server mode, although the concepts described here can be extended to include the symmetric variant as well.
本节中的描述涉及PTP的端到端方案，但同样适用于对等方案。如本文档所述，MPNTP指的是NTP客户机-服务器模式，尽管这里描述的概念也可以扩展为包括对称变量。
Multipath synchronization by nature requires protocol messages to be sent as unicast. Specifically in PTP, the following messages must be sent as unicast in MPPTP: Sync, Delay_Req, Delay_Resp, PDelay_Req, PDelay_Resp, Follow_Up, and PDelay_Resp_Follow_Up. Note that [IEEE1588] allows these messages to be sent either as multicast or as unicast.
多径同步本质上要求协议消息作为单播发送。特别是在PTP中，以下消息必须在MPPTP中以单播方式发送：同步、延迟请求、延迟响应、延迟请求、延迟响应、延迟响应、跟进和延迟响应跟进。请注意，[IEEE1588]允许以多播或单播的方式发送这些消息。
In the single-ended approach, only the slave is aware of the fact that multiple paths are used, while the master is agnostic to the usage of multiple paths. This approach allows a hybrid network, where some of the clocks are multipath clocks and others are conventional one-path clocks. A single-ended multipath clock presents itself to the network as N independent clocks, using N IP addresses, as well as N clockIdentity [IEEE1588] values (in PTP). Thus, the usage of multiple slave identities by a slave clock is transparent from the master's point of view, such that it treats each of the identities as a separate slave clock.
在单端方法中，只有从机知道使用了多条路径，而主机不知道使用多条路径。这种方法允许混合网络，其中一些时钟是多径时钟，而另一些是传统的单路径时钟。单端多路径时钟在网络中显示为N个独立时钟，使用N个IP地址以及N个clockIdentity[IEEE1588]值（在PTP中）。因此，从主时钟的角度来看，从时钟对多个从身份的使用是透明的，因此它将每个身份视为单独的从时钟。
The single-ended MPPTP message exchange procedure is as follows.
单端MPPTP报文交换程序如下。
o Each single-ended MPPTP clock has a fixed set of N IP addresses and N corresponding clockIdentities. Each clock arbitrarily defines one of its IP addresses and clockIdentity values as the clock primary identity.
o 每个单端MPPTP时钟具有一组固定的N个IP地址和N个相应的时钟标识。每个时钟任意定义其一个IP地址和时钟标识值作为时钟主标识。
o A single-ended MPPTP port sends Announce messages only from its primary identity, according to the BMC algorithm.
o 根据BMC算法，单端MPPTP端口仅从其主标识发送公告消息。
o The BMC algorithm at each clock determines the master, based on the received Announce messages.
o 每个时钟的BMC算法根据接收到的公告消息确定主节点。
o A single-ended MPPTP port that is in the 'slave' state uses unicast negotiation to request the master to transmit unicast messages to each of the N slave clockIdentity values. The slave port periodically sends N Signaling messages to the master, using each of its N identities. The Signaling message includes the REQUEST_UNICAST_TRANSMISSION TLV [IEEE1588].
o 处于“从”状态的单端MPPTP端口使用单播协商来请求主机向N个从时钟标识值中的每一个发送单播消息。从端口使用其N个标识中的每一个周期性地向主端口发送N个信令消息。信令消息包括请求单播传输TLV[IEEE1588]。
o The master periodically sends unicast Sync messages from its primary identity, identified by the sourcePortIdentity [IEEE1588] and IP address, to each of the slave identities.
o 主机定期从其主标识（由sourcePortIdentity[IEEE1588]和IP地址标识）向每个从属标识发送单播同步消息。
o The slave, upon receiving a Sync message, identifies its path according to the destination IP address. The slave sends a Delay_Req unicast message to the primary identity of the master. The Delay_Req is sent using the slave identity corresponding to the path through which the Sync was received. Note that the rate of Delay_Req messages may be lower than the Sync message rate, and thus a Sync message is not necessarily followed by a Delay_Req.
o 从机在接收到同步消息后，根据目标IP地址标识其路径。从机向主机的主标识发送延迟请求单播消息。使用与接收同步的路径相对应的从属标识发送延迟请求。请注意，延迟请求消息的速率可能低于同步消息速率，因此同步消息后面不一定跟着延迟请求。
o The master, in response to a Delay_Req message from the slave, responds with a Delay_Resp message using the IP address and sourcePortIdentity from the Delay_Req message.
o 作为对来自从机的延迟请求消息的响应，主机使用延迟请求消息中的IP地址和sourcePortIdentity以延迟响应消息进行响应。
o Upon receiving the Delay_Resp message, the slave identifies the path using the destination IP address and the requestingPortIdentity [IEEE1588]. The slave can then compute the corresponding path delay and the offset from the master.
o 在接收到延迟响应消息后，从机使用目标IP地址和请求端口身份识别路径[IEEE1588]。然后，从机可以计算相应的路径延迟和与主机的偏移量。
o The slave combines the information from all negotiated paths.
o 从属服务器组合来自所有协商路径的信息。
The single-ended MPNTP message exchange procedure is as follows.
单端MPNTP报文交换程序如下。
o A single-ended MPNTP client has N separate identities, i.e., N IP addresses. The assumption is that the server information, including its IP address, is known to the NTP clients. This is a fair assumption, as typically the address(es) of the NTP server(s) is provided to the NTP client by configuration.
o 单端MPNTP客户端有N个单独的标识，即N个IP地址。假设NTP客户端知道服务器信息，包括其IP地址。这是一个公平的假设，因为NTP服务器的地址通常通过配置提供给NTP客户端。
o A single-ended MPNTP client initiates NTP with an NTP server N times, using each of its N identities.
o 单端MPNTP客户端使用NTP服务器的N个标识中的每一个启动NTP N次。
o NTP is maintained between the server and each of the N client identities.
o NTP在服务器和N个客户端标识之间进行维护。
o The client sends NTP messages to the master using each of its N identities.
o 客户端使用其N个标识中的每一个向主机发送NTP消息。
o The server responds to the client's NTP messages using the IP address from the received NTP packet.
o 服务器使用接收到的NTP数据包中的IP地址响应客户端的NTP消息。
o The client, upon receiving an NTP packet, uses the IP destination address to identify the path through which it came, and it uses the time information accordingly.
o 客户端在接收到NTP数据包时，使用IP目的地地址来标识数据包经过的路径，并相应地使用时间信息。
o The client combines the information from all paths.
o 客户端将来自所有路径的信息组合在一起。
In dual-ended multipath synchronization, each clock has N IP addresses. Time synchronization messages are exchanged between some of the combinations of {master IP, slave IP} addresses, allowing multiple paths between the master and slave. Note that the actual number of paths between the master and slave may be less than the number of chosen {master IP, slave IP} address pairs.
在双端多路径同步中，每个时钟有N个IP地址。时间同步消息在{master IP，slave IP}地址的某些组合之间交换，从而允许主和从地址之间的多条路径。注意，主和从之间的实际路径数可能小于所选{master IP，slave IP}地址对的数目。
Once the multiple two-way connections are established, a separate synchronization protocol exchange instance is run through each of them.
一旦建立了多个双向连接，就会通过每个双向连接运行一个单独的同步协议交换实例。
The dual-ended MPPTP message exchange procedure is as follows.
双端MPPTP消息交换程序如下所示。
o Every clock has N IP addresses but uses a single clockIdentity.
o 每个时钟有N个IP地址，但使用一个时钟标识。
o The BMC algorithm at each clock determines the master. The master is identified by its clockIdentity, allowing other clocks to know the multiple IP addresses it uses.
o 每个时钟的BMC算法确定主时钟。主机由其时钟标识标识，允许其他时钟知道其使用的多个IP地址。
o When a clock sends an Announce message, it sends it from each of its IP addresses with its clockIdentity.
o 当一个时钟发送一条公告消息时，它会从它的每个IP地址以及它的时钟标识发送该消息。
o A dual-ended MPPTP port that is in the 'slave' state uses unicast negotiation to request the master to transmit unicast messages to some or all of its N_s IP addresses. This negotiation is done individually between a slave IP address and the corresponding master IP address with which the slave desires a connection. The slave port periodically sends Signaling messages to the master, using some or all of its N_s IP addresses as the source, to the corresponding master's N_m IP addresses. The Signaling message includes the REQUEST_UNICAST_TRANSMISSION TLV [IEEE1588].
o 处于“从”状态的双端MPPTP端口使用单播协商来请求主机将单播消息传输到其部分或全部N_s IP地址。此协商在从属IP地址和从属希望连接的相应主IP地址之间单独完成。从端口使用其部分或全部N_s IP地址作为源，周期性地将信令消息发送到主端口，并发送到相应的主端口N_m IP地址。信令消息包括请求单播传输TLV[IEEE1588]。
('N_s' and 'N_m' indicate the number of IP addresses of the slave and master, respectively.)
（'N_s'和'N_m'分别表示从机和主机的IP地址数。）
o The master periodically sends unicast Sync messages from each of its IP addresses to the corresponding slave IP addresses for which a unicast connection was negotiated.
o 主机定期从其每个IP地址向协商单播连接的相应从属IP地址发送单播同步消息。
o The slave, upon receiving a Sync message, identifies its path according to the {source IP, destination IP} addresses. The slave sends a Delay_Req unicast message, swapping the source and destination IP addresses from the Sync message. Note that the rate of Delay_Req messages may be lower than the Sync message rate, and thus a Sync message is not necessarily followed by a Delay_Req.
o 从机在收到同步消息时，根据{源IP，目标IP}地址标识其路径。从机发送延迟请求单播消息，从同步消息交换源和目标IP地址。请注意，延迟请求消息的速率可能低于同步消息速率，因此同步消息后面不一定跟着延迟请求。
o The master, in response to a Delay_Req message from the slave, responds with a Delay_Resp message using the sourcePortIdentity from the Delay_Req message and swapping the IP addresses from the Delay_Req.
o 主设备响应从设备发出的延迟请求消息，使用延迟请求消息中的sourcePortIdentity并交换延迟请求中的IP地址，以延迟响应消息进行响应。
o Upon receiving the Delay_Resp message, the slave identifies the path using the {source IP, destination IP} address pair. The slave can then compute the corresponding path delay and the offset from the master.
o 在接收到Delay_Resp消息后，从机使用{source IP，destination IP}地址对标识路径。然后，从机可以计算相应的路径延迟和与主机的偏移量。
o The slave combines the information from all negotiated paths.
o 从属服务器组合来自所有协商路径的信息。
The MPNTP message exchange procedure is as follows.
MPNTP消息交换过程如下所示。
o Each NTP clock has a set of N IP addresses. The assumption is that the server information, including its multiple IP addresses, is known to the NTP clients.
o 每个NTP时钟有一组N个IP地址。假设NTP客户端知道服务器信息，包括其多个IP地址。
o The MPNTP client chooses N_svr server IP addresses and N_c client IP addresses and initiates the N_svr*N_c instances of the protocol, one for each {server IP, client IP} address pair, allowing the client to combine the information from the N_s*N_c paths.
o MPNTP客户端选择N_svr服务器IP地址和N_c客户端IP地址，并启动协议的N_svr*N_c实例，每个{服务器IP，客户端IP}地址对一个实例，允许客户端组合N_s*N_c路径中的信息。
('N_svr' and 'N_c' indicate the number of IP addresses of the server and client, respectively, with which a client chooses to connect.)
（'N_svr'和'N_c'分别表示客户端选择连接的服务器和客户端的IP地址数。）
o The client sends NTP messages to the master using each of the source-destination address combinations.
o 客户端使用每个源-目标地址组合向主机发送NTP消息。
o The server responds to the client's NTP messages using the IP address combination from the received NTP packet.
o 服务器使用接收到的NTP数据包中的IP地址组合响应客户端的NTP消息。
o Using the {source IP, destination IP} address pair in the received packets, the client identifies the path and performs its computations for each of the paths accordingly.
o 使用接收到的数据包中的{source IP，destination IP}地址对，客户机识别路径并相应地对每个路径执行计算。
o The client combines the information from all paths.
o 客户端将来自所有路径的信息组合在一起。
The approach described thus far uses multiple IP addresses in a single clock to create multiple paths. However, although each two-way path is defined by a different {master IP, slave IP} address pair, some of the IP address pairs may traverse exactly the same network path, making them redundant.
到目前为止所描述的方法在单个时钟中使用多个IP地址来创建多条路径。然而，尽管每个双向路径由不同的{master IP，slave IP}地址对定义，但是一些IP地址对可能会穿越完全相同的网络路径，从而使它们成为冗余的。
Traceroute-based path discovery can be used for filtering only the IP addresses that obtain diverse paths. 'Paris traceroute' [PARIS] and 'TraceFlow' [TRACEFLOW] are examples of tools that discover the paths between two points in the network. It should be noted that this filtering approach is effective only if the Traceroute implementation uses the same IP addresses and UDP ports as the synchronization protocol packets. Since some Traceroute implementations vary the UDP ports, they may not be effective in identifying and filtering redundant paths in synchronization protocols.
基于跟踪路由的路径发现只能用于筛选获得不同路径的IP地址。”Paris traceroute“[Paris]和“TraceFlow”[TraceFlow]是发现网络中两点之间路径的工具示例。应该注意的是，只有当跟踪路由实现使用与同步协议数据包相同的IP地址和UDP端口时，这种过滤方法才有效。由于某些跟踪路由实现会改变UDP端口，因此它们可能无法有效地识别和过滤同步协议中的冗余路径。
Traceroute-based filtering can be implemented by both master and slave nodes, or it can be restricted to run only on slave nodes to reduce the overhead on the master. For networks that guarantee that the path of the timing packets in the forward and reverse directions are the same, path discovery should only be performed at the slave.
基于跟踪路由的过滤可以由主节点和从节点实现，也可以限制它仅在从节点上运行，以减少主节点上的开销。对于保证正向和反向定时分组的路径相同的网络，路径发现应仅在从机上执行。
Since network routes change over time, path discovery and redundant path filtering should be performed periodically. Two {master IP, slave IP} address pairs that produce two diverse paths may be rerouted to use the same paths. Thus, the set of addresses that are used by each clock should be reassessed regularly.
由于网络路由随时间变化，因此应定期执行路径发现和冗余路径过滤。产生两条不同路径的两个{master IP，slave IP}地址对可以被重新路由以使用相同的路径。因此，应该定期重新评估每个时钟使用的地址集。
As presented above, MPPTP uses Announce messages and the BMC algorithm to discover the master. The unicast discovery option of PTP can be used as an alternative.
如上所述，MPPTP使用公告消息和BMC算法来发现主节点。PTP的单播发现选项可用作替代方案。
When using unicast discovery, the MPPTP slave ports maintain a list of the IP addresses of the master. The slave port uses unicast negotiation to request unicast service from the master as follows:
使用单播发现时，MPPTP从端口维护主端口的IP地址列表。从端口使用单播协商从主端口请求单播服务，如下所示：
o In single-ended MPPTP, the slave uses unicast negotiation from each of its identities to the master's (only) identity.
o 在单端MPPTP中，从机使用从其每个身份到主机（唯一）身份的单播协商。
o In dual-ended MPPTP, the slave uses unicast negotiation from its IP addresses, each to a corresponding master IP address, to request unicast synchronization messages.
o 在双端MPPTP中，从机使用从其IP地址到相应主IP地址的单播协商来请求单播同步消息。
Afterwards, the message exchange continues as described in Sections 5.2.1 and 5.3.1.
之后，按照第5.2.1节和第5.3.1节的说明继续进行消息交换。
The unicast discovery option can be used in networks that do not support multicast or in networks in which the master clocks are known in advance. In particular, unicast discovery avoids multicasting Announce messages.
单播发现选项可以在不支持多播的网络中使用，或者在主时钟预先已知的网络中使用。特别是，单播发现避免了多播公告消息。
Previous sections discussed the methods of creating the multiple paths and obtaining the time information required by the slave algorithm. Once the time information is received through each of the paths, the slave should use a combining algorithm, which consolidates the information from the different paths into a single clock. Various methods have been suggested for combining information from different paths or from different clocks, e.g., [NTP] [SLAVEDIV] [HIGH-AVAI] [KALMAN]. The choice of the combining algorithm is local to the slave and does not affect interoperability. Hence, this document does not define a specific method to be used by the slave. The combining algorithm should be chosen carefully based on the system properties, as different combining algorithms provide different advantages. For example, some combining algorithms (e.g., [NTP] [DELAY-ATT]) are intended to be robust in the face of security attacks, while other combining algorithms (e.g., [KALMAN]) are more resilient to random delay variation.
前几节讨论了创建多条路径和获取从属算法所需时间信息的方法。一旦通过每条路径接收到时间信息，从机应使用组合算法，将来自不同路径的信息整合到单个时钟中。已经提出了各种方法来组合来自不同路径或不同时钟的信息，例如[NTP][SLAVEDIV][HIGH-Avi][KALMAN]。组合算法的选择是从机本地的，不影响互操作性。因此，本文档未定义从属服务器使用的特定方法。由于不同的合并算法具有不同的优点，因此应根据系统特性仔细选择合并算法。例如，一些组合算法（例如，[NTP][DELAY-ATT]）旨在在面对安全攻击时具有鲁棒性，而其他组合算法（例如，[KALMAN]）对随机延迟变化更具弹性。
The security aspects of time synchronization protocols are discussed in detail in [RFC7384]. The methods described in this document propose to run a time synchronization protocol through redundant paths and thus allow the detection and mitigation of man-in-the-middle attacks, as described in [DELAY-ATT]. Specifically, multipath synchronization can mitigate the following threats (as per [RFC7384]):
[RFC7384]详细讨论了时间同步协议的安全方面。本文件中描述的方法建议通过冗余路径运行时间同步协议，从而允许检测和缓解中间人攻击，如[DELAY-ATT]中所述。具体而言，多路径同步可以缓解以下威胁（根据[RFC7384]）：
o Packet manipulation (Section 3.2.1 of [RFC7384]).
o 数据包操作（RFC7384第3.2.1节）。
o Packet interception and removal (Section 3.2.5 of [RFC7384]).
o 数据包截获和删除（RFC7384第3.2.5节）。
o Packet delay manipulation (Section 3.2.6 of [RFC7384]).
o 数据包延迟操纵（RFC7384第3.2.6节）。
It should be noted that when using multiple paths, these paths may partially overlap, and thus an attack that takes place in a common segment of these paths is not mitigated by the redundancy. Moreover, an on-path attacker may in some cases have access to more than one router or may be able to migrate from one router to another. Therefore, when using multiple paths, it is important for the paths to be as diverse and as independent as possible, making the redundancy scheme more tolerant to on-path attacks.
应注意，当使用多条路径时，这些路径可能部分重叠，因此在这些路径的公共段中发生的攻击不会因冗余而减轻。此外，在某些情况下，路径上攻击者可以访问多个路由器，或者可以从一个路由器迁移到另一个路由器。因此，在使用多条路径时，路径应尽可能多样化和独立，使冗余方案更能容忍路径攻击。
It should be noted that the multipath approach requires the master (or NTP server) to dedicate more resources to each slave (client) than the conventional single-path approach. Hence, well-known Distributed Denial-of-Service (DDoS) attacks may potentially be amplified when the multipath approach is enabled.
应该注意的是，多路径方法要求主服务器（或NTP服务器）为每个从服务器（客户机）分配比传统的单路径方法更多的资源。因此，当启用多路径方法时，众所周知的分布式拒绝服务（DDoS）攻击可能会被放大。
This memo is published as an Experimental RFC. The purpose of the experimental period is to allow the community to analyze and to verify the methods defined in this document. An experimental evaluation of some of these methods has been published in [MULTI]. It is expected that the experimental period will allow the methods to be further investigated and verified by the community. The duration of the experiment is expected to be no less than two years from the publication of this document.
本备忘录作为实验性RFC发布。实验期的目的是让社区能够分析和验证本文中定义的方法。其中一些方法的实验评估已发表在[MULTI]上。预计实验期间将允许社区进一步调查和验证这些方法。实验的持续时间预计不少于本文件出版后两年。
[IEEE1588] IEEE Instrumentation and Measurement Society, "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", IEEE Std 1588-2008, DOI 10.1109/IEEESTD.2008.4579760.
[IEEE1588]IEEE仪器和测量协会，“网络测量和控制系统精密时钟同步协议的IEEE标准”，IEEE标准1588-2008，DOI 10.1109/IEEESTD.2008.4579760。
[NTP] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, <http://www.rfc-editor.org/info/rfc5905>.
[NTP]Mills，D.，Martin，J.，Ed.，Burbank，J.，和W.Kasch，“网络时间协议版本4：协议和算法规范”，RFC 5905，DOI 10.17487/RFC59052010年6月<http://www.rfc-editor.org/info/rfc5905>.
[ASYMMETRY] He, Y., Faloutsos, M., Krishnamurthy, S., and B. Huffaker, "On routing asymmetry in the Internet", IEEE GLOBECOM, DOI 10.1109/GLOCOM.2005.1577769, December 2005.
[不对称性]他，Y.，Falutsos，M.，Krishnamurthy，S.，和B.Huffaker，“关于互联网中的路由不对称性”，IEEE GLOBECOM，DOI 10.1109/GLOCOM.2005.1577769，2005年12月。
[ASYMMETRY2] Pathak, A., Pucha, H., Zhang, Y., Hu, C., and Z. Mao, "A measurement study of internet delay asymmetry", International Conference on Passive and Active Network Measurement 2008, DOI 10.1007/978-3-540-79232-1_19, April 2008.
[ASYMMETRY2]Pathak，A.，Pucha，H.，Zhang，Y.，Hu，C.，和Z.Mao，“互联网延迟不对称性的测量研究”，2008年被动和主动网络测量国际会议，DOI 10.1007/978-3-540-79232-119，2008年4月。
[DELAY-ATT] Mizrahi, T., "A Game Theoretic Analysis of Delay Attacks against Time Synchronization Protocols", IEEE International Symposium on Precision Clock Synchronization for Measurement, Control and Communication (ISPCS), DOI 10.1109/ISPCS.2012.6336612, September 2012.
[DELAY-ATT]Mizrahi，T.，“针对时间同步协议的延迟攻击的博弈论分析”，IEEE测量、控制和通信精密时钟同步国际研讨会（ISPCS），DOI 10.1109/ISPCS.2012.6336612，2012年9月。
[HIGH-AVAI] Ferrari, P., Flammini, A., Rinaldi, S., and G. Prytz, "High availability IEEE 1588 nodes over IEEE 802.1 aq Shortest Path Bridging networks", IEEE International Symposium on Precision Clock Synchronization for Measurement, Control and Communication (ISPCS), DOI 10.1109/ISPCS.2013.6644760, September 2013.
[高可用性]Ferrari，P.，Flammini，A.，Rinaldi，S.，和G.Prytz，“IEEE 802.1 aq最短路径桥接网络上的高可用性IEEE 1588节点”，IEEE测量、控制和通信精密时钟同步国际研讨会（ISPCS），DOI 10.1109/ISPCS.2013.6644760，2013年9月。
[KALMAN] Giorgi, G. and C. Narduzzi, "Kalman filtering for multi-path network synchronization", IEEE International Symposium on Precision Clock Synchronization for Measurement, Control and Communication (ISPCS), DOI 10.1109/ISPCS.2014.6948693, September 2014.
[KALMAN]Giorgi，G.和C.Narduzzi，“多径网络同步的KALMAN滤波”，IEEE测量、控制和通信精密时钟同步国际研讨会（ISPCS），DOI 10.1109/ISPCS.2014.6948693，2014年9月。
[MIF] Blanchet, M. and P. Seite, "Multiple Interfaces and Provisioning Domains Problem Statement", RFC 6418, DOI 10.17487/RFC6418, November 2011, <http://www.rfc-editor.org/info/rfc6418>.
[MIF]Blanchet，M.和P.Seite，“多接口和供应域问题陈述”，RFC 6418，DOI 10.17487/RFC6418，2011年11月<http://www.rfc-editor.org/info/rfc6418>.
[MPTCP] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, <http://www.rfc-editor.org/info/rfc6824>.
[MPTCP]Ford，A.，Raiciu，C.，Handley，M.，和O.Bonaventure，“具有多个地址的多路径操作的TCP扩展”，RFC 6824DOI 10.17487/RFC6824，2013年1月<http://www.rfc-editor.org/info/rfc6824>.
[MULTI] Shpiner, A., Revah, Y., and T. Mizrahi, "Multi-path Time Protocols", IEEE International Symposium on Precision Clock Synchronization for Measurement, Control and Communication (ISPCS), DOI 10.1109/ISPCS.2013.6644754, September 2013.
[MULTI]Spiner，A.，Revah，Y.，和T.Mizrahi，“多路径时间协议”，IEEE测量、控制和通信精密时钟同步国际研讨会（ISPCS），DOI 10.1109/ISPCS.2013.66447542013年9月。
[PARIS] Augustin, B., Friedman, T., and R. Teixeira, "Measuring Load-balanced Paths in the Internet", 7th ACM SIGCOMM conference on Internet measurement (IMC '07), DOI 10.1145/1298306.1298329, October 2007.
[PARIS]Augustin，B.，Friedman，T.，和R.Teixeira，“测量互联网中的负载平衡路径”，第七届ACM SIGCOMM互联网测量会议（IMC'07），DOI 10.1145/1298306.1298329，2007年10月。
[PARIS2] Augustin, B., Friedman, T., and R. Teixeira, "Measuring Multipath Routing in the Internet", IEEE/ACM Transactions on Networking, 19(3), pp. 830-840, DOI 10.1109/TNET.2010.2096232, June 2011.
[PARIS2]Augustin，B.，Friedman，T.，和R.Teixeira，“测量互联网中的多路径路由”，IEEE/ACM网络交易，19（3），第830-840页，DOI 10.1109/TNET.2010.2096232，2011年6月。
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, October 2014, <http://www.rfc-editor.org/info/rfc7384>.
[RFC7384]Mizrahi，T.，“分组交换网络中时间协议的安全要求”，RFC 7384，DOI 10.17487/RFC7384，2014年10月<http://www.rfc-editor.org/info/rfc7384>.
[SLAVEDIV] Mizrahi, T., "Slave Diversity: Using Multiple Paths to Improve the Accuracy of Clock Synchronization Protocols", IEEE International Symposium on Precision Clock Synchronization for Measurement, Control and Communication (ISPCS), DOI 10.1109/ISPCS.2012.6336621, September 2012.
[SLAVEDIV]Mizrahi，T.，“从分集：使用多条路径提高时钟同步协议的准确性”，IEEE测量、控制和通信（ISPCS）精密时钟同步国际研讨会，DOI 10.1109/ISPCS.2012.633662112012年9月。
[TRACEFLOW] Narasimhan, J., Venkataswami, B., Groves, R., and P. Hoose, "Traceflow", Work in Progress, draft-janapath-intarea-traceflow-00, January 2012.
[TRACEFLOW]Narasimhan，J.，Venkataswami，B.，Groves，R.，和P.Hoose，“TRACEFLOW”，在建工程，草稿-janapath-Intrea-TRACEFLOW-00，2012年1月。
Acknowledgments
致谢
The authors would like to thank Yoram Revah for his contribution to this work. The authors also gratefully acknowledge the useful comments provided by Peter Meyer, Doug Arnold, Joe Abley, Zhen Cao, Watson Ladd, and Mirja Kuehlewind, as well as other comments received from the TICTOC working group participants.
作者要感谢Yoram Revah对这项工作的贡献。作者还感谢Peter Meyer、Doug Arnold、Joe Abley、Zhen Cao、Watson Ladd和Mirja Kuehlewind提供的有用意见，以及TICTOC工作组参与者提供的其他意见。
Authors' Addresses
作者地址
Alex Shpiner Mellanox Technologies, Ltd. Hakidma 26 Ofer Industrial Park Yokneam, 2069200 Israel
Alex Spiner Mellanox Technologies，Ltd.哈基德马26 Ofer工业园Yokneam，2069200以色列
Email: alexshp@mellanox.com
Email: alexshp@mellanox.com
Richard Tse Microsemi 8555 Baxter Place Burnaby, BC V5A 4V7 Canada
Richard Tse Microsemi 8555 Baxter Place Burnaby，BC V5A 4V7加拿大
Email: Richard.Tse@microsemi.com
Email: Richard.Tse@microsemi.com
Craig Schelp Oracle
克雷格·谢尔普神谕
Email: craig.schelp@oracle.com
Email: craig.schelp@oracle.com
Tal Mizrahi Marvell 6 Hamada St. Yokneam, 2066721 Israel
Tal Mizrahi Marvell 6 Hamada St.Yokneam，2066721以色列
Email: talmi@marvell.com
Email: talmi@marvell.com