RFC 8186 - Support of the IEEE 1588 Timestamp Format in a Two-Way Active Measurement Protocol (TWAMP) 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc8186
タイトル : RFC 8186 - 双方向アクティブ測定プロトコル（TWAMP）でのIEEE 1588タイムスタンプ形式のサポート
翻訳編集 : 自動生成

[要約] RFC 8186は、Two-Way Active Measurement Protocol（TWAMP）でIEEE 1588タイムスタンプ形式をサポートするためのガイドラインです。目的は、ネットワークのパフォーマンス測定において正確なタイムスタンプを提供することです。

Internet Engineering Task Force (IETF)                         G. Mirsky
Request for Comments: 8186                                     ZTE Corp.
Category: Standards Track                                      I. Meilik
ISSN: 2070-1721                                                 Broadcom
                                                               June 2017

Support of the IEEE 1588 Timestamp Format in a Two-Way Active Measurement Protocol (TWAMP)

双方向アクティブ測定プロトコル（TWAMP）でのIEEE 1588タイムスタンプ形式のサポート

Abstract

概要

This document describes an OPTIONAL feature for active performance measurement protocols that allows use of the Precision Time Protocol timestamp format defined in IEEE 1588v2, as an alternative to the Network Time Protocol that is currently used.

このドキュメントでは、現在使用されているネットワークタイムプロトコルの代わりに、IEEE 1588v2で定義されている高精度タイムプロトコルのタイムスタンプ形式を使用できるアクティブパフォーマンス測定プロトコルのオプション機能について説明します。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

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). Further information on Internet Standards is available in Section 2 of RFC 7841.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc8186.

このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8186で入手できます。

著作権表示

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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Conventions Used in This Document . . . . . . . . . . . .   3
       1.1.1.  Terminology . . . . . . . . . . . . . . . . . . . . .   3
       1.1.2.  Requirements Language . . . . . . . . . . . . . . . .   3
   2.  OWAMP and TWAMP Extensions  . . . . . . . . . . . . . . . . .   3
     2.1.  Timestamp Format Negotiation in OWAMP Connection Setup  .   4
     2.2.  Timestamp Format Negotiation in TWAMP Connection Setup  .   5
     2.3.  OWAMP-Test and TWAMP-Test Updates . . . . . . . . . . . .   5
       2.3.1.  Consideration for TWAMP Light Mode  . . . . . . . . .   6
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   5.  Normative References  . . . . . . . . . . . . . . . . . . . .   7
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1. Introduction

1. はじめに

The One-Way Active Measurement Protocol (OWAMP) [RFC4656] defines that only the NTP format [RFC5905] of a timestamp can be used in the OWAMP-Test protocol. The Two-Way Active Measurement Protocol (TWAMP) [RFC5357] adopted the OWAMP-Test packet format and extended it by adding a format for a reflected test packet. Both the sender's and reflector's packets timestamps are expected to follow the 64-bit-long NTP format [RFC5905]. NTP, when used over the Internet, typically achieves clock accuracy within 5 ms to 100 ms. Surveys conducted recently suggest that 90% of devices achieve accuracy better than 100 ms and 99% of devices achieve accuracy better than 1 sec. It should be noted that NTP synchronizes clocks on the control plane, not on data plane. Distribution of clock within a node may be supported by an independent NTP domain or via interprocess communication in a multiprocessor distributed system. Any of the mentioned solutions will be subject to additional queuing delays that negatively affect data-plane clock accuracy.

一方向アクティブ測定プロトコル（OWAMP）[RFC4656]は、タイムスタンプのNTP形式[RFC5905]のみがOWAMP-Testプロトコルで使用できることを定義しています。 Two-Way Active Measurement Protocol（TWAMP）[RFC5357]はOWAMP-Testパケットフォーマットを採用し、反射テストパケットのフォーマットを追加することで拡張しました。送信者とリフレクターの両方のパケットのタイムスタンプは、64ビット長のNTP形式[RFC5905]に従うことが期待されています。 NTPをインターネット経由で使用すると、通常は5ミリ秒から100ミリ秒以内のクロック精度が達成されます。最近実施された調査では、デバイスの90％が100 msを超える精度を達成し、99％のデバイスが1秒を超える精度を達成していることが示唆されています。 NTPは、データプレーンではなく、コントロールプレーンでクロックを同期することに注意してください。ノード内のクロックの分配は、独立したNTPドメインによって、またはマルチプロセッサ分散システムのプロセス間通信を介してサポートされます。前述のソリューションはいずれも、データプレーンのクロック精度に悪影響を及ぼす追加のキューイング遅延の影響を受けます。

