[要約] RFC 8039は、複数のパスを使用して時刻同期を行うためのプロトコルを提案しています。その目的は、ネットワーク内の時刻同期の信頼性と精度を向上させることです。
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）の導入が急速に進んでいます。時間に敏感なアプリケーションが進化するにつれて、クロック精度の要件はますます厳しくなり、時間同期プロトコルが高精度を提供することを要求しています。このメモでは、PTPおよびNTP over NTPネットワークへのマルチパスアプローチについて説明し、これらのプロトコルを変更せずに、プロトコルをマスタークロックとスレーブクロック間の複数の通信パスで同時に実行できるようにします。マルチパスアプローチは、クロックの精度、セキュリティ、フォールトトレランスに大きく貢献します。このドキュメントで説明するマルチパスアプローチにより、マルチパス機能をサポートしないノードとの下位互換性が可能になります。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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ネットワークで最も一般的な2つの時刻同期プロトコルは、（1）Network Time Protocol [NTP]と（2）IEEE 1588標準[IEEE1588]で定義されているPrecision Time Protocol（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.
時間同期プロトコルの精度は、マスタークロックとスレーブクロック間の双方向の伝播遅延の安定性と対称性に直接依存します。基盤となるネットワークの性質に応じて、時間同期プロトコルパケットは、可変ネットワークレイテンシまたはパスの非対称性の影響を受ける可能性があります（[ASYMMETRY] [ASYMMETRY2]など）。時間に敏感なアプリケーションが進化するにつれて、精度要件はますます厳しくなっています。クロック同期プロトコルで単一のネットワークパスを使用すると、スレーブクロックの精度が特定のパスの動作に密接に関連付けられ、一時的な輻輳、障害、または悪意のある攻撃の影響を受ける可能性があります。 NTPのように複数のクロックサーバーに依存すると、これらの問題は解決しますが、ネットワーク内の複数の正確なソースをアクティブに維持する必要がありますが、これは常に可能とは限りません。 PTPでの透過クロック（TC）の使用は、遅延計算からキューイング時間を排除することで輻輳の問題を解決しますが、セキュリティやフォールトトレランスの側面には対処しません。
____
______/ \_____
___/ \____
____/ \
____ / 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]に示すように、クロック精度を大幅に向上させることができます。第2に、このアプローチは追加のセキュリティを提供し、時刻同期プロトコル[DELAY-ATT]に対する中間者攻撃を軽減できます。第3に、複数のパスを同時に使用すると、固有の障害保護メカニズムが提供されます。
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の組み合わせペアは、マルチパス同期プロトコルで使用される複数の多様なパスを形成できます。ワイドインターネット上で複数のIPアドレスを使用すると、実際に2つのエンドポイントで複数の多様なパスを実現できることが示されています。
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.
このドキュメントでは、マルチパスアプローチの2つのバリアントを紹介します：（1）マスターノードとスレーブノードの両方がマルチパス機能をサポートするために必要なバリアント（デュアルエンドバリアントと呼ばれる）、および（2）マルチパスを許可する下位互換性のあるバリアントシングルエンドバリアントと呼ばれる従来のシングルパスクロックに接続するためのクロック。
BMC Best Master Clock [IEEE1588]
BMCベストマスタークロック[IEEE1588]
ECMP Equal-Cost Multipath
ECMP等コストマルチパス
LAN Local Area Network
LANローカルエリアネットワーク
MPNTP Multipath Network Time Protocol
MPNTPマルチパスネットワークタイムプロトコル
MPPTP Multipath Precision Time Protocol
MPPTPマルチパス高精度時間プロトコル
NTP Network Time Protocol [NTP]
NTPネットワークタイムプロトコル[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.
3つの一般的なロードバランシング基準は、宛先ごと、フローごと、およびパケットごとです。宛先ごとのロードバランサーは、宛先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アドレスと宛先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へのパケットと同じパスを通過するわけではないということです。したがって、マスタースレーブ接続の双方向パスを一方向のペアとして定義パス：最初はマスターからスレーブへ、2番目はスレーブからマスターへ。
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.
ここで紹介するマルチパス時間同期プロトコルは、2つの構成要素で構成されています。1つはパスの構成と識別、もう1つはスレーブがさまざまなパスから受信した情報を組み合わせるために使用するアルゴリズムです。
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.
可能であれば、ネットワーク全体のルーティングテーブルは、クロックのペア間に複数のトラフィックエンジニアリングされたパスを使用して構成する必要があります。このようなネットワークでルーターを注意深く構成することにより、ネットワーク内の2つのクロック間の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の2つのバリアントであるシングルエンドマルチパス時間同期とデュアルエンドマルチパス時間同期について説明します。最初のバリアントでは、マルチパスアプローチはスレーブによってのみ実装され、マスターはその使用法を認識していません。 2番目のバリアントでは、すべてのクロックが複数のパスを使用します。
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 discovery should be used to identify the possible paths between the master and slave. Path discovery is further discussed in Section 5.4.
ネットワークアドレス変換（NAT）を使用すると、マルチパス同期の効果が大幅に低下する場合があります。たとえば、マスターが単一のIPアドレスに変換される複数のIPアドレスを使用する場合、NATを使用しないネットワークと比較して、パスの多様性を大幅に減らすことができます。したがって、パス検出を使用して、マスターとスレーブ間の可能なパスを特定する必要があります。パス検出については、セクション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でユニキャストとして次のメッセージを送信する必要があります：Sync、Delay_Req、Delay_Resp、PDelay_Req、PDelay_Resp、Follow_Up、およびPDelay_Resp_Follow_Up。 [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.
シングルエンドアプローチでは、スレーブのみが複数のパスが使用されていることを認識していますが、マスターは複数のパスの使用にとらわれていません。このアプローチにより、ハイブリッドネットワークが可能になり、一部のクロックはマルチパスクロックで、他のクロックは従来の1パスクロックです。シングルエンドマルチパスクロックは、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個のclockIdentityの固定セットがあります。各クロックは、そのIPアドレスとclockIdentity値の1つをクロックプライマリアイデンティティとして任意に定義します。
o A single-ended MPPTP port sends Announce messages only from its primary identity, according to the BMC algorithm.
o シングルエンドのMPPTPポートは、BMCアルゴリズムに従って、プライマリIDからのみアナウンスメッセージを送信します。
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個のスレーブclockIdentity値のそれぞれにユニキャストメッセージを送信するように要求します。スレーブポートは、N個のIDのそれぞれを使用して、N個のシグナリングメッセージを定期的にマスターに送信します。シグナリングメッセージには、REQUEST_UNICAST_TRANSMISSION 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アドレスで識別されるプライマリIDから各スレーブIDにユニキャスト同期メッセージを定期的に送信します。
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アドレスに従ってパスを識別します。スレーブは、Delay_ReqユニキャストメッセージをマスターのプライマリIDに送信します。 Delay_Reqは、同期が受信されたパスに対応するスレーブIDを使用して送信されます。 Delay_ReqメッセージのレートはSyncメッセージレートよりも低い場合があるため、Syncメッセージの後に必ずしもDelay_Reqが続くわけではないことに注意してください。
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 マスターは、スレーブからのDelay_Reqメッセージに応答して、Delay_ReqメッセージからのIPアドレスとsourcePortIdentityを使用して、Delay_Respメッセージで応答します。
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 Delay_Respメッセージを受信すると、スレーブは宛先IPアドレスとrequestingPortIdentity [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個の個別のID、つまりN個のIPアドレスがあります。 IPアドレスを含むサーバー情報がNTPクライアントに認識されていることが前提です。通常、NTPサーバーのアドレスは構成によってNTPクライアントに提供されるため、これは公平な仮定です。
o A single-ended MPNTP client initiates NTP with an NTP server N times, using each of its N identities.
o シングルエンドMPNTPクライアントは、N個のIDのそれぞれを使用して、NTPサーバーとのN回のNTPを開始します。
o NTP is maintained between the server and each of the N client identities.
o NTPは、サーバーとN個の各クライアントIDの間で維持されます。
o The client sends NTP messages to the master using each of its N identities.
o クライアントは、N個のIDのそれぞれを使用して、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アドレスがあります。時間同期メッセージは、{マスターIP、スレーブIP}アドレスのいくつかの組み合わせの間で交換され、マスターとスレーブ間の複数のパスを許可します。マスターとスレーブ間の実際のパス数は、選択された{マスターIP、スレーブ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アドレスがありますが、単一のclockIdentityを使用します。
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アルゴリズムがマスターを決定します。マスターはそのclockIdentityによって識別され、他のクロックが使用する複数のIPアドレスを知ることができます。
o When a clock sends an Announce message, it sends it from each of its IP addresses with its clockIdentity.
o クロックがアナウンスメッセージを送信する場合、クロックはそれぞれのIPアドレスからclockIdentityで送信されます。
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アドレスに定期的にシグナリングメッセージを送信します。シグナリングメッセージには、REQUEST_UNICAST_TRANSMISSION 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}アドレスに従ってパスを識別します。スレーブはDelay_Reqユニキャストメッセージを送信し、同期メッセージから送信元と宛先のIPアドレスを交換します。 Delay_ReqメッセージのレートはSyncメッセージレートよりも低い場合があるため、Syncメッセージの後に必ずしもDelay_Reqが続くわけではないことに注意してください。
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 マスターは、スレーブからのDelay_Reqメッセージに応答して、Delay_ReqメッセージからのsourcePortIdentityを使用し、Delay_ReqからIPアドレスをスワップして、Delay_Respメッセージで応答します。
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アドレスのセットがあります。複数のIPアドレスを含むサーバー情報がNTPクライアントに認識されていることが前提です。
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}アドレスペアに対して1つであり、クライアントが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アドレスを使用して複数のパスを作成します。ただし、各双方向パスは異なる{マスターIP、スレーブ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.
Tracerouteベースのパス検出は、多様なパスを取得するIPアドレスのみをフィルタリングするために使用できます。 「Paris traceroute」[PARIS]および「TraceFlow」[TRACEFLOW]は、ネットワーク内の2つのポイント間のパスを検出するツールの例です。このフィルタリングアプローチは、Traceroute実装が同期プロトコルパケットと同じIPアドレスとUDPポートを使用する場合にのみ有効であることに注意してください。 Tracerouteの実装によっては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.
tracerouteベースのフィルタリングは、マスターノードとスレーブノードの両方で実装できます。または、スレーブノードでのみ実行するように制限して、マスターのオーバーヘッドを減らすことができます。順方向と逆方向のタイミングパケットのパスが同じであることを保証するネットワークの場合、パス検出はスレーブでのみ実行する必要があります。
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.
ネットワークルートは時間とともに変化するため、パス検出と冗長パスフィルタリングを定期的に実行する必要があります。 2つの異なるパスを生成する2つの{マスターIP、スレーブ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-AVAI] [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]で公開されています。実験期間は、メソッドがコミュニティによってさらに調査および検証されることを可能にすることが期待されます。実験期間は、このドキュメントの公開から2年以上になると予想されます。
[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 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。
[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、「Network Time Protocol Version 4：Protocol and Algorithms Specification」、RFC 5905、DOI 10.17487 / RFC5905、2010年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.
[ASYMMETRY]彼、Y.、Faloutsos、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-1_19、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]ミズラヒ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.
[HIGH-AVAI] 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、「マルチパスネットワーク同期のためのカルマンフィルタリング」、IEEE International Symposium on Precision Clock Synchronization for Measurement、Control and Communication（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、「Multiple Interfaces and Provisioning Domains Problem Statement」、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 6824、DOI 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] Shpiner、A.、Revah、Y。、および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、 2013年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]オーガスティン、B。、フリードマン、T。、およびR.テイシェイラ、「インターネットでの負荷分散パスの測定」、インターネット測定に関する第7回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]オーガスティン、B。、フリードマン、T。、およびR.テイシェイラ、「インターネットでのマルチパスルーティングの測定」、IEEE / ACM Transactions on Networking、19（3）、pp。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]ミズラヒ、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]ミズラヒ、T。、「スレーブの多様性：クロック同期プロトコルの精度を向上させるための複数のパスの使用」、測定、制御、通信のための高精度クロック同期に関するIEEE国際シンポジウム（ISPCS）、DOI 10.1109 / ISPCS.2012.6336621、9月2012。
[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」、Work in Progress、draft-janapath-intarea-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 Shpiner Mellanox Technologies、Ltd. Hakidma 26 Ofer Industrial Park Yokneam、2069200 Israel
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 Canada
Email: Richard.Tse@microsemi.com
Craig Schelp Oracle
クレイグシェルオラクル
Email: craig.schelp@oracle.com
Tal Mizrahi Marvell 6 Hamada St. Yokneam, 2066721 Israel
Tal Mizrahi Marvell 6 Hamada St. Yokneam、2066721 Israel
Email: talmi@marvell.com