[要約] RFC 5814は、一般化されたMPLSネットワークにおけるラベルスイッチパス（LSP）の動的プロビジョニングのパフォーマンスメトリックに関する情報を提供します。このRFCの目的は、LSPの動的プロビジョニングのパフォーマンスを評価し、ネットワークの効率性を向上させるためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) W. Sun, Ed.
Request for Comments: 5814 SJTU
Category: Standards Track G. Zhang, Ed.
ISSN: 2070-1721 CATR
March 2010
Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks
一般化されたMPLSネットワークのラベルスイッチパス（LSP）動的プロビジョニングパフォーマンスメトリック
Abstract
概要
Generalized Multi-Protocol Label Switching (GMPLS) is one of the most promising candidate technologies for a future data transmission network. GMPLS has been developed to control and operate different kinds of network elements, such as conventional routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexers (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. These physically diverse devices differ drastically from one another in dynamic provisioning ability. At the same time, the need for dynamically provisioned connections is increasing because optical networks are being deployed in metro areas. As different applications have varied requirements in the provisioning performance of optical networks, it is imperative to define standardized metrics and procedures such that the performance of networks and application needs can be mapped to each other.
一般化されたマルチプロトコルラベルスイッチング（GMPLS）は、将来のデータ送信ネットワークで最も有望な候補技術の1つです。GMPLSは、従来のルーター、スイッチ、高密度波長分割マルチプレックス（DWDM）システム、アドロップマルチプレクサ（ADM）、フォトニッククロスコネクト（PXC）、光学クロスコネクトなど、さまざまな種類のネットワーク要素を制御および操作するために開発されています。（OXCS）など。これらの物理的に多様なデバイスは、動的なプロビジョニング能力で互いに劇的に異なります。同時に、光学ネットワークがメトロエリアに展開されているため、動的にプロビジョニングされた接続の必要性が増加しています。さまざまなアプリケーションが光学ネットワークのプロビジョニングパフォーマンスにさまざまな要件があるため、ネットワークとアプリケーションのニーズのパフォーマンスを相互にマッピングできるように、標準化されたメトリックと手順を定義することが不可欠です。
This document provides a series of performance metrics to evaluate the dynamic Label Switched Path (LSP) provisioning performance in GMPLS networks, specifically the dynamic LSP setup/release performance. These metrics can be used to characterize the features of GMPLS networks in LSP dynamic provisioning.
このドキュメントは、GMPLSネットワークの動的ラベルスイッチ付きパス（LSP）プロビジョニングパフォーマンス、特に動的LSPセットアップ/リリースパフォーマンスを評価するための一連のパフォーマンスメトリックを提供します。これらのメトリックは、LSP動的プロビジョニングのGMPLSネットワークの機能を特徴付けるために使用できます。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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）の製品です。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/rfc5814.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5814で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................6
2. Conventions Used in This Document ...............................6
3. Overview of Performance Metrics .................................6
4. A Singleton Definition for Single Unidirectional LSP
Setup Delay .....................................................7
4.1. Motivation .................................................7
4.2. Metric Name ................................................7
4.3. Metric Parameters ..........................................8
4.4. Metric Units ...............................................8
4.5. Definition .................................................8
4.6. Discussion .................................................8
4.7. Methodologies ..............................................9
4.8. Metric Reporting ...........................................9
5. A Singleton Definition for Multiple Unidirectional LSPs
Setup Delay ....................................................10
5.1. Motivation ................................................10
5.2. Metric Name ...............................................10
5.3. Metric Parameters .........................................10
5.4. Metric Units ..............................................10
5.5. Definition ................................................11
5.6. Discussion ................................................11
5.7. Methodologies .............................................12
5.8. Metric Reporting ..........................................13
6. A Singleton Definition for Single Bidirectional LSP
Setup Delay ....................................................13
6.1. Motivation ................................................13
6.2. Metric Name ...............................................14
6.3. Metric Parameters .........................................14
6.4. Metric Units ..............................................14
6.5. Definition ................................................14
6.6. Discussion ................................................15
6.7. Methodologies .............................................15
6.8. Metric Reporting ..........................................16
7. A Singleton Definition for Multiple Bidirectional LSPs
Setup Delay ....................................................16
7.1. Motivation ................................................16
7.2. Metric Name ...............................................16
7.3. Metric Parameters .........................................17
7.4. Metric Units ..............................................17
7.5. Definition ................................................17
7.6. Discussion ................................................18
7.7. Methodologies .............................................19
7.8. Metric Reporting ..........................................19
8. A Singleton Definition for LSP Graceful Release Delay ..........20
8.1. Motivation ................................................20
8.2. Metric Name ...............................................20
8.3. Metric Parameters .........................................20
8.4. Metric Units ..............................................20
8.5. Definition ................................................20
8.6. Discussion ................................................22
8.7. Methodologies .............................................22
8.8. Metric Reporting ..........................................23
9. A Definition for Samples of Single Unidirectional LSP
Setup Delay ....................................................24
9.1. Metric Name ...............................................24
9.2. Metric Parameters .........................................24
9.3. Metric Units ..............................................24
9.4. Definition ................................................24
9.5. Discussion ................................................25
9.6. Methodologies .............................................25
9.7. Typical Testing Cases .....................................26
9.7.1. With No LSP in the Network .........................26
9.7.2. With a Number of LSPs in the Network ...............26
9.8. Metric Reporting ..........................................26
10. A Definition for Samples of Multiple Unidirectional
LSPs Setup Delay ..............................................26
10.1. Metric Name ..............................................27
10.2. Metric Parameters ........................................27
10.3. Metric Units .............................................27
10.4. Definition ...............................................27
10.5. Discussion ...............................................28
10.6. Methodologies ............................................28
10.7. Typical Testing Cases ....................................29
10.7.1. With No LSP in the Network ........................29
10.7.2. With a Number of LSPs in the Network ..............29
10.8. Metric Reporting .........................................29
11. A Definition for Samples of Single Bidirectional LSP
Setup Delay ...................................................30
11.1. Metric Name ..............................................30
11.2. Metric Parameters ........................................30
11.3. Metric Units .............................................30
11.4. Definition ...............................................30
11.5. Discussion ...............................................31
11.6. Methodologies ............................................31
11.7. Typical Testing Cases ....................................32
11.7.1. With No LSP in the Network ........................32
11.7.2. With a Number of LSPs in the Network ..............32
11.8. Metric Reporting .........................................32
12. A Definition for Samples of Multiple Bidirectional
LSPs Setup Delay ..............................................32
12.1. Metric Name ..............................................33
12.2. Metric Parameters ........................................33
12.3. Metric Units .............................................33
12.4. Definition ...............................................33
12.5. Discussion ...............................................34
12.6. Methodologies ............................................34
12.7. Typical Testing Cases ....................................35
12.7.1. With No LSP in the Network ........................35
12.7.2. With a Number of LSPs in the Network ..............35
12.8. Metric Reporting .........................................35
13. A Definition for Samples of LSP Graceful Release Delay ........35
13.1. Metric Name ..............................................36
13.2. Metric Parameters ........................................36
13.3. Metric Units .............................................36
13.4. Definition ...............................................36
13.5. Discussion ...............................................36
13.6. Methodologies ............................................37
13.7. Metric Reporting .........................................37
14. Some Statistics Definitions for Metrics to Report .............37
14.1. The Minimum of Metric ....................................37
14.2. The Median of Metric .....................................37
14.3. The Maximum of Metric ....................................38
14.4. The Percentile of Metric .................................38
14.5. Failure Statistics of Metric .............................38
14.5.1. Failure Count .....................................39
14.5.2. Failure Ratio .....................................39
15. Discussion ....................................................39
16. Security Considerations .......................................40
17. Acknowledgments ...............................................41
18. References ....................................................41
18.1. Normative References .....................................41
18.2. Informative References ...................................42
Appendix A. Authors' Addresses ...................................43
Generalized Multi-Protocol Label Switching (GMPLS) is one of the most promising control plane solutions for future transport and service network. GMPLS has been developed to control and operate different kinds of network elements, such as conventional routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. These physically diverse devices differ drastically from one another in dynamic provisioning ability.
一般化されたマルチプロトコルラベルスイッチング（GMPLS）は、将来の輸送およびサービスネットワーク向けの最も有望なコントロールプレーンソリューションの1つです。GMPLSは、従来のルーター、スイッチ、高密度波長分割多重化（DWDM）システム、アドロップマルチプレクサ（ADM）、フォトニッククロスコネクト（PXCS）、光学クロスコネクトなど、さまざまな種類のネットワーク要素を制御および操作するために開発されています。（OXCS）など。これらの物理的に多様なデバイスは、動的なプロビジョニング能力で互いに劇的に異なります。
The introduction of a control plane into optical circuit switching networks provides the basis for automating the provisioning of connections and drastically reduces connection provision delay. As more and more services and applications are seeking to use GMPLS-controlled networks as their underlying transport network, and increasingly in a dynamic way, the need is growing for measuring and characterizing the performance of LSP provisioning in GMPLS networks, such that requirement from applications and the provisioning capability of the network can be mapped to each other.
光回路スイッチングネットワークへの制御プレーンの導入は、接続のプロビジョニングを自動化するための基礎を提供し、接続の提供遅延を大幅に削減します。ますます多くのサービスとアプリケーションがGMPLS制御ネットワークを基礎となる輸送ネットワークとして使用しようとしているため、ますます動的な方法で、GMPLSネットワークでのLSPプロビジョニングのパフォーマンスを測定および特性化する必要が高まっています。ネットワークのプロビジョニング機能は相互にマッピングできます。
This document defines performance metrics and methodologies that can be used to characterize the dynamic LSP provisioning performance of GMPLS networks, more specifically, performance of the signaling protocol. The metrics defined in this document can be used to characterize the average performance of GMPLS implementations.
このドキュメントでは、GMPLSネットワークの動的なLSPプロビジョニングパフォーマンス、より具体的にはシグナリングプロトコルのパフォーマンスを特徴付けるために使用できるパフォーマンスメトリックと方法論を定義します。このドキュメントで定義されているメトリックは、GMPLS実装の平均パフォーマンスを特徴付けるために使用できます。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
In this memo, to characterize the dynamic LSP provisioning performance of a GMPLS network, we define three performance metrics: unidirectional LSP setup delay, bidirectional LSP setup delay, and LSP graceful release delay. The latency of the LSP setup/release signal is conceptually similar to the Round-trip Delay in IP networks. This enables us to refer to 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.
このメモでは、GMPLSネットワークの動的なLSPプロビジョニングパフォーマンスを特徴付けるために、3つのパフォーマンスメトリックを定義します。単方向LSPセットアップ遅延、双方向LSPセットアップ遅延、LSP Gracefulリリース遅延です。LSPセットアップ/リリース信号の遅延は、IPネットワークの往復遅延と概念的に類似しています。これにより、IPパフォーマンスメトリック（IPPM）フレームワークドキュメント[RFC2330] [RFC2679] [RFC2681]で導入および議論された構造と概念を参照できます。読者は、それらの文書の概念に精通していると想定されています。
Note that data-path-related metrics, for example, the time between the reception of a Resv message by the ingress node and when the forward data path becomes operational, are defined in another document [CCAMP-DPM]. It is desirable that both measurements are performed to complement each other.
たとえば、IngressノードによるRESVメッセージの受信までの時間と、フォワードデータパスが動作する場合の時間は、別のドキュメント[CCAMP-DPM]で定義されていることに注意してください。両方の測定が互いに補完するために実行されることが望ましいです。
This section defines a metric for single unidirectional Label Switched Path setup delay across a GMPLS network.
このセクションでは、GMPLSネットワーク全体で単一の単方向ラベルスイッチ付きパスセットアップ遅延のメトリックを定義します。
Single unidirectional Label Switched Path setup delay is useful for several reasons:
単一の単方向ラベルスイッチ付きパスセットアップ遅延は、いくつかの理由で役立ちます。
o Single LSP setup delay is an important metric that characterizes the provisioning performance of a GMPLS network. Longer LSP setup delay will most likely incur higher overhead for the requesting application, especially when the LSP duration itself is comparable to the LSP setup delay.
o 単一のLSPセットアップ遅延は、GMPLSネットワークのプロビジョニングパフォーマンスを特徴付ける重要なメトリックです。LSPセットアップの遅延が長くなると、特にLSPのセットアップ遅延に匹敵する場合、要求アプリケーションのオーバーヘッドが高くなる可能性が最も高くなります。
o The minimum value of this metric provides an indication of the delay that will likely be experienced when the LSP traverses the shortest route at the lightest load in the control plane. As the delay itself consists of several components, such as link propagation delay and nodal processing delay, this metric also reflects the status of the control plane. For example, for LSPs traversing the same route, longer setup delays may suggest congestion in the control channel or high control element load. For this reason, this metric is useful for testing and diagnostic purposes.
o このメトリックの最小値は、LSPがコントロールプレーンの最も軽い荷重で最も短いルートを横断するときに経験される可能性が高い遅延を示すことを示します。遅延自体は、リンク伝播遅延や節点処理遅延などのいくつかのコンポーネントで構成されているため、このメトリックはコントロールプレーンの状態も反映しています。たとえば、同じルートを横断するLSPの場合、セットアップの遅延が長くなると、コントロールチャネルまたは高制御要素の荷重が渋滞を示唆する場合があります。このため、このメトリックはテストと診断の目的に役立ちます。
o The observed variance in a sample of LSP setup delay metric values variance may serve as an early indicator on the feasibility of support of applications that have stringent setup delay requirements.
o LSPセットアップ遅延メートリック値の分散のサンプルで観測された分散は、厳しいセットアップ遅延要件を持つアプリケーションのサポートの実現可能性に関する初期の指標として機能する可能性があります。
The measurement of single unidirectional LSP setup delay instead of bidirectional LSP setup delay is motivated by the following factors:
双方向LSPセットアップ遅延の代わりに単一の単方向LSPセットアップ遅延の測定は、次の要因によって動機付けられています。
o Some applications may use only unidirectional LSPs rather than bidirectional ones. For example, content delivery services with multicasting may use only unidirectional LSPs.
o 一部のアプリケーションは、双方向LSPではなく単方向LSPのみを使用する場合があります。たとえば、マルチリキャストを備えたコンテンツ配信サービスは、単方向LSPのみを使用できます。
Single unidirectional LSP setup delay
単一の単方向LSPセットアップ遅延
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 single unidirectional LSP setup delay is either a real number of milliseconds or undefined.
単一の単方向LSPセットアップ遅延の値は、実際の数ミリ秒または未定義のいずれかです。
The single unidirectional LSP setup delay from ingress node ID0 to egress node ID1 [RFC3945] at T is dT means that ingress node ID0 sends the first bit of a Path message packet to egress node ID1 at wire-time T, and that ingress node ID0 received the last bit of responding Resv message packet from egress node ID1 at wire-time T+dT.
IngressノードID0からTのIngress Node ID0からNode Node ID1 [RFC3945]への単一の単方向LSPセットアップ遅延は、ingressノードID0がワイヤタイムTでNode ID1を出力するパスメッセージパケットの最初のビットを送信し、イングレスノードID0を送信することを意味します。ワイヤタイムT DTで出力ノードID1から応答するRESVメッセージパケットの最後のビットを受信しました。
The single unidirectional LSP setup delay from ingress node ID0 to egress node ID1 at T is undefined means that ingress node ID0 sends the first bit of Path message packet to egress node ID1 at wire-time T and that ingress node ID0 does not receive the corresponding Resv message within a reasonable period of time.
IngressノードID0からTでの出力ノードID1への単一単方向LSPセットアップ遅延は、イングレスノードID0がワイヤタイムTでの出力ノードID1に最初のパスメッセージパケットを送信し、イングレスノードID0が対応するものを受信しないことを意味します。合理的な期間内にRESVメッセージ。
The undefined value of this metric indicates an event of Single Unidirectional LSP Setup Failure and would be used to report a count or a percentage of Single Unidirectional LSP Setup failures. See Section 14.5 for definitions of LSP setup/release failures.
このメトリックの未定義の値は、単一の単方向LSPセットアップ障害のイベントを示しており、単一の単方向LSPセットアップ障害のカウントまたは割合を報告するために使用されます。LSPセットアップ/リリース障害の定義については、セクション14.5を参照してください。
The following issues are likely to come up in practice:
以下の問題は実際に発生する可能性があります。
o The accuracy of unidirectional LSP setup delay at time T depends on the clock resolution in the ingress node; but synchronization between the ingress node and egress node is not required since unidirectional LSP setup uses two-way signaling.
o 時間tでの単方向LSPセットアップ遅延の精度は、イングレスノードの時計解像度に依存します。ただし、単方向LSPセットアップでは双方向シグナリングを使用するため、イングレスノードと出口ノード間の同期は必要ありません。
o A given methodology will have to include a way to determine whether a latency value is infinite or whether it is merely very large. Simple upper bounds MAY be used, but GMPLS networks may accommodate many kinds of devices. For example, some photonic cross-connects (PXCs) have to move micro mirrors. This physical motion may take several milliseconds, but the common electronic switches can finish the nodal processing within several microseconds. So the unidirectional LSP setup delay varies drastically from one network to another. In practice, the upper bound SHOULD be chosen carefully.
o 特定の方法論には、レイテンシ値が無限であるかどうか、または単に非常に大きいかどうかを判断する方法を含める必要があります。単純な上限を使用することもできますが、GMPLSネットワークは多くの種類のデバイスに対応する場合があります。たとえば、一部のフォトニッククロスコネクト（PXC）はマイクロミラーを移動する必要があります。この物理的な動きには数ミリ秒かかる場合がありますが、一般的な電子スイッチは数マイクロ秒以内にノード処理を終了できます。したがって、単方向のLSPセットアップ遅延は、ネットワークによって劇的に異なります。実際には、上限を慎重に選択する必要があります。
o If the ingress node sends out the Path message to set up an LSP, but never receives the corresponding Resv message, the unidirectional LSP setup delay MUST be set to undefined.
o IngressノードがLSPをセットアップするためにパスメッセージを送信するが、対応するRESVメッセージを受信しない場合、単方向LSPセットアップ遅延を未定義に設定する必要があります。
o If the ingress node sends out the Path message to set up an LSP but receives a PathErr message, the unidirectional LSP setup delay MUST be set to undefined. There are many possible reasons for this case; for example, the Path message has invalid parameters or the network does not have enough resources to set up the requested LSP, etc.
o IngressノードがLSPをセットアップするためにパスメッセージを送信するが、PatherRメッセージを受信する場合、単方向LSPセットアップ遅延を未定義に設定する必要があります。このケースには多くの理由があります。たとえば、パスメッセージには無効なパラメーターがあるか、ネットワークには要求されたLSPなどを設定するのに十分なリソースがありません。
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 At the ingress node, form the Path message according to the LSP requirements. A timestamp (T1) may be stored locally on the ingress node when the Path message packet is sent towards the egress node.
o Ingressノードで、LSP要件に従ってパスメッセージを形成します。タイムスタンプ（T1）は、パスメッセージパケットが出口ノードに向けて送信されると、イングレスノードにローカルに保存できます。
o If the corresponding Resv message arrives within a reasonable period of time, take the timestamp (T2) as soon as possible upon receipt of the message. By subtracting the two timestamps, an estimate of unidirectional LSP setup delay (T2-T1) can be computed.
o 対応するRESVメッセージが妥当な期間内に到着した場合、メッセージを受け取ったときにできるだけ早くタイムスタンプ（T2）を取ります。2つのタイムスタンプを減算することにより、単方向LSPセットアップ遅延（T2-T1）の推定値を計算できます。
o If the corresponding Resv message fails to arrive within a reasonable period of time, the unidirectional LSP setup delay is deemed to be undefined. Note that the "reasonable" threshold is a parameter of the methodology.
o 対応するRESVメッセージが合理的な期間内に到着できない場合、単方向LSPセットアップ遅延は未定義であるとみなされます。「合理的な」しきい値は、方法論のパラメーターであることに注意してください。
o If the corresponding response is a PathErr message, the unidirectional LSP setup delay is deemed to be undefined.
o 対応する応答がPatherRメッセージである場合、単方向LSPセットアップ遅延は未定義であるとみなされます。
The metric result (either a real number or undefined) MUST be reported together with the selected upper bound. The route that the LSP traverses MUST also be reported. The route MAY be collected via use of the record route object, see [RFC3209], or via the management plane. The collection of routes via the management plane is out of scope of this document.
メトリック結果（実際の数または未定義のいずれか）は、選択した上限と一緒に報告する必要があります。LSPが通過するルートも報告する必要があります。ルートは、レコードルートオブジェクトを使用して収集することができます。[RFC3209]または管理プレーンを介して。管理プレーンを介したルートの収集は、このドキュメントの範囲外です。
This section defines a metric for multiple unidirectional Label Switched Paths setup delay across a GMPLS network.
このセクションでは、GMPLSネットワーク全体で複数の単方向ラベルスイッチ付きパスセットアップ遅延のメトリックを定義します。
Multiple unidirectional Label Switched Paths setup delay is useful for several reasons:
複数の単方向ラベルスイッチ付きパスセットアップ遅延は、いくつかの理由で役立ちます。
o Carriers may require that a large number of LSPs be set up during a short time period. This request may arise, e.g., as a consequence to interruptions on established LSPs or other network failures.
o キャリアは、短期間に多数のLSPをセットアップすることを要求する場合があります。この要求は、例えば、確立されたLSPまたは他のネットワーク障害の中断の結果として発生する可能性があります。
o The time needed to set up a large number of LSPs during a short time period cannot be deduced from single LSP setup delay.
o 短期間に多数のLSPをセットアップするのに必要な時間は、単一のLSPセットアップ遅延から推測することはできません。
Multiple unidirectional LSPs setup delay
複数の単方向LSPセットアップ遅延
o ID0, the ingress LSR ID
o ID0、Ingress LSR ID
o ID1, the egress LSR ID
o id1、出力LSR ID
o Lambda_m, a rate in reciprocal milliseconds
o Lambda_m、相互ミリ秒のレート
o X, the number of LSPs to set up
o X、セットアップするLSPの数
o T, a time when the first setup is attempted
o t、最初のセットアップが試行される時期
The value of multiple unidirectional LSPs setup delay is either a real number of milliseconds or undefined
複数の単方向LSPSセットアップ遅延の値は、実際の数ミリ秒または未定義のいずれかです
Given Lambda_m and X, the multiple unidirectional LSPs setup delay from the ingress node to the egress node [RFC3945] at T is dT means:
lambda_mおよびxを考えると、Tのingressノードから出口ノード[RFC3945]までの複数の単方向LSPSセットアップ遅延は、次の平均です。
o ingress node ID0 sends the first bit of the first Path message packet to egress node ID1 at wire-time T;
o IngressノードID0は、ワイヤタイムTでNode ID1を出力するために最初のパスメッセージパケットの最初のビットを送信します。
o all subsequent (X-1) Path messages are sent according to the specified Poisson process with arrival rate Lambda_m;
o すべての後続の（x-1）パスメッセージは、指定されたポアソンプロセスに従って到着率lambda_m;
o ingress node ID0 receives all corresponding Resv message packets from egress node ID1; and
o IngressノードID0は、EgressノードID1から対応するすべてのRESVメッセージパケットを受信します。と
o ingress node ID0 receives the last Resv message packet at wire-time T+dT.
o IngressノードID0は、ワイヤタイムT DTで最後のRESVメッセージパケットを受信します。
If the multiple unidirectional LSPs setup delay at T is "undefined", this means that:
Tでの複数の単方向LSPSセットアップ遅延が「未定義」である場合、これは次のことを意味します。
o ingress node ID0 sends all the Path messages toward egress node ID1,
o IngressノードID0は、すべてのパスメッセージを出力ノードID1に送信します。
o the first bit of the first Path message packet is sent at wire-time T, and
o 最初のパスメッセージパケットの最初のビットは、ワイヤタイムTで送信され、
o ingress node ID0 does not receive one or more of the corresponding Resv messages within a reasonable period of time.
o IngressノードID0は、合理的な期間内に対応するRESVメッセージの1つ以上を受信しません。
The undefined value of this metric indicates an event of Multiple Unidirectional LSP Setup Failure and would be used to report a count or a percentage of Multiple Unidirectional LSP Setup failures. See Section 14.5 for definitions of LSP setup/release failures.
このメトリックの未定義の値は、複数の単方向LSPセットアップ障害のイベントを示し、複数の単方向LSPセットアップ障害のカウントまたは割合を報告するために使用されます。LSPセットアップ/リリース障害の定義については、セクション14.5を参照してください。
The following issues are likely to come up in practice:
以下の問題は実際に発生する可能性があります。
o The accuracy of multiple unidirectional LSPs setup delay at time T depends on the clock resolution in the ingress node; but synchronization between the ingress node and egress node is not required since unidirectional LSP setup uses two-way signaling.
o 時間tでの複数の単方向LSPSセットアップ遅延の精度は、イングレスノードのクロック解像度に依存します。ただし、単方向LSPセットアップでは双方向シグナリングを使用するため、イングレスノードと出口ノード間の同期は必要ありません。
o A given methodology will have to include a way to determine whether a latency value is infinite or whether it is merely very large. Simple upper bounds MAY be used, but GMPLS networks may accommodate many kinds of devices. For example, some photonic cross-connects (PXCs) have to move micro mirrors. This physical motion may take several milliseconds, but electronic switches can finish the nodal processing within several microseconds. So the multiple unidirectional LSP setup delay varies drastically from one network to another. In practice, the upper bound SHOULD be chosen carefully.
o 特定の方法論には、レイテンシ値が無限であるかどうか、または単に非常に大きいかどうかを判断する方法を含める必要があります。単純な上限を使用することもできますが、GMPLSネットワークは多くの種類のデバイスに対応する場合があります。たとえば、一部のフォトニッククロスコネクト（PXC）はマイクロミラーを移動する必要があります。この物理的な動きには数ミリ秒かかる場合がありますが、電子スイッチは数マイクロ秒以内にノード処理を終了できます。したがって、複数の単方向LSPセットアップの遅延は、ネットワークによって劇的に異なります。実際には、上限を慎重に選択する必要があります。
o If the ingress node sends out the multiple Path messages to set up the LSPs, but never receives one or more of the corresponding Resv messages, multiple unidirectional LSP setup delay MUST be set to undefined.
o Ingressノードが複数のパスメッセージを送信してLSPをセットアップするが、対応するRESVメッセージの1つ以上を受信しない場合、複数の単方向LSPセットアップ遅延を未定義に設定する必要があります。
o If the ingress node sends out the Path messages to set up the LSPs but receives one or more PathErr messages, multiple unidirectional LSPs setup delay MUST be set to undefined. There are many possible reasons for this case. For example, one of the Path messages has invalid parameters or the network does not have enough resources to set up the requested LSPs, etc.
o IngressノードがPATHメッセージを送信してLSPをセットアップするが、1つ以上のPatherRメッセージを受信する場合、複数の単方向LSPSセットアップ遅延を未定義に設定する必要があります。このケースには多くの理由があります。たとえば、パスメッセージの1つに無効なパラメーターがあるか、ネットワークには要求されたLSPなどを設定するのに十分なリソースがありません。
o The arrival rate of the Poisson process Lambda_m SHOULD be chosen carefully such that on the one hand, the control plane is not overburdened. On the other hand, the arrival rate is large enough to meet the requirements of applications or services.
o ポアソンプロセスの到着率Lambda_mは、一方でコントロールプレーンが過負荷にならないように慎重に選択する必要があります。一方、到着率は、アプリケーションまたはサービスの要件を満たすのに十分な大きさです。
o It is important that all the LSPs MUST traverse the same route. If there are multiple routes between the ingress node ID0 and egress node ID1, Explicit Route Objects (EROs), or an alternate method, e.g., static configuration, MUST be used to ensure that all LSPs traverse the same route.
o すべてのLSPが同じルートを横断する必要があることが重要です。イングレスノードID0と出口ノードID1の間に複数のルートがある場合、明示的なルートオブジェクト（EROS）、またはたとえば静的構成などの代替方法を使用して、すべてのLSPが同じルートを横断することを確認する必要があります。
Generally, the methodology would proceed as follows:
一般に、方法論は次のように進行します。
o Make sure that the network has enough resources to set up the requested LSPs.
o ネットワークに、要求されたLSPを設定するのに十分なリソースがあることを確認してください。
o At the ingress node, form the Path messages according to the LSPs' requirements.
o Ingressノードで、LSPSの要件に従ってパスメッセージを形成します。
o At the ingress node, select the time for each of the Path messages according to the specified Poisson process.
o イングレスノードで、指定されたポアソンプロセスに従って各パスメッセージの時間を選択します。
o At the ingress node, send out the Path messages according to the selected time.
o イングレスノードで、選択した時間に従ってパスメッセージを送信します。
o Store a timestamp (T1) locally on the ingress node when the first Path message packet is sent towards the egress node.
o 最初のパスメッセージパケットが出口ノードに送られたときに、タイムスタンプ（T1）をイングレスノードにローカルに保存します。
o If all of the corresponding Resv messages arrive within a reasonable period of time, take the final timestamp (T2) as soon as possible upon the receipt of all the messages. By subtracting the two timestamps, an estimate of multiple unidirectional LSPs setup delay (T2-T1) can be computed.
o 対応するすべてのRESVメッセージが妥当な期間内に到着した場合、すべてのメッセージを受信したときにできるだけ早く最終的なタイムスタンプ（T2）を取ります。2つのタイムスタンプを減算することにより、複数の単方向LSPSセットアップ遅延（T2-T1）の推定値を計算できます。
o If one or more of the corresponding Resv messages fail to arrive within a reasonable period of time, the multiple unidirectional LSPs setup delay is deemed to be undefined. Note that the "reasonable" threshold is a parameter of the methodology.
o 対応するRESVメッセージの1つ以上が妥当な期間内に到着できない場合、複数の単方向LSPSセットアップ遅延は未定義であるとみなされます。「合理的な」しきい値は、方法論のパラメーターであることに注意してください。
o If one or more of the corresponding responses are PathErr messages, the multiple unidirectional LSPs setup delay is deemed to be undefined.
o 対応する応答の1つ以上がPatherRメッセージである場合、複数の単方向LSPSセットアップ遅延が未定義であるとみなされます。
The metric result (either a real number or undefined) MUST be reported together with the selected upper bound. The route that the LSPs traverse MUST also be reported. The route MAY be collected via use of the record route object, see [RFC3209], or via the management plane. The collection of routes via the management plane is out of scope of this document.
メトリック結果（実際の数または未定義のいずれか）は、選択した上限と一緒に報告する必要があります。LSPSトラバースのルートも報告する必要があります。ルートは、レコードルートオブジェクトを使用して収集することができます。[RFC3209]または管理プレーンを介して。管理プレーンを介したルートの収集は、このドキュメントの範囲外です。
GMPLS allows establishment of bidirectional symmetric LSPs (not of asymmetric LSPs). This section defines a metric for single bidirectional LSP setup delay across a GMPLS network.
GMPLは、双方向対称LSP（非対称LSPではない）の確立を可能にします。このセクションでは、GMPLSネットワーク全体で単一の双方向LSPセットアップ遅延のメトリックを定義します。
Single bidirectional Label Switched Path setup delay is useful for several reasons:
単一の双方向ラベルの切り替えパスセットアップ遅延は、いくつかの理由で役立ちます。
o LSP setup delay is an important metric that characterizes the provisioning performance of a GMPLS network. Longer LSP setup delay will incur higher overhead for the requesting application, especially when the LSP duration is comparable to the LSP setup delay. Thus, measuring the setup delay is important for application scheduling.
o LSPセットアップ遅延は、GMPLSネットワークのプロビジョニングパフォーマンスを特徴付ける重要なメトリックです。LSPのセットアップ遅延が長くなると、特にLSPのセットアップ遅延に匹敵する場合、要求アプリケーションのオーバーヘッドが高くなります。したがって、セットアップ遅延を測定することは、アプリケーションのスケジューリングに重要です。
o The minimum value of this metric provides an indication of the delay that will likely be experienced when the LSP traverses the shortest route at the lightest load in the control plane. As the delay itself consists of several components, such as link propagation delay and nodal processing delay, this metric also reflects the status of the control plane. For example, for LSPs traversing the same route, longer setup delays may suggest congestion in the control channel or high control element load. For this reason, this metric is useful for testing and diagnostic purposes.
o このメトリックの最小値は、LSPがコントロールプレーンの最も軽い荷重で最も短いルートを横断するときに経験される可能性が高い遅延を示すことを示します。遅延自体は、リンク伝播遅延や節点処理遅延などのいくつかのコンポーネントで構成されているため、このメトリックはコントロールプレーンの状態も反映しています。たとえば、同じルートを横断するLSPの場合、セットアップの遅延が長くなると、コントロールチャネルまたは高制御要素の荷重が渋滞を示唆する場合があります。このため、このメトリックはテストと診断の目的に役立ちます。
o LSP setup delay variance has a different impact on applications. Erratic variation in LSP setup delay makes it difficult to support applications that have stringent setup delay requirement.
o LSPセットアップ遅延差異は、アプリケーションに異なる影響を及ぼします。LSPセットアップ遅延の不安定な変動により、厳しいセットアップ遅延要件があるアプリケーションをサポートすることが困難です。
The measurement of single bidirectional LSP setup delay instead of unidirectional LSP setup delay is motivated by the following factors:
単方向LSPセットアップ遅延の代わりに単一の双方向LSPセットアップ遅延の測定は、次の要因によって動機付けられています。
o Bidirectional LSPs are seen as a requirement for many GMPLS networks. Its provisioning performance is important to applications that generate bidirectional traffic.
o 双方向LSPは、多くのGMPLSネットワークの要件と見なされています。そのプロビジョニングパフォーマンスは、双方向トラフィックを生成するアプリケーションにとって重要です。
Single bidirectional LSP setup delay
単一の双方向LSPセットアップ遅延
o ID0, the ingress LSR ID
o ID0、Ingress 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 single bidirectional LSP setup delay is either a real number of milliseconds or undefined
単一の双方向LSPセットアップ遅延の値は、実際のミリ秒または未定義のいずれかです
For a real number dT, the single bidirectional LSP setup delay from ingress node ID0 to egress node ID1 at T is dT means that ingress node ID0 sends out the first bit of a Path message including an Upstream Label [RFC3473] heading for egress node ID1 at wire-time T, egress node ID1 receives that packet, then immediately sends a Resv message packet back to ingress node ID0, and that ingress node ID0 receives the last bit of the Resv message packet at wire-time T+dT.
実数DTの場合、IngressノードID0からTでの出力ノードID1への単一の双方向LSPセットアップ遅延は、イングレスノードID0が上流ラベル[RFC3473]を含むパスメッセージの最初のビットを送信することを意味します。Wire-Time Tでは、Egress Node ID1がそのパケットを受信し、すぐにRESVメッセージパケットを送信してNodeノードID0をイングレスし、NodeノードID0がワイヤタイムT DTでRESVメッセージパケットの最後のビットを受信します。
If the single bidirectional LSP setup delay from ingress node ID0 to egress node ID1 at T is "undefined", this means that ingress node ID0 sends the first bit of a Path message to egress node ID1 at wire-time T and that ingress node ID0 does not receive that response packet within a reasonable period of time.
単一の双方向LSPセットアップ遅延がイングレスノードID0からTでの出力ノードID1への遅延が「未定義」である場合、これは、イングレスノードID0がワイヤタイムTでの出力ノードID1にパスメッセージの最初のビットを送信し、イングレスノードID0を送信することを意味します合理的な期間内にその応答パケットを受け取っていません。
The undefined value of this metric indicates an event of Single Bidirectional LSP Setup Failure and would be used to report a count or a percentage of Single Bidirectional LSP Setup failures. See Section 14.5 for definitions of LSP setup/release failures.
このメトリックの未定義の値は、単一の双方向LSPセットアップ障害のイベントを示し、単一の双方向LSPセットアップ障害のカウントまたは割合を報告するために使用されます。LSPセットアップ/リリース障害の定義については、セクション14.5を参照してください。
The following issues are likely to come up in practice:
以下の問題は実際に発生する可能性があります。
o The accuracy of single bidirectional LSP setup delay depends on the clock resolution in the ingress node; but synchronization between the ingress node and egress node is not required since single bidirectional LSP setup uses two-way signaling.
o 単一の双方向LSPセットアップ遅延の精度は、イングレスノードの時計解像度に依存します。ただし、単一の双方向LSPセットアップでは双方向シグナリングを使用するため、イングレスノードと出口ノード間の同期は必要ありません。
o A given methodology will have to include a way to determine whether a latency value is infinite or whether it is merely very large. Simple upper bounds MAY be used, but GMPLS networks may accommodate many kinds of devices. For example, some photonic cross-connects (PXCs) have to move micro mirrors. This physical motion may take several milliseconds, but electronic switches can finish the nodal processing within several microseconds. So the bidirectional LSP setup delay varies drastically from one network to another. In the process of bidirectional LSP setup, if the downstream node overrides the label suggested by the upstream node, the setup delay may also increase. Thus, in practice, the upper bound SHOULD be chosen carefully.
o 特定の方法論には、レイテンシ値が無限であるかどうか、または単に非常に大きいかどうかを判断する方法を含める必要があります。単純な上限を使用することもできますが、GMPLSネットワークは多くの種類のデバイスに対応する場合があります。たとえば、一部のフォトニッククロスコネクト（PXC）はマイクロミラーを移動する必要があります。この物理的な動きには数ミリ秒かかる場合がありますが、電子スイッチは数マイクロ秒以内にノード処理を終了できます。したがって、双方向LSPセットアップの遅延は、ネットワークによって劇的に異なります。双方向LSPセットアップの過程で、下流ノードが上流ノードによって提案されたラベルをオーバーライドすると、セットアップの遅延も増加する可能性があります。したがって、実際には、上限を慎重に選択する必要があります。
o If the ingress node sends out the Path message to set up the LSP, but never receives the corresponding Resv message, single bidirectional LSP setup delay MUST be set to undefined.
o IngressノードがLSPをセットアップするためにパスメッセージを送信するが、対応するRESVメッセージを受信しない場合、単一の双方向LSPセットアップ遅延を未定義に設定する必要があります。
o If the ingress node sends out the Path message to set up the LSP, but receives a PathErr message, single bidirectional LSP setup delay MUST be set to undefined. There are many possible reasons for this case. For example, the Path message has invalid parameters or the network does not have enough resources to set up the requested LSP.
o IngressノードがLSPをセットアップするためにパスメッセージを送信するが、Patherrメッセージを受信する場合、単一の双方向LSPセットアップ遅延を未定義に設定する必要があります。このケースには多くの理由があります。たとえば、パスメッセージには無効なパラメーターがあるか、ネットワークには要求されたLSPを設定するのに十分なリソースがありません。
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 At the ingress node, form the Path message (including the Upstream Label or suggested label) according to the LSP requirements. A timestamp (T1) may be stored locally on the ingress node when the Path message packet is sent towards the egress node.
o Ingressノードでは、LSP要件に従ってパスメッセージ（上流ラベルまたは提案されたラベルを含む）を形成します。タイムスタンプ（T1）は、パスメッセージパケットが出口ノードに向けて送信されると、イングレスノードにローカルに保存できます。
o If the corresponding Resv message arrives within a reasonable period of time, take the final timestamp (T2) as soon as possible upon the receipt of the message. By subtracting the two timestamps, an estimate of bidirectional LSP setup delay (T2-T1) can be computed.
o 対応するRESVメッセージが妥当な期間内に到着した場合、メッセージの受信時に最終的なタイムスタンプ（T2）をできるだけ早く取ります。2つのタイムスタンプを減算することにより、双方向LSPセットアップ遅延（T2-T1）の推定値を計算できます。
o If the corresponding Resv message fails to arrive within a reasonable period of time, the single bidirectional LSP setup delay is deemed to be undefined. Note that the "reasonable" threshold is a parameter of the methodology.
o 対応するRESVメッセージが合理的な期間内に到着できない場合、単一の双方向LSPセットアップ遅延は未定義であるとみなされます。「合理的な」しきい値は、方法論のパラメーターであることに注意してください。
o If the corresponding response is a PathErr message, the single bidirectional LSP setup delay is deemed to be undefined.
o 対応する応答がPatherRメッセージである場合、単一の双方向LSPセットアップ遅延は未定義であるとみなされます。
The metric result (either a real number or undefined) MUST be reported together with the selected upper bound. The route that the LSP traverses MUST also be reported. The route MAY be collected via use of the record route object, see [RFC3209], or via the management plane. The collection of routes via the management plane is out of scope of this document.
メトリック結果（実際の数または未定義のいずれか）は、選択した上限と一緒に報告する必要があります。LSPが通過するルートも報告する必要があります。ルートは、レコードルートオブジェクトを使用して収集することができます。[RFC3209]または管理プレーンを介して。管理プレーンを介したルートの収集は、このドキュメントの範囲外です。
This section defines a metric for multiple bidirectional LSPs setup delay across a GMPLS network.
このセクションでは、GMPLSネットワーク全体で複数の双方向LSPSセットアップ遅延のメトリックを定義します。
Multiple bidirectional LSPs setup delay is useful for several reasons:
複数の双方向LSPのセットアップ遅延は、いくつかの理由で役立ちます。
o Upon traffic interruption caused by network failure or network upgrade, carriers may require a large number of LSPs be set up during a short time period.
o ネットワークの障害またはネットワークのアップグレードによって引き起こされるトラフィックの中断が発生すると、キャリアは短期間に多数のLSPを設定する必要があります。
o The time needed to set up a large number of LSPs during a short time period cannot be deduced by single LSP setup delay.
o 短期間に多数のLSPをセットアップするのに必要な時間は、単一のLSPセットアップ遅延によって推測することはできません。
Multiple bidirectional LSPs setup delay
複数の双方向LSPセットアップ遅延
o ID0, the ingress LSR ID
o ID0、Ingress LSR ID
o ID1, the egress LSR ID
o id1、出力LSR ID
o Lambda_m, a rate in reciprocal milliseconds
o Lambda_m、相互ミリ秒のレート
o X, the number of LSPs to set up
o X、セットアップするLSPの数
o T, a time when the first setup is attempted
o t、最初のセットアップが試行される時期
The value of multiple bidirectional LSPs setup delay is either a real number of milliseconds or undefined
複数の双方向LSPSセットアップ遅延の値は、実際のミリ秒または未定義のいずれかです
Given Lambda_m and X, for a real number dT, the multiple bidirectional LSPs setup delay from ingress node to egress node at T is dT, means that:
lambda_mおよびxを考えると、実数dtの場合、イングレスノードからTでの出口ノードまでの複数の双方向LSPSセットアップ遅延はdt、次のことを意味します。
o Ingress node ID0 sends the first bit of the first Path message heading for egress node ID1 at wire-time T;
o IngressノードID0は、ワイヤタイムTでの出力ノードID1に向かう最初のパスメッセージの最初のビットを送信します。
o All subsequent (X-1) Path messages are sent according to the specified Poisson process with arrival rate Lambda_m;
o すべての後続の（x-1）パスメッセージは、指定されたポアソンプロセスに従って到着率lambda_m;
o Ingress node ID1 receives all corresponding Resv message packets from egress node ID1; and
o IngressノードID1は、EgressノードID1から対応するすべてのRESVメッセージパケットを受信します。と
o Ingress node ID0 receives the last Resv message packet at wire-time T+dT.
o IngressノードID0は、ワイヤタイムT DTで最後のRESVメッセージパケットを受信します。
If the multiple bidirectional LSPs setup delay from ingress node to egress node at T is "undefined", this means that the ingress node sends all the Path messages to the egress node and that the ingress node fails to receive one or more of the response Resv messages within a reasonable period of time.
複数の双方向LSPSセットアップ遅延がイングレスノードからTでの出口ノードまでの遅延が「未定義」である場合、これはイングレスノードがすべてのパスメッセージを出力ノードに送信し、イングレスノードが1つ以上の応答resvを受信できないことを意味します合理的な期間内のメッセージ。
The undefined value of this metric indicates an event of Multiple Bidirectional LSP Setup Failure and would be used to report a count or a percentage of Multiple Bidirectional LSP Setup failures. See Section 14.5 for definitions of LSP setup/release failures.
このメトリックの未定義の値は、複数の双方向LSPセットアップ障害のイベントを示し、複数の双方向LSPセットアップ障害のカウントまたは割合を報告するために使用されます。LSPセットアップ/リリース障害の定義については、セクション14.5を参照してください。
The following issues are likely to come up in practice:
以下の問題は実際に発生する可能性があります。
o The accuracy of multiple bidirectional LSPs setup delay depends on the clock resolution in the ingress node; but synchronization between the ingress node and egress node is not required since bidirectional LSP setup uses two-way signaling.
o 複数の双方向LSPSセットアップ遅延の精度は、イングレスノードの時計解像度に依存します。ただし、双方向のLSPセットアップでは双方向シグナリングを使用するため、イングレスノードと出口ノード間の同期は必要ありません。
o A given methodology will have to include a way to determine whether a latency value is infinite or whether it is merely very large. Simple upper bounds MAY be used, but GMPLS networks may accommodate many kinds of devices. For example, some photonic cross-connects (PXCs) have to move micro mirrors. This physical motion may take several milliseconds, but electronic switches can finish the nodal process within several microseconds. So the multiple bidirectional LSPs setup delay varies drastically from a network to another. In the process of multiple bidirectional LSPs setup, if the downstream node overrides the label suggested by the upstream node, the setup delay may also increase. Thus, in practice, the upper bound SHOULD be chosen carefully.
o 特定の方法論には、レイテンシ値が無限であるかどうか、または単に非常に大きいかどうかを判断する方法を含める必要があります。単純な上限を使用することもできますが、GMPLSネットワークは多くの種類のデバイスに対応する場合があります。たとえば、一部のフォトニッククロスコネクト（PXC）はマイクロミラーを移動する必要があります。この物理的な動きには数ミリ秒かかる場合がありますが、電子スイッチは数マイクロ秒以内にノードプロセスを完了することができます。したがって、複数の双方向LSPのセットアップ遅延は、ネットワークから別のネットワークまで劇的に異なります。複数の双方向LSPSセットアップの過程で、下流ノードが上流ノードによって提案されたラベルをオーバーライドすると、セットアップの遅延も増加する可能性があります。したがって、実際には、上限を慎重に選択する必要があります。
o If the ingress node sends out the Path messages to set up the LSPs, but never receives all the corresponding Resv messages, the multiple bidirectional LSPs setup delay MUST be set to undefined.
o IngressノードがPATHメッセージを送信してLSPをセットアップするが、対応するすべてのRESVメッセージを受信しない場合、複数の双方向LSPSセットアップ遅延を未定義に設定する必要があります。
o If the ingress node sends out the Path messages to set up the LSPs, but receives one or more responding PathErr messages, the multiple bidirectional LSPs setup delay MUST be set to undefined. There are many possible reasons for this case. For example, one or more of the Path messages have invalid parameters or the network does not have enough resources to set up the requested LSPs.
o IngressノードがPATHメッセージを送信してLSPをセットアップするが、1つまたは複数の応答するPATHERRメッセージを受信する場合、複数の双方向LSPSセットアップ遅延を未定義に設定する必要があります。このケースには多くの理由があります。たとえば、1つ以上のパスメッセージには無効なパラメーターがあるか、ネットワークには要求されたLSPを設定するのに十分なリソースがありません。
o The arrival rate of the Poisson process Lambda_m SHOULD be carefully chosen such that on the one hand, the control plane is not overburdened. On the other hand, the arrival rate is large enough to meet the requirements of applications or services.
o ポアソンプロセスの到着率Lambda_mは、一方でコントロールプレーンが過負荷にならないように、慎重に選択する必要があります。一方、到着率は、アプリケーションまたはサービスの要件を満たすのに十分な大きさです。
o It is important that all the LSPs MUST traverse the same route. If there are multiple routes between the ingress node ID0 and egress node ID1, EROs, or an alternate method, e.g., static configuration, MUST be used to ensure that all LSPs traverse the same route.
o すべてのLSPが同じルートを横断する必要があることが重要です。イングレスノードID0と出口ノードID1の間に複数のルートがある場合、EROS、または代替メソッド、たとえば静的構成を使用して、すべてのLSPが同じルートを横断することを確認する必要があります。
Generally, the methodology would proceed as follows:
一般に、方法論は次のように進行します。
o Make sure that the network has enough resources to set up the requested LSPs.
o ネットワークに、要求されたLSPを設定するのに十分なリソースがあることを確認してください。
o At the ingress node, form the Path messages (including the Upstream Label or suggested label) according to the LSPs' requirements.
o Ingressノードでは、LSPSの要件に従ってパスメッセージ（上流ラベルまたは提案されたラベルを含む）を形成します。
o At the ingress node, select the time for each of the Path messages according to the specified Poisson process.
o イングレスノードで、指定されたポアソンプロセスに従って各パスメッセージの時間を選択します。
o At the ingress node, send out the Path messages according to the selected time.
o イングレスノードで、選択した時間に従ってパスメッセージを送信します。
o Store a timestamp (T1) locally in the ingress node when the first Path message packet is sent towards the egress node.
o 最初のパスメッセージパケットが出口ノードに送られたときに、タイムスタンプ（T1）をイングレスノードにローカルに保存します。
o If all of the corresponding Resv messages arrive within a reasonable period of time, take the final timestamp (T2) as soon as possible upon the receipt of all the messages. By subtracting the two timestamps, an estimate of multiple bidirectional LSPs setup delay (T2-T1) can be computed.
o 対応するすべてのRESVメッセージが妥当な期間内に到着した場合、すべてのメッセージを受信したときにできるだけ早く最終的なタイムスタンプ（T2）を取ります。2つのタイムスタンプを減算することにより、複数の双方向LSPSセットアップ遅延（T2-T1）の推定値を計算できます。
o If one or more of the corresponding Resv messages fail to arrive within a reasonable period of time, the multiple bidirectional LSPs setup delay is deemed to be undefined. Note that the "reasonable" threshold is a parameter of the methodology.
o 対応するRESVメッセージの1つ以上が合理的な期間内に到着できない場合、複数の双方向LSPSセットアップ遅延は未定義であるとみなされます。「合理的な」しきい値は、方法論のパラメーターであることに注意してください。
o If one or more of the corresponding responses are PathErr messages, the multiple bidirectional LSPs setup delay is deemed to be undefined.
o 対応する応答の1つ以上がPatherRメッセージである場合、複数の双方向LSPSセットアップ遅延が未定義であるとみなされます。
The metric result (either a real number or undefined) MUST be reported together with the selected upper bound. The route that the LSPs traverse MUST also be reported. The route MAY be collected via use of the record route object, see [RFC3209], or via the management plane. The collection of routes via the management plane is out of scope of this document.
メトリック結果（実際の数または未定義のいずれか）は、選択した上限と一緒に報告する必要があります。LSPSトラバースのルートも報告する必要があります。ルートは、レコードルートオブジェクトを使用して収集することができます。[RFC3209]または管理プレーンを介して。管理プレーンを介したルートの収集は、このドキュメントの範囲外です。
There are two different kinds of LSP release mechanisms in GMPLS networks: graceful release and forceful release. This document does not take forceful LSP release procedure into account.
GMPLSネットワークには、2つの異なる種類のLSPリリースメカニズムがあります。優雅なリリースと強力なリリースです。このドキュメントでは、力強いLSPリリース手順を考慮していません。
LSP graceful release delay is useful for several reasons:
LSP Graceful Release Delayは、いくつかの理由で役立ちます。
o The LSP graceful release delay is part of the total cost of dynamic LSP provisioning. For some short duration applications, the LSP release time cannot be ignored.
o LSPの優雅なリリース遅延は、動的LSPプロビジョニングの総コストの一部です。一部の短い期間アプリケーションでは、LSPのリリース時間を無視することはできません。
o The LSP graceful release procedure is more preferred in a GMPLS controlled network, particularly the optical networks. Since it doesn't trigger restoration/protection, it is "alarm-free connection deletion" in [RFC4208].
o LSPの優雅なリリース手順は、GMPLS制御ネットワーク、特に光ネットワークでより優先されます。復元/保護をトリガーしないため、[RFC4208]の「アラームフリーの接続削除」です。
LSP graceful release delay
LSP優雅なリリース遅延
o ID0, the ingress LSR ID
o ID0、Ingress LSR ID
o ID1, the egress LSR ID
o id1、出力LSR ID
o T, a time when the release is attempted
o T、リリースが試行される時期
The value of LSP graceful release delay is either a real number of milliseconds or undefined
LSPの優雅なリリース遅延の値は、実際のミリ秒または未定義のいずれかです
There are two different LSP graceful release procedures: one is initiated by the ingress node, and another is initiated by the egress node. The two procedures are depicted in [RFC3473]. We define the graceful LSP release delay for these two procedures separately.
2つの異なるLSPの優雅なリリース手順があります。1つはイングレスノードによって開始され、もう1つは出口ノードによって開始されます。2つの手順は[RFC3473]に示されています。これら2つの手順の優雅なLSPリリース遅延を個別に定義します。
For a real number dT, if the LSP graceful release delay from ingress node ID0 to egress node ID1 at T is dT, this means that ingress node ID0 sends the first bit of a Path message including an Admin Status Object with the Reflect (R) and Delete (D) bits set to the egress node at wire-time T, that egress node ID1 receives that packet, then immediately sends a Resv message including an Admin Status Object with the Delete (D) bit set back to the ingress node. Ingress node ID0 sends the PathTear message downstream to remove the LSP, and egress node ID1 receives the last bit of PathTear packet at wire-time T+dT.
実数DTの場合、LSPの優雅なリリース遅延がイングレスノードID0からTでノードID1への出力ノードID1への優雅なリリース遅延がDTである場合、イングレスノードID0は、反射（r）を持つ管理ステータスオブジェクトを含むパスメッセージの最初のビットを送信することを意味します。削除（d）ビットは、ワイヤタイムtで出口ノードに設定されています。出口ノードID1がそのパケットを受信し、削除（d）ビットをイングレスノードに戻す管理者ステータスオブジェクトを含むRESVメッセージをすぐに送信します。IngressノードID0は、PathTearメッセージを下流に送信してLSPを削除し、Egress Node ID1はワイヤタイムT DTでPathTearパケットの最後のビットを受信します。
Also, as an option, upon receipt of the Path message including an Admin Status Object with the Reflect (R) and Delete (D) bits set, egress node ID1 may respond with a PathErr message with the Path_State_Removed flag set.
また、オプションとして、Reflect（r）とdelete（d）ビットセットを備えた管理者ステータスオブジェクトを含むパスメッセージを受信すると、EgressノードID1はpath_state_removedフラグセットを使用してpatherrメッセージで応答できます。
The LSP graceful release delay from ingress node ID0 to egress node ID1 at T is undefined means that ingress node ID0 sends the first bit of Path message to egress node ID1 at wire-time T and that (either the egress node does not receive the Path packet, the egress node does not send a corresponding Resv message packet in response, or the ingress node does not receive that Resv packet, and) egress node ID1 does not receive the PathTear message within a reasonable period of time.
IngressノードID0からTでのNodeノードID1へのingressノードへの優雅なリリース遅延は、イングレスノードID0がワイヤタイムTで脱出ノードID1に最初のパスメッセージを送信することを意味します（出口ノードはパスを受信しませんパケット、出力ノードは、対応するRESVメッセージパケットを応答して送信しません。また、IngressノードはそのRESVパケットを受信しません。
If the LSP graceful release delay from egress node ID1 to ingress node ID0 at T is dT, this means that egress node ID1 sends the first bit of a Resv message including an Admin Status Object with the Reflect (R) and Delete (D) bits set to the ingress node at wire-time T. Ingress node ID0 sends a PathTear message downstream to remove the LSP, and egress node ID1 receives the last bit of PathTear packet at wire-time T+dT.
LSPの優雅なリリース遅延は、EgressノードID1からTでノードID0を侵入するためにdtである場合、これは、出力ノードID1が反射（r）と削除（d）ビットを備えた管理者ステータスオブジェクトを含むRESVメッセージの最初のビットを送信することを意味します。ワイヤタイムでイングレスノードに設定されています。イングレスノードID0は、LSPを削除するためにPathTearメッセージを下流に送信し、Egress Node ID1はワイヤタイムT DTで最後のパステアパケットを受信します。
If the LSP graceful release delay from egress node ID1 to ingress node ID0 at T is "undefined", this means that egress node ID1 sends the first bit of Resv message including an Admin Status Object with the Reflect (R) and Delete (D) bits set to the ingress node ID0 at wire-time T and that (either the ingress node does not receive the Resv packet or the ingress node does not send PathTear message packet in response, and) egress node ID1 does not receive the PathTear message within a reasonable period of time.
LSPの優雅なリリース遅延は、TAT TでのNodeノードID1へのNodeノードID0へのNodeノードID0へのGrasefulリリースの遅延が「未定義」である場合、Egress Node ID1がREFS（R）とDelete（D）を含む管理ステータスオブジェクトを含むRESVメッセージの最初のビットを送信することを意味します。ワイヤタイムTでイングレスノードID0に設定されたビットおよびそれ（イングレスノードがRESVパケットを受信しないか、イングレスノードがそれに応じてPathTearメッセージパケットを送信しない）、およびEngressノードID1はPATHTEARメッセージを受信しません妥当な期間。
The undefined value of this metric indicates an event of LSP Graceful Release Failure and would be used to report a count or a percentage of LSP Graceful Release failures. See Section 14.5 for definitions of LSP setup/release failures.
このメトリックの未定義の値は、LSPの優雅なリリース障害のイベントを示し、LSPの優雅なリリース障害のカウントまたは割合を報告するために使用されます。LSPセットアップ/リリース障害の定義については、セクション14.5を参照してください。
The following issues are likely to come up in practice:
以下の問題は実際に発生する可能性があります。
o In the first (second) circumstance, the accuracy of LSP graceful release delay at time T depends on the clock resolution in the ingress (egress) node. In the first circumstance, synchronization between the ingress node and egress node is required, but it is not in the second circumstance.
o 最初の（2番目の）状況では、時間tでのLSPの優雅なリリース遅延の精度は、イングレス（出口）ノードのクロック解像度に依存します。最初の状況では、イングレスノードと出口ノードの間の同期が必要ですが、2番目の状況ではありません。
o A given methodology has to include a way to determine whether a latency value is infinite or whether it is merely very large. Simple upper bounds MAY be used, but the upper bound SHOULD be chosen carefully in practice.
o 特定の方法論には、レイテンシ値が無限であるかどうか、それとも単に非常に大きいかどうかを判断する方法を含める必要があります。単純な上限を使用することもできますが、上限は実際には慎重に選択する必要があります。
o In the first circumstance, if the ingress node sends out Path message including an Admin Status Object with the Reflect (R) and Delete (D) bits set to initiate LSP graceful release, but the egress node never receives the corresponding PathTear message, LSP graceful release delay MUST be set to undefined.
o 最初の状況では、イングレスノードがlspの優雅なリリースを開始するように設定されたriffer（r）と削除（d）ビットを含む管理者ステータスオブジェクトを含むパスメッセージを送信する場合、出力ノードは対応するパステアメッセージ、lsp gregulfulを受信することはありませんリリース遅延は未定義に設定する必要があります。
o In the second circumstance, if the egress node sends out the Resv message including an Admin Status Object with the Reflect (R) and Delete (D) bits set to initiate LSP graceful release, but never receives the corresponding PathTear message, LSP graceful release delay MUST be set to undefined.
o 2番目の状況では、出力ノードがLSPの優雅なリリースを開始するように設定されたriffer（r）と削除（d）ビットを含む管理者ステータスオブジェクトを含むRESVメッセージを送信する場合、対応するPathtearメッセージ、LSP Gracefulリリース遅延を受信することはありません未定義に設定する必要があります。
In the first circumstance, the methodology may proceed as follows:
最初の状況では、方法論は次のように進行する場合があります。
o Make sure the LSP to be deleted is set up;
o 削除するLSPがセットアップされていることを確認してください。
o At the ingress node, form the Path message including an Admin Status Object with the Reflect (R) and Delete (D) bits set. A timestamp (T1) may be stored locally on the ingress node when the Path message packet is sent towards the egress node.
o Ingressノードで、Reflect（R）と削除（D）ビットセットを備えた管理者ステータスオブジェクトを含むパスメッセージを形成します。タイムスタンプ（T1）は、パスメッセージパケットが出口ノードに向けて送信されると、イングレスノードにローカルに保存できます。
o Upon receiving the Path message including an Admin Status Object with the Reflect (R) and Delete (D) bits set, the egress node sends a Resv message including an Admin Status Object with the Delete (D) and Reflect (R) bits set. Alternatively, the egress node sends a PathErr message with the Path_State_Removed flag set upstream.
o Reflect（r）とdelete（d）ビットセットを備えた管理者ステータスオブジェクトを含むパスメッセージを受信すると、出力ノードは、削除（d）および反射（r）ビットセットを備えた管理者ステータスオブジェクトを含むRESVメッセージを送信します。あるいは、出口ノードは、Path_State_Removedフラグを上流に設定してPatherRメッセージを送信します。
o When the ingress node receives the Resv message or the PathErr message, it sends a PathTear message to remove the LSP.
o IngressノードがRESVメッセージまたはPatherRメッセージを受信すると、LSPを削除するためのPATHTEARメッセージを送信します。
o The egress node takes a timestamp (T2) once it receives the last bit of the PathTear message. The LSP graceful release delay is then (T2-T1).
o 出力ノードは、PathTearメッセージの最後のビットを受信すると、タイムスタンプ（T2）を取得します。LSPの優雅なリリース遅延は（T2-T1）です。
o If the ingress node sends the Path message downstream, but the egress node fails to receive the PathTear message within a reasonable period of time, the LSP graceful release delay is deemed to be undefined. Note that the "reasonable" threshold is a parameter of the methodology.
o Ingressノードがパスメッセージを下流に送信するが、Egressノードが合理的な期間内にPathTearメッセージを受信できない場合、LSPの優雅なリリース遅延は未定義であるとみなされます。「合理的な」しきい値は、方法論のパラメーターであることに注意してください。
In the second circumstance, the methodology would proceed as follows:
2番目の状況では、方法論は次のように進みます。
o Make sure the LSP to be deleted is set up;
o 削除するLSPがセットアップされていることを確認してください。
o On the egress node, form the Resv message including an Admin Status Object with the Reflect (R) and Delete (D) bits set. A timestamp may be stored locally on the egress node when the Resv message packet is sent towards the ingress node.
o 出力ノードで、反射（r）と削除（d）ビットセットを備えた管理者ステータスオブジェクトを含むRESVメッセージを形成します。RESVメッセージパケットがイングレスノードに向かって送信されると、タイムスタンプは出力ノードにローカルに保存できます。
o Upon receiving the Admin Status Object with the Reflect (R) and Delete (D) bits set in the Resv message, the ingress node sends a PathTear message downstream to remove the LSP.
o RESVメッセージに設定された反射（r）と削除（d）ビットを使用して管理者ステータスオブジェクトを受信すると、IngressノードはLSPを削除するためにPathtearメッセージを下流に送信します。
o The egress node takes a timestamp (T2) once it receives the last bit of the PathTear message. The LSP graceful release delay is then (T2-T1).
o 出力ノードは、PathTearメッセージの最後のビットを受信すると、タイムスタンプ（T2）を取得します。LSPの優雅なリリース遅延は（T2-T1）です。
o If the egress node sends the Resv message upstream, but it fails to receive the PathTear message within a reasonable period of time, the LSP graceful release delay is deemed to be undefined. Note that the "reasonable" threshold is a parameter of the methodology.
o 出力ノードがRESVメッセージを上流に送信するが、合理的な期間内にPathTearメッセージを受信できない場合、LSPの優雅なリリース遅延は未定義であるとみなされます。「合理的な」しきい値は、方法論のパラメーターであることに注意してください。
The metric result (either a real number or undefined) MUST be reported together with the selected upper bound and the procedure used (e.g., either from the ingress node to the egress node or from the egress node to the ingress node; see Section 8.5 for more details). The route that the LSP traverses MUST also be reported. The route MAY be collected via use of the record route object, see [RFC3209], or via the management plane. The collection of routes via the management plane is out of scope of this document.
メトリックの結果（実数または未定義のいずれか）は、選択した上限と使用された手順（例：イングレスノードから出口ノードへ、または出口ノードからイングレスノードへの手順とともに報告する必要があります。セクション8.5を参照してください。詳細）。LSPが通過するルートも報告する必要があります。ルートは、レコードルートオブジェクトを使用して収集することができます。[RFC3209]または管理プレーンを介して。管理プレーンを介したルートの収集は、このドキュメントの範囲外です。
In Section 4, we defined the singleton metric of single unidirectional LSP setup delay. Now we define how to get one particular sample of single unidirectional LSP setup delay. Sampling means to take a number of distinct instances of a skeleton metric under a given set of parameters. As in [RFC2330], we use Poisson sampling as an example.
セクション4では、単一の単方向LSPセットアップ遅延のシングルトンメトリックを定義しました。次に、単一の単方向LSPセットアップ遅延の特定のサンプルを1つ取得する方法を定義します。サンプリングとは、特定のパラメーターセットの下でスケルトンメトリックの多くの異なるインスタンスを取得することを意味します。[RFC2330]のように、例としてポアソンサンプリングを使用します。
Single unidirectional LSP setup delay sample
単一方向LSPセットアップ遅延サンプル
o ID0, the ingress LSR ID
o ID0、Ingress 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 the reciprocal milliseconds
o ラムダ、相互ミリ秒のレート
o Th, LSP holding time
o TH、LSP保持時間
o Td, the maximum waiting time for successful setup
o TD、セットアップが成功するための最大待ち時間
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 unidirectional LSP setup delay sample. The value of the sample is the sequence made up of the resulting <time, LSP setup 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を考慮して、平均到着率LambdaでT0から始まり、TFで終了する擬似ランダムポアソンプロセスを計算します。T0以上およびTF以下のこれらの時間値が選択されます。このプロセスの各時間で、単方向LSPセットアップ遅延サンプルの値を取得します。サンプルの値は、結果の<時間、LSPセットアップ遅延>ペアで構成されるシーケンスです。そのようなペアがない場合、シーケンスは長さゼロであり、サンプルは空であると言われています。
The parameter Lambda should be carefully chosen. If the rate is too high, too frequent LSP setup/release procedure will result in high overhead in the control plane. In turn, the high overhead will increase unidirectional LSP setup delay. On the other hand, if the rate is too low, the sample might not completely reflect the dynamic provisioning performance of the GMPLS network. The appropriate Lambda value depends on the given network.
パラメーターラムダは慎重に選択する必要があります。レートが高すぎる場合、LSPのセットアップ/リリース手順が頻繁すぎると、コントロールプレーンのオーバーヘッドが高くなります。次に、オーバーヘッドが高いと、一方向のLSPセットアップ遅延が増加します。一方、レートが低すぎる場合、サンプルはGMPLSネットワークの動的プロビジョニングパフォーマンスを完全に反映していない可能性があります。適切なラムダ値は、指定されたネットワークに依存します。
The parameters Td should be carefully chosen. Different switching technologies may vary significantly in performing a cross-connect operation. At the same time, the time needed in setting up an LSP under different traffic may also vary significantly.
パラメーターTDを慎重に選択する必要があります。異なるスイッチング技術は、相互接続操作の実行で大きく異なる場合があります。同時に、異なるトラフィックでLSPをセットアップするのに必要な時間も大きく異なる場合があります。
In the case of active measurement, the parameters Th should be carefully chosen. The combination of Lambda and Th reflects the load of the network. The selection of Th should take into account that the network has sufficient resources to perform subsequent tests. The value of Th MAY be constant during one sampling process for simplicity considerations.
アクティブ測定の場合、パラメーターを慎重に選択する必要があります。LambdaとTHの組み合わせは、ネットワークの負荷を反映しています。THの選択では、ネットワークには後続のテストを実行するのに十分なリソースがあることを考慮に入れる必要があります。単純さの考慮事項のために、1つのサンプリングプロセス中にTHの値が一定になる場合があります。
Note that for online or passive measurements, the arrival rate and LSP holding time are determined by actual traffic; hence, in this case, Lambda and Th are not input parameters.
オンラインまたはパッシブ測定の場合、到着率とLSP保持時間は実際のトラフィックによって決定されることに注意してください。したがって、この場合、LambdaとTHは入力パラメーターではありません。
It is important that, in obtaining a sample, all the LSPs MUST traverse the same route. If there are multiple routes between the ingress node ID0 and egress node ID1, EROs, or an alternate method, e.g., static configuration, MUST be used to ensure that all LSPs traverse the same route.
サンプルを取得する際に、すべてのLSPが同じルートを横断する必要があることが重要です。イングレスノードID0と出口ノードID1の間に複数のルートがある場合、EROS、または代替メソッド、たとえば静的構成を使用して、すべてのLSPが同じルートを横断することを確認する必要があります。
o Select the times using the specified Poisson arrival process,
o 指定されたポアソン到着プロセスを使用して時間を選択し、
o Set up the LSP as the methodology for the singleton unidirectional LSP setup delay, and obtain the value of unidirectional LSP setup delay, and
o LSPをシングルトン単方向LSPセットアップ遅延の方法論として設定し、単方向LSPセットアップ遅延の値を取得し、
o Release the LSP after Th, and wait for the next Poisson arrival event.
o THの後にLSPをリリースし、次のポアソン到着イベントを待ちます。
Note: it is possible that before the previous LSP release procedure completes, the next Poisson arrival event arrives and the LSP setup procedure is initiated. If there is resource contention between the two LSPs, the LSP setup may fail. Ways to avoid such contention are outside the scope of this document.
注：以前のLSPリリース手順が完了する前に、次のポアソン到着イベントが到着し、LSPセットアップ手順が開始される可能性があります。2つのLSPの間にリソースの競合がある場合、LSPセットアップが失敗する可能性があります。そのような競合を回避する方法は、この文書の範囲外です。
Single unidirectional LSP setup delay with no LSP in the network is important because this reflects the inherent delay of a Resource Reservation Protocol - Traffic Engineering (RSVP-TE) implementation. The minimum value provides an indication of the delay that will likely be experienced when an LSP traverses the shortest route with the lightest load in the control plane.
ネットワークにLSPがない単一の単方向LSPセットアップ遅延は重要です。これは、リソース予約プロトコル - トラフィックエンジニアリング（RSVP -TE）の実装の固有の遅延を反映しているためです。最小値は、LSPがコントロールプレーンで最も軽い荷重を伴う最短ルートを横断するときに経験される可能性が高い遅延を示すことを提供します。
Make sure that there is no LSP in the network and proceed with the methodologies described in Section 9.6
ネットワークにLSPがないことを確認し、セクション9.6で説明した方法論を進めてください
Single unidirectional LSP setup 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 vary. It can be used as a scalability metric of an RSVP-TE implementation.
ネットワーク内の多数のLSPを使用した単一の単方向LSPセットアップ遅延は、かなりの負荷で運用ネットワークのパフォーマンスを反映するため重要です。この遅延は、既存のLSPの数が異なるため、大きく異なる場合があります。RSVP-TE実装のスケーラビリティメトリックとして使用できます。
Set up the required number of LSPs, and wait until the network reaches a stable state; then, proceed with the methodologies described in Section 9.6.
必要な数のLSPを設定し、ネットワークが安定した状態に達するまで待ちます。次に、セクション9.6で説明した方法論を進めます。
The metric results including both real and undefined values MUST be reported together with the total number of values. The context under which the sample is obtained, including the selected parameters, the route traversed by the LSPs, and the testing case used, MUST also be reported.
実際の値と未定義の両方の値を含むメトリック結果は、値の総数とともに報告する必要があります。選択したパラメーター、LSPによって横断されるルート、および使用されたテストケースなど、サンプルが取得されるコンテキストも報告する必要があります。
In Section 5, we defined the singleton metric of multiple unidirectional LSPs setup delay. Now we define how to get one particular sample of multiple unidirectional LSPs setup delay.
セクション5では、複数の単方向LSPSセットアップ遅延のシングルトンメトリックを定義しました。次に、複数の単方向LSPSセットアップ遅延の特定のサンプルを1つ取得する方法を定義します。
Sampling means to take a number of distinct instances of a skeleton metric under a given set of parameters. As in [RFC2330], we use Poisson sampling as an example.
サンプリングとは、特定のパラメーターセットの下でスケルトンメトリックの多くの異なるインスタンスを取得することを意味します。[RFC2330]のように、例としてポアソンサンプリングを使用します。
Multiple unidirectional LSPs setup delay sample
複数の単方向LSPセットアップ遅延サンプル
o ID0, the ingress LSR ID
o ID0、Ingress 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_m, a rate in the reciprocal milliseconds
o Lambda_m、相互ミリ秒のレート
o Lambda, a rate in the reciprocal milliseconds
o ラムダ、相互ミリ秒のレート
o X, the number of LSPs to set up
o X、セットアップするLSPの数
o Th, LSP holding time
o TH、LSP保持時間
o Td, the maximum waiting time for successful multiple unidirectional LSPs setup
o TD、成功した複数の単方向LSPSセットアップの最大待ち時間
A sequence of pairs; the elements of each pair are:
一連のペア。各ペアの要素は次のとおりです。
o T, a time when the first 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 an 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 multiple unidirectional LSP setup delay sample. The value of the sample is the sequence made up of the resulting <time, setup 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または前に開始する擬似ランダムポアソンプロセスを計算し、平均到着率ラムダとTFで終了します。T0以上およびTF以下のこれらの時間値が選択されます。このプロセスの各時間で、複数の単方向LSPセットアップ遅延サンプルの値を取得します。サンプルの値は、結果の<時間、セットアップ遅延>ペアで構成されるシーケンスです。そのようなペアがない場合、シーケンスは長さゼロであり、サンプルは空であると言われています。
The parameter Lambda is used as an arrival rate of "batch unidirectional LSPs setup" operation. It regulates the interval in between each batch operation. The parameter Lambda_m is used within each batch operation, as described in Section 5
パラメーターラムダは、「バッチ単方向LSPSセットアップ」操作の到着率として使用されます。各バッチ操作間の間隔を調節します。セクション5で説明されているように、パラメーターLAMBDA_Mは各バッチ操作内で使用されます
The parameters Lambda and Lambda_m should be carefully chosen. If the rate is too high, overly frequent LSP setup/release procedure will result in high overhead in the control plane. In turn, the high overhead will increase unidirectional LSP setup delay. On the other hand, if the rate is too low, the sample might not completely reflect the dynamic provisioning performance of the GMPLS network. The appropriate Lambda and Lambda_m value depends on the given network.
パラメーターLambdaとLambda_mは慎重に選択する必要があります。レートが高すぎると、LSPのセットアップ/リリース手順が過度に頻繁に行われると、コントロールプレーンのオーバーヘッドが高くなります。次に、オーバーヘッドが高いと、一方向のLSPセットアップ遅延が増加します。一方、レートが低すぎる場合、サンプルはGMPLSネットワークの動的プロビジョニングパフォーマンスを完全に反映していない可能性があります。適切なLambdaおよびLambda_M値は、特定のネットワークに依存します。
The parameters Td should be carefully chosen. Different switching technologies may vary significantly in performing a cross-connect operation. At the same time, the time needed in setting up an LSP under different traffic may also vary significantly.
パラメーターTDを慎重に選択する必要があります。異なるスイッチング技術は、相互接続操作の実行で大きく異なる場合があります。同時に、異なるトラフィックでLSPをセットアップするのに必要な時間も大きく異なる場合があります。
It is important that, in obtaining a sample, all the LSPs MUST traverse the same route. If there are multiple routes between the ingress node ID0 and egress node ID1, EROs, or an alternate method, e.g., static configuration, MUST be used to ensure that all LSPs traverse the same route.
サンプルを取得する際に、すべてのLSPが同じルートを横断する必要があることが重要です。イングレスノードID0と出口ノードID1の間に複数のルートがある場合、EROS、または代替メソッド、たとえば静的構成を使用して、すべてのLSPが同じルートを横断することを確認する必要があります。
o Select the times using the specified Poisson arrival process,
o 指定されたポアソン到着プロセスを使用して時間を選択し、
o Set up the LSP as the methodology for the singleton multiple unidirectional LSPs setup delay, and obtain the value of multiple unidirectional LSPs setup delay, and
o LSPをシングルトンの複数の単方向LSPSセットアップ遅延の方法論として設定し、複数の単方向LSPSセットアップ遅延の値を取得し、
o Release the LSP after Th, and wait for the next Poisson arrival event.
o THの後にLSPをリリースし、次のポアソン到着イベントを待ちます。
Note: it is possible that before the previous LSP release procedure completes, the next Poisson arrival event arrives and the LSP setup procedure is initiated. If there is resource contention between the two LSPs, the LSP setup may fail. Ways to avoid such contention are outside the scope of this document.
注：以前のLSPリリース手順が完了する前に、次のポアソン到着イベントが到着し、LSPセットアップ手順が開始される可能性があります。2つのLSPの間にリソースの競合がある場合、LSPセットアップが失敗する可能性があります。そのような競合を回避する方法は、この文書の範囲外です。
Multiple unidirectional LSPs setup delay with no LSP in the network is important because this reflects the inherent delay of an RSVP-TE implementation. The minimum value provides an indication of the delay that will likely be experienced when LSPs traverse the shortest route with the lightest load in the control plane.
ネットワークにLSPがない複数の単方向LSPセットアップ遅延は、RSVP-TE実装の固有の遅延を反映しているため重要です。最小値は、LSPがコントロールプレーンで最も軽い荷重で最短ルートを横断するときに経験される可能性が高い遅延を示すことを提供します。
Make sure that there is no LSP in the network and proceed with the methodologies described in Section 10.6.
ネットワークにLSPがないことを確認し、セクション10.6で説明した方法論を進めてください。
Multiple unidirectional LSPs setup 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 can vary significantly as the number of existing LSPs vary. It can be used as a scalability metric of an RSVP-TE implementation.
ネットワーク内の多数のLSPを使用した複数の単方向LSPセットアップの遅延は、かなりの負荷で動作ネットワークのパフォーマンスを反映するため重要です。この遅延は、既存のLSPの数が異なるため、大きく異なる場合があります。RSVP-TE実装のスケーラビリティメトリックとして使用できます。
Set up the required number of LSPs, and wait until the network reaches a stable state; then, proceed with the methodologies described in Section 10.6.
必要な数のLSPを設定し、ネットワークが安定した状態に達するまで待ちます。次に、セクション10.6で説明した方法論を進めます。
The metric results including both real and undefined values MUST be reported together with the total number of values. The context under which the sample is obtained, including the selected parameters, the route traversed by the LSPs, and the testing case used, MUST also be reported.
実際の値と未定義の両方の値を含むメトリック結果は、値の総数とともに報告する必要があります。選択したパラメーター、LSPによって横断されるルート、および使用されたテストケースなど、サンプルが取得されるコンテキストも報告する必要があります。
In Section 6, we defined the singleton metric of single bidirectional LSP setup delay. Now we define how to get one particular sample of single bidirectional LSP setup delay. Sampling means to take a number of distinct instances of a skeleton metric under a given set of parameters. As in [RFC2330], we use Poisson sampling as an example.
セクション6では、単一の双方向LSPセットアップ遅延のシングルトンメトリックを定義しました。次に、単一の双方向LSPセットアップ遅延の特定のサンプルを1つ取得する方法を定義します。サンプリングとは、特定のパラメーターセットの下でスケルトンメトリックの多くの異なるインスタンスを取得することを意味します。[RFC2330]のように、例としてポアソンサンプリングを使用します。
Single bidirectional LSP setup delay sample with no LSP in the network
ネットワークにLSPがない単一の双方向LSPセットアップ遅延サンプル
o ID0, the ingress LSR ID
o ID0、Ingress 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 the reciprocal milliseconds
o ラムダ、相互ミリ秒のレート
o Th, LSP holding time
o TH、LSP保持時間
o Td, the maximum waiting time for successful setup
o TD、セットアップが成功するための最大待ち時間
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 an 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 bidirectional LSP setup delay sample. The value of the sample is the sequence made up of the resulting <time, LSP setup 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を考慮して、平均到着率LambdaでT0または前に始まり、TFで終了する擬似ランダムポアソンプロセスを計算します。T0以上およびTF以下のこれらの時間値が選択されます。このプロセスの各時間で、双方向LSPセットアップ遅延サンプルの値を取得します。サンプルの値は、結果の<時間、LSPセットアップ遅延>ペアで構成されるシーケンスです。そのようなペアがない場合、シーケンスは長さゼロであり、サンプルは空であると言われています。
The parameters Lambda should be carefully chosen. If the rate is too high, overly frequent LSP setup/release procedure will result in high overhead in the control plane. In turn, the high overhead will increase bidirectional LSP setup delay. On the other hand, if the rate is too low, the sample might not completely reflect the dynamic provisioning performance of the GMPLS network. The appropriate Lambda value depends on the given network.
ラムダのパラメーターは慎重に選択する必要があります。レートが高すぎると、LSPのセットアップ/リリース手順が過度に頻繁に行われると、コントロールプレーンのオーバーヘッドが高くなります。次に、オーバーヘッドが高いため、双方向LSPセットアップの遅延が増加します。一方、レートが低すぎる場合、サンプルはGMPLSネットワークの動的プロビジョニングパフォーマンスを完全に反映していない可能性があります。適切なラムダ値は、指定されたネットワークに依存します。
The parameters Td should be carefully chosen. Different switching technologies may vary significantly in performing a cross-connect operation. At the same time, the time needed to set up an LSP under different traffic may also vary significantly.
パラメーターTDを慎重に選択する必要があります。異なるスイッチング技術は、相互接続操作の実行で大きく異なる場合があります。同時に、異なるトラフィックの下でLSPをセットアップするのに必要な時間も大きく異なる場合があります。
In the case of active measurement, the parameters Th should be carefully chosen. The combination of Lambda and Th reflects the load of the network. The selection of Th SHOULD take into account that the network has sufficient resources to perform subsequent tests. The value of Th MAY be constant during one sampling process for simplicity considerations.
アクティブ測定の場合、パラメーターを慎重に選択する必要があります。LambdaとTHの組み合わせは、ネットワークの負荷を反映しています。THの選択では、ネットワークには後続のテストを実行するのに十分なリソースがあることを考慮に入れる必要があります。単純さの考慮事項のために、1つのサンプリングプロセス中にTHの値が一定になる場合があります。
Note that for online or passive measurements, the arrival rate and the LSP holding time are determined by actual traffic; hence, in this case, Lambda and Th are not input parameters.
オンラインまたはパッシブ測定の場合、到着率とLSP保持時間は実際のトラフィックによって決定されることに注意してください。したがって、この場合、LambdaとTHは入力パラメーターではありません。
It is important that, in obtaining a sample, all the LSPs MUST traverse the same route. If there are multiple routes between the ingress node ID0 and egress node ID1, EROs, or an alternate method, e.g., static configuration, MUST be used to ensure that all LSPs traverse the same route.
サンプルを取得する際に、すべてのLSPが同じルートを横断する必要があることが重要です。イングレスノードID0と出口ノードID1の間に複数のルートがある場合、EROS、または代替メソッド、たとえば静的構成を使用して、すべてのLSPが同じルートを横断することを確認する必要があります。
o Select the times using the specified Poisson arrival process,
o 指定されたポアソン到着プロセスを使用して時間を選択し、
o Set up the LSP as the methodology for the singleton bidirectional LSP setup delay, and obtain the value of bidirectional LSP setup delay, and
o LSPをシングルトン双方向LSPセットアップ遅延の方法論として設定し、双方向LSPセットアップ遅延の値を取得し、
o Release the LSP after Th, and wait for the next Poisson arrival event.
o THの後にLSPをリリースし、次のポアソン到着イベントを待ちます。
Note: it is possible that before the previous LSP release procedure completes, the next Poisson arrival event arrives and the LSP setup procedure is initiated. If there is resource contention between the two LSPs, the LSP setup may fail. Ways to avoid such contention are outside the scope of this document.
注：以前のLSPリリース手順が完了する前に、次のポアソン到着イベントが到着し、LSPセットアップ手順が開始される可能性があります。2つのLSPの間にリソースの競合がある場合、LSPセットアップが失敗する可能性があります。そのような競合を回避する方法は、この文書の範囲外です。
Single bidirectional LSP setup delay with no LSP in the network is important because this reflects the inherent delay of an RSVP-TE implementation. The minimum value provides an indication of the delay that will likely be experienced when an LSP traverses the shortest route with the lightest load in the control plane.
ネットワークにLSPがない単一の双方向LSPセットアップ遅延は、RSVP-TE実装の固有の遅延を反映しているため重要です。最小値は、LSPがコントロールプレーンで最も軽い荷重を伴う最短ルートを横断するときに経験される可能性が高い遅延を示すことを提供します。
Make sure that there is no LSP in the network and proceed with the methodologies described in Section 11.6.
ネットワークにLSPがないことを確認し、セクション11.6で説明した方法論を進めてください。
Single bidirectional LSP setup 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 can vary significantly as the number of existing LSPs varies. It can be used as a scalability metric of an RSVP-TE implementation.
ネットワーク内の多数のLSPを使用した単一の双方向LSPセットアップ遅延は、かなりの負荷で運用ネットワークのパフォーマンスを反映するため重要です。この遅延は、既存のLSPの数が異なるため、大きく異なる場合があります。RSVP-TE実装のスケーラビリティメトリックとして使用できます。
Set up the required number of LSPs and wait until the network reaches a stable state; then, proceed with the methodologies described in Section 11.6.
必要な数のLSPをセットアップし、ネットワークが安定した状態に達するまで待ちます。次に、セクション11.6で説明されている方法論を進めます。
The metric results including both real and undefined values MUST be reported together with the total number of values. The context under which the sample is obtained, including the selected parameters, the route traversed by the LSPs, and the testing case used, MUST also be reported.
実際の値と未定義の両方の値を含むメトリック結果は、値の総数とともに報告する必要があります。選択したパラメーター、LSPによって横断されるルート、および使用されたテストケースなど、サンプルが取得されるコンテキストも報告する必要があります。
In Section 7, we defined the singleton metric of multiple bidirectional LSPs setup delay. Now we define how to get one particular sample of multiple bidirectional LSP setup delay.
セクション7では、複数の双方向LSPSセットアップ遅延のシングルトンメトリックを定義しました。次に、複数の双方向LSPセットアップ遅延の特定のサンプルを取得する方法を定義します。
Sampling means to take a number of distinct instances of a skeleton metric under a given set of parameters. As in [RFC2330], we use Poisson sampling as an example.
サンプリングとは、特定のパラメーターセットの下でスケルトンメトリックの多くの異なるインスタンスを取得することを意味します。[RFC2330]のように、例としてポアソンサンプリングを使用します。
Multiple bidirectional LSPs setup delay sample
複数の双方向LSPセットアップ遅延サンプル
o ID0, the ingress LSR ID
o ID0、Ingress 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_m, a rate in the reciprocal milliseconds
o Lambda_m、相互ミリ秒のレート
o Lambda, a rate in the reciprocal milliseconds
o ラムダ、相互ミリ秒のレート
o X, the number of LSPs to set up
o X、セットアップするLSPの数
o Th, LSP holding time
o TH、LSP保持時間
o Td, the maximum waiting time for successful multiple unidirectional LSPs setup
o TD、成功した複数の単方向LSPSセットアップの最大待ち時間
A sequence of pairs; the elements of each pair are:
一連のペア。各ペアの要素は次のとおりです。
o T, a time when the first 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 an 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 multiple unidirectional LSP setup delay sample. The value of the sample is the sequence made up of the resulting <time, setup 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または前に開始する擬似ランダムポアソンプロセスを計算し、平均到着率ラムダとTFで終了します。T0以上およびTF以下のこれらの時間値が選択されます。このプロセスの各時間で、複数の単方向LSPセットアップ遅延サンプルの値を取得します。サンプルの値は、結果の<時間、セットアップ遅延>ペアで構成されるシーケンスです。そのようなペアがない場合、シーケンスは長さゼロであり、サンプルは空であると言われています。
The parameter Lambda is used as an arrival rate of "batch bidirectional LSPs setup" operation. It regulates the interval in between each batch operation. The parameter Lambda_m is used within each batch operation, as described in Section 7.
パラメーターラムダは、「バッチ双方向LSPSセットアップ」操作の到着率として使用されます。各バッチ操作間の間隔を調節します。セクション7で説明されているように、パラメーターLAMBDA_Mは各バッチ操作内で使用されます。
The parameters Lambda and Lambda_m should be carefully chosen. If the rate is too high, overly frequent LSP setup/release procedure will result in high overhead in the control plane. In turn, the high overhead will increase unidirectional LSP setup delay. On the other hand, if the rate is too low, the sample might not completely reflect the dynamic provisioning performance of the GMPLS network. The appropriate Lambda and Lambda_m values depend on the given network.
パラメーターLambdaとLambda_mは慎重に選択する必要があります。レートが高すぎると、LSPのセットアップ/リリース手順が過度に頻繁に行われると、コントロールプレーンのオーバーヘッドが高くなります。次に、オーバーヘッドが高いと、一方向のLSPセットアップ遅延が増加します。一方、レートが低すぎる場合、サンプルはGMPLSネットワークの動的プロビジョニングパフォーマンスを完全に反映していない可能性があります。適切なLambdaおよびLambda_m値は、指定されたネットワークに依存します。
The parameters Td should be carefully chosen. Different switching technologies may vary significantly in performing a cross-connect operation. At the same time, the time needed to set up an LSP under different traffic may also vary significantly.
パラメーターTDを慎重に選択する必要があります。異なるスイッチング技術は、相互接続操作の実行で大きく異なる場合があります。同時に、異なるトラフィックの下でLSPをセットアップするのに必要な時間も大きく異なる場合があります。
It is important that, in obtaining a sample, all the LSPs MUST traverse the same route. If there are multiple routes between the ingress node ID0 and egress node ID1, EROs, or an alternate method, e.g., static configuration, MUST be used to ensure that all LSPs traverse the same route.
サンプルを取得する際に、すべてのLSPが同じルートを横断する必要があることが重要です。イングレスノードID0と出口ノードID1の間に複数のルートがある場合、EROS、または代替メソッド、たとえば静的構成を使用して、すべてのLSPが同じルートを横断することを確認する必要があります。
o Select the times using the specified Poisson arrival process,
o 指定されたポアソン到着プロセスを使用して時間を選択し、
o Set up the LSP as the methodology for the singleton multiple bidirectional LSPs setup delay, and obtain the value of multiple unidirectional LSPs setup delay, and
o LSPをシングルトンの複数の双方向LSPSセットアップ遅延の方法論として設定し、複数の単方向LSPSセットアップ遅延の値を取得し、
o Release the LSP after Th, and wait for the next Poisson arrival event.
o THの後にLSPをリリースし、次のポアソン到着イベントを待ちます。
Note: it is possible that before the previous LSP release procedure completes, the next Poisson arrival event arrives and the LSP setup procedure is initiated. If there is resource contention between the two LSPs, the LSP setup may fail. Ways to avoid such contention are outside the scope of this document.
注：以前のLSPリリース手順が完了する前に、次のポアソン到着イベントが到着し、LSPセットアップ手順が開始される可能性があります。2つのLSPの間にリソースの競合がある場合、LSPセットアップが失敗する可能性があります。そのような競合を回避する方法は、この文書の範囲外です。
Multiple bidirectional LSPs setup delay with no LSP in the network is important because this reflects the inherent delay of an RSVP-TE implementation. The minimum value provides an indication of the delay that will likely be experienced when an LSPs traverse the shortest route with the lightest load in the control plane.
これは、RSVP-TE実装の固有の遅延を反映しているため、ネットワークにLSPがないため、複数の双方向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で説明した方法論を進めてください。
Multiple bidirectional LSPs setup 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 vary. It may be used as a scalability metric of an RSVP-TE implementation.
ネットワーク内の多数のLSPを使用した複数の双方向LSPセットアップの遅延は、かなりの負荷で動作ネットワークのパフォーマンスを反映するため重要です。この遅延は、既存のLSPの数が異なるため、大きく異なる場合があります。RSVP-TE実装のスケーラビリティメトリックとして使用できます。
Set up the required number of LSPs, and wait until the network reaches a stable state; then, proceed with the methodologies described in Section 12.6.
必要な数のLSPを設定し、ネットワークが安定した状態に達するまで待ちます。次に、セクション12.6で説明した方法論を進めます。
The metric results including both real and undefined values MUST be reported together with the total number of values. The context under which the sample is obtained, including the selected parameters, the route traversed by the LSPs, and the testing case used, MUST also be reported.
実際の値と未定義の両方の値を含むメトリック結果は、値の総数とともに報告する必要があります。選択したパラメーター、LSPによって横断されるルート、および使用されたテストケースなど、サンプルが取得されるコンテキストも報告する必要があります。
In Section 8, we defined the singleton metric of LSP graceful release delay. Now we define how to get one particular sample of LSP graceful release delay. We also use Poisson sampling as an example.
セクション8では、LSP Graceful Release DelayのSingleton Metricを定義しました。次に、LSPの優雅なリリース遅延の特定のサンプルを1つ取得する方法を定義します。また、例としてポアソンサンプリングも使用しています。
LSP graceful release delay sample
LSP優雅なリリース遅延サンプル
o ID0, the ingress LSR ID
o ID0、Ingress 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 Td, the maximum waiting time for successful LSP release
o TD、LSPリリースを成功させるための最大待ち時間
A sequence of pairs; the elements of each pair are:
一連のペア。各ペアの要素は次のとおりです。
o T, a time, and
o t、時間、そして
o dT, either a real number of milliseconds or undefined
o DT、実際の数ミリ秒または未定義のいずれか
Given T0, Tf, and Lambda, we compute a pseudo-random Poisson process beginning at or before T0, with an 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 LSP graceful release delay sample. The value of the sample is the sequence made up of the resulting <time, LSP graceful 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または前に開始する擬似ランダムポアソンプロセスを計算し、平均到着率ラムダとTFで終了します。T0以上およびTF以下のこれらの時間値が選択されます。このプロセスの各時間で、LSPの優雅なリリース遅延サンプルの値を取得します。サンプルの値は、結果の<時間、lspの優雅な遅延>ペアで構成されるシーケンスです。そのようなペアがない場合、シーケンスは長さゼロであり、サンプルは空であると言われています。
The parameter Lambda should be carefully chosen. If the rate is too large, overly frequent LSP setup/release procedure will result in high overhead in the control plane. In turn, the high overhead will increase unidirectional LSP setup delay. On the other hand, if the rate is too small, the sample might not completely reflect the dynamic provisioning performance of the GMPLS network. The appropriate Lambda value depends on the given network.
パラメーターラムダは慎重に選択する必要があります。レートが大きすぎる場合、LSPのセットアップ/リリース手順が過度に頻繁に行われると、コントロールプレーンのオーバーヘッドが高くなります。次に、オーバーヘッドが高いと、一方向のLSPセットアップ遅延が増加します。一方、レートが小さすぎる場合、サンプルはGMPLSネットワークの動的プロビジョニングパフォーマンスを完全に反映していない可能性があります。適切なラムダ値は、指定されたネットワークに依存します。
It is important that, in obtaining a sample, all the LSPs MUST traverse the same route. If there are multiple routes between the ingress node ID0 and egress node ID1, EROs, or an alternate method, e.g., static configuration, MUST be used to ensure that all LSPs traverse the same route.
サンプルを取得する際に、すべてのLSPが同じルートを横断する必要があることが重要です。イングレスノードID0と出口ノードID1の間に複数のルートがある場合、EROS、または代替メソッド、たとえば静的構成を使用して、すべてのLSPが同じルートを横断することを確認する必要があります。
Generally, the methodology would proceed as follows:
一般に、方法論は次のように進行します。
o Set up the LSP to be deleted
o 削除するLSPをセットアップします
o Select the times using the specified Poisson arrival process,
o 指定されたポアソン到着プロセスを使用して時間を選択し、
o Release the LSP as the methodology for the singleton LSP graceful release delay, and obtain the value of LSP graceful release delay, and
o LSPをSingleton LSP Graceful Release Delayの方法論としてリリースし、LSP Graceful Release Delayの値を取得し、
o Set up the LSP, and restart the Poisson arrival process, wait for the next Poisson arrival event.
o LSPをセットアップし、ポアソン到着プロセスを再起動し、次のポアソン到着イベントを待ちます。
The metric results including both real and undefined values MUST be reported together with the total number of values. The context under which the sample is obtained, including the selected parameters, and the route traversed by the LSPs MUST also be reported.
実際の値と未定義の両方の値を含むメトリック結果は、値の総数とともに報告する必要があります。選択したパラメーターを含むサンプルが取得されるコンテキストと、LSPによって横断されるルートも報告する必要があります。
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 of 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値の最小値です。これを計算する際に、未定義の値は無限に大きいと扱われる必要があります。これは、すべてのDT値が未定義である場合、最小値を未定義にする可能性があることを意味することに注意してください。さらに、サンプルが空である場合、メトリックの最小値を未定義に設定する必要があります。
Metric median is the median of the dT values in the given sample. In computing the median, the undefined values MUST NOT be included.
メートルの中央値は、指定されたサンプルのDT値の中央値です。中央値の計算では、未定義の値を含めてはなりません。
The maximum of the metric is the maximum of all the dT values in the sample. In computing this, undefined values MUST NOT be included. Note that this means that measurements that exceed the upper bound are not reported in this statistic. This is an important consideration when evaluating the maximum when the number of undefined measurements is non-zero.
メトリックの最大値は、サンプル内のすべてのDT値の最大値です。これを計算する際には、未定義の値を含めてはなりません。これは、上限を超える測定値がこの統計では報告されていないことを意味することに注意してください。これは、未定義の測定の数がゼロでない場合に最大を評価する場合に重要な考慮事項です。
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 X-th 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]を参照してください。
In the process of LSP setup/release, it may fail due to various reasons. For example, setup/release may fail when the control plane is overburdened or when there is resource shortage in one of the intermediate nodes. Since the setup/release failure may have significant impact on network operation, it is worthwhile to report each failure cases, so that appropriate operations can be performed to check the possible implementation, configuration or other deficiencies.
LSPのセットアップ/リリースの過程で、さまざまな理由により失敗する可能性があります。たとえば、コントロールプレーンが過負荷になっている場合、または中間ノードの1つでリソース不足がある場合、セットアップ/リリースが故障する場合があります。セットアップ/リリースの失敗はネットワーク操作に大きな影響を与える可能性があるため、各障害ケースを報告する価値があるため、実装、構成、またはその他の欠陥を確認するために適切な操作を実行できます。
Five types of failure events are defined in previous sections:
5種類の障害イベントは、以前のセクションで定義されています。
o Single Unidirectional LSP Setup Failure
o 単一の単方向LSPセットアップ障害
o Multiple Unidirectional LSP Setup Failure
o 複数の単方向LSPセットアップ障害
o Single Bidirectional LSP Setup Failure
o 単一の双方向LSPセットアップ障害
o Multiple Bidirectional LSP Setup Failure
o 複数の双方向LSPセットアップ障害
o LSP Graceful Release Failure
o LSP優雅なリリース障害
Given the samples of the performance metric, we now offer two statistics of failure events of these samples to report.
パフォーマンスメトリックのサンプルを考えると、報告するこれらのサンプルの故障イベントの2つの統計を提供します。
Failure Count is defined as the number of the undefined value of the corresponding performance metric (failure events) 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. The calculation for Failure Ratio is defined as follows:
故障比は、サンプル内のリクエストの総数に対する障害イベントの数の割合です。故障比の計算は、次のように定義されます。
X type failure ratio = Number of X type failure events/(Number of valid X type metric values + Number of X type failure events) * 100%.
Xタイプ障害比= Xタイプ障害イベントの数/（有効なXタイプメトリック値の数Xタイプ障害イベントの数） * 100％。
It is worthwhile to point out that:
それを指摘することは価値があります：
o The unidirectional/bidirectional LSP setup delay is one ingress-egress round-trip time plus processing time. But in this document, unidirectional/bidirectional LSP setup delay has not taken the processing time in the end nodes (ingress and/or egress) into account. The timestamp T2 is taken after the endpoint node receives it. Actually, the last node has to take some time to process local procedures. Similarly, in the LSP graceful release delay, the memo has not considered the processing time in the end node.
o 一方向/双方向LSPセットアップ遅延は、1つの侵入侵入往復時間と処理時間です。しかし、このドキュメントでは、単方向/双方向LSPセットアップ遅延が、最後のノード（イングレスおよび/または出口）の処理時間を考慮していません。タイムスタンプT2は、エンドポイントノードが受信された後に撮影されます。実際、最後のノードはローカル手順を処理するために時間がかかる必要があります。同様に、LSPの優雅なリリース遅延では、メモはエンドノードの処理時間を考慮していません。
o This document assumes that the correct procedures for installing the data plane are followed as described in [RFC3209], [RFC3471], and [RFC3473]. That is, by the time the egress receives and processes a Path message, it is safe for the egress to transmit data on the reverse path, and by the time the ingress receives and processes a Resv message it is safe for the ingress to transmit data on the forward path. See [CCAMP-SWITCH] for detailed explanations. This document does not include any verification that the implementations of the control plane software are conformant, although such tests MAY be constructed with the use of suitable signal generation test equipment. In [CCAMP-DPM], we defined a series of metrics to do such verifications. However, it is RECOMMENDED that both the measurements defined in this document and the measurements defined in [CCAMP-DPM] are performed to complement each other.
o このドキュメントは、[RFC3209]、[RFC3471]、および[RFC3473]に記載されているように、データプレーンをインストールするための正しい手順が追跡されることを前提としています。つまり、出力がパスメッセージを受信して処理するまでに、出口が逆パスでデータを送信することは安全であり、イングレスがRESVメッセージを受信して処理するまでに、イングレスがデータを送信するのは安全ですフォワードパス上。詳細な説明については、[ccamp-switch]を参照してください。このドキュメントには、コントロールプレーンソフトウェアの実装が適切であるという確認は含まれていませんが、そのようなテストは適切な信号生成テスト機器を使用して構築される場合があります。[CCAMP-DPM]では、そのような検証を行うために一連のメトリックを定義しました。ただし、このドキュメントで定義されている測定と[CCAMP-DPM]で定義された測定値の両方が実行されることをお勧めします。
o Note that, in implementing the tests described in this document, a tester should be sure to measure the time taken for the control plane messages including the processing of those messages by the nodes under test.
o このドキュメントで説明されているテストを実装する際に、テスターは、テスト中のノードによるそれらのメッセージの処理を含むコントロールプレーンメッセージの時間を測定する必要があることに注意してください。
o Bidirectional LSPs may be set up using three-way signaling, where the initiating node will send a ResvConf message downstream upon receiving the Resv message. The ResvConf message is used to notify the terminate node that it can transfer data upstream. Actually, both directions should be ready to transfer data when the Resv message is received by the initiating node. Therefore, the bidirectional LSP setup delay defined in this document does not take the confirmation procedure into account.
o 双方向LSPは、3方向信号を使用してセットアップされる場合があります。ここでは、開始ノードがRESVメッセージを受信すると下流のRESVCONFメッセージを送信します。RESVCONFメッセージは、上流のデータを転送できることを終了ノードに通知するために使用されます。実際、resvメッセージが開始ノードによって受信されると、両方方向がデータを転送する準備ができている必要があります。したがって、このドキュメントで定義された双方向LSPセットアップ遅延は、確認手順を考慮していません。
Samples of the metrics can be obtained in either active or passive manners.
メトリックのサンプルは、アクティブマナーまたはパッシブマナーのいずれかで取得できます。
In active measurement, ingress nodes inject probing messages into the control plane. Since the measurement endpoints must be conformant to signaling specifications and behave as normal signaling endpoints, it will not incur other security issues 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プロビジョニング以外のセキュリティの問題は発生しません。ただし、測定値が測定するネットワークに測定量の追加トラフィックを注入するように、測定パラメーターを慎重に選択する必要があります。「あまりにも多くの」トラフィックを注入すると、測定の結果を歪め、極端な場合には混雑とサービスの拒否を引き起こす可能性があります。
When samples of the metrics are collected in a passive manner, e.g., by monitoring the operations on real-life LSPs, the implementation of the monitoring and reporting mechanism must be careful so that they will not be used to attack the control plane. A typical implementation may use the Management Information Base (MIB) to collect/store the metrics and access to the MIB is limited to the Network Management Systems (NMSs). In this case, passive monitoring will not incur other security issues than implementing the MIBs and NMSs. If an implementation chooses to expose the performance data to other applications, then it must take into account the possible security issues it may face. For example, when exposing the performance data through Simple Network Management Protocol (SNMP), certain authentication methods should be used to ensure that the entity maintaining the performance data are not subject to unauthorized readings and modifications. Rate limiting on the performance query may also be desirable to reduce the risk that the entity maintaining the performance data are overwhelmed by too many query requests. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy).
メトリックのサンプルがパッシブな方法で収集される場合、たとえば、実際のLSPの操作を監視することにより、監視および報告メカニズムの実装は、コントロールプレーンの攻撃に使用されないように注意する必要があります。一般的な実装では、管理情報ベース（MIB）を使用してメトリックを収集/保存し、MIBへのアクセスはネットワーク管理システム（NMSS）に限定されます。この場合、パッシブ監視は、MIBSおよびNMSを実装する以外のセキュリティ問題を負いません。実装がパフォーマンスデータを他のアプリケーションに公開することを選択した場合、直面する可能性のあるセキュリティの問題を考慮する必要があります。たとえば、単純なネットワーク管理プロトコル（SNMP）を介してパフォーマンスデータを公開する場合、特定の認証方法を使用して、パフォーマンスデータを維持するエンティティが不正な読み取りと変更の対象ではないことを確認する必要があります。パフォーマンスクエリの制限は、パフォーマンスデータを維持するエンティティがクエリリクエストが多すぎることに圧倒されるリスクを減らすためにも望ましい場合があります。実装者は、SNMPV3暗号化メカニズム（認証とプライバシーのため）の完全なサポートを含む、SNMPV3フレームワーク（[RFC3410]、セクション8を参照）で提供されるセキュリティ機能を考慮することをお勧めします。
Additionally, the security considerations pertaining to the original RSVP protocol [RFC2205] and its TE extensions [RFC3209] also remain relevant.
さらに、元のRSVPプロトコル[RFC2205]およびそのTE拡張機能[RFC3209]に関するセキュリティに関する考慮事項も関連しています。
We wish to thank Dan Li, Fang Liu (Christine), Zafar Ali, Monique Morrow, Adrian Farrel, Deborah Brungard, Lou Berger, Thomas D. Nadeau for their comments and help. Lou Berger and Adrian Farrel have made text contributions to this document.
ダン・リー、ファン・リュー（クリスティーン）、ザファー・アリ、モニーク・モロー、エイドリアン・ファレル、デボラ・ブランガード、ルー・バーガー、トーマス・D・ナドーのコメントと助けに感謝したいと思います。Lou BergerとAdrian Farrelは、この文書にテキスト貢献をしました。
We wish to thank experts from IPPM and BMWG -- Reinhard Schrage, Al Morton, and Henk Uijterwaal -- for reviewing this document. Reinhard Schrage has made text contributions to this document.
このドキュメントをレビューしてくれたIPPMとBMWGの専門家（Reinhard Schrage、Al Morton、Henk Uijterwaal）に感謝します。Reinhard Schrageは、この文書にテキスト貢献をしました。
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.
このドキュメントには、既存のIETFドキュメントに表示されているテキストと同様に、アイデアとテキストが含まれています。著者は、G。Almes、S。Kalidindi、および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 the valuable comments. We also wish to thank the support from National Natural Science Foundation of China (NSFC) and 863 program of China.
また、貴重なコメントについては、高度な光学通信システムとネットワークの州の主要研究所のWeisheng Hu、Yaohui Jin、およびWei Guoに感謝します。また、中国国立自然科学財団（NSFC）と中国の863プログラムからの支援にも感謝したいと思います。
[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。、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、1997年9月。
[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、「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：LSP TunnelsのRSVPへの拡張"、RFC 3209、12月2001年。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471] Berger、L。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナル伝達機能説明」、RFC 3471、2003年1月。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473] Berger、L。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリングリソースリソースプロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 3473、2003年1月。
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945] Mannie、E。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）アーキテクチャ」、RFC 3945、2004年10月。
[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。、およびY. Rekhter、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）ユーザーネットワークインターフェイス（UNI）：リソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）オーバーレイモデルのサポート」、RFC 4208、2005年10月。
[CCAMP-DPM] Sun, W., Zhang, G., Gao, J., Xie, G., Papneja, R., Gu, B., Wei, X., Otani, T., and R. Jing, "Label Switched Path (LSP) Data Path Delay Metric in Generalized MPLS/ MPLS-TE Networks", Work in Progress, December 2009.
[CCAMP-DPM] Sun、W.、Zhang、G.、Gao、J.、Xie、G.、Papneja、R.、Gu、B.、Wei、X.、Otani、T。、およびR. Jing、「一般化されたMPLS/ MPLS-TEネットワークのラベルスイッチパス（LSP）データパス遅延メトリック」、2009年12月、進行中の作業。
[CCAMP-SWITCH] Shiomoto, K. and A. Farrel, "Advice on When It is Safe to Start Sending Data on Label Switched Paths Established Using RSVP-TE", Work in Progress, October 2009.
[CCAMP-SWITCH] Shiomoto、K。およびA. Farrel、「RSVP-TEを使用して確立されたラベルスイッチパスのデータの送信を開始することが安全である場合のアドバイス」、2009年10月の作業。
[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。、およびM. Mathis、「IPパフォーマンスメトリックのフレームワーク」、RFC 2330、1998年5月。
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
[RFC3410] Case、J.、Mundy、R.、Partain、D。、およびB. Stewart、「インターネット標準管理フレームワークの紹介と適用声明」、RFC 3410、2002年12月。
Jianhua Gao Huawei Technologies Co., LTD. China
Jianhua Gao Huawei Technologies Co.、Ltd。中国
Phone: +86 755 28973237
EMail: gjhhit@huawei.com
Guowu Xie University of California, Riverside 900 University Ave. Riverside, CA 92521 USA
カリフォルニア大学グウウXie校、リバーサイド900大学アベニュー、リバーサイド、CA 92521 USA
Phone: +1 951 237 8825
EMail: xieg@cs.ucr.edu
Rajiv Papneja Isocore 12359 Sunrise Valley Drive, STE 100 Reston, VA 20190 USA
Rajiv Papneja Isocore 12359 Sunrise Valley Drive、Ste 100 Reston、VA 20190 USA
Phone: +1 703 860 9273
EMail: rpapneja@isocore.com
Bin Gu IXIA Oriental Kenzo Plaza 8M, 48 Dongzhimen Wai Street, Dongcheng District Beijing 200240 China
Bin Gu ixia Oriental Kenzo Plaza 8M、48 Dongzhimen Wai Street、Dongcheng District Beijing 200240 China
Phone: +86 13611590766
EMail: BGu@ixiacom.com
Xueqin Wei Fiberhome Telecommunication Technology Co., Ltd. Wuhan China
XueQin Wei Fiberhome Telecommunicated Technology Co.、Ltd。Wuhan China
Phone: +86 13871127882 EMail: xqwei@fiberhome.com.cn Tomohiro Otani KDDI R&D Laboratories, Inc. 2-1-15 Ohara Kamifukuoka Saitama 356-8502 Japan
電話：86 13871127882メール：xqwei@fiberhome.com.cn tomohiro otani kddi R＆D Laboratories、Inc。
Phone: +81-49-278-7357
EMail: otani@kddilabs.jp
Ruiquan Jing China Telecom Beijing Research Institute 118 Xizhimenwai Avenue Beijing 100035 China
Ruiquan Jing China Telecom Beijing Research Institute 118 Xizhimenwai Avenue Beijing 100035 China
Phone: +86-10-58552000
EMail: jingrq@ctbri.com.cn
Editors' Addresses
編集者のアドレス
Weiqiang Sun (editor) Shanghai Jiao Tong University 800 Dongchuan Road Shanghai 200240 China
Weiqiang Sun（編集者）Shanghai Jiao Tong University 800 Dongchuan Road Shanghai 200240 China
Phone: +86 21 3420 5359
EMail: sunwq@mit.edu
Guoying Zhang (editor) China Academy of Telecommunication Research, MIIT, China. No.52 Hua Yuan Bei Lu,Haidian District Beijing 100083 China
Guoying Zhang（編集者）China Academy of Telecommunication Research、MIIT、中国。No.52 Hua Yuan Bei Lu、Haidian District Beijing 100083 China
Phone: +86 1062300103
EMail: zhangguoying@mail.ritt.com.cn