The Precision Time Protocol (PTP) [IEEE.1588] has gained wide support since the development of OWAMP and TWAMP. PTP, using on-path support and other mechanisms, allows sub-microsecond clock accuracy. PTP is now supported in multiple implementations of fast-forwarding engines; thus, accuracy achieved by PTP is the accuracy of the clock in the data plane. Having an option to use a more accurate clock as a source of timestamps for IP performance measurements is one of the advantages of this specification. Another advantage is realized by simplification of hardware in the data plane. To support OWAMP or TWAMP, test protocol timestamps must be converted from PTP to NTP. That requires resources, use of microcode or additional processing elements, that are always limited. To address this, this document proposes optional extensions to Control and Test protocols to support use of the IEEE 1588v2 timestamp format as an optional alternative to the NTP timestamp format.

Precision Time Protocol（PTP）[IEEE.1588]は、OWAMPおよびTWAMPの開発以来、幅広いサポートを得ています。パス上のサポートおよびその他のメカニズムを使用するPTPは、サブマイクロ秒のクロック精度を可能にします。 PTPは、早送りエンジンの複数の実装でサポートされるようになりました。したがって、PTPによって達成される精度は、データプレーンのクロックの精度です。 IPパフォーマンス測定のタイムスタンプのソースとしてより正確なクロックを使用するオプションがあることは、この仕様の利点の1つです。別の利点は、データプレーン内のハードウェアの簡素化によって実現されます。 OWAMPまたはTWAMPをサポートするには、テストプロトコルのタイムスタンプをPTPからNTPに変換する必要があります。これには、常に制限されているリソース、マイクロコードまたは追加の処理要素の使用が必要です。これに対処するために、このドキュメントでは、NTPタイムスタンプ形式のオプションの代替として、IEEE 1588v2タイムスタンプ形式の使用をサポートするために、制御およびテストプロトコルにオプションの拡張機能を提案します。

One of the goals of this specification is not only to allow endpoints of a test session to use a timestamp format other than NTP, but to support backwards compatibility with nodes that do not yet support this extension.

この仕様の目的の1つは、テストセッションのエンドポイントがNTP以外のタイムスタンプ形式を使用できるようにするだけでなく、この拡張をまだサポートしていないノードとの下位互換性をサポートすることです。

1.1. Conventions Used in This Document

1.1. このドキュメントで使用される規則

1.1.1. Terminology

1.1.1. 用語

NTP: Network Time Protocol

NTP：ネットワークタイムプロトコル

PTP: Precision Time Protocol

PTP：Precision Time Protocol

TWAMP: Two-Way Active Measurement Protocol

TWAMP：双方向アクティブ測定プロトコル

OWAMP: One-Way Active Measurement Protocol

OWAMP：一方向アクティブ測定プロトコル

1.1.2. Requirements Language

1.1.2. 要件言語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。

2. OWAMP and TWAMP Extensions

2. OWAMPおよびTWAMP拡張

OWAMP connection establishment follows the procedure defined in Section 3.1 of [RFC4656] and additional steps in TWAMP described in Section 3.1 of [RFC5357]. In these procedures, the Modes field has been used to identify and select specific communication capabilities. At the same time, the Modes field has been recognized and used as an extension mechanism [RFC6038]. The new feature requires one bit position for the Server and Control-Client to negotiate which timestamp format can be used in some or all test sessions invoked with this control connection. The endpoint of the test session, Session-Sender and Session-Receiver (for OWAMP) or Session-Reflector (for TWAMP), that supports this extension MUST be capable of interpreting the NTP and PTPv2 timestamp formats. If the endpoint does not support this extension, then the value of the PTPv2 Timestamp flag MUST be 0 because it is in Must Be Zero field. If the value of the PTPv2 Timestamp flag is 0, then the advertising node can use and interpret only the NTP timestamp format. Implementations of OWAMP and/or TWAMP MAY provide a configuration knob to bypass the timestamp format negotiation process and use the locally configured values instead.

