[要約] RFC 6802は、Ericsson Two-Way Active Measurement Protocol（TWAMP）の値追加オクテットに関する仕様です。このRFCの目的は、TWAMPの拡張性と柔軟性を向上させるために、値追加オクテットの使用方法を定義することです。
Internet Engineering Task Force (IETF) S. Baillargeon
Request for Comments: 6802 C. Flinta
Category: Informational A. Johnsson
ISSN: 2070-1721 Ericsson
November 2012
Ericsson Two-Way Active Measurement Protocol (TWAMP) Value-Added Octets
エリクソン双方向アクティブ測定プロトコル（TWAMP）付加価値オクテット
Abstract
概要
This memo describes an extension to the Two-Way Active Measurement Protocol (TWAMP). Specifically, it extends the TWAMP-Test protocol, which identifies and manages packet trains, in order to measure capacity metrics like the available path capacity, tight section capacity, and UDP delivery rate in the forward and reverse path directions.
このメモは、双方向アクティブ測定プロトコル（TWAMP）の拡張について説明しています。具体的には、TWAMP-Testプロトコルを拡張し、パケットトレインを識別および管理して、利用可能なパスキャパシティ、タイトセクションキャパシティ、フォワードおよびリバースパス方向のUDP配信レートなどのキャパシティメトリックを測定します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It 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 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。 Internet Engineering Steering Group（IESG）による公開が承認されています。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション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/rfc6802.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6802で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 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 ....................................................2
1.1. Requirements Language ......................................3
2. Purpose and Scope ...............................................3
3. Capacity Measurement Principles .................................4
4. TWAMP-Control Extensions ........................................5
4.1. Additional Considerations ..................................6
5. Extended TWAMP-Test .............................................6
5.1. Sender Behavior ............................................6
5.1.1. Packet Timings ......................................7
5.1.2. Session-Sender Packet Format ........................7
5.2. Reflector Behavior ........................................12
5.2.1. Session-Reflector Packet Format ....................13
5.3. Additional Considerations .................................13
6. Experiments ....................................................14
7. Security Considerations ........................................14
8. Acknowledgements ...............................................14
9. References .....................................................15
9.1. Normative References ......................................15
9.2. Informative References ....................................15
The notion of embedding a number of meaningful fields in the padding octets has been established as a viable methodology for carrying additional information within the TWAMP-Test protocol running between a Session-Sender and a Session-Reflector [RFC5357] [RFC6038].
多くの意味のあるフィールドをパディングオクテットに埋め込むという概念は、Session-SenderとSession-Reflector [RFC5357] [RFC6038]の間で実行されるTWAMP-Testプロトコル内で追加情報を運ぶための実行可能な方法論として確立されています。
This memo describes an optional extension to the Two-Way Active Measurement Protocol (TWAMP) [RFC5357]. It is called the Ericsson TWAMP Value-Added Octets feature. This memo defines version 1.
このメモは、双方向アクティブ測定プロトコル（TWAMP）[RFC5357]のオプションの拡張について説明しています。これは、Ericsson TWAMP付加価値オクテット機能と呼ばれます。このメモはバージョン1を定義します。
This feature enables the controller host to measure capacity metrics like the IP-type-P available path capacity (APC) [RFC5136], IP-layer tight section capacity (TSC) [Y1540], and UDP delivery rate on both forward and reverse paths using a single TWAMP test session. The actual method to calculate the APC, TSC, or the UDP delivery rate from packet-level performance data is not discussed in this memo.
この機能により、コントローラーホストは、IPタイプPの利用可能なパス容量（APC）[RFC5136]、IPレイヤーのタイトセクションキャパシティ（TSC）[Y1540]、およびフォワードパスとリバースパスの両方のUDP配信率などの容量メトリックを測定できます単一のTWAMPテストセッションを使用します。このメモでは、パケットレベルのパフォーマンスデータからAPC、TSC、またはUDP配信率を計算する実際の方法については説明していません。
The Valued-Added Octets feature consists of new behaviors for the Session-Sender and Session-Reflector and a set of value-added octets of information that are placed at the beginning of the Packet Padding [RFC5357] or immediately after the Server Octets in the Packet Padding (to be reflected) [RFC6038] by the Session-Sender and are reflected or returned by the Session-Reflector. The length of the value-added octets in version 1 is 10 octets. The Valued-Added Octets feature does not change the basic roles and functions of the TWAMP hosts, which are still responsible to include timestamp(s) and sequence number(s) in the test packets.
Valued-Added Octets機能は、Session-SenderおよびSession-Reflectorの新しい動作と、パケットパディング[RFC5357]の先頭またはサーバーオクテットの直後に配置される一連の付加価値オクテットで構成されます。 Session-Senderによるパケットパディング（反映される）[RFC6038]。Session-Reflectorによって反映または返されます。バージョン1の付加価値オクテットの長さは10オクテットです。付加価値オクテット機能は、テストパケットにタイムスタンプとシーケンス番号を含める責任があるTWAMPホストの基本的な役割と機能を変更しません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
The purpose of this memo is to describe the Ericsson TWAMP Valued-Added Octets feature (version 1) for TWAMP [RFC5357].
このメモの目的は、TWAMP [RFC5357]のエリクソンTWAMP付加価値オクテット機能（バージョン1）について説明することです。
The scope of the memo is limited to specifications of the following enhancements:
メモの範囲は、次の拡張の仕様に限定されています。
o The definition of a structure for embedding a sequence of value-added fields at the beginning of the Packet Padding [RFC5357] or Packet Padding (to be reflected) [RFC6038] in the TWAMP-Test packets
o TWAMP-Testパケットのパケットパディング[RFC5357]またはパケットパディング（反映される）[RFC6038]の先頭に付加価値フィールドのシーケンスを埋め込むための構造の定義
o The definition of new Session-Sender and Session-Reflector behaviors
o 新しいSession-SenderおよびSession-Reflectorの動作の定義
The motivation for this feature is to enable the measurement of capacity metrics on both the forward and reverse paths using a single TWAMP test session. Multiple TWAMP test sessions between a controller and a responder with different Diffserv Code Points (DSCPs) may also be used to evaluate the QoS impacts on the capacity metrics.
この機能の動機は、単一のTWAMPテストセッションを使用して、フォワードパスとリバースパスの両方で容量メトリックを測定できるようにすることです。異なるDiffservコードポイント（DSCP）を持つコントローラーとレスポンダー間の複数のTWAMPテストセッションを使用して、容量メトリックへのQoSの影響を評価することもできます。
This memo captures the prototype presented and demonstrated at IETF 80. It may be used as a reference for future work or may be used during benchmark analysis to compare the accuracy or performance of the available path capacity estimates under various condition or use cases.
このメモは、IETF 80で提示および実証されたプロトタイプをキャプチャします。これは、将来の作業の参照として使用したり、ベンチマーク分析中に使用して、さまざまな条件またはユースケースで使用可能なパス容量の見積もりの精度またはパフォーマンスを比較したりできます。
This memo does not extend the standard modes of operation through assignment of a new value in the Modes field (see Section 3.1 of [RFC4656] for the format of the Server Greeting message). This memo does not define a vendor-specific or experimental mode since the Modes field as currently defined does not explicitly reserve a value or range of values for this purpose.
このメモは、[モード]フィールドに新しい値を割り当てて標準の動作モードを拡張するものではありません（サーバーグリーティングメッセージの形式については、[RFC4656]のセクション3.1を参照してください）。現在定義されている[モード]フィールドはこの目的のために値または値の範囲を明示的に予約していないため、このメモはベンダー固有または実験的なモードを定義していません。
This memo assumes the TWAMP controller is capable to send test packets with value-added padding octets and the TWAMP responder is configured to interpret the value-added padding octets embedded in each TWAMP-Test packet. Bootstrapping such behavior at the TWAMP responder is implementation specific. By default, the feature MUST be disabled on the TWAMP host. The Value-Added Octets feature MUST be deployed in an environment where both controller and responder are managed by the same administrative entity and such entity has established an agreement to operate the Value-Added Octets feature between the pair of hosts or between specific UDP endpoints between the pair of hosts. See Sections 4 and 5.3 for additional considerations.
このメモは、TWAMPコントローラが付加価値パディングオクテットを含むテストパケットを送信でき、TWAMPレスポンダが各TWAMPテストパケットに埋め込まれた付加価値パディングオクテットを解釈するように設定されていることを前提としています。 TWAMPレスポンダでのこのような動作のブートストラップは、実装固有です。デフォルトでは、機能はTWAMPホストで無効にする必要があります。付加価値オクテット機能は、コントローラーとレスポンダーの両方が同じ管理エンティティーによって管理され、そのようなエンティティーがホストのペア間または特定のUDPエンドポイント間で付加価値オクテット機能を動作させるための合意を確立している環境に展開する必要がありますホストのペア。その他の考慮事項については、セクション4および5.3を参照してください。
The Value-Added Octets Version 1 feature is intended to work in conjunction with any TWAMP modes. When the Server and Control-Client are configured or have agreed to use the Value-Added Octets Version 1 feature, then the Control-Client, the Server, the Session-Sender, and the Session-Reflector must all conform to the requirements of that feature, as identified below.
付加価値オクテットバージョン1機能は、任意のTWAMPモードと連携して機能することを目的としています。サーバーとコントロールクライアントが構成されているか、付加価値オクテットバージョン1機能を使用することに同意している場合、コントロールクライアント、サーバー、セッション送信者、およびセッションリフレクターはすべて、その要件に準拠する必要があります。以下に示すように、機能。
Most capacity estimation methods for APC [RRBNC] [PDM] [ENHJMMB] [SBW] and for UDP delivery rate need to send and receive packets in groups, called "packet trains" or simply "trains". Each train is sent at a specific transmission rate in a given direction. These trains must be identified within each bidirectional test session stream.
APC [RRBNC] [PDM] [ENHJMMB] [SBW]およびUDP配信レートのほとんどの容量推定方法は、「パケット列」または単に「列」と呼ばれるグループでパケットを送受信する必要があります。各トレインは、特定の方向に特定の伝送速度で送信されます。これらのトレインは、各双方向テストセッションストリーム内で識別される必要があります。
The first measurement principle is to send multiple trains within a test session stream from one IP node to another IP node in order to estimate the APC, TSC, or UDP delivery rate in the forward direction. Each train consists of a group of test packets that are separated from each other by a packet interval, as shown in the figure below. The packet interval is measured using either the first bit or the last bit of two consecutive packets.
最初の測定原理は、順方向のAPC、TSC、またはUDP配信率を推定するために、1つのIPノードから別のIPノードにテストセッションストリーム内で複数のトレインを送信することです。次の図に示すように、各トレインは、パケット間隔で互いに分離されたテストパケットのグループで構成されています。パケット間隔は、2つの連続するパケットの最初のビットまたは最後のビットを使用して測定されます。
tt tt tt
|<---------->| |<---------->| |<---------->|
| | | | | |
+------------+ +------------+ +------------+
| Packet 1 | | Packet 2 | | Packet 3 |
+------------+ +------------+ +------------+
| | |
|<--------------------->|<--------------------->|
packet interval 1 packet interval 2
The test packet size and interval between consecutive packets for each train sent by the Session-Sender and reflected by the Session-Reflector MUST be calculated and determined by the controller or an application or entity communicating with the controller. The packet size and interval MAY vary within a train and/or between trains. Determination of the packet size and interval is implementation specific.
セッションセンダーによって送信され、セッションリフレクターによって反映された各トレインの連続パケット間のテストパケットサイズと間隔は、コントローラー、またはコントローラーと通信するアプリケーションまたはエンティティによって計算および決定される必要があります。パケットのサイズと間隔は、トレイン内やトレイン間で異なる場合があります。パケットサイズと間隔の決定は実装固有です。
The transmission time tt to send one packet (i.e., determined by the interface speed and the IP packet size) is also shown in the figure above. Observe that the packet interval MUST be larger than or equal to tt.
1つのパケットを送信するための送信時間tt（つまり、インターフェース速度とIPパケットサイズによって決定される）も、上の図に示されています。パケット間隔はtt以上でなければならないことに注意してください。
At the Session-Reflector, each received test packet within a forward train is time stamped. This provides a second set of packet interval values. Methods for measuring the APC, TSC, and UDP delivery rate use the packet intervals obtained from both endpoints in the estimation process. The method of measuring the UDP delivery rate may also require the rate of packet loss. The estimation process itself, as well as any requirements on software or hardware, is implementation specific.
セッションリフレクタでは、フォワードトレイン内で受信された各テストパケットにタイムスタンプが付けられます。これにより、パケット間隔値の2番目のセットが提供されます。 APC、TSC、およびUDPの配信速度を測定する方法では、推定プロセスで両方のエンドポイントから取得したパケット間隔を使用します。 UDP配信速度を測定する方法では、パケット損失率も必要になる場合があります。推定プロセス自体、およびソフトウェアまたはハードウェアの要件は、実装固有です。
The second measurement principle is referred to as "self-induced congestion". According to this principle, in order to measure APC, TSC, and UDP delivery rates, some trains MUST cause momentary congestion on the network path. In essence, this means that some trains MUST be sent at a higher rate than what is available on the network path.
2番目の測定原理は、「自己誘導型輻輳」と呼ばれます。この原理によれば、APC、TSC、およびUDPの配信速度を測定するために、一部のトレインはネットワークパス上で一時的な輻輳を引き起こす必要があります。本質的に、これは、一部のトレインがネットワークパスで利用可能なものよりも高いレートで送信される必要があることを意味します。
In order to fulfill the above measurement principles and to measure the APC, TSC, and UDP delivery rates in the reverse direction, the test packets at the Session-Reflector MUST be regrouped into trains and then transmitted back to the Session-Sender with a provided packet interval.
上記の測定原理を満たし、APC、TSC、UDPの配信速度を逆方向に測定するには、セッションリフレクターでのテストパケットをトレインに再グループ化し、提供されたセッションセンダーに送り返す必要があります。パケット間隔。
TWAMP connection establishment follows the procedure defined in Section 3.1 of [RFC4656] and Section 3.1 of [RFC5357]. The TWAMP-Control protocol [RFC5357] uses the Modes field to identify and select specific communication capabilities. According to the standard specifications, the Value-Added Octets feature requires one new bit position (and value) to identify the ability of the Server/Session-Reflector to read and act upon the new fields in the value-added octets. Such bit position (and value) is not defined in this memo. Bootstrapping the TWAMP Value-Added Octets Version 1 feature is implementation specific.
TWAMP接続の確立は、[RFC4656]のセクション3.1および[RFC5357]のセクション3.1で定義された手順に従います。 TWAMP制御プロトコル[RFC5357]は、モードフィールドを使用して、特定の通信機能を識別および選択します。標準仕様によると、付加価値オクテット機能では、サーバー/セッションリフレクターが付加価値オクテットの新しいフィールドを読み取って処理する能力を識別するために、1つの新しいビット位置（および値）が必要です。そのようなビット位置（および値）は、このメモでは定義されていません。 TWAMP付加価値オクテットバージョン1機能のブートストラップは、実装固有です。
Both the Reflect Octets mode and Symmetrical Size mode MAY be selected to ensure the reflection of the value-added padding octets by the Session-Reflector and symmetrical size TWAMP-Test packets in the forward and reverse directions of transmission.
リフレクトオクテットモードと対称サイズモードの両方を選択して、セッションリフレクターと対称サイズのTWAMP-テストパケットによる付加価値のあるパディングオクテットの転送を、転送の順方向と逆方向で確実に反映できます。
In the TWAMP control architecture, the TWAMP reflector (server) signals the modes it wishes to operate and the TWAMP controller (control-client) selects the mode or modes supported by the responder. This feature is designed to retain backward compatibility with the original TWAMP-Control and TWAMP-Test protocols. As an alternative, the user may opt for TWAMP Light architecture, which does not require the TWAMP-Control protocol.
TWAMP制御アーキテクチャーでは、TWAMPリフレクター（サーバー）が動作したいモードを通知し、TWAMPコントローラー（制御クライアント）がレスポンダがサポートするモードを選択します。この機能は、元のTWAMP-ControlおよびTWAMP-Testプロトコルとの下位互換性を維持するように設計されています。別の方法として、ユーザーはTWAMP-Controlプロトコルを必要としないTWAMP Lightアーキテクチャを選択できます。
The methods to determine if the Value-Added Octets feature is supported on a TWAMP reflector is implementation specific. When the Value-Added Octets feature is not supported on a TWAMP reflector, the TWAMP controller MUST NOT select the Value-Added Octets feature and MUST NOT include any value-added octets in the test packets. If the TWAMP controller inadvertently sends value-added octets in the test packets to a TWAMP responder that does not support such feature, the TWAMP responder shall treat the value-added octets as regular padding octets and return the test packets as quickly as possible to the Session-Sender as defined in [RFC5357].
付加価値オクテット機能がTWAMPリフレクタでサポートされているかどうかを判断する方法は、実装固有です。付加価値オクテット機能がTWAMPリフレクターでサポートされていない場合、TWAMPコントローラーは付加価値オクテット機能を選択してはならず、テストパケットに付加価値オクテットを含めてはなりません。 TWAMPコントローラがテストパケット内の付加価値オクテットを、そのような機能をサポートしないTWAMPレスポンダに誤って送信した場合、TWAMPレスポンダは、付加価値オクテットを通常のパディングオクテットとして扱い、テストパケットをできるだけ早く[RFC5357]で定義されているセッション送信者。
The forward and reverse APC, TSC, and UDP delivery rate measurement characteristics depend on the size and packet intervals of the test packets. This memo allows variable packet sizes and packet intervals between trains and even between packets in the same train. The functionality is described below.
順方向および逆方向のAPC、TSC、およびUDPの配信速度測定特性は、テストパケットのサイズとパケット間隔に依存します。このメモは、トレイン間の、さらには同じトレイン内のパケット間のパケットサイズとパケット間隔を可変にすることができます。機能については以下で説明します。
The TWAMP-Test protocol carrying the value-added padding octets is identical to TWAMP [RFC5357] except for the definition of the first 10 octets in the Packet Padding that the Session-Sender expects to be reflected. The new octets define fields for Value-Added Octets Version, Flags, Last Sequence Number in Train, and Desired Reverse Packet Interval. Each of these fields are described in detail below.
付加価値パディングオクテットを伝送するTWAMP-Testプロトコルは、Session-Senderが反映されると期待するパケットパディングの最初の10オクテットの定義を除いて、TWAMP [RFC5357]と同じです。新しいオクテットは、付加価値オクテットバージョン、フラグ、トレインの最後のシーケンス番号、および必要な逆パケット間隔のフィールドを定義します。これらの各フィールドについて、以下で詳しく説明します。
The Session-Sender and Session-Reflector behaviors are also modified.
Session-SenderとSession-Reflectorの動作も変更されています。
This section describes the extensions to the behavior of the TWAMP Session-Sender.
このセクションでは、TWAMP Session-Senderの動作に対する拡張機能について説明します。
The Send Schedule is not utilized in TWAMP, and this is unchanged in this memo.
送信スケジュールはTWAMPでは利用されておらず、これはこのメモでは変更されていません。
The Session-Sender packet format follows the same procedure and guidelines as defined in TWAMP [RFC5357] and TWAMP Reflect Octets and Symmetrical Size Features [RFC6038].
セッション送信者パケット形式は、TWAMP [RFC5357]およびTWAMPリフレクトオクテットと対称サイズ機能[RFC6038]で定義されているのと同じ手順とガイドラインに従います。
This feature allows the Session-Sender to set the first few octets in the TWAMP-Test Packet Padding with information to communicate value-added padding version number, flag bits, sequence number of the last packet in a train, and desired reverse packet interval (or per-packet waiting time) for the reverse path direction of transmission.
この機能により、Session-SenderはTWAMP-Test Packet Paddingの最初の数オクテットを、付加価値パディングバージョン番号、フラグビット、トレイン内の最後のパケットのシーケンス番号、および必要なリバースパケットインターバルを通信するための情報で設定できます（またはパケットごとの待機時間）。
The Valued-Added Octets feature must be placed immediately after the TWAMP header or immediately after any new field that could be added to the TWAMP header or added to the beginning of the padding octets in the future. Therefore, the placement of the first bit from the valued-added octets depends on the mode(s) being selected.
付加価値オクテット機能は、TWAMPヘッダーの直後、またはTWAMPヘッダーに追加できる、または将来パディングオクテットの先頭に追加できる新しいフィールドの直後に配置する必要があります。したがって、付加価値オクテットの最初のビットの配置は、選択されているモードによって異なります。
A version number and a sequence of flag bits are defined at the very beginning of the value-added padding octets. The version number identifies the version of the value-added padding octets and meaning of the flag bits and corresponding fields. Each flag bit indicates if a specific field is used in the valued-added padding octets. The version number and flag bits provide an effective method for extracting information at Session-Reflector and Session-Sender. This document defines version 1 with two flag bits: L and I.
バージョン番号と一連のフラグビットは、付加価値パディングオクテットの最初に定義されます。バージョン番号は、付加価値パディングオクテットのバージョンと、フラグビットと対応するフィールドの意味を識別します。各フラグビットは、特定のフィールドが付加価値パディングオクテットで使用されているかどうかを示します。バージョン番号とフラグビットは、Session-ReflectorおよびSession-Senderで情報を抽出するための効果的な方法を提供します。このドキュメントでは、LとIの2つのフラグビットでバージョン1を定義しています。
The format of the test packet depends on the TWAMP modes. The Value-Added Octets Version 1 feature is intended to work with any TWAMP modes.
テストパケットのフォーマットは、TWAMPモードによって異なります。付加価値オクテットバージョン1機能は、すべてのTWAMPモードで機能することを目的としています。
The Session-Sender SHALL use the following TWAMP-Test packet format when the Value-Added Octets Version 1 feature is selected in conjunction with the Unauthenticated mode:
付加価値オクテットバージョン1機能が非認証モードと組み合わせて選択されている場合、セッション送信者は次のTWAMP-Testパケット形式を使用する必要があります（SHALL）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | Ver |L|I| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Seqno In Train |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Desired Reverse Packet Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Packet Padding |
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Session-Sender SHALL use the following TWAMP-Test packet format when the Value-Added Octets Version 1 feature is selected in conjunction with the Unauthenticated mode, Symmetrical Size mode, and Reflect Octets mode:
非認証モード、対称サイズモード、およびリフレクトオクテットモードとともに付加価値オクテットバージョン1機能が選択されている場合、セッション送信者は次のTWAMP-テストパケット形式を使用する必要があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| |
| MBZ (27 octets) |
| |
| |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Ver |L|I| Reserved | Last... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seqno in Train | Desired... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reverse Packet Interval | Additional... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Padding |
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Session-Sender SHALL use the following TWAMP-Test packet format when the Value-Added Octets Version 1 feature is selected in conjunction with the Unauthenticated mode, Symmetrical Size mode, and Reflect Octets mode with a non-zero value in the Server Octets field:
付加価値オクテットバージョン1機能が非認証モード、対称サイズモード、およびサーバーオクテットフィールドにゼロ以外の値を持つリフレクトオクテットモードとともに選択されている場合、セッション送信者は次のTWAMPテストパケット形式を使用する必要があります（SHALL）。 ：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| |
| MBZ (27 octets) |
| |
| |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Server Octets | Ver |L|I|...|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Last Seqno in... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Train | Desired Reverse Packet... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interval | Additional Packet Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In the mode using Reflect Octets illustrated above, the value-added padding octets are embedded in the Packet Padding (to be reflected).
上記のリフレクトオクテットを使用するモードでは、付加価値パディングオクテットがパケットパディングに埋め込まれます（リフレクトされます）。
The Version (Ver) field MUST be encoded in the first 4 bits. It identifies the version number of the value-added padding octets and meaning of the flag bits and the corresponding fields. This memo defines version 1 with two flag bits: L and I. When the Value-Added Octets Version 1 feature is selected, the Session-Sender MUST set the Ver field to 1.
バージョン（Ver）フィールドは最初の4ビットでエンコードする必要があります。これは、付加価値パディングオクテットのバージョン番号と、フラグビットと対応するフィールドの意味を識別します。このメモは、2つのフラグビットLとIでバージョン1を定義します。付加価値オクテットバージョン1機能が選択されている場合、セッション送信者はVerフィールドを1に設定する必要があります。
The 2 bits after the Version field are used for flags: L and I.
バージョンフィールドの後の2ビットは、フラグLおよびIに使用されます。
The Last Seqno in Train bit (L) is the first flag. When the Value-Added Octets Version 1 feature is selected, the Session-Sender MAY set the Last Seqno in Train bit L to 1.
トレインビットの最後のシーケンス番号（L）が最初のフラグです。付加価値オクテットバージョン1機能が選択されている場合、セッション送信者はトレインビットLの最後のシーケンス番号を1に設定できます。
The Desired Reverse Packet Interval bit (I) is the second flag. When the Value-Added Octets Version 1 feature is selected, the Session-Sender MAY set the Desired Reverse Packet Interval bit I to 1.
必要な逆パケット間隔ビット（I）は2番目のフラグです。付加価値オクテットバージョン1機能が選択されている場合、セッション送信者は、希望する逆パケット間隔ビットIを1に設定してもよい（MAY）。
The Reserved field is reserved for future use. All 10 bits of the Reserved field MUST be transmitted as zero by the Session-Sender.
Reservedフィールドは、将来の使用のために予約されています。予約フィールドのすべての10ビットは、セッション送信者によってゼロとして送信される必要があります。
If the Last Seqno in Train bit is set to 1, then the Last Seqno in Train field MUST contain an unsigned 32-bit integer generated by the Session-Sender. It MUST indicate the expected sequence number of the last packet in the train. It SHOULD be used by the Session-Sender and Session-Reflector to identify the train to which a test packet belongs. The packets belonging to a train are determined by observing the test packet Sequence Number in relation to the Last Seqno in Train. The Last Seqno in Train MUST be higher or equal to Sequence Number of the packet. It must also be higher than the Last Seqno in Train for the previous train. If the L bit is set to 0, the Session-Sender shall set all the bits in the Last Seqno in Train field to zero.
列車の最後のシーケンス番号が1に設定されている場合、列車の最後のシーケンス番号フィールドには、セッション送信者によって生成された符号なし32ビット整数が含まれている必要があります。トレインの最後のパケットの予期されるシーケンス番号を示さなければなりません（MUST）。セッションセンダーとセッションリフレクターは、テストパケットが属するトレインを識別するために使用する必要があります。トレインに属するパケットは、トレインの最後のシーケンス番号に関連するテストパケットのシーケンス番号を監視することによって決定されます。トレインの最後のシーケンス番号は、パケットのシーケンス番号以上である必要があります。また、前の列車の列車の最後のシーケンス番号よりも高い必要があります。 Lビットが0に設定されている場合、Session-Senderは、Last Seqno in Trainフィールドのすべてのビットを0に設定します。
If the Desired Reverse Packet Interval bit is set to 1, then the Desired Reverse Packet Interval field MUST contain an unsigned 32 bit integer generated by the Session-Sender. It MUST indicate the desired packet interval (or the waiting time) that the Session-Reflector SHOULD use when transmitting the reflected test packets towards the Session-Sender. The value 0 means the Session-Reflector SHOULD return the test packet to the Session-Sender as quickly as possible. The format of this field MUST be a fractional part of a second as defined in the One-Way Active Measurement Protocol (OWAMP) [RFC4656]. If the I bit is set to 0, the Session-Sender shall set all the bits in the Desired Reverse Packet Interval field to zero.
Desired Reverse Packet Intervalビットが1に設定されている場合、Desired Reverse Packet Intervalフィールドには、Session-Senderによって生成された符号なし32ビット整数が含まれている必要があります。反射されたテストパケットをセッション送信者に送信するときにセッションリフレクタが使用する必要のある望ましいパケット間隔（または待機時間）を示さなければなりません（MUST）。値0は、セッションリフレクターがテストパケットをセッションセンダーにできるだけ早く返す必要があることを意味します。このフィールドのフォーマットは、一方向アクティブ測定プロトコル（OWAMP）[RFC4656]で定義されている秒の小数部分である必要があります。 Iビットが0に設定されている場合、Session-Senderは、Desired Reverse Packet Intervalフィールドのすべてのビットをゼロに設定します。
The values of the above fields are usually provided by a measurement method, tool, or algorithm. This measurement algorithm is outside the scope of this specification.
上記のフィールドの値は、通常、測定方法、ツール、またはアルゴリズムによって提供されます。この測定アルゴリズムは、この仕様の範囲外です。
The TWAMP Session-Reflector follows the procedures and guidelines in Section 4.2 of [RFC5357], with some changes and additional functions.
TWAMP Session-Reflectorは、[RFC5357]のセクション4.2の手順とガイドラインに従い、いくつかの変更と追加機能を備えています。
When the Value-Added Octets Version 1 feature is selected, the behavior of the Session-Reflector SHALL be as follows:
付加価値オクテットバージョン1機能が選択されている場合、Session-Reflectorの動作は次のようになります。
o The Session-Reflector MUST read the Version field. If Ver = 1, the Session-Reflector MUST read the L and I flag bits.
o Session-ReflectorはVersionフィールドを読み取る必要があります。 Ver = 1の場合、Session-ReflectorはLおよびIフラグビットを読み取る必要があります。
o If L=1 and I=1, the Session-Reflector MUST read and extract the information from the Last Seqno in Train field and the Desired Reverse Packet Interval field in the value-added padding octets.
o L = 1およびI = 1の場合、Session-Reflectorは、TrainフィールドのLast Seqnoおよび付加価値パディングオクテットのDesired Reverse Packet Intervalフィールドから情報を読み取り、抽出する必要があります。
- The Last Seqno in Train MUST be compared to Sequence Number in the same packet in order to determine when a complete train has been collected. The Session-Reflector SHOULD buffer the packets belonging to the current train (or store the packet-level performance data). After the last packet of the train has been received, the Session-Reflector SHOULD transmit the packets belonging to a reverse train with a waiting time (packet interval) for each packet indicated in the Desired Reverse Packet Interval field. If the Desired Reverse Packet Interval field is set to zero, then the Session-Reflector SHOULD transmit the packet as quickly as possible. The last packet within a train has Sender Sequence Number = Last Seqno in Train.
- 完全なトレインがいつ収集されたかを判断するために、トレインの最後のシーケンス番号を同じパケットのシーケンス番号と比較する必要があります。 Session-Reflectorは、現在のトレインに属するパケットをバッファリングする必要があります（またはパケットレベルのパフォーマンスデータを格納します）。トレインの最後のパケットが受信された後、Session-Reflectorは、Redesed Reverse Packet Intervalフィールドに示される各パケットの待機時間（パケット間隔）で、リバーストレインに属するパケットを送信する必要があります（SHOULD）。 Desired Reverse Packet Intervalフィールドがゼロに設定されている場合、Session-Reflectorはパケットを可能な限り迅速に送信する必要があります（SHOULD）。トレイン内の最後のパケットには、Sender Sequence Number = Last Seqno in Trainがあります。
- The Last Seqno in Train of a packet MUST also be compared to the Last Seqno in Train of the previous packet in order to determine if a new train needs to be collected. In case of packet loss, the Session-Reflector MUST transmit the incomplete train when it receives a packet with a Last Seqno in Train belonging to another train (e.g., next train) of the test session or after a timeout. The timeout MAY be the REFWAIT timer specified in section 4.2 of [RFC5357].
- 新しいトレインを収集する必要があるかどうかを判断するために、パケットの最後のシーケンス番号を前のパケットの最後のシーケンス番号と比較する必要もあります。パケット損失の場合、セッションリフレクターは、テストセッションの別のトレイン（次のトレインなど）に属するトレインの最後のシーケンス番号を持つパケットを受信したとき、またはタイムアウト後に、不完全なトレインを送信する必要があります。タイムアウトは、[RFC5357]のセクション4.2で指定されているREFWAITタイマーである場合があります。
- Packets arriving out-of-order within a train MUST be buffered at the Session-Reflector if the train is not yet transmitted to the Session-Sender. If the train is already transmitted, the test packet SHOULD be returned to the Session-Sender as quickly as possible. The Session-Reflector MUST NOT reorder the test packets if they happen to arrive out-of-sequence.
- トレインがまだSession-Senderに送信されていない場合、トレイン内で順不同で到着するパケットは、Session-Reflectorでバッファリングされる必要があります。トレインがすでに送信されている場合は、テストパケットをできるだけ早くセッション送信者に返す必要があります（SHOULD）。セッションリフレクターは、テストパケットが順序どおりに到着しない場合、テストパケットの順序を変更してはなりません。
- Duplicate packets within a train MUST be buffered at the Session-Reflector if the train is not yet transmitted to the Session-Sender. If the train is already transmitted, the duplicate test packet SHOULD be returned to the Session-Sender as quickly as possible. The Session-Reflector MUST NOT discard duplicate test packets.
-トレインがまだSession-Senderに送信されていない場合は、トレイン内の重複パケットをSession-Reflectorでバッファリングする必要があります。トレインがすでに送信されている場合は、重複したテストパケットをできるだけ早くセッション送信者に返す必要があります（SHOULD）。 Session-Reflectorは、重複したテストパケットを破棄してはなりません（MUST NOT）。
For any other combinations of the Version field and the L and I flags, the Session-Reflector SHOULD return the test packet to the Session-Sender as quickly as possible.
VersionフィールドとLおよびIフラグの他の組み合わせの場合、Session-Reflectorは、可能な限り迅速にテストパケットをSession-Senderに返す必要があります（SHOULD）。
The Session-Reflector MUST implement the changes described above when the Value-Added Octets Version 1 feature is selected.
付加価値オクテットバージョン1機能が選択されている場合、セッションリフレクターは上記の変更を実装する必要があります。
The Session-Reflector packet format follows the same procedure and guidelines as defined in TWAMP [RFC5357] and TWAMP Reflect Octets and Symmetrical Size Features [RFC6038], with the following changes:
Session-Reflectorパケット形式は、TWAMP [RFC5357]およびTWAMPリフレクトオクテットと対称サイズ機能[RFC6038]で定義されているものと同じ手順とガイドラインに従いますが、次の変更点があります。
o The Session-Reflector MUST reuse (reflect) the value-added padding octets (10 octets) provided in the Sender's Packet Padding.
o セッションリフレクターは、送信者のパケットパディングで提供される付加価値パディングオクテット（10オクテット）を再利用（反映）する必要があります。
o The Session-Reflector MAY reuse the rest of the padding octets in the Sender's Packet Padding.
o セッションリフレクターは、送信者のパケットパディングの残りのパディングオクテットを再利用してもよい（MAY）。
The truncation process [RFC5357] is recommended when the Symmetrical mode is not used. The Session-Reflector MUST truncate exactly 27 octets of padding in Unauthenticated mode and exactly 56 octets in Authenticated and Encrypted modes.
対称モードを使用しない場合は、切り捨てプロセス[RFC5357]をお勧めします。セッションリフレクターは、非認証モードでは正確に27オクテットのパディングを切り捨て、認証モードと暗号化モードでは正確に56オクテットを切り捨てる必要があります。
The Session-Reflector supporting the Value-Added Octets feature should revert back to the standard Session-Reflector behavior if it cannot interpret the value-added padding octets in a given test packet. Section 5.2 also describes such behavior. For instance, the test packet is returned as quickly as possible to the Session-Sender when the Last Seqno in the Train is not what is expected.
付加価値オクテット機能をサポートするセッションリフレクターは、特定のテストパケットの付加価値パディングオクテットを解釈できない場合、標準のセッションリフレクターの動作に戻る必要があります。セクション5.2では、このような動作についても説明しています。たとえば、テストパケットは、トレインの最後のシーケンス番号が予期したものでない場合に、セッションセンダーにできるだけ早く返されます。
Capacity measurements introduce an additional consideration when the test sessions operate in TWAMP Light. When the Session-Reflector does not have knowledge of the session state, the measurement system may be restricted to estimating or calculating the capacity metrics in the forward path direction of transmission only. Capacity measurements in the reverse path direction is best handled with a Session-Reflector supporting knowledge of the session state and being capable of identifying the test packets belonging to a specific test session. A method for creating a session state from the initial test packet may be implemented on the TWAMP Light Session-Reflector. This is outside the scope of this specification.
容量測定では、テストセッションがTWAMPライトで動作するときに、追加の考慮事項が導入されます。セッションリフレクターがセッション状態を認識していない場合、測定システムは、転送の順方向パス方向の容量メトリックの推定または計算のみに制限される場合があります。逆パス方向の容量測定は、セッション状態の知識をサポートし、特定のテストセッションに属するテストパケットを識別できるSession-Reflectorで最適に処理されます。初期テストパケットからセッション状態を作成する方法は、TWAMP Light Session-Reflectorで実装できます。これは、この仕様の範囲外です。
This memo describes the protocol used in the current working prototype implementation of the Value-Added Octets feature in the Ericsson lab. The prototype has been tested in real network environments. The conclusion from these tests is that the Value-Added Octets feature is able to enable estimation of capacity metrics such as available path capacity in both the forward and reverse directions of the network path.
このメモは、Ericssonラボの付加価値オクテット機能の現在作業中のプロトタイプ実装で使用されているプロトコルについて説明しています。プロトタイプは実際のネットワーク環境でテストされています。これらのテストの結論は、付加価値オクテット機能により、ネットワークパスの順方向と逆方向の両方で使用可能なパス容量などの容量メトリックの推定が可能になるということです。
During the experiments with the protocol described in this memo, we have identified a need for the controller and responder to use the same maximum train length. The reflector must be able to buffer the whole train received from the controller. In order to reduce the risk for buffer overrun, the maximum train length should be negotiated. This can be resolved through configuration, introduction of a new field in the value-added octets, or a new maximum train length field in the Request-TW-Session message.
このメモに記載されているプロトコルを使用した実験中に、コントローラーとレスポンダーが同じ最大列車長を使用する必要性を確認しました。リフレクターは、コントローラーから受信したトレイン全体をバッファーできる必要があります。バッファオーバーランのリスクを減らすために、トレインの最大長を交渉する必要があります。これは、構成、付加価値オクテットの新しいフィールドの導入、またはRequest-TW-Sessionメッセージの新しい最大トレイン長フィールドによって解決できます。
The Sender Discriminator (SD) field, which was proposed in an early draft of this document, was removed because of complications with different Session-Reflector implementations. A Session-Reflector may not be able to easily identify the SD field or associate it with a specific Session-Sender, which may skew the test results.
このドキュメントの初期の草案で提案されていたSender Discriminator（SD）フィールドは、さまざまなSession-Reflector実装の複雑さのために削除されました。セッションリフレクターは、SDフィールドを簡単に識別できないか、またはそれを特定のセッション送信者に関連付けることができない場合があり、テスト結果を歪める可能性があります。
The flags defined in the value-added octets now indicate the usage of fields and not the presence of fields. This modification was needed to simplify the responder implementation in the working prototype.
付加価値オクテットで定義されたフラグは、フィールドの使用ではなく、フィールドの使用を示します。この変更は、動作するプロトタイプでのレスポンダー実装を簡素化するために必要でした。
The value-added padding octets permit DoS attacks on the responder host communicating with core TWAMP [RFC5357]. For instance, a DoS condition could arise when the Last Seqno in Train is too large to handle, potentially causing undesirable processing delay or discard of the TWAMP-Test packets. The responder host MUST provide a mechanism to protect or limit the use of its local memory, buffer space, or maximum transmission time for a train.
付加価値パディングオクテットは、コアTWAMP [RFC5357]と通信するレスポンダホストへのDoS攻撃を許可します。たとえば、DoS状態は、TrainのLast Seqnoが大きすぎて処理できない場合に発生し、TWAMP-Testパケットの望ましくない処理遅延または破棄を引き起こす可能性があります。レスポンダーホストは、ローカルメモリ、バッファースペース、またはトレインの最大送信時間の使用を保護または制限するメカニズムを提供する必要があります。
The security considerations that apply to any active measurement of live networks are relevant here as well. See [RFC4656] and [RFC5357].
ライブネットワークのアクティブな測定に適用されるセキュリティの考慮事項は、ここでも関係があります。 [RFC4656]と[RFC5357]を参照してください。
The authors thank Svante Ekelin for providing direction and comments on this document.
著者は、このドキュメントに対する指示とコメントを提供してくれたSvante Ekelinに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, September 2006.
[RFC4656] Shalunov、S.、Teitelbaum、B.、Karp、A.、Boote、J。、およびM. Zekauskas、「A One-way Active Measurement Protocol（OWAMP）」、RFC 4656、2006年9月。
[RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", RFC 5136, February 2008.
[RFC5136] Chimento、P。およびJ. Ishac、「Defining Network Capacity」、RFC 5136、2008年2月。
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, October 2008.
[RFC5357] Hedayat、K.、Krzanowski、R.、Morton、A.、Yum、K。、およびJ. Babiarz、「A Two-Way Active Measurement Protocol（TWAMP）」、RFC 5357、2008年10月。
[RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features", RFC 6038, October 2010.
[RFC6038] Morton、A。およびL. Ciavattone、「Two-Way Active Measurement Protocol（TWAMP）Reflect Octets and Symmetrical Size Features」、RFC 6038、2010年10月。
[ENHJMMB] Ekelin, S., Nilsson, M., Hartikainen, E., Johnsson, A., Mangs, J., Melander, B., and M. Bjorkman, "Real-Time Measurement of End-to-End Available Bandwidth Using Kalman Filtering", Proceedings to the IEEE/IFIP Network Operations and Management Symposium, 2006.
[ENHJMMB] Ekelin、S.、Nilsson、M.、Hartikainen、E.、Johnsson、A.、Mangs、J.、Manderer、B。、およびM. Bjorkman、「エンドツーエンドのリアルタイム測定が利用可能カルマンフィルタリングを使用した帯域幅」、IEEE / IFIPネットワーク運用および管理シンポジウム、2006年の議事録。
[PDM] Dovrolis, C., Ramanathan, P., and D. Moore, "Packet-Dispersion Techniques and a Capacity-Estimation Methodology", IEEE/ACM Transactions on Networking, December 2004.
[PDM] Dovrolis、C.、Ramanathan、P。、およびD. Moore、「Packet-Dispersion Techniques and a Capacity-Estimation Methodology」、IEEE / ACM Transactions on Networking、2004年12月。
[RRBNC] Ribeiro, V., Riedi, R., Baraniuk, R., Navratil, J., and L. Cottrel, "pathChirp: Efficient Available Bandwidth Estimation for Network Paths", Passive and Active Monitoring Workshop, 2003.
[RRBNC] Ribeiro、V.、Riedi、R.、Baraniuk、R.、Navratil、J。、およびL. Cottrel、「pathChirp：Efficient Available Bandwidth Estimation for Network Paths」、パッシブおよびアクティブモニタリングワークショップ、2003。
[SBW] Sommers, J., Barford, P., and W. Willinger, "Laboratory-based Calibration of Available Bandwidth Estimation Tools", Microprocessors and Microsystems, 2007.
[SBW] Sommers、J.、Barford、P。、およびW. Willinger、「利用可能な帯域幅推定ツールの実験室ベースのキャリブレーション」、マイクロプロセッサおよびマイクロシステム、2007年。
[Y1540] International Telecommunications Union, "Internet protocol data communication service - IP packet transfer and availability performance parameters", ITU-T Recommendation Y.1540, 2011.
[Y1540]国際電気通信連合、「インターネットプロトコルデータ通信サービス-IPパケット転送および可用性パフォーマンスパラメータ」、ITU-T勧告Y.1540、2011年。
Authors' Addresses
著者のアドレス
Steve Baillargeon Ericsson 3500 Carling Avenue Ottawa, Ontario K2H 8E9 Canada
Steve Baillargeon Ericsson 3500 Carling Avenueオタワオンタリオ州K2H 8E9カナダ
EMail: steve.baillargeon@ericsson.com
Christofer Flinta Ericsson Farogatan 6 Stockholm, 164 80 Sweden
Christofer Flinta Ericsson Farogatan 6ストックホルム、164 80スウェーデン
EMail: christofer.flinta@ericsson.com
Andreas Johnsson Ericsson Farogatan 6 Stockholm, 164 80 Sweden
Andreas Johnsson Ericsson Farogatan 6ストックホルム、164 80スウェーデン
EMail: andreas.a.johnsson@ericsson.com