[要約] RFC 6777は、一般化されたMPLSおよびMPLS Traffic Engineering（MPLS-TE）ネットワークにおけるラベルスイッチパス（LSP）データパスの遅延メトリックに関する情報を提供しています。このRFCの目的は、LSPのパフォーマンスモニタリングとトラブルシューティングを支援することです。
Internet Engineering Task Force (IETF) W. Sun, Ed.
Request for Comments: 6777 SJTU
Category: Standards Track G. Zhang, Ed.
ISSN: 2070-1721 CATR
J. Gao
Huawei
G. Xie
UC Riverside
R. Papneja
Huawei
November 2012
Label Switched Path (LSP) Data Path Delay Metrics in Generalized MPLS and MPLS Traffic Engineering (MPLS-TE) Networks
一般化MPLSおよびMPLSトラフィックエンジニアリング（MPLS-TE）ネットワークにおけるラベルスイッチドパス（LSP）データパス遅延メトリック
Abstract
概要
When setting up a Label Switched Path (LSP) in Generalized MPLS (GMPLS) and MPLS Traffic Engineering (MPLS-TE) networks, the completion of the signaling process does not necessarily mean that the cross-connection along the LSP has been programmed accordingly and in a timely manner. Meanwhile, the completion of the signaling process may be used by LSP users or applications that control their use as an indication that the data path has become usable. The existence of the inconsistency between the signaling messages and cross-connection programming, and the possible failure of cross-connection programming, if not properly treated, will result in data loss or even application failure. Characterization of this performance can thus help designers to improve the way in which LSPs are used and to make applications or tools that depend on and use LSPs more robust. This document defines a series of performance metrics to evaluate the connectivity of the data path in the signaling process.
汎用MPLS（GMPLS）およびMPLSトラフィックエンジニアリング（MPLS-TE）ネットワークでラベルスイッチドパス（LSP）を設定する場合、シグナリングプロセスの完了は、LSPに沿ったクロス接続がそれに応じてプログラムされていることを必ずしも意味しません。はやくて。一方、シグナリングプロセスの完了は、データパスが使用可能になったことを示すものとして、LSPユーザーまたはアプリケーションの使用を制御するアプリケーションによって使用される場合があります。シグナリングメッセージとクロスコネクトプログラミングの間に不整合が存在し、クロスコネクトプログラミングが失敗すると、適切に処理されないと、データが失われたり、アプリケーションが失敗したりする可能性があります。したがって、このパフォーマンスの特性評価は、設計者がLSPの使用方法を改善し、LSPに依存して使用するアプリケーションまたはツールをより堅牢にするのに役立ちます。このドキュメントでは、シグナリングプロセスにおけるデータパスの接続を評価するための一連のパフォーマンスメトリックを定義しています。
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 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc6777.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6777で入手できます。
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 ....................................................4
2. Conventions Used in This Document ...............................5
3. Overview of Performance Metrics .................................5
4. Terms Used in This Document .....................................6
5. A Singleton Definition for RRFD .................................7
5.1. Motivation .................................................7
5.2. Metric Name ................................................7
5.3. Metric Parameters ..........................................7
5.4. Metric Units ...............................................7
5.5. Definition .................................................8
5.6. Discussion .................................................8
5.7. Methodologies ..............................................9
6. A Singleton Definition for RSRD ................................10
6.1. Motivation ................................................10
6.2. Metric Name ...............................................10
6.3. Metric Parameters .........................................10
6.4. Metric Units ..............................................11
6.5. Definition ................................................11
6.6. Discussion ................................................11
6.7. Methodologies .............................................12
7. A Singleton Definition for PRFD ................................13
7.1. Motivation ................................................13
7.2. Metric Name ...............................................13
7.3. Metric Parameters .........................................13
7.4. Metric Units ..............................................13
7.5. Definition ................................................14
7.6. Discussion ................................................14
7.7. Methodologies .............................................15
8. A Singleton Definition for PSFD ................................16
8.1. Motivation ................................................16
8.2. Metric Name ...............................................16
8.3. Metric Parameters .........................................16
8.4. Metric Units ..............................................16
8.5. Definition ................................................17
8.6. Discussion ................................................17
8.7. Methodologies .............................................18
9. A Singleton Definition for PSRD ................................19
9.1. Motivation ................................................19
9.2. Metric Name ...............................................19
9.3. Metric Parameters .........................................19
9.4. Metric Units ..............................................19
9.5. Definition ................................................20
9.6. Discussion ................................................20
9.7. Methodologies .............................................21
10. A Definition for Samples of Data Path Delay ...................22
10.1. Metric Name ..............................................22
10.2. Metric Parameters ........................................22
10.3. Metric Units .............................................22
10.4. Definition ...............................................22
10.5. Discussion ...............................................23
10.6. Methodologies ............................................23
10.7. Typical Testing Cases ....................................23
10.7.1. With No LSP in the Network ........................23
10.7.2. With a Number of LSPs in the Network ..............24
11. Some Statistics Definitions for Metrics to Report .............24
11.1. The Minimum of the Metric ................................24
11.2. The Median of the Metric .................................24
11.3. The Percentile of the Metric .............................24
11.4. Failure Probability ......................................25
11.4.1. Failure Count .....................................25
11.4.2. Failure Ratio .....................................25
12. Security Considerations .......................................25
13. References ....................................................26
13.1. Normative References .....................................26
13.2. Informative References ...................................26
Appendix A. Acknowledgements ......................................27
Appendix B. Contributors ..........................................28
Label Switched Paths (LSPs) are established, controlled, and allocated for use by management tools or directly by the components that use them. In this document, we call such management tools and the components that use LSPs "applications". Such applications may be Network Management Systems (NMSs); hardware or software components that forward data onto virtual links; programs or tools that use dedicated links; or any other user of an LSP.
ラベルスイッチドパス（LSP）は、管理ツールで使用するために、またはそれらを使用するコンポーネントによって直接、確立、制御、および割り当てられます。このドキュメントでは、このような管理ツールと、LSPを使用するコンポーネントを「アプリケーション」と呼びます。このようなアプリケーションは、ネットワーク管理システム（NMS）です。仮想リンクにデータを転送するハードウェアまたはソフトウェアコンポーネント。専用リンクを使用するプログラムまたはツール。またはLSPの他のユーザー。
Ideally, the completion of the signaling process means that the signaled LSP is ready to carry traffic. However, in actual implementations, vendors may choose to program the cross-connection in a pipelined manner, so that the overall LSP provisioning delay can be reduced. In such situations, the data path may not be ready for use instantly after the signaling process completes. Implementation deficiency may also cause inconsistency between the signaling process and data path provisioning. For example, if the data plane fails to program the cross-connection accordingly but does not manage to report this to the control plane, the signaling process may complete successfully while the corresponding data path will never become functional at all.
理想的には、シグナリングプロセスの完了は、シグナリングされたLSPがトラフィックを伝送する準備ができていることを意味します。ただし、実際の実装では、ベンダーはクロスコネクトをパイプライン方式でプログラムすることを選択できるため、LSPプロビジョニングの全体的な遅延を削減できます。このような状況では、シグナリングプロセスの完了後、データパスがすぐに使用できる状態にならない場合があります。実装の欠陥は、シグナリングプロセスとデータパスプロビジョニングの間の不整合を引き起こす可能性もあります。たとえば、データプレーンがクロスコネクトを適切にプログラムできなかったが、これをコントロールプレーンに報告できない場合、対応するデータパスがまったく機能しなくなる一方で、シグナリングプロセスが正常に完了する場合があります。
On the other hand, the completion of the signaling process may be used in many cases as an indication of data path connectivity. For example, when invoking through the User-Network Interface (UNI) [RFC4208], a client device or an application may use the reception of the correct Resv message as an indication that the data path is fully functional and start to transmit traffic. This will result in data loss or even application failure.
一方、シグナリングプロセスの完了は、多くの場合、データパス接続の指標として使用できます。たとえば、ユーザーネットワークインターフェイス（UNI）[RFC4208]を介して呼び出す場合、クライアントデバイスまたはアプリケーションは、正しいResvメッセージの受信を、データパスが完全に機能しており、トラフィックの送信を開始することを示すものとして使用できます。これにより、データが失われたり、アプリケーション障害が発生したりします。
Although RSVP(-TE) specifications have suggested that the cross-connections are programmed before signaling messages are propagated upstream, it is still worthwhile to verify the conformance of an implementation and measure the delay, when necessary.
RSVP（-TE）仕様では、シグナリングメッセージがアップストリームに伝播される前にクロスコネクトがプログラムされることが推奨されていますが、必要に応じて、実装の適合性を確認し、遅延を測定することは価値があります。
This document defines a series of performance metrics to evaluate the connectivity of the data path during the signaling process. The metrics defined in this document complement the control plane metrics defined in [RFC5814]. These metrics can be used to verify the conformance of implementations against related specifications, as elaborated in [RFC6383]. They also can be used to build more robust applications.
このドキュメントでは、シグナリングプロセス中にデータパスの接続を評価する一連のパフォーマンスメトリックを定義します。このドキュメントで定義されているメトリックは、[RFC5814]で定義されているコントロールプレーンメトリックを補完します。これらのメトリックは、[RFC6383]で詳述されているように、関連する仕様に対する実装の適合性を検証するために使用できます。また、より堅牢なアプリケーションを構築するためにも使用できます。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
In this memo, we define five performance metrics to characterize the performance of data path provisioning with GMPLS/MPLS-TE signaling. These metrics complement the metrics defined in [RFC5814], in the sense that the completion of the signaling process for an LSP and the programming of cross-connections along the LSP may not be consistent. The performance metrics in [RFC5814] characterize the performance of LSP provisioning from the pure signaling point of view, while the metric in this document takes into account the validity of the data path.
このメモでは、GMPLS / MPLS-TEシグナリングによるデータパスプロビジョニングのパフォーマンスを特徴付ける5つのパフォーマンスメトリックを定義します。これらのメトリックは、LSPのシグナリングプロセスの完了とLSPに沿ったクロスコネクトのプログラミングが一致しない可能性があるという意味で、[RFC5814]で定義されたメトリックを補完します。 [RFC5814]のパフォーマンスメトリックは、純粋なシグナリングの観点からのLSPプロビジョニングのパフォーマンスを特徴付けますが、このドキュメントのメトリックはデータパスの有効性を考慮しています。
The five metrics are:
5つのメトリックは次のとおりです。
o Resv Received, Forward Data (RRFD) - the delay between the point when the Resv message is received by the ingress node and the forward data path becomes ready for use.
o Resv受信、転送データ（RRFD）-入力ノードがResvメッセージを受信してから、転送データパスを使用できるようになるまでの遅延。
o Resv Sent, Reverse Data (RSRD) - the delay between the point when the Resv message is sent by the egress node and the reverse data path becomes ready for use.
o Resv Sent、Reverse Data（RSRD）-出力ノードによってResvメッセージが送信されてからリバースデータパスが使用可能になるまでの遅延。
o PATH Received, Forward Data (PRFD) - the delay between the point when the PATH message is received by the egress node and the forward data path becomes ready for use.
o PATH Received、Forward Data（PRFD）-出口メッセージがPATHメッセージを受信してから、転送データパスを使用できるようになるまでの遅延。
o PATH Sent, Forward Data (PSFD) - the delay between the point when the PATH message is sent by the ingress node and the forward data path becomes ready for use.
o PATH Sent、Forward Data（PSFD）-入力ノードによってPATHメッセージが送信されてから、転送データパスが使用可能になるまでの遅延。
o PATH Sent, Reverse Data (PSRD) - the delay between the point when the PATH message is sent by the ingress node and the reverse data path becomes ready for use.
o PATH Sent、Reverse Data（PSRD）-入力ノードによってPATHメッセージが送信されてから、リバースデータパスが使用可能になるまでの遅延。
As in [RFC5814], we continue to use the structures and notions introduced and discussed in the IP Performance Metrics (IPPM) Framework documents [RFC2330] [RFC2679] [RFC2681]. The reader is assumed to be familiar with the notions in those documents. The reader is also assumed to be familiar with the definitions in [RFC5814].
[RFC5814]と同様に、IPパフォーマンスメトリック（IPPM）フレームワークドキュメント[RFC2330] [RFC2679] [RFC2681]で導入および説明されている構造と概念を引き続き使用します。読者は、これらのドキュメントの概念に精通していることを前提としています。また、読者は[RFC5814]の定義に精通していることを前提としています。
o Forward data path - the data path from the ingress node to the egress node. Instances of a forward data path include the data path of a unidirectional LSP and a data path from the ingress node to the egress node in a bidirectional LSP.
o 転送データパス-入力ノードから出力ノードへのデータパス。フォワードデータパスのインスタンスには、単方向LSPのデータパスと、双方向LSPの入口ノードから出口ノードへのデータパスが含まれます。
o Reverse data path - the data path from the egress node to the ingress node in a bidirectional LSP.
o リバースデータパス-双方向LSPの出口ノードから入口ノードへのデータパス。
o Data path delay - the time needed to complete the data path configuration, in relation to the signaling process. Five types of data path delay are defined in this document, namely RRFD, RSRD, PRFD, PSFD, and PSRD. Data path delay as used in this document must be distinguished from the transmission delay along the data path, i.e., the time needed to transmit traffic from one side of the data path to the other.
o データパス遅延-シグナリングプロセスに関連して、データパス構成を完了するのに必要な時間。このドキュメントでは、RRFD、RSRD、PRFD、PSFD、PSRDの5種類のデータパス遅延が定義されています。このドキュメントで使用されているデータパス遅延は、データパスに沿った伝送遅延、つまり、データパスの一方の側から他方の側にトラフィックを送信するために必要な時間と区別する必要があります。
o Error-free signal - data-plane-specific indication of connectivity of the data path. For example, for interfaces capable of packet switching, the reception of the first error-free packet from one side of the LSP to the other may be used as the error-free signal. For Synchronous Digital Hierarchy/Synchronous Optical Network (SDH/SONET) cross-connects, the disappearance of alarm can be used as the error-free signal. Throughout this document, we will use "error-free signal" as a general term. An implementation must choose a proper data path signal that is specific to the data path technology being tested.
o エラーのない信号-データパスの接続性のデータプレーン固有の表示。たとえば、パケット交換が可能なインターフェイスの場合、LSPの一方の側からもう一方の側への最初のエラーのないパケットの受信を、エラーのない信号として使用できます。同期デジタル階層/同期光ネットワーク（SDH / SONET）クロスコネクトの場合、アラームの消失をエラーのない信号として使用できます。このドキュメントでは、「エラーのない信号」を一般的な用語として使用します。実装では、テストするデータパステクノロジに固有の適切なデータパス信号を選択する必要があります。
o Ingress/egress node - in this memo, an ingress/egress node means a measurement endpoint with both control plane and data plane features. Typically, the control plane part on an ingress/egress node interacts with the control plane of the network under test. The data plane part of an ingress/egress node will generate data path signals and send the signal to the data plane of the network under test, or receive data path signals from the network under test.
o 入力/出力ノード-このメモでは、入力/出力ノードは、コントロールプレーンとデータプレーンの両方の機能を持つ測定エンドポイントを意味します。通常、入力/出力ノードのコントロールプレーンパーツは、テスト中のネットワークのコントロールプレーンと相互作用します。入力/出力ノードのデータプレーン部分は、データパス信号を生成して、テスト中のネットワークのデータプレーンに信号を送信するか、テスト中のネットワークからデータパス信号を受信します。
This part defines a metric for forward data path delay when an LSP is set up.
この部分では、LSPが設定されている場合の転送データパス遅延のメトリックを定義します。
As described in [RFC6383], the completion of the RSVP-TE signaling process does not necessarily mean that the cross-connections along the LSP being set up are in place and ready to carry traffic. This metric defines the time difference between the reception of a Resv message by the ingress node and the completion of the cross-connection programming along the forward data path.
[RFC6383]で説明されているように、RSVP-TEシグナリングプロセスが完了しても、セットアップ中のLSPに沿ったクロスコネクトが確立され、トラフィックを伝送する準備ができているとは限りません。このメトリックは、入口ノードによるResvメッセージの受信と、フォワードデータパスに沿ったクロスコネクトプログラミングの完了との時間差を定義します。
RRFD is useful for the following reasons:
RRFDは、次の理由で役立ちます。
o For the reasons described in [RFC6383], the data path may not be ready for use instantly after the completion of the RSVP-TE signaling process. The delay itself is part of the implementation performance.
o [RFC6383]で説明されている理由により、RSVP-TEシグナリングプロセスの完了後、データパスがすぐに使用できる状態にならない場合があります。遅延自体は実装パフォーマンスの一部です。
o The completion of the signaling process may be used by application designers as an indication of data path connectivity. The existence of this delay and the potential failure of cross-connection programming, if not properly treated, will result in data loss or application failure. The typical value of this delay can thus help designers to improve the application model.
o シグナリングプロセスの完了は、アプリケーション設計者がデータパス接続の指標として使用できます。この遅延の存在とクロスコネクトプログラミングの潜在的な障害は、適切に処理されないと、データの損失やアプリケーションの障害につながります。したがって、この遅延の一般的な値は、設計者がアプリケーションモデルを改善するのに役立ちます。
RRFD = Resv Received, Forward Data path
RRFD = Resv Received、Forward Data Path
o ID0, the ingress Label Switching Router (LSR) ID
o ID0、入力ラベルスイッチングルータ（LSR）ID
o ID1, the egress LSR ID
o ID1、出力LSR ID
o T, a time when the setup is attempted
o T、セットアップが試行された時間
The value of RRFD is either a real number of milliseconds or undefined.
RRFDの値は、実際のミリ秒数か未定義です。
For a real number dT,
実数dTの場合、
RRFD from ingress node ID0 to egress node ID1 at T is dT
入力ノードID0からTでの出力ノードID1へのRRFDはdTです。
means that
という意味です
o ingress node ID0 sends a PATH message to egress node ID1,
o 入力ノードID0はPATHメッセージを出力ノードID1に送信します
o the last bit of the corresponding Resv message is received by ingress node ID0 at T, and
o 対応するResvメッセージの最後のビットは、Tで入口ノードID0によって受信されます。
o an error-free signal is received by egress node ID1 by using a data-plane-specific test pattern at T+dT.
o エラーのない信号は、T + dTでデータプレーン固有のテストパターンを使用して、出口ノードID1によって受信されます。
The following issues are likely to come up in practice:
実際には次の問題が発生する可能性があります。
o The accuracy of RRFD depends on the clock resolution of both the ingress node and egress node. Clock synchronization between the ingress node and egress node is required.
o RRFDの精度は、入力ノードと出力ノードの両方のクロック分解能に依存します。入力ノードと出力ノード間のクロック同期が必要です。
o The accuracy of RRFD is also dependent on how the error-free signal is received and may differ significantly when the underlying data plane technology is different. For instance, for an LSP between a pair of Ethernet interfaces, the ingress node may use a rate-based method to verify the connectivity of the data path and use the reception of the first error-free frame as the error-free signal. In this case, the interval between two successive frames has a significant impact on accuracy. It is RECOMMENDED that the ingress node use small intervals, under the condition that the injected traffic does not exceed the capacity of the forward data path. The value of such intervals MUST be reported.
o RRFDの精度は、エラーのない信号の受信方法にも依存し、基礎となるデータプレーンテクノロジーが異なる場合は大きく異なる可能性があります。たとえば、イーサネットインターフェイスのペア間のLSPの場合、入力ノードはレートベースの方法を使用してデータパスの接続を確認し、最初のエラーのないフレームの受信をエラーのない信号として使用できます。この場合、2つの連続するフレーム間の間隔は、精度に大きな影響を与えます。注入されたトラフィックが転送データパスの容量を超えないという条件下で、入口ノードが短い間隔を使用することをお勧めします。そのような間隔の値は報告されなければなりません。
o The accuracy of RRFD is also dependent on the time needed to propagate the error-free signal from the ingress node to the egress node. A typical value for propagating the error-free signal from the ingress node to the egress node under the same measurement setup MAY be reported. The methodology to obtain such values is outside the scope of this document.
o RRFDの精度は、エラーのない信号を入力ノードから出力ノードに伝搬するのに必要な時間にも依存します。同じ測定設定の下で入力ノードから出力ノードにエラーのない信号を伝搬するための典型的な値が報告される場合があります。このような値を取得する方法は、このドキュメントの範囲外です。
o The accuracy of this metric is also dependent on the physical-layer serialization/deserialization of the test signal for certain data path technologies. For instance, for an LSP between a pair of low-speed Ethernet interfaces, the time needed to serialize/ deserialize a large frame may not be negligible. In this case, it is RECOMMENDED that the ingress node use small frames. The average length of the frame MAY be reported.
oこのメトリックの精度は、特定のデータパステクノロジのテスト信号の物理層シリアル化/非シリアル化にも依存します。たとえば、一対の低速イーサネットインターフェイス間のLSPの場合、大きなフレームをシリアル化/非シリアル化するために必要な時間は無視できない場合があります。この場合、入口ノードで小さなフレームを使用することをお勧めします。フレームの平均の長さが報告される場合があります。
o It is possible that under some implementations, a node may program the cross-connection before it sends a PATH message further downstream, and the data path may be ready for use before a Resv message reaches the ingress node. In such cases, RRFD can be a negative value. It is RECOMMENDED that a PRFD measurement be carried out to further characterize the forward data path delay when a negative RRFD value is observed.
o 一部の実装では、ノードがPATHメッセージをさらに下流に送信する前にノードがクロスコネクトをプログラムし、Resvメッセージが入力ノードに到達する前にデータパスを使用できるようになる場合があります。このような場合、RRFDは負の値になることがあります。負のRRFD値が観測された場合、順方向データパス遅延をさらに特徴付けるためにPRFD測定を実行することをお勧めします。
o If an error-free signal is received by the egress node before a PATH message is sent on the ingress node, an error MUST be reported and the measurement SHOULD terminate.
o 入力ノードでPATHメッセージが送信される前にエラーのない信号が出力ノードによって受信された場合、エラーを報告する必要があり、測定を終了する必要があります（SHOULD）。
o If the corresponding Resv message is received but no error-free signal is received by the egress node within a reasonable period of time, i.e., a threshold, RRFD MUST be treated as undefined. The value of the threshold MUST be reported.
o 対応するResvメッセージが受信されたが、妥当な時間内、つまりしきい値内でエラーのない信号が出口ノードによって受信されない場合、RRFDは未定義として扱われなければなりません（MUST）。しきい値の値を報告する必要があります。
o If the LSP setup fails, this metric value MUST NOT be counted.
o LSPセットアップが失敗した場合、このメトリック値をカウントしてはなりません（MUST NOT）。
Generally, the methodology would proceed as follows:
一般に、方法論は次のように進行します。
o Make sure that the network has enough resources to set up the requested LSP.
o ネットワークに、要求されたLSPをセットアップするのに十分なリソースがあることを確認してください。
o Start the data path measurement and/or monitoring procedures on the ingress node and egress node. If an error-free signal is received by the egress node before a PATH message is sent, report an error and terminate the measurement.
o 入力ノードと出力ノードでデータパスの測定と監視の手順を開始します。 PATHメッセージが送信される前にエラーのない信号が出力ノードによって受信された場合、エラーを報告して測定を終了します。
o At the ingress node, form the PATH message according to the LSP requirements and send the message towards the egress node.
o 入力ノードで、LSP要件に従ってPATHメッセージを形成し、メッセージを出力ノードに送信します。
o Upon receiving the last bit of the corresponding Resv message, take the timestamp (T1) on the ingress node as soon as possible.
o 対応するResvメッセージの最後のビットを受信したら、できるだけ早く入力ノードのタイムスタンプ（T1）を取得します。
o When an error-free signal is observed on the egress node, take the timestamp (T2) as soon as possible. An estimate of RRFD (T2 - T1) can be computed.
o 出力ノードでエラーのない信号が確認されたら、できるだけ早くタイムスタンプ（T2）を取得します。 RRFD（T2-T1）の推定値を計算できます。
o If the corresponding Resv message arrives but no error-free signal is received within a reasonable period of time by the ingress node, RRFD is deemed to be undefined.
o 対応するResvメッセージが到着したが、入力ノードによって妥当な期間内にエラーのない信号が受信されなかった場合、RRFDは未定義と見なされます。
o If the LSP setup fails, RRFD is not counted.
o LSPセットアップが失敗した場合、RRFDはカウントされません。
This part defines a metric for reverse data path delay when an LSP is set up.
この部分では、LSPが設定されている場合の逆データパス遅延のメトリックを定義します。
As described in [RFC6383], the completion of the RSVP-TE signaling process does not necessarily mean that the cross-connections along the LSP being set up are in place and ready to carry traffic. This metric defines the time difference between the completion of the signaling process and the completion of the cross-connection programming along the reverse data path. This metric MAY be used together with RRFD to characterize the data path delay of a bidirectional LSP.
[RFC6383]で説明されているように、RSVP-TEシグナリングプロセスが完了しても、セットアップ中のLSPに沿ったクロスコネクトが確立され、トラフィックを伝送する準備ができているとは限りません。このメトリックは、シグナリングプロセスの完了と、リバースデータパスに沿ったクロスコネクトプログラミングの完了との時間差を定義します。このメトリックは、双方向LSPのデータパス遅延を特徴付けるためにRRFDと一緒に使用される場合があります。
RSRD is useful for the following reasons:
RSRDは、次の理由で役立ちます。
o For the reasons described in [RFC6383], the data path may not be ready for use instantly after the completion of the RSVP-TE signaling process. The delay itself is part of the implementation performance.
o [RFC6383]で説明されている理由により、RSVP-TEシグナリングプロセスの完了後、データパスがすぐに使用できる状態にならない場合があります。遅延自体は実装パフォーマンスの一部です。
o The completion of the signaling process may be used by application designers as an indication of data path connectivity. The existence of this delay and the possible failure of cross-connection programming, if not properly treated, will result in data loss or application failure. The typical value of this delay can thus help designers to improve the application model.
o シグナリングプロセスの完了は、アプリケーション設計者がデータパス接続の指標として使用できます。この遅延が存在し、クロスコネクトプログラミングが失敗する可能性があると、適切に処理されないと、データの損失やアプリケーションの障害が発生します。したがって、この遅延の一般的な値は、設計者がアプリケーションモデルを改善するのに役立ちます。
RSRD = Resv Sent, Reverse Data path
RSRD = Resv Sent、Reverse Data Path
o ID0, the ingress LSR ID
o ID0、入力LSR ID
o ID1, the egress LSR ID
o ID1、出力LSR ID
o T, a time when the setup is attempted
o T、セットアップが試行された時間
The value of RSRD is either a real number of milliseconds or undefined.
RSRDの値は、実際のミリ秒数か未定義です。
For a real number dT,
実数dTの場合、
RSRD from ingress node ID0 to egress node ID1 at T is dT
入力ノードID0からTでの出力ノードID1へのRSRDはdTです。
means that
という意味です
o ingress node ID0 sends a PATH message to egress node ID1,
o 入力ノードID0はPATHメッセージを出力ノードID1に送信します
o the last bit of the corresponding Resv message is sent by egress node ID1 at T, and
o 対応するResvメッセージの最後のビットは、Tで出口ノードID1によって送信されます。
o an error-free signal is received by the ingress node ID0 using a data-plane-specific test pattern at T+dT.
o エラーのない信号は、T + dTでデータプレーン固有のテストパターンを使用して、イングレスノードID0によって受信されます。
The following issues are likely to come up in practice:
実際には次の問題が発生する可能性があります。
o The accuracy of RSRD depends on the clock resolution of both the ingress node and egress node. Clock synchronization between the ingress node and egress node is required.
o RSRDの精度は、入力ノードと出力ノードの両方のクロック分解能に依存します。入力ノードと出力ノード間のクロック同期が必要です。
o The accuracy of RSRD is also dependent on how the error-free signal is received and may differ significantly when the underlying data plane technology is different. For instance, for an LSP between a pair of Ethernet interfaces, the egress node (sometimes the tester) may use a rate-based method to verify the connectivity of the data path and use the reception of the first error-free frame as the error-free signal. In this case, the interval between two successive frames has a significant impact on accuracy. It is RECOMMENDED in this case that the egress node use small intervals, under the condition that the injected traffic does not exceed the capacity of the reverse data path. The value of the interval MUST be reported.
o RSRDの精度は、エラーのない信号の受信方法にも依存し、基礎となるデータプレーンテクノロジーが異なる場合は大きく異なる可能性があります。たとえば、イーサネットインターフェイスのペア間のLSPの場合、出力ノード（テスターの場合もあります）は、レートベースの方法を使用してデータパスの接続を確認し、最初のエラーのないフレームの受信をエラーとして使用します。 -無料の信号。この場合、2つの連続するフレーム間の間隔は、精度に大きな影響を与えます。この場合、注入されたトラフィックがリバースデータパスの容量を超えないという条件下で、出力ノードが短い間隔を使用することをお勧めします。間隔の値を報告する必要があります。
o The accuracy of RSRD is also dependent on the time needed to propagate the error-free signal from the egress node to the ingress node. A typical value for propagating the error-free signal from the egress node to the ingress node under the same measurement setup MAY be reported. The methodology to obtain such values is outside the scope of this document.
o RSRDの精度は、エラーのない信号を出力ノードから入力ノードに伝搬するのに必要な時間にも依存します。同じ測定設定の下で出口ノードから入口ノードにエラーのない信号を伝搬するための典型的な値が報告される場合があります。このような値を取得する方法は、このドキュメントの範囲外です。
o The accuracy of this metric is also dependent on the physical-layer serialization/deserialization of the test signal for certain data path technologies. For instance, for an LSP between a pair of low-speed Ethernet interfaces, the time needed to serialize/ deserialize a large frame may not be negligible. In this case, it is RECOMMENDED that the egress node use small frames. The average length of the frame MAY be reported.
o このメトリックの精度は、特定のデータパステクノロジのテスト信号の物理層シリアル化/非シリアル化にも依存します。たとえば、一対の低速イーサネットインターフェイス間のLSPの場合、大きなフレームをシリアル化/非シリアル化するために必要な時間は無視できない場合があります。この場合、出力ノードが小さなフレームを使用することが推奨されます。フレームの平均の長さが報告される場合があります。
o If the corresponding Resv message is sent but no error-free signal is received by the ingress node within a reasonable period of time, i.e., a threshold, RSRD MUST be treated as undefined. The value of the threshold MUST be reported.
o 対応するResvメッセージが送信されても、妥当な時間内、つまりしきい値内でエラーのない信号が入口ノードによって受信されない場合、RSRDは未定義として扱われなければなりません（MUST）。しきい値の値を報告する必要があります。
o If an error-free signal is received before a PATH message is sent on the ingress node, an error MUST be reported and the measurement SHOULD terminate.
o 入力ノードでPATHメッセージが送信される前にエラーのない信号を受信した場合、エラーを報告する必要があり、測定を終了する必要があります（SHOULD）。
o If the LSP setup fails, this metric value MUST NOT be counted.
o LSPセットアップが失敗した場合、このメトリック値をカウントしてはなりません（MUST NOT）。
Generally, the methodology would proceed as follows:
一般に、方法論は次のように進行します。
o Make sure that the network has enough resources to set up the requested LSP.
o ネットワークに、要求されたLSPをセットアップするのに十分なリソースがあることを確認してください。
o Start the data path measurement and/or monitoring procedures on the ingress node and egress node. If an error-free signal is received by the ingress node before a PATH message is sent, report an error and terminate the measurement.
o 入力ノードと出力ノードでデータパスの測定と監視の手順を開始します。 PATHメッセージが送信される前にエラーのない信号が入力ノードによって受信された場合、エラーを報告して測定を終了します。
o At the ingress node, form the PATH message according to the LSP requirements and send the message towards the egress node.
o 入力ノードで、LSP要件に従ってPATHメッセージを形成し、メッセージを出力ノードに送信します。
o Upon sending the last bit of the corresponding Resv message, take the timestamp (T1) on the egress node as soon as possible.
o 対応するResvメッセージの最後のビットを送信したら、出力ノードのタイムスタンプ（T1）をできるだけ早く取得します。
o When an error-free signal is observed on the ingress node, take the timestamp (T2) as soon as possible. An estimate of RSRD (T2 - T1) can be computed.
o 入力ノードでエラーのない信号が確認されたら、できるだけ早くタイムスタンプ（T2）を取得します。 RSRD（T2-T1）の推定値を計算できます。
o If the LSP setup fails, RSRD is not counted.
o LSPセットアップが失敗した場合、RSRDはカウントされません。
o If no error-free signal is received within a reasonable period of time by the ingress node, RSRD is deemed to be undefined.
o 入力ノードが妥当な期間内にエラーのない信号を受信しない場合、RSRDは未定義と見なされます。
This part defines a metric for forward data path delay when an LSP is set up.
この部分では、LSPが設定されている場合の転送データパス遅延のメトリックを定義します。
In an RSVP-TE implementation, when setting up an LSP, each node may choose to program the cross-connection before it sends a PATH message further downstream. In this case, the forward data path may become ready for use before the signaling process completes, i.e., before the Resv message reaches the ingress node. This metric can be used to identify such an implementation practice and give useful information to application designers.
RSVP-TEの実装では、LSPを設定するときに、各ノードはPATHメッセージをさらに下流に送信する前に、クロスコネクトをプログラムすることを選択できます。この場合、転送データパスは、シグナリングプロセスが完了する前、つまりResvメッセージが入力ノードに到達する前に、使用できる状態になる場合があります。このメトリックは、そのような実装方法を特定し、アプリケーション設計者に有用な情報を提供するために使用できます。
PRFD is useful for the following reasons:
PRFDは次の理由で役立ちます。
o PRFD can be used to identify an RSVP-TE implementation practice in which cross-connections are programmed before a PATH message is sent downstream.
o PRFDを使用すると、PATHメッセージがダウンストリームに送信される前にクロスコネクトがプログラムされるRSVP-TEの実装方法を識別できます。
o The value of PRFD may also help application designers to fine-tune their application model.
o PRFDの価値は、アプリケーション設計者がアプリケーションモデルを微調整するのにも役立ちます。
PRFD = PATH Received, Forward Data path
PRFD = PATH受信、転送データパス
o ID0, the ingress LSR ID
o ID0、入力LSR ID
o ID1, the egress LSR ID
o ID1、出力LSR ID
o T, a time when the setup is attempted
o T、セットアップが試行された時間
The value of PRFD is either a real number of milliseconds or undefined.
PRFDの値は、実際のミリ秒数または未定義です。
For a real number dT,
実数dTの場合、
PRFD from ingress node ID0 to egress node ID1 at T is dT
Tでの入口ノードID0から出口ノードID1へのPRFDはdTです。
means that
という意味です
o ingress node ID0 sends a PATH message to egress node ID1,
o 入力ノードID0はPATHメッセージを出力ノードID1に送信します
o the last bit of the PATH message is received by egress node ID1 at T, and
o PATHメッセージの最後のビットは、Tで出口ノードID1によって受信されます。
o an error-free signal is received by the egress node ID1 using a data-plane-specific test pattern at T+dT.
o エラーのない信号は、T + dTでデータプレーン固有のテストパターンを使用して、出口ノードID1によって受信されます。
The following issues are likely to come up in practice:
実際には次の問題が発生する可能性があります。
o The accuracy of PRFD depends on the clock resolution of the egress node. Clock synchronization between the ingress node and egress node is not required.
o PRFDの精度は、出力ノードのクロック分解能に依存します。入力ノードと出力ノード間のクロック同期は必要ありません。
o The accuracy of PRFD is also dependent on how the error-free signal is received and may differ significantly when the underlying data plane technology is different. For instance, for an LSP between a pair of Ethernet interfaces, the egress node (sometimes the tester) may use a rate-based method to verify the connectivity of the data path and use the reception of the first error-free frame as the error-free signal. In this case, the interval between two successive frames has a significant impact on accuracy. It is RECOMMENDED in this case that the ingress node use small intervals, under the condition that the injected traffic does not exceed the capacity of the forward data path. The value of the interval MUST be reported.
o PRFDの精度は、エラーのない信号の受信方法にも依存し、基礎となるデータプレーンテクノロジーが異なる場合は大きく異なる可能性があります。たとえば、イーサネットインターフェイスのペア間のLSPの場合、出力ノード（テスターの場合もあります）は、レートベースの方法を使用してデータパスの接続を確認し、最初のエラーのないフレームの受信をエラーとして使用します。 -無料の信号。この場合、2つの連続するフレーム間の間隔は、精度に大きな影響を与えます。この場合、注入されたトラフィックが転送データパスの容量を超えないという条件下で、入口ノードが短い間隔を使用することをお勧めします。間隔の値を報告する必要があります。
o The accuracy of PRFD is also dependent on the time needed to propagate the error-free signal from the ingress node to the egress node. A typical value for propagating the error-free signal from the ingress node to the egress node under the same measurement setup MAY be reported. The methodology to obtain such values is outside the scope of this document.
o PRFDの精度は、エラーのない信号を入力ノードから出力ノードに伝搬するのに必要な時間にも依存します。同じ測定設定の下で入力ノードから出力ノードにエラーのない信号を伝搬するための典型的な値が報告される場合があります。このような値を取得する方法は、このドキュメントの範囲外です。
o The accuracy of this metric is also dependent on the physical-layer serialization/deserialization of the test signal for certain data path technologies. For instance, for an LSP between a pair of low-speed Ethernet interfaces, the time needed to serialize/ deserialize a large frame may not be negligible. In this case, it is RECOMMENDED that the ingress node use small frames. The average length of the frame MAY be reported.
oこのメトリックの精度は、特定のデータパステクノロジのテスト信号の物理層シリアル化/非シリアル化にも依存します。たとえば、一対の低速イーサネットインターフェイス間のLSPの場合、大きなフレームをシリアル化/非シリアル化するために必要な時間は無視できない場合があります。この場合、入口ノードで小さなフレームを使用することをお勧めします。フレームの平均の長さが報告される場合があります。
o If an error-free signal is received before a PATH message is sent, an error MUST be reported and the measurement SHOULD terminate.
o PATHメッセージが送信される前にエラーのない信号が受信された場合は、エラーを報告する必要があり、測定を終了する必要があります（SHOULD）。
o If the LSP setup fails, this metric value MUST NOT be counted.
o LSPセットアップが失敗した場合、このメトリック値をカウントしてはなりません（MUST NOT）。
o This metric SHOULD be used together with RRFD. It is RECOMMENDED that a PRFD measurement be carried out after a negative RRFD value has already been observed.
o このメトリックは、RRFDとともに使用する必要があります（SHOULD）。負のRRFD値がすでに観測された後で、PRFD測定を実行することをお勧めします。
Generally, the methodology would proceed as follows:
一般に、方法論は次のように進行します。
o Make sure that the network has enough resources to set up the requested LSP.
o ネットワークに、要求されたLSPをセットアップするのに十分なリソースがあることを確認してください。
o Start the data path measurement and/or monitoring procedures on the ingress node and egress node. If an error-free signal is received by the egress node before a PATH message is sent, report an error and terminate the measurement.
o 入力ノードと出力ノードでデータパスの測定と監視の手順を開始します。 PATHメッセージが送信される前にエラーのない信号が出力ノードによって受信された場合、エラーを報告して測定を終了します。
o At the ingress node, form the PATH message according to the LSP requirements and send the message towards the egress node.
o 入力ノードで、LSP要件に従ってPATHメッセージを形成し、メッセージを出力ノードに送信します。
o Upon receiving the last bit of the PATH message, take the timestamp (T1) on the egress node as soon as possible.
o PATHメッセージの最後のビットを受信したら、できるだけ早く出力ノードのタイムスタンプ（T1）を取得します。
o When an error-free signal is observed on the egress node, take the timestamp (T2) as soon as possible. An estimate of PRFD (T2 - T1) can be computed.
o 出力ノードでエラーのない信号が確認されたら、できるだけ早くタイムスタンプ（T2）を取得します。 PRFD（T2-T1）の推定値を計算できます。
o If the LSP setup fails, PRFD is not counted.
o LSPセットアップが失敗した場合、PRFDはカウントされません。
o If no error-free signal is received within a reasonable period of time by the egress node, PRFD is deemed to be undefined.
o エラーのない信号が妥当な期間内に出力ノードによって受信されない場合、PRFDは未定義と見なされます。
This part defines a metric for forward data path delay when an LSP is set up.
この部分では、LSPが設定されている場合の転送データパス遅延のメトリックを定義します。
As described in [RFC6383], the completion of the RSVP-TE signaling process does not necessarily mean that the cross-connections along the LSP being set up are in place and ready to carry traffic. This metric defines the time difference between the point when the PATH message is sent by the ingress node and the completion of the cross-connection programming along the LSP forward data path.
[RFC6383]で説明されているように、RSVP-TEシグナリングプロセスが完了しても、セットアップ中のLSPに沿ったクロスコネクトが確立され、トラフィックを伝送する準備ができているとは限りません。このメトリックは、PATHノードが入力ノードによって送信された時点と、LSP転送データパスに沿ったクロスコネクトプログラミングの完了との時間差を定義します。
PSFD is useful for the following reasons:
PSFDは次の理由で役立ちます。
o For the reasons described in [RFC6383], the data path setup delay may not be consistent with the control plane LSP setup delay. The data path setup delay metric is more precise for LSP setup performance measurement.
o [RFC6383]で説明されている理由により、データパスのセットアップ遅延は、コントロールプレーンのLSPセットアップ遅延と一致しない場合があります。 LSPセットアップパフォーマンス測定では、データパスセットアップ遅延メトリックがより正確です。
o The completion of the signaling process may be used by application designers as an indication of data path connectivity. The difference between the control plane setup delay and data path delay, and the potential failure of cross-connection programming, if not properly treated, will result in data loss or application failure. This metric can thus help designers to improve the application model.
o シグナリングプロセスの完了は、アプリケーション設計者がデータパス接続の指標として使用できます。コントロールプレーンのセットアップ遅延とデータパス遅延の違い、およびクロスコネクトプログラミングの潜在的な障害が適切に処理されないと、データの損失またはアプリケーションの障害が発生します。したがって、このメトリックは、設計者がアプリケーションモデルを改善するのに役立ちます。
PSFD = PATH Sent, Forward Data path
PSFD = PATH送信、転送データパス
o ID0, the ingress LSR ID
o ID0、入力LSR ID
o ID1, the egress LSR ID
o ID1、出力LSR ID
o T, a time when the setup is attempted
o T、セットアップが試行された時間
The value of PSFD is either a real number of milliseconds or undefined.
PSFDの値は、実際のミリ秒数か未定義です。
For a real number dT,
実数dTの場合、
PSFD from ingress node ID0 to egress node ID1 at T is dT
入力ノードID0からTでの出力ノードID1へのPSFDはdTです。
means that
という意味です
o ingress node ID0 sends the first bit of a PATH message to egress node ID1 at T, and
o 入力ノードID0は、PATHメッセージの最初のビットをTで出力ノードID1に送信し、
o an error-free signal is received by the egress node ID1 using a data-plane-specific test pattern at T+dT.
o エラーのない信号は、T + dTでデータプレーン固有のテストパターンを使用して、出口ノードID1によって受信されます。
The following issues are likely to come up in practice:
実際には次の問題が発生する可能性があります。
o The accuracy of PSFD depends on the clock resolution of both the ingress node and egress node. Clock synchronization between the ingress node and egress node is required.
o PSFDの精度は、入力ノードと出力ノードの両方のクロック分解能に依存します。入力ノードと出力ノード間のクロック同期が必要です。
o The accuracy of PSFD is also dependent on how the error-free signal is received and may differ significantly when the underlying data plane technology is different. For instance, for an LSP between a pair of Ethernet interfaces, the ingress node may use a rate-based method to verify the connectivity of the data path and use the reception of the first error-free frame as the error-free signal. In this case, the interval between two successive frames has a significant impact on accuracy. It is RECOMMENDED that the ingress node use small intervals, under the condition that the injected traffic does not exceed the capacity of the forward data path. The value of the interval MUST be reported.
o PSFDの精度は、エラーのない信号の受信方法にも依存し、基礎となるデータプレーンテクノロジーが異なる場合は大きく異なる可能性があります。たとえば、イーサネットインターフェイスのペア間のLSPの場合、入力ノードはレートベースの方法を使用してデータパスの接続を確認し、最初のエラーのないフレームの受信をエラーのない信号として使用できます。この場合、2つの連続するフレーム間の間隔は、精度に大きな影響を与えます。注入されたトラフィックが転送データパスの容量を超えないという条件下で、入口ノードが短い間隔を使用することをお勧めします。間隔の値を報告する必要があります。
o The accuracy of PSFD is also dependent on the time needed to propagate the error-free signal from the ingress node to the egress node. A typical value for propagating the error-free signal from the ingress node to the egress node under the same measurement setup MAY be reported. The methodology to obtain such values is outside the scope of this document.
o PSFDの精度は、エラーのない信号を入力ノードから出力ノードに伝搬するのに必要な時間にも依存します。同じ測定設定の下で入力ノードから出力ノードにエラーのない信号を伝搬するための典型的な値が報告される場合があります。このような値を取得する方法は、このドキュメントの範囲外です。
o The accuracy of this metric is also dependent on the physical-layer serialization/deserialization of the test signal for certain data path technologies. For instance, for an LSP between a pair of low-speed Ethernet interfaces, the time needed to serialize/ deserialize a large frame may not be negligible. In this case, it is RECOMMENDED that the ingress node use small frames. The average length of the frame MAY be reported.
oこのメトリックの精度は、特定のデータパステクノロジのテスト信号の物理層シリアル化/非シリアル化にも依存します。たとえば、一対の低速イーサネットインターフェイス間のLSPの場合、大きなフレームをシリアル化/非シリアル化するために必要な時間は無視できない場合があります。この場合、入口ノードで小さなフレームを使用することをお勧めします。フレームの平均の長さが報告される場合があります。
o If an error-free signal is received before a PATH message is sent, an error MUST be reported and the measurement SHOULD terminate.
o PATHメッセージが送信される前にエラーのない信号が受信された場合は、エラーを報告する必要があり、測定を終了する必要があります（SHOULD）。
o If the LSP setup fails, this metric value MUST NOT be counted.
o LSPセットアップが失敗した場合、このメトリック値をカウントしてはなりません（MUST NOT）。
o If the PATH message is sent by the ingress node but no error-free signal is received by the egress node within a reasonable period of time, i.e., a threshold, PSFD MUST be treated as undefined. The value of the threshold MUST be reported.
o PATHメッセージが入力ノードによって送信されたが、妥当な時間内、つまりしきい値内でエラーのない信号が出力ノードによって受信されない場合、PSFDは未定義として扱われなければなりません（MUST）。しきい値の値を報告する必要があります。
Generally, the methodology would proceed as follows:
一般に、方法論は次のように進行します。
o Make sure that the network has enough resources to set up the requested LSP.
o ネットワークに、要求されたLSPをセットアップするのに十分なリソースがあることを確認してください。
o Start the data path measurement and/or monitoring procedures on the ingress node and egress node. If an error-free signal is received by the egress node before a PATH message is sent, report an error and terminate the measurement.
o 入力ノードと出力ノードでデータパスの測定と監視の手順を開始します。 PATHメッセージが送信される前にエラーのない信号が出力ノードによって受信された場合、エラーを報告して測定を終了します。
o At the ingress node, form the PATH message according to the LSP requirements and send the message towards the egress node. A timestamp (T1) may be stored locally in the ingress node when the PATH message packet is sent towards the egress node.
o 入力ノードで、LSP要件に従ってPATHメッセージを形成し、メッセージを出力ノードに送信します。 PATHメッセージパケットが出口ノードに送信されると、タイムスタンプ（T1）が入口ノードにローカルに格納されます。
o When an error-free signal is observed on the egress node, take the timestamp (T2) as soon as possible. An estimate of PSFD (T2 - T1) can be computed.
o 出力ノードでエラーのない信号が確認されたら、できるだけ早くタイムスタンプ（T2）を取得します。 PSFD（T2-T1）の推定値を計算できます。
o If the LSP setup fails, PSFD is not counted.
o LSPセットアップが失敗した場合、PSFDはカウントされません。
o If no error-free signal is received within a reasonable period of time by the egress node, PSFD is deemed to be undefined.
o エラーのない信号が妥当な期間内に出口ノードによって受信されない場合、PSFDは未定義と見なされます。
This part defines a metric for reverse data path delay when an LSP is set up.
この部分では、LSPが設定されている場合の逆データパス遅延のメトリックを定義します。
This metric defines the time difference between the point when the ingress node sends the PATH message and the completion of the cross-connection programming along the LSP reverse data path. This metric MAY be used together with PSFD to characterize the data path delay of a bidirectional LSP.
このメトリックは、入力ノードがPATHメッセージを送信する時点と、LSPリバースデータパスに沿ったクロスコネクトプログラミングの完了との間の時間差を定義します。このメトリックは、双方向LSPのデータパス遅延を特徴付けるためにPSFDと一緒に使用される場合があります。
PSRD is useful for the following reasons:
PSRDは、次の理由で役立ちます。
o For the reasons described in [RFC6383], the data path setup delay may not be consistent with the control plane LSP setup delay. The data path setup delay metric is more precise for LSP setup performance measurement.
o [RFC6383]で説明されている理由により、データパスのセットアップ遅延は、コントロールプレーンのLSPセットアップ遅延と一致しない場合があります。 LSPセットアップパフォーマンス測定では、データパスセットアップ遅延メトリックがより正確です。
o The completion of the signaling process may be used by application designers as an indication of data path connectivity. The difference between the control plane setup delay and data path delay, and the potential failure of cross-connection programming, if not properly treated, will result in data loss or application failure. This metric can thus help designers to improve the application model.
o シグナリングプロセスの完了は、アプリケーション設計者がデータパス接続の指標として使用できます。コントロールプレーンのセットアップ遅延とデータパス遅延の違い、およびクロスコネクトプログラミングの潜在的な障害が適切に処理されないと、データの損失またはアプリケーションの障害が発生します。したがって、このメトリックは、設計者がアプリケーションモデルを改善するのに役立ちます。
PSRD = PATH Sent, Reverse Data path
PSRD = PATH送信、逆データパス
o ID0, the ingress LSR ID
o ID0、入力LSR ID
o ID1, the egress LSR ID
o ID1、出力LSR ID
o T, a time when the setup is attempted
o T、セットアップが試行された時間
The value of PSRD is either a real number of milliseconds or undefined.
PSRDの値は、実際のミリ秒数か未定義です。
For a real number dT,
実数dTの場合、
PSRD from ingress node ID0 to egress node ID1 at T is dT
入力ノードID0から出力ノードID1へのTでのPSRDはdTです。
means that
という意味です
o ingress node ID0 sends the first bit of a PATH message to egress node ID1 at T, and
o 入力ノードID0は、PATHメッセージの最初のビットをTで出力ノードID1に送信し、
o an error-free signal is received through the reverse data path by the ingress node ID0 using a data-plane-specific test pattern at T+dT.
o エラーのない信号は、T + dTでデータプレーン固有のテストパターンを使用して、イングレスノードID0によってリバースデータパスを介して受信されます。
The following issues are likely to come up in practice:
実際には次の問題が発生する可能性があります。
o The accuracy of PSRD depends on the clock resolution of the ingress node. Clock synchronization between the ingress node and egress node is not required.
o PSRDの精度は、入力ノードのクロック分解能に依存します。入力ノードと出力ノード間のクロック同期は必要ありません。
o The accuracy of PSRD is also dependent on how the error-free signal is received and may differ significantly when the underlying data plane technology is different. For instance, for an LSP between a pair of Ethernet interfaces, the egress node may use a rate-based method to verify the connectivity of the data path and use the reception of the first error-free frame as the error-free signal. In this case, the interval between two successive frames has a significant impact on accuracy. It is RECOMMENDED that the egress node use small intervals, under the condition that the injected traffic does not exceed the capacity of the forward data path. The value of the interval MUST be reported.
o PSRDの精度は、エラーのない信号の受信方法にも依存し、基礎となるデータプレーンテクノロジーが異なる場合は大きく異なる可能性があります。たとえば、イーサネットインターフェイスのペア間のLSPの場合、出力ノードはレートベースの方法を使用してデータパスの接続を確認し、最初のエラーのないフレームの受信をエラーのない信号として使用できます。この場合、2つの連続するフレーム間の間隔は、精度に大きな影響を与えます。注入されたトラフィックが転送データパスの容量を超えないという条件下で、出力ノードは短い間隔を使用することをお勧めします。間隔の値を報告する必要があります。
o The accuracy of PSRD is also dependent on the time needed to propagate the error-free signal from the egress node to the ingress node. A typical value for propagating the error-free signal from the egress node to the ingress node under the same measurement setup MAY be reported. The methodology to obtain such values is outside the scope of this document.
o PSRDの精度は、エラーのない信号を出力ノードから入力ノードに伝搬するのに必要な時間にも依存します。同じ測定設定の下で出口ノードから入口ノードにエラーのない信号を伝搬するための典型的な値が報告される場合があります。このような値を取得する方法は、このドキュメントの範囲外です。
o The accuracy of this metric is also dependent on the physical-layer serialization/deserialization of the test signal for certain data path technologies. For instance, for an LSP between a pair of low-speed Ethernet interfaces, the time needed to serialize/ deserialize a large frame may not be negligible. In this case, it is RECOMMENDED that the egress node use small frames. The average length of the frame MAY be reported.
oこのメトリックの精度は、特定のデータパステクノロジのテスト信号の物理層シリアル化/非シリアル化にも依存します。たとえば、一対の低速イーサネットインターフェイス間のLSPの場合、大きなフレームをシリアル化/非シリアル化するために必要な時間は無視できない場合があります。この場合、出力ノードが小さなフレームを使用することが推奨されます。フレームの平均の長さが報告される場合があります。
o If an error-free signal is received before a PATH message is sent, an error MUST be reported and the measurement SHOULD terminate.
o PATHメッセージが送信される前にエラーのない信号が受信された場合は、エラーを報告する必要があり、測定を終了する必要があります（SHOULD）。
o If the LSP setup fails, this metric value MUST NOT be counted.
o LSPセットアップが失敗した場合、このメトリック値をカウントしてはなりません（MUST NOT）。
o If the PATH message is sent by the ingress node but no error-free signal is received by the ingress node within a reasonable period of time, i.e., a threshold, PSRD MUST be treated as undefined. The value of the threshold MUST be reported.
o PATHメッセージが入力ノードによって送信されたが、妥当な時間内、つまりしきい値内でエラーのない信号が入力ノードによって受信されない場合、PSRDは未定義として扱われなければなりません（MUST）。しきい値の値を報告する必要があります。
Generally, the methodology would proceed as follows:
一般に、方法論は次のように進行します。
o Make sure that the network has enough resources to set up the requested LSP.
o ネットワークに、要求されたLSPをセットアップするのに十分なリソースがあることを確認してください。
o Start the data path measurement and/or monitoring procedures on the ingress node and egress node. If an error-free signal is received by the egress node before a PATH message is sent, report an error and terminate the measurement.
o 入力ノードと出力ノードでデータパスの測定と監視の手順を開始します。 PATHメッセージが送信される前にエラーのない信号が出力ノードによって受信された場合、エラーを報告して測定を終了します。
o At the ingress node, form the PATH message according to the LSP requirements and send the message towards the egress node. A timestamp (T1) may be stored locally in the ingress node when the PATH message packet is sent towards the egress node.
o 入力ノードで、LSP要件に従ってPATHメッセージを形成し、メッセージを出力ノードに送信します。 PATHメッセージパケットが出口ノードに送信されると、タイムスタンプ（T1）が入口ノードにローカルに格納されます。
o When an error-free signal is observed on the ingress node, take the timestamp (T2) as soon as possible. An estimate of PSRD (T2 - T1) can be computed.
o 入力ノードでエラーのない信号が確認されたら、できるだけ早くタイムスタンプ（T2）を取得します。 PSRD（T2-T1）の推定値を計算できます。
o If the LSP setup fails, PSRD is not counted.
o LSPセットアップが失敗した場合、PSRDはカウントされません。
o If no error-free signal is received within a reasonable period of time by the ingress node, PSRD is deemed to be undefined.
o 入力ノードが妥当な期間内にエラーのない信号を受信しない場合、PSRDは未定義と見なされます。
In Sections 5, 6, 7, 8, and 9, we defined the singleton metrics of data path delay. Now, we define how to get one particular sample of such a delay. Sampling is done to select a particular portion of singleton values of the given parameters. As in [RFC2330], we use Poisson sampling as an example.
セクション5、6、7、8、9では、データパス遅延のシングルトンメトリックを定義しました。次に、そのような遅延の特定のサンプルを取得する方法を定義します。サンプリングは、指定されたパラメーターのシングルトン値の特定の部分を選択するために行われます。 [RFC2330]と同様に、ポアソンサンプリングを例として使用します。
Type <X> data path delay sample, where X is either RRFD, RSRD, PRFD, PSFD, or PSRD.
タイプ<X>データパス遅延サンプル。Xは、RRFD、RSRD、PRFD、PSFD、またはPSRDのいずれかです。
o ID0, the ingress LSR ID
o ID0、入力LSR ID
o ID1, the egress LSR ID
o ID1、出力LSR ID
o T0, a time
o T0、時間
o Tf, a time
o Tf、時間
o Lambda, a rate in reciprocal milliseconds
o ラムダ、ミリ秒単位の速度
o Th, the LSP holding time
o Th、LSP保持時間
o Td, the maximum waiting time for successful LSP setup
o Td、LSPセットアップが成功するまでの最大待機時間
o Ts, the maximum waiting time for an error-free signal
o Ts、エラーのない信号の最大待機時間
A sequence of pairs; the elements of each pair are:
ペアのシーケンス。各ペアの要素は次のとおりです。
o T, a time when setup is attempted
o T、セットアップが試行された時間
o dT, either a real number of milliseconds or undefined
o dT、実際のミリ秒数または未定義
Given T0, Tf, and Lambda, compute a pseudo-random Poisson process beginning at or before T0, with average arrival rate Lambda, and ending at or after Tf. Those time values greater than or equal to T0 and less than or equal to Tf are then selected. At each of the times in this process, we obtain the value of a data path delay sample of type <X> at this time. The value of the sample is the sequence made up of the resulting <time, type <X> data path delay> pairs. If there are no such pairs, the sequence is of length zero and the sample is said to be empty.
T0、Tf、およびLambdaが与えられた場合、T0以前で始まり、平均到着率LambdaでTf以降で終了する疑似ランダムポアソンプロセスを計算します。次に、Ｔ０以上かつＴｆ以下のこれらの時間値が選択される。このプロセスの各時間で、この時点でタイプ<X>のデータパス遅延サンプルの値を取得します。サンプルの値は、結果の<time、type <X> data path delay>ペアで構成されるシーケンスです。そのようなペアがない場合、シーケンスは長さがゼロであり、サンプルは空であるといいます。
The following issues are likely to come up in practice:
実際には次の問題が発生する可能性があります。
o The parameters Lambda, Th, and Td should be carefully chosen, as explained in the discussions for LSP setup delay (see [RFC5814]).
o LSPセットアップ遅延の説明で説明されているように、パラメータLambda、Th、およびTdは慎重に選択する必要があります（[RFC5814]を参照）。
o The parameter Ts should be carefully chosen and MUST be reported along with the LSP forward/reverse data path delay sample.
o パラメータTsは慎重に選択する必要があり、LSPフォワード/リバースデータパス遅延サンプルとともに報告する必要があります。
Generally, the methodology would proceed as follows:
一般に、方法論は次のように進行します。
o Select specific times, using the specified Poisson arrival process.
o 指定されたポアソン到着プロセスを使用して、特定の時間を選択します。
o Set up the LSP and obtain the value of type <X> data path delay.
o LSPを設定し、タイプ<X>データパス遅延の値を取得します。
o Release the LSP after Th, and wait for the next Poisson arrival process.
o Thの後にLSPを解放し、次のポアソン到着プロセスを待ちます。
Data path delay with no LSP in the network is important because this reflects the inherent delay of a device implementation. The minimum value provides an indication of the delay that will likely be experienced when an LSP data path is configured under light traffic load.
ネットワークにLSPがない場合のデータパス遅延は、デバイス実装に固有の遅延を反映するため重要です。最小値は、LSPデータパスがトラフィックの負荷が少ない状態で構成されている場合に発生する可能性が高い遅延を示します。
Make sure that there is no LSP in the network, and proceed with the methodologies described in Section 10.6.
ネットワークにLSPがないことを確認し、10.6項で説明されている方法に進みます。
Data path delay with a number of LSPs in the network is important because it reflects the performance of an operational network with considerable load. This delay may vary significantly as the number of existing LSPs varies. It can be used as a scalability metric of a device implementation.
ネットワークに多数のLSPがある場合のデータパス遅延は、負荷が大きい運用ネットワークのパフォーマンスを反映するため、重要です。既存のLSPの数が変わると、この遅延は大幅に変わる可能性があります。これは、デバイス実装のスケーラビリティメトリックとして使用できます。
o Set up the required number of LSPs.
o 必要な数のLSPを設定します。
o Wait until the network reaches a stable state.
o ネットワークが安定した状態になるまで待ちます。
o Then proceed with the methodologies described in Section 10.6.
o 次に、セクション10.6に記載されている方法に進みます。
Given the samples of the performance metric, we now offer several statistics of these samples to report. From these statistics, we can draw some useful conclusions regarding a GMPLS network. The value of these metrics is either a real number of milliseconds or undefined. In the following discussion, we only consider the finite values.
パフォーマンスメトリックのサンプルを考慮して、これらのサンプルのいくつかの統計をレポートに提供します。これらの統計から、GMPLSネットワークに関するいくつかの有用な結論を引き出すことができます。これらのメトリックの値は、実際のミリ秒数または未定義です。以下の説明では、有限値のみを考慮します。
The minimum of the metric is the minimum of all the dT values in the sample. In computing this, undefined values SHOULD be treated as infinitely large. Note that this means that the minimum could thus be undefined if all the dT values are undefined. In addition, the metric minimum SHOULD be set to undefined if the sample is empty.
メトリックの最小値は、サンプル内のすべてのdT値の最小値です。これを計算する場合、未定義の値は無限に大きいものとして扱う必要があります（SHOULD）。これは、すべてのdT値が未定義の場合、最小値が未定義になる可能性があることを意味することに注意してください。さらに、サンプルが空の場合、メトリックの最小値を未定義に設定する必要があります（SHOULD）。
The median of the metric is the median of the dT values in the given sample. In computing the median, the undefined values MUST NOT be included. The median SHOULD be set to undefined if all the dT values are undefined, or if the sample is empty. When the number of defined values in the given sample is small, the metric median may not be typical and SHOULD be used carefully.
メトリックの中央値は、指定されたサンプルのdT値の中央値です。中央値の計算では、未定義の値を含めてはなりません（MUST NOT）。すべてのdT値が未定義の場合、またはサンプルが空の場合、中央値は未定義に設定する必要があります（SHOULD）。所定のサンプルで定義された値の数が少ない場合、メトリック中央値は一般的ではない可能性があるため、慎重に使用する必要があります。
The "empirical distribution function" (EDF) of a set of scalar measurements is a function F(x), which, for any x, gives the fractional proportion of the total measurements that were <= x.
スカラー測定値のセットの「経験的分布関数」（EDF）は関数F（x）です。これは、任意のxに対して、<= xであった合計測定値の分数の比率を与えます。
Given a percentage X, the Xth percentile of the metric means the smallest value of x for which F(x) >= X. In computing the percentile, undefined values MUST NOT be included.
パーセンテージXが与えられた場合、メトリクスのX番目のパーセンタイルは、F（x）> = Xであるxの最小値を意味します。パーセンタイルの計算では、未定義の値を含めてはなりません。
See [RFC2330] for further details.
詳細については、[RFC2330]を参照してください。
Given the samples of the performance metric, we now offer two statistics of failure events of these samples to report: Failure Count and Failure Ratio. The two statistics can be applied to both the forward data path and reverse data path. For example, when a sample of RRFD has been obtained, the forward data path failure statistics can be obtained, while a sample of RSRD can be used to calculate the reverse data path failure statistics. Detailed definitions of Failure Count and Failure Ratio are given below.
パフォーマンスメトリックのサンプルを前提として、これらのサンプルの失敗イベントの2つの統計を報告するために提供します。失敗数と失敗率です。 2つの統計情報は、フォワードデータパスとリバースデータパスの両方に適用できます。たとえば、RRFDのサンプルが取得されると、順方向データパス障害統計を取得できますが、RSRDのサンプルを使用して、逆データパス障害統計を計算できます。失敗数と失敗率の詳細な定義を以下に示します。
Failure Count is defined as the number of the undefined value of the corresponding performance metric in a sample. The value of Failure Count is an integer.
障害カウントは、サンプル内の対応するパフォーマンスメトリックの未定義の値の数として定義されます。失敗数の値は整数です。
Failure Ratio is the percentage of the number of failure events to the total number of requests in a sample. Here, a failure event means that the signaling completes with no error, while no error-free signal is observed. The calculation for Failure Ratio is defined as follows:
失敗率は、サンプル内のリクエストの総数に対する失敗イベントの数の割合です。ここで、障害イベントとは、エラーのない信号が観察されない一方で、シグナリングがエラーなしで完了することを意味します。故障率の計算は次のように定義されます。
Failure Ratio = Number of undefined value/(Number of valid metric values + Number of undefined value) * 100%.
失敗率=未定義値の数/（有効なメトリック値の数+未定義値の数）* 100％。
In the control plane, since the measurement endpoints must be conformant to signaling specifications and behave as normal signaling endpoints, it will not incur security issues other than normal LSP provisioning. However, the measurement parameters must be carefully selected so that the measurements inject trivial amounts of additional traffic into the networks they measure. If they inject "too much" traffic, they can skew the results of the measurement and in extreme cases cause congestion and denial of service.
コントロールプレーンでは、測定エンドポイントはシグナリング仕様に準拠し、通常のシグナリングエンドポイントとして動作する必要があるため、通常のLSPプロビジョニング以外のセキュリティ問題は発生しません。ただし、測定が測定するネットワークに少量の追加トラフィックを注入するように、測定パラメーターは慎重に選択する必要があります。注入するトラフィックが多すぎると、測定結果が歪む可能性があり、極端な場合には、輻輳やサービス拒否が発生します。
In the data plane, the measurement endpoint MUST use a signal that is consistent with what is specified in the control plane. For example, in a packet switched case, the traffic injected into the data plane MUST NOT exceed the specified rate in the corresponding LSP setup request. In a wavelength switched case, the measurement endpoint MUST use the specified or negotiated lambda with appropriate power.
データプレーンでは、測定エンドポイントは、コントロールプレーンで指定されているものと一致する信号を使用する必要があります。たとえば、パケット交換の場合、データプレーンに注入されたトラフィックは、対応するLSPセットアップ要求で指定されたレートを超えてはなりません（MUST NOT）。波長切り替えの場合、測定エンドポイントは指定された、または交渉されたラムダを適切なパワーで使用する必要があります。
The security considerations pertaining to the original RSVP protocol [RFC2205] and its TE extensions [RFC3209] also remain relevant.
元のRSVPプロトコル[RFC2205]とそのTE拡張[RFC3209]に関連するセキュリティの考慮事項も引き続き関連しています。
[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月。
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2679] Almes、G.、Kalidindi、S。、およびM. Zekauskas、「A IP-way Delay Metric for IPPM」、RFC 2679、1999年9月。
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999.
[RFC2681] Almes、G.、Kalidindi、S。、およびM. Zekauskas、「IPPMの往復遅延メトリック」、RFC 2681、1999年9月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：Extensions for RSVP for LSP Tunnels」、RFC 3209、12月2001年。
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998.
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998.
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, "Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model", RFC 4208, October 2005.
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, "Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model", RFC 4208, October 2005.
[RFC5814] Sun, W. and G. Zhang, "Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks", RFC 5814, March 2010.
[RFC5814] Sun、W.、G。Zhang、「Label Switched Path（LSP）Dynamic Provisioning Performance Metrics in Generalized MPLS Networks」、RFC 5814、2010年3月。
[RFC6383] Shiomoto, K. and A. Farrel, "Advice on When It Is Safe to Start Sending Data on Label Switched Paths Established Using RSVP-TE", RFC 6383, September 2011.
[RFC6383] Shiomoto、K。およびA. Farrel、「RSVP-TEを使用して確立されたラベルスイッチドパスでデータの送信を開始しても安全な場合のアドバイス」、RFC 6383、2011年9月。
We wish to thank Adrian Farrel, Lou Berger, and Al Morton for their comments and help. We also wish to thank Klaas Wierenga and Alexey Melnikov for their reviews.
Adrian Farrel、Lou Berger、Al Mortonのコメントと支援に感謝します。また、Klaas WierengaとAlexey Melnikovのレビューにも感謝します。
This document contains ideas as well as text that have appeared in existing IETF documents. The authors wish to thank G. Almes, S. Kalidindi, and M. Zekauskas.
This document contains ideas as well as text that have appeared in existing IETF documents. The authors wish to thank G. Almes, S. Kalidindi, and M. Zekauskas.
We also wish to thank Weisheng Hu, Yaohui Jin, and Wei Guo in the state key laboratory of advanced optical communication systems and networks for their valuable comments. We also wish to thank the National Natural Science Foundation of China (NSFC) and the 863 program of China for their support.
また、高度な光通信システムとネットワークの州の主要な研究所の貴重なコメントを提供してくれたWeisheng Hu、Yaohui Jin、およびWei Guoにも感謝します。また、中国国家自然科学財団（NSFC）および中国の863プログラムの支援にも感謝します。
Bin Gu IXIA Oriental Kenzo Plaza 8M, 48 Dongzhimen Wai Street Dongcheng District Beijing 200240 China
Bingu IXIAオリエンタルケンゾープラザ8M、48 Dongzhimen Wai Street Dongcheng District北京200240中国
Phone: +86 13611590766
EMail: BGu@ixiacom.com
Xueqin Wei Fiberhome Telecommunication Technology Co., Ltd. Wuhan China
X UE Pro Weiファイバーホームテレコミュニケーションテクノロジー株式会社武漢中国
Phone: +86 13871127882
EMail: xqwei@fiberhome.com.cn
Tomohiro Otani KDDI R&D Laboratories, Inc. 2-1-15 Ohara Kamifukuoka Saitama 356-8502 Japan
ともひろ おたに Ｋっぢ Ｒ＆Ｄ ぁぼらとりえｓ、 いんｃ。 ２ー１ー１５ おはら かみふくおか さいたま ３５６ー８５０２ じゃぱん
Phone: +81-49-278-7357
EMail: tm-otani@kddi.com
Ruiquan Jing China Telecom Beijing Research Institute 118 Xizhimenwai Avenue Beijing 100035 China
Ru iクーポンジンフルーツチャイナテレコム北京研究所118ξバリューアベニュー北京100035中国
Phone: +86-10-58552000
EMail: jingrq@ctbri.com.cn
Authors' Addresses
著者のアドレス
Weiqiang Sun (editor) Shanghai Jiao Tong University 800 Dongchuan Road Shanghai 200240 China
Wei Qiangsun（編集者）上海J i AOトング大学800ドンウェアロード上海200240中国
Phone: +86 21 3420 5359
EMail: sun.weiqiang@gmail.com
Guoying Zhang (editor) China Academy of Telecommunication Research, MIIT, China No. 52 Hua Yuan Bei Lu, Haidian District Beijing 100191 China
GU OYing Zhang（編集者）中国電気通信研究アカデミー、MI IT、中国No. 52 hu阿元be IL U、H Xiaodian地区北京100191中国
Phone: +86 1062300103
EMail: zhangguoying@catr.cn
Jianhua Gao Huawei Technologies Co., Ltd. China
J Ianはテクノロジー株式会社中国にGooh UAを投資
Phone: +86 755 28973237
EMail: gjhhit@huawei.com
Guowu Xie University of California, Riverside 900 University Ave. Riverside, CA 92521 USA
GU O5X IEカリフォルニア大学リバーサイド900大学平均リバーサイド、カリフォルニア92521米国
Phone: +1 951 237 8825
EMail: xieg@cs.ucr.edu
Rajiv Papneja Huawei Technologies Santa Clara, CA 95050 Reston, VA 20190 USA
Rajiv Papaneja Huawei Technologies Santa Clara、95050軒のレストラン、20190彼
EMail: rajiv.papneja@huawei.com