OWAMP接続の確立は、[RFC4656]のセクション3.1で定義されている手順と、[RFC5357]のセクション3.1で説明されているTWAMPの追加手順に従います。これらの手順では、「モード」フィールドを使用して、特定の通信機能を識別および選択しています。同時に、Modesフィールドは拡張メカニズムとして認識され、使用されています[RFC6038]。新しい機能では、サーバーとコントロールクライアントがこのコントロール接続で呼び出される一部またはすべてのテストセッションで使用できるタイムスタンプ形式をネゴシエートするために1ビットの位置が必要です。この拡張をサポートするテストセッションのエンドポイント、Session-SenderおよびSession-Receiver（OWAMPの場合）またはSession-Reflector（TWAMPの場合）は、NTPおよびPTPv2タイムスタンプ形式を解釈できる必要があります。エンドポイントがこの拡張機能をサポートしていない場合、PTPv2タイムスタンプフラグの値はゼロでなければならないフィールドにあるため、0でなければなりません。 PTPv2タイムスタンプフラグの値が0の場合、アドバタイズノードはNTPタイムスタンプ形式のみを使用および解釈できます。 OWAMPまたはTWAMP、あるいはその両方の実装は、タイムスタンプ形式のネゴシエーションプロセスをバイパスし、代わりにローカルで構成された値を使用する構成ノブを提供する場合があります。

Use of PTPv2 Timestamp flags is discussed in the following subsections. For details on the assigned values and bit positions, see the Section 3.

PTPv2タイムスタンプフラグの使用については、次のサブセクションで説明します。割り当てられた値とビット位置の詳細については、セクション3を参照してください。

2.1. Timestamp Format Negotiation in OWAMP Connection Setup

2.1. OWAMP接続設定でのタイムスタンプ形式のネゴシエーション

In OWAMP-Test [RFC4656], the Session-Receiver and/or Fetch-Client interpret collected timestamps. Thus, the Server uses the Modes field timestamp format to indicate which formats the Session-Receiver is capable of interpreting. The Control-Client inspects values set by the Server for timestamp formats and sets values in the Modes field of the Set-Up-Response message according to the timestamp formats the Session-Sender can use. The rules for setting timestamp flags in the Modes field in Server Greeting and Set-Up-Response messages and interpreting them are as follows:

OWAMP-Test [RFC4656]では、Session-ReceiverやFetch-Clientが収集されたタイムスタンプを解釈します。したがって、サーバーは、モードフィールドのタイムスタンプ形式を使用して、Session-Receiverが解釈できる形式を示します。 Control-Clientは、サーバーによって設定されたタイムスタンプ形式の値を検査し、Session-Senderが使用できるタイムスタンプ形式に従ってSet-Up-ResponseメッセージのModesフィールドに値を設定します。サーバーグリーティングメッセージとSet-Up-Responseメッセージの[モード]フィールドにタイムスタンプフラグを設定し、それらを解釈するためのルールは次のとおりです。

o If the Session-Receiver supports this extension, then the Server that establishes test sessions on its behalf MUST set the PTPv2 Timestamp flag to 1 in the Server Greeting message per the requirement listed in Section 2. Otherwise, the PTPv2 Timestamp flag will be set to 0 to indicate that the Session-Receiver interprets only the NTP format.

o Session-Receiverがこの拡張をサポートしている場合、その代わりにテストセッションを確立するサーバーは、セクション2に記載されている要件に従ってサーバーグリーティングメッセージでPTPv2タイムスタンプフラグを1に設定する必要があります。それ以外の場合、PTPv2タイムスタンプフラグは次のように設定されます。 0は、Session-ReceiverがNTP形式のみを解釈することを示します。

o If the Control-Client receives a greeting message with the PTPv2 Timestamp flag set to 0, then the Session-Sender MUST use the NTP format for the timestamp in the test session, and the Control-Client SHOULD set the PTPv2 Timestamp flag to 0 in accordance with [RFC4656]. If the Session-Sender cannot use NTP timestamps, then the Control-Client SHOULD close the TCP connection associated with the OWAMP-Control session.

o Control-ClientがPTPv2 Timestampフラグを0に設定してグリーティングメッセージを受信した場合、Session-SenderはテストセッションのタイムスタンプにNTP形式を使用する必要があり、Control-ClientはPTPv2 Timestampフラグを0に設定する必要があります（SHOULD）。 [RFC4656]に準拠。 Session-SenderがNTPタイムスタンプを使用できない場合、Control-ClientはOWAMP-Controlセッションに関連付けられたTCP接続を閉じる必要があります（SHOULD）。

o If the Control-Client receives a greeting message with the PTPv2 Timestamp flag set to 1 and the Session-Sender can set the timestamp in PTPv2 format, then the Control-Client MUST set the PTPv2 Timestamp flag to 1 in the Modes field in the Set-Up-Response message and the Session-Sender MUST use PTPv2 timestamp format.

o Control-ClientがPTPv2 Timestampフラグを1に設定してグリーティングメッセージを受信し、Session-SenderがタイムスタンプをPTPv2形式で設定できる場合、Control-ClientはSetのModesフィールドでPTPv2 Timestampフラグを1に設定する必要があります。 -Up-ResponseメッセージとSession-Senderは、PTPv2タイムスタンプ形式を使用する必要があります。

o If the Session-Sender doesn't support this extension and can set the timestamp in NTP format only, then the PTPv2 Timestamp flag in the Modes field in the Set-Up-Response message will be set to 0 as part of the Must Be Zero field and the Session-Sender will use the NTP format.

o Session-Senderがこの拡張をサポートせず、NTP形式でのみタイムスタンプを設定できる場合、Set-Up-ResponseメッセージのModesフィールドのPTPv2 Timestampフラグは、Must Be Zeroの一部として0に設定されます。フィールドとセッション送信者はNTP形式を使用します。

If OWAMP-Control uses Fetch-Session commands, then selection and use of one timestamp format or another is a local decision for both Session-Sender and Session-Receiver.

OWAMP-ControlがFetch-Sessionコマンドを使用する場合、1つのタイムスタンプ形式または別のタイムスタンプ形式の選択と使用は、Session-SenderとSession-Receiverの両方のローカル決定です。

2.2. Timestamp Format Negotiation in TWAMP Connection Setup

2.2. TWAMP接続設定でのタイムスタンプ形式のネゴシエーション

In TWAMP-Test [RFC5357], the Session-Sender interprets collected timestamps. Hence, in the Modes field, a Server advertises timestamp formats that the Session-Reflector can use in the TWAMP-Test message. The choice of the timestamp format to be used by the Session-Sender is a local decision. The Control-Client inspects the Modes field and sets timestamp flag values to indicate the format that will be used by the Session-Reflector. The rules of setting and interpreting flag values are as follows:

TWAMP-Test [RFC5357]では、Session-Senderは収集されたタイムスタンプを解釈します。したがって、[モード]フィールドで、サーバーはセッションリフレクターがTWAMP-Testメッセージで使用できるタイムスタンプ形式を通知します。セッション送信者が使用するタイムスタンプ形式の選択は、ローカルの決定です。 Control-Clientは、Modesフィールドを検査し、タイムスタンプフラグ値を設定して、Session-Reflectorで使用される形式を示します。フラグ値の設定と解釈の規則は次のとおりです。

o The Server MUST set the PTPv2 Timestamp flag value to 1 in its greeting message if the Session-Reflector can set the timestamp in the PTPv2 format. Otherwise, the PTPv2 Timestamp flag MUST be set to 0.

o サーバーは、Session-ReflectorがPTPv2形式でタイムスタンプを設定できる場合、グリーティングメッセージでPTPv2タイムスタンプフラグ値を1に設定する必要があります。それ以外の場合は、PTPv2タイムスタンプフラグを0に設定する必要があります。

o If the value of the PTPv2 Timestamp flag in the received Server Greeting message is 0, then the Session-Reflector does not support this extension and will use the NTP timestamp format. The Control-Client SHOULD set the PTPv2 Timestamp flag to 0 in the Set-Up-Response message in accordance with [RFC4656].

o 受信したサーバーグリーティングメッセージのPTPv2タイムスタンプフラグの値が0の場合、Session-Reflectorはこの拡張をサポートせず、NTPタイムスタンプ形式を使用します。 Control-Clientは、[RFC4656]に従って、Set-Up-ResponseメッセージでPTPv2 Timestampフラグを0に設定する必要があります（SHOULD）。

o The Control-Client MUST set the PTPv2 Timestamp flag value to 1 in the Modes field in the Set-Up-Response message if the Server advertised that the Session-Reflector has the ability to use the PTPv2 format for timestamps. Otherwise, the flag MUST be set to 0.

o サーバーがSession-ReflectorがタイムスタンプにPTPv2形式を使用できることを通知した場合、Control-ClientはSet-Up-ResponseメッセージのModesフィールドでPTPv2 Timestampフラグ値を1に設定する必要があります。それ以外の場合は、フラグを0に設定する必要があります。

o If the value of the PTPv2 Timestamp flag in the Set-Up-Response message is 0, then that means that the Session-Sender can only interpret the NTP timestamp format. Therefore, the Session-Reflector MUST use the NTP timestamp format. If the Session-Reflector does not support the NTP format, then the Server MUST close the TCP connection associated with the TWAMP-Control session.

o Set-Up-ResponseメッセージのPTPv2 Timestampフラグの値が0の場合、それは、Session-SenderがNTPタイムスタンプ形式のみを解釈できることを意味します。したがって、Session-ReflectorはNTPタイムスタンプ形式を使用する必要があります。 Session-ReflectorがNTP形式をサポートしない場合、サーバーはTWAMP-Controlセッションに関連付けられたTCP接続を閉じる必要があります。

2.3. OWAMP-Test and TWAMP-Test Updates

2.3. OWAMP-TestおよびTWAMP-Testの更新

Participants of a test session need to indicate which timestamp format is being used. Currently, the Z field in the Error Estimate defined in Section 4.1.2 of [RFC4656] is used for this purpose. However, this document extends the Error Estimate to indicate the format of a collected timestamp, in addition to the estimate of error and synchronization. This specification also changes the semantics of the Z bit field (the field between S and Scale fields) to be referred to as the Timestamp format; the value MUST be set as follows:

テストセッションの参加者は、使用されているタイムスタンプ形式を示す必要があります。現在、[RFC4656]のセクション4.1.2で定義されているError EstimateのZフィールドがこの目的で使用されています。ただし、このドキュメントでは、エラーと同期の見積もりに加えて、収集されたタイムスタンプの形式を示すためにエラー見積もりを拡張しています。この仕様は、タイムスタンプ形式と呼ばれるZビットフィールド（SフィールドとScaleフィールドの間のフィールド）のセマンティクスも変更します。値は次のように設定する必要があります。

o 0 - NTP 64-bit format of a timestamp.

o 0-タイムスタンプのNTP 64ビット形式。

o 1 - PTPv2-truncated format of a timestamp.

o 1-タイムスタンプのPTPv2切り捨て形式。

As a result of this value of the Z field from the Error Estimate, the Sender Error Estimate (in TWAMP) or Send Error Estimate (in OWAMP) and Receive Error Estimate SHOULD NOT be ignored and MUST be used when calculating delay and delay-variation metrics based on collected timestamps.

Error EstimateからのZフィールドのこの値の結果として、Sender Error Estimate（TWAMP内）またはSend Error Estimate（OWAMP内）およびReceive Error Estimateは無視してはならず、遅延および遅延変動を計算するときに使用する必要があります（SHOULD NOT）。収集されたタイムスタンプに基づくメトリック。

2.3.1. Consideration for TWAMP Light Mode

2.3.1. TWAMPライトモードに関する考慮事項

This document does not specify how the Session-Sender and Session-Reflector in TWAMP Light mode are informed of the timestamp format to be used. It is assumed that, for example, configuration could be used to direct the Session-Sender and Session-Reflector to use the timestamp format per their capabilities and rules listed in Section 2.2.

このドキュメントでは、TWAMP LightモードのSession-SenderとSession-Reflectorに、使用するタイムスタンプ形式を通知する方法を指定していません。たとえば、構成を使用して、Session-SenderおよびSession-Reflectorに、セクション2.2にリストされている機能およびルールごとにタイムスタンプ形式を使用するように指示できると想定されています。

3. IANA Considerations

3. IANAに関する考慮事項

IANA has registered a new PTPv2 Timestamp in the "TWAMP-Modes" registry [RFC5618] as follows:

IANAは、次のように「TWAMP-Modes」レジストリ[RFC5618]に新しいPTPv2タイムスタンプを登録しました。

   +------+-----------------------------+-----------+------------------+
   | Bit  | Description                 | Semantics | Reference        |
   | Pos  |                             |           |                  |
   +------+-----------------------------+-----------+------------------+
   | 9    | PTPv2 Timestamp Capability  | Section 2 | RFC 8186 (this   |
   |      |                             |           | document)        |
   +------+-----------------------------+-----------+------------------+

Table 1: New Timestamp Capability

表1：新しいタイムスタンプ機能

4. Security Considerations

4. セキュリティに関する考慮事項

Use of a particular timestamp format in a test session does not appear to introduce any additional security threat to hosts that communicate with OWAMP and/or TWAMP as defined in [RFC4656] and [RFC5357], respectively. The security considerations that apply to any active measurement of live networks are relevant here as well. See the Security Considerations sections in [RFC4656] and [RFC5357].

テストセッションで特定のタイムスタンプ形式を使用しても、[RFC4656]と[RFC5357]でそれぞれ定義されているように、OWAMPまたはTWAMP、あるいはその両方と通信するホストにセキュリティ上の脅威が追加されることはないようです。ライブネットワークのアクティブな測定に適用されるセキュリティの考慮事項は、ここでも関係があります。 [RFC4656]および[RFC5357]のセキュリティに関する考慮事項のセクションを参照してください。

5. Normative References

5. 引用文献

[IEEE.1588] IEEE, "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", IEEE Std 1588-2008, DOI 10.1109/IEEESTD.2008.4579760.

[IEEE.1588] IEEE、「IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems」、IEEE Std 1588-2008、DOI 10.1109 / IEEESTD.2008.4579760。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。

[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, <http://www.rfc-editor.org/info/rfc4656>.

[RFC4656] Shalunov、S.、Teitelbaum、B.、Karp、A.、Boote、J。、およびM. Zekauskas、「A One-way Active Measurement Protocol（OWAMP）」、RFC 4656、DOI 10.17487 / RFC4656、9月2006、<http://www.rfc-editor.org/info/rfc4656>。

[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, DOI 10.17487/RFC5357, October 2008, <http://www.rfc-editor.org/info/rfc5357>.

[RFC5357] Hedayat、K.、Krzanowski、R.、Morton、A.、Yum、K。、およびJ. Babiarz、「A Two-Way Active Measurement Protocol（TWAMP）」、RFC 5357、DOI 10.17487 / RFC5357、10月2008、<http://www.rfc-editor.org/info/rfc5357>。

[RFC5618] Morton, A. and K. Hedayat, "Mixed Security Mode for the Two-Way Active Measurement Protocol (TWAMP)", RFC 5618, DOI 10.17487/RFC5618, August 2009, <http://www.rfc-editor.org/info/rfc5618>.

[RFC5618] Morton、A。およびK. Hedayat、「双方向アクティブ測定プロトコル（TWAMP）の混合セキュリティモード」、RFC 5618、DOI 10.17487 / RFC5618、2009年8月、<http：//www.rfc-editor .org / info / rfc5618>。

[RFC5905] 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>.

[RFC5905] 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>。

[RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features", RFC 6038, DOI 10.17487/RFC6038, October 2010, <http://www.rfc-editor.org/info/rfc6038>.

[RFC6038] Morton、A。およびL. Ciavattone、「Two-Way Active Measurement Protocol（TWAMP）Reflect Octets and Symmetrical Size Features」、RFC 6038、DOI 10.17487 / RFC6038、2010年10月、<http：//www.rfc- editor.org/info/rfc6038>。

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.

[RFC8174] Leiba、B。、「あいまいな大文字と小文字のRFC 2119キーワード」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<http://www.rfc-editor.org/info/ rfc8174>。

Acknowledgements

謝辞

The authors would like to thank Ramanathan Lakshmikanthan and Suchit Bansal for their insightful suggestions. The authors would also like to thank David Allan for his thorough review and thoughtful comments.

著者は、洞察に満ちた提案をしてくれたRamanathan LakshmikanthanとSuchit Bansalに感謝します。著者はまた、David Allanの徹底したレビューと思慮深いコメントに感謝します。

Authors' Addresses

著者のアドレス

Greg Mirsky ZTE Corp.

グレッグ・ミルスキーZTE Corp.

   Email: gregimirsky@gmail.com

Israel Meilik Broadcom

イスラエルがBroadcomを所有

   Email: israel@broadcom.com