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
ラベルスイッチパス（LSP）一般化MPLSネットワークにおける動的なプロビジョニングパフォーマンス・メトリック
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）をスイッチング汎用マルチプロトコルラベルは、将来のデータ伝送ネットワークのための最も有望な候補技術の一つです。 GMPLSは、従来のルータ、スイッチ、高密度波長分割多重（DWDM）システム、などのネットワーク要素の異なる種類の制御および操作するために開発されたアド・ドロップマルチプレクサ（ADM装置）、光クロスコネクト（PXCs）、光クロスコネクト（のOXC）、等が挙げられる。これらの物理的に多様なデバイスは、動的プロビジョニング能力に互いに大幅に異なります。光ネットワークは、メトロエリアで展開されているため、同時に、動的にプロビジョニングされた接続の必要性が増しています。異なるアプリケーションは、光ネットワークのプロビジョニング性能の変化の要件を持っているように、ネットワークとアプリケーションのニーズの性能を互いにマッピングすることができるように標準化されたメトリックおよび手順を定義することが不可欠です。
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.
この文書では、動的なラベルスイッチパス（LSP）GMPLSネットワークのプロビジョニング、パフォーマンス、特にダイナミックな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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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）、光クロスコネクト（のOXC）、等が挙げられる。これらの物理的に多様なデバイスは、動的プロビジョニング能力に互いに大幅に異なります。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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.
単方向LSP設定遅延、双方向LSP設定遅延、およびLSP優雅な解除遅延：このメモでは、GMPLSネットワークの動的なプロビジョニングLSPの性能を特徴づけるために、我々は3つのパフォーマンスメトリックを定義します。 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.
そのデータパスに関連メトリックに注意し、例えば、入口ノードとするとき、順方向データ・パスが動作可能になることにより、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期間自体は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を使用することができます。
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
ID1、出口LSR ID O
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.
Tにおける出口ノードID1 [RFC3945]に入口ノードID0からの単一の単方向LSPセットアップ遅延はdTが入口ノードID0がワイヤ時間T、およびその入口ノードID0で出口ノードID1にPathメッセージパケットの最初のビットを送信することを意味していますワイヤ時刻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.
Tにおける出口ノードID1に入口ノードID0からの単一の単方向LSPセットアップ遅延が未定義である入口ノードID0がワイヤ時間TとID0に対応する受信しないその入口ノードにおける出口ノードID1にPathメッセージパケットの最初のビットを送信することを意味合理的な期間内に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.
Tは、入口ノードにおけるクロックの分解能に依存時に一方向LSPセットアップ遅延の精度O。一方向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ネットワークは、デバイスの多くの種類を収容することができます。例えば、いくつかの光クロスコネクト（PXCs）は、マイクロミラーを移動しなければなりません。この物理的な運動は、数ミリ秒かかる場合がありますが、一般的な電子スイッチは、数マイクロ秒以内に節点処理を終了することができます。だから、単方向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入口ノードは、LSPを設定するには、Pathメッセージを送信しますが、対応するResvメッセージを受信しなかった場合、単方向LSP設定遅延はundefinedに設定しなければなりません。
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.
入口ノードは、LSPを設定するには、Pathメッセージを送信しますが、のPathErrメッセージを受信した場合、O、単方向LSP設定遅延はundefinedに設定しなければなりません。この場合には多くの理由があります。例えば、Pathメッセージは、無効なパラメータを持っているか、ネットワークが要求された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入口ノードにおいて、LSPの要件に応じてPathメッセージを形成します。 Pathメッセージパケットが出口ノードに向けて送信されたときのタイムスタンプ（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.
対応するResvメッセージは、合理的な期間内に到着した場合、O、メッセージの受信時にできるだけ早くタイムスタンプ（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.
対応するResvメッセージは、妥当な期間内に到着しなかった場合、O、一方向LSPセットアップ遅延が未定義すると考えられます。 「合理的な」しきい値は、方法論のパラメータであることに注意してください。
o If the corresponding response is a PathErr message, the unidirectional LSP setup delay is deemed to be undefined.
対応する応答は、のPathErrメッセージである場合、O、一方向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、イングレスLSR ID
o ID1, the egress LSR ID
ID1、出口LSR ID O
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
複数の単方向のLSP設定遅延の値はミリ秒単位または未定義の実数のどちらかであります
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における出口ノード[RFC3945]に入口ノードから複数の単方向のLSPセットアップ遅延はdTの手段です。
o ingress node ID0 sends the first bit of the first Path message packet to egress node ID1 at wire-time T;
O入口ノードID0は、ワイヤ時間Tにおける出口ノードID1〜第Pathメッセージパケットの最初のビットを送信します。
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入口ノードID0は、出口ノードID1からすべての対応するResvメッセージのパケットを受信します。そして
o ingress node ID0 receives the last Resv message packet at wire-time T+dT.
O入口ノードID0は、ワイヤ時間T + dTの最後Resvメッセージパケットを受信します。
If the multiple unidirectional LSPs setup delay at T is "undefined", this means that:
Tで複数の単方向のLSP設定遅延が「未定義」であれば、これはそれを意味します。
o ingress node ID0 sends all the Path messages toward egress node ID1,
Oの入口ノードID0は、出口ノードID1に向けて、すべてのPathメッセージを送信します
o the first bit of the first Path message packet is sent at wire-time T, and
パケットがワイヤ時間Tで送信される最初のPathメッセージの最初のビットO、及び
o ingress node ID0 does not receive one or more of the corresponding Resv messages within a reasonable period of time.
O入口ノードID0は、合理的な期間内に対応するRESVメッセージの一つ以上を受信しません。
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における複数の単方向の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 multiple unidirectional LSP setup delay varies drastically from one network to another. In practice, the upper bound SHOULD be chosen carefully.
O所定の方法論は、レイテンシ値が無限大であるかどうかそれは単に非常に大きいかどうかを決定する方法を含むことがあります。単純な上限を用いることができるが、GMPLSネットワークは、デバイスの多くの種類を収容することができます。例えば、いくつかの光クロスコネクト（PXCs）は、マイクロミラーを移動しなければなりません。この物理的な運動は、数ミリ秒かかる場合がありますが、電子スイッチは、数マイクロ秒以内に節点処理を終了することができます。だから、複数の単方向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入口ノードは、LSPを設定するために、複数のPathメッセージを送信しますが、対応するRESVメッセージの一つ以上を受け取ることはありません、複数の単方向LSP設定遅延はundefinedに設定する必要がある場合。
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.
入口ノードは、LSPを設定するためにPathメッセージを送信するが、1つのまたは複数のPathErrメッセージを受信した場合、O、複数の単方向のLSP設定遅延はundefinedに設定しなければなりません。この場合には多くの理由があります。たとえば、パスメッセージのいずれかが無効なパラメータを持っているか、ネットワークが要求された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、明示的経路オブジェクト（エロス）、または別の方法、例えば、静的構成の間に複数の経路が存在する場合、すべての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-、LSPの要件に応じPathメッセージを形成します。
o At the ingress node, select the time for each of the Path messages according to the specified Poisson process.
入口ノードにおけるO、指定されたポアソン過程に従うPathメッセージのそれぞれの時間を選択します。
o At the ingress node, send out the Path messages according to the selected time.
入口ノードのo-、選択した時間に応じてPathメッセージを送信します。
o Store a timestamp (T1) locally on the ingress node when the first Path message packet is sent towards the egress node.
最初のPathメッセージパケットが出口ノードに向けて送信されたときに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.
対応するRESVメッセージのすべてが合理的な期間内に到着した場合、O、すべてのメッセージの受信時に、できるだけ早く最終タイムスタンプ（T2）を取ります。 2つのタイムスタンプを減算することにより、複数の単方向のLSPセットアップ遅延（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.
対応するRESVメッセージの1つ以上が妥当な期間内に到着しなかった場合、O、複数の単方向のLSPセットアップ遅延が未定義すると考えられます。 「合理的な」しきい値は、方法論のパラメータであることに注意してください。
o If one or more of the corresponding responses are PathErr messages, the multiple unidirectional LSPs setup delay is deemed to be undefined.
対応する応答の1つ以上がのPathErrメッセージである場合には、O、複数の単方向のLSP設定遅延は未定義すると認められます。
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.
メトリック結果（実数または未定義のいずれか）が選択された上限と一緒に報告されなければなりません。 LSPが通過するというルートも報告しなければなりません。ルートは、[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.
GMPLSは、双方向対称の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期間が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、イングレスLSR ID
o ID1, the egress LSR ID
ID1、出口LSR ID O
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のために、Tにおける出口ノードID1に入口ノードID0から単一の双方向LSPセットアップ遅延はdTが入口ノードID0は、上流のラベルを含むPathメッセージの最初のビットを送信することを意味している[RFC3473]出口ノードID1に向かいますワイヤ時間Tで、出口ノードID1は、パケットが、その後すぐに戻って入口ノードID0にResvメッセージのパケットを送信し、その入口ノード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.
Tにおける入口ノードID0から出口ノードID1に単一の双方向LSPセットアップ遅延が「不定」である場合、これは、入口ノードID0がワイヤ時間Tとその入口ノードID0で出口ノードID1のPathメッセージの最初のビットを送信することを意味します合理的な期間内にその応答パケットを受信しません。
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ネットワークは、デバイスの多くの種類を収容することができます。例えば、いくつかの光クロスコネクト（PXCs）は、マイクロミラーを移動しなければなりません。この物理的な運動は、数ミリ秒かかる場合がありますが、電子スイッチは、数マイクロ秒以内に節点処理を終了することができます。だから、双方向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入口ノードは、LSPを設定するには、Pathメッセージを送信し、決して対応するResvメッセージを受信した場合、単一の双方向LSP設定遅延はundefinedに設定しなければなりません。
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.
入口ノードは、LSPを設定するPathメッセージを送信し、しかしのPathErrメッセージを受信した場合、O、単一の双方向LSPセットアップ遅延は未定義に設定しなければなりません。この場合には多くの理由があります。たとえば、Pathメッセージは、無効なパラメータを持っているか、ネットワークが要求された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入口ノードにおいて、LSPの要求に応じて（上流のラベルまたは推奨ラベルを含む）Pathメッセージを形成します。 Pathメッセージパケットが出口ノードに向けて送信されたときのタイムスタンプ（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.
対応するResvメッセージは、合理的な期間内に到着した場合、O、メッセージの受信時に、できるだけ早く最終タイムスタンプ（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.
対応するResvメッセージは、妥当な期間内に到着しなかった場合、O、単一の双方向LSPセットアップ遅延が未定義すると考えられます。 「合理的な」しきい値は、方法論のパラメータであることに注意してください。
o If the corresponding response is a PathErr message, the single bidirectional LSP setup delay is deemed to be undefined.
対応する応答は、のPathErrメッセージである場合、O、単一の双方向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ネットワークを介して複数の双方向のLSP設定遅延のメトリックを定義します。
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、イングレスLSR ID
o ID1, the egress LSR ID
ID1、出口LSR ID O
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
複数の双方向のLSP設定遅延の値はミリ秒単位または未定義の実数のどちらかであります
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の入口ノードから出口ノードへの複数の双方向のLSP設定遅延が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に向かう第1の経路メッセージの最初のビットを送信します。
o All subsequent (X-1) Path messages are sent according to the specified Poisson process with arrival rate Lambda_m;
Oすべての（X-1）以降のPathメッセージが到着率Lambda_mと指定されたポアソン過程に従って送信されます。
o Ingress node ID1 receives all corresponding Resv message packets from egress node ID1; and
O IngressノードID1は、出口ノード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.
入口ノードからTの出口ノードへの複数の双方向のLSP設定遅延が「未定義」であれば、これは入口ノードは出口ノードにすべてのPathメッセージを送信し、入口ノードは、応答の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複数の双方向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 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ネットワークは、デバイスの多くの種類を収容することができます。例えば、いくつかの光クロスコネクト（PXCs）は、マイクロミラーを移動しなければなりません。この物理的な運動は、数ミリ秒かかる場合がありますが、電子スイッチは、数マイクロ秒以内に節点プロセスを終了することができます。だから、複数の双方向のLSP設定遅延は、ネットワークから別のものに劇的に変化します。下流ノードは、上流ノードによって示唆ラベルをオーバーライドする場合は、複数の双方向のLSPセットアップのプロセスでは、セットアップ遅延も増加し得ます。したがって、実際には、上限は慎重に選択しなければなりません。
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入口ノードは、LSPを設定するためにPathメッセージを送信しませんが、決してすべての対応するRESVメッセージを受信した場合、複数の双方向のLSP設定遅延はundefinedに設定しなければなりません。
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入口ノードは、複数の双方向のLSP設定遅延はundefinedに設定しなければならない、LSPを設定するためにPathメッセージを送信しますが、一つ以上の応答のPathErrメッセージを受信した場合。この場合には多くの理由があります。たとえば、Pathメッセージの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、エロス、または別の方法との間の複数のルートが存在する場合、例えば、静的構成は、すべての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-、LSPの要件に応じて（上流のラベルまたは示唆したラベルを含む）、Pathメッセージを形成します。
o At the ingress node, select the time for each of the Path messages according to the specified Poisson process.
入口ノードにおけるO、指定されたポアソン過程に従うPathメッセージのそれぞれの時間を選択します。
o At the ingress node, send out the Path messages according to the selected time.
入口ノードのo-、選択した時間に応じてPathメッセージを送信します。
o Store a timestamp (T1) locally in the ingress node when the first Path message packet is sent towards the egress node.
最初のPathメッセージパケットが出口ノードに向けて送信されたときに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.
対応するRESVメッセージのすべてが合理的な期間内に到着した場合、O、すべてのメッセージの受信時に、できるだけ早く最終タイムスタンプ（T2）を取ります。 2つのタイムスタンプを減算することにより、複数の双方向のLSPセットアップ遅延（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.
対応するRESVメッセージの1つ以上が妥当な期間内に到着しなかった場合、O、複数の双方向のLSPセットアップ遅延が未定義すると考えられます。 「合理的な」しきい値は、方法論のパラメータであることに注意してください。
o If one or more of the corresponding responses are PathErr messages, the multiple bidirectional LSPs setup delay is deemed to be undefined.
対応する応答の1つ以上がのPathErrメッセージがある場合は、O、複数の双方向のLSP設定遅延は未定義であるとみなされます。
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.
メトリック結果（実数または未定義のいずれか）が選択された上限と一緒に報告されなければなりません。 LSPが通過するというルートも報告しなければなりません。ルートは、[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ネットワークにおけるLSPの解放機構の2種類があります。この文書は、アカウントに強力LSP解放手順を取ることはありません。
LSP graceful release delay is useful for several reasons:
LSP優雅な解除遅延はいくつかの理由のために有用です：
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].
LSP優雅なリリース手順O GMPLS制御ネットワーク、特に光ネットワークにおいてより好ましいです。それは回復/保護をトリガしないので、それは[RFC4208]で「アラームなしの接続の削除」です。
LSP graceful release delay
LSP優雅な解除遅延
o ID0, the ingress LSR ID
O ID0、イングレスLSR ID
o ID1, the egress LSR ID
ID1、出口LSR ID O
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.
二つの異なるLSP優雅なリリース手順があります：1は、入口ノードによって開始され、別の出口ノードによって開始されます。二つの手順は、[RFC3473]に示されています。私たちは、別途これら二つの手順のための優雅な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.
Tにおける出口ノードID1に入口ノードID0からLSP優雅な放出遅延がdTのであれば実数dTのために、これは、入口ノードID0が反映（R）との管理ステータスオブジェクトを含むPathメッセージの最初のビットを送信することを意味ワイヤ時間Tでの出口ノードに設定（D）ビットを削除し、出口ノードID1がそのパケットを受信した後、直ちに削除（D）との管理ステータスオブジェクトを含むResvメッセージを送信バック入口ノードへのビットセット。入口ノードID0は、LSPを除去するために下流PathTearメッセージを送信し、出口ノード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.
また、オプションとして、設定（D）（R）反射し、削除ビットの管理ステータスオブジェクトを含むPathメッセージを受信すると、出口ノード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.
Tにおける出口ノードID1に入口ノードID0からLSP優雅な放出遅延は未定義である入口ノードID0がワイヤ時間Tで出口ノードID1にPathメッセージの最初のビットを送信し、その（出口ノードがパスを受けないかということを意味出口ノードID1が合理的な期間内にPathTearメッセージを受信しない）パケットは、出口ノードは、応答して、対応するResvメッセージのパケットを送信しない、又は入口ノードは、そのた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.
TのノードID0を進入する出口ノードID1からLSP優雅な放出遅延dTの場合、これは出口ノードID1が（R）反射し、（D）ビットを削除すると、管理ステータスオブジェクトを含むResvメッセージの最初のビットを送信することを意味しますPathTearメッセージは、LSPを除去するために、下流のワイヤ時間T.のIngressノードID0で入口ノードに送信し、及び出口ノードID1は、ワイヤ時間T + dTのでPathTearパケットの最後のビットを受信します。
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.
TのノードID0を進入する出口ノードID1からLSP優雅な放出遅延が「不定」である場合、これは、（D）出口ノードID1が反映（R）との管理ステータスオブジェクトを含むResvメッセージの最初のビットを送信することを意味し、Deleteワイヤ時間Tにおける入口ノードID0に設定されたビットとその（入口ノードがたResvパケット又は入口ノードを受信しないか、応答にPathTearメッセージのパケットを送信しない、など）出口ノード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第1（第2）の状況では、時刻TにおけるLSP優雅な放出遅延の精度は、入力（出力）ノードにおけるクロックの分解能に依存します。最初の状況では、入口ノードと出口ノードとの間の同期が必要とされ、それは第二の状況ではありません。
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.
入口ノードは、（R）反射し、LSP優雅な放出を開始するように設定（D）ビットを削除すると、管理ステータスオブジェクトを含むPathメッセージを送信するが、出口ノードは、対応するPathTearメッセージ、LSPを受信しなかった場合、最初の状況において、O優雅な解除遅延はundefinedに設定しなければなりません。
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.
出口ノードが反映（R）との管理ステータスオブジェクトを含むResvメッセージを送信し、削除する第2状況では、（D）ビットがLSP優雅な放出を開始するように設定が、対応するPathTearメッセージを受信することはないO、LSP優雅な放出遅延はundefinedに設定しなければなりません。
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入口ノードにおいて、反映（R）との管理ステータスオブジェクトを含むPathメッセージを形成し、設定（D）ビットを削除します。 Pathメッセージパケットが出口ノードに向けて送信されたときのタイムスタンプ（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セットビット（R）反射し、削除（D）との管理ステータスオブジェクトを含むPathメッセージを受信すると、出口ノードは、削除（D）との管理ステータスオブジェクトを含むResvメッセージを送信し、設定（R）ビットを反映します。あるいは、出口ノードは、上流設定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.
入口ノードは、ResvメッセージやたPathErrメッセージを受信すると、Oは、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).
それはPathTearメッセージの最後のビットを受信すると、O出口ノードは、タイムスタンプ（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.
入口ノードは、ダウンストリームPathメッセージを送信するが、出口ノードは、合理的な期間内にPathTearメッセージの受信に失敗した場合はO、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）との管理ステータスオブジェクトを含むResvメッセージを形成し、（D）ビットがセット削除。 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（R）反射し、Resvメッセージに設定（D）ビットを削除すると、管理ステータスオブジェクトを受信すると、入口ノードは、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).
それはPathTearメッセージの最後のビットを受信すると、O出口ノードは、タイムスタンプ（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.
出口ノードが上流のResvメッセージを送信し、それは合理的な期間内にPathTearメッセージの受信に失敗した場合はO、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設定遅延の一つの特定のサンプルを取得する方法を定義します。サンプリングパラメータの所与の組の下で骨格メトリックの別個のインスタンスの数を取ることを意味します。 [RFC2330]のように、私たちは、一例として、ポアソンサンプリングを使用します。
Single unidirectional LSP setup delay sample
単一の単方向LSP設定遅延サンプル
o ID0, the ingress LSR ID
O ID0、イングレスLSR ID
o ID1, the egress LSR ID
ID1、出口LSR ID O
o T0, a time
T0、時間O
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は、およびラムダ考えると、擬似ランダムポアソン過程の平均到着率ラムダを、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.
活性測定の場合には、パラメータThが注意深く選択されるべきです。ラムダとのThの組み合わせは、ネットワークの負荷を反映しています。 Thの選択は、ネットワークが次の試験を行うために十分なリソースを持っていることを考慮に入れる必要があります。 Thの値は、単純化の考慮事項のための1つのサンプリング処理中に一定であってもよいです。
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保持時間は、実際のトラフィックによって決定されることに留意されたいです。したがって、この場合には、ラムダおよび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、エロス、または別の方法との間の複数のルートが存在する場合、例えば、静的構成は、すべての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.
トラフィックエンジニアリング（RSVP-TE）の実装 - これはリソース予約プロトコルの固有の遅延を反映しているため、ネットワーク内の無LSPを備えた単一の単方向LSP設定遅延は重要です。最小値は、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によって横断経路、及び使用されるテストケースも報告されなければならないなど、得られます。
10. A Definition for Samples of Multiple Unidirectional LSPs Setup Delay
10.複数の単方向の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節では、複数の単方向のLSP設定遅延のシングルトンメトリックを定義しました。今、私たちは、複数の単方向の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 unidirectional LSPs setup delay sample
複数の単方向のLSPセットアップ遅延サンプル
o ID0, the ingress LSR ID
O ID0、イングレスLSR ID
o ID1, the egress LSR ID
ID1、出口LSR ID O
o T0, a time
T0、時間O
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と、成功した複数の単方向のLSP設定のための最大待機時間
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は、およびラムダ考えると、擬似ランダムポアソン過程の平均到着率ラムダを、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
パラメータラムダは、「バッチの単方向LSPの設定」操作の到着率として使用されています。これは、各バッチ操作の間に間隔を調節します。セクション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_mは慎重に選択する必要があります。率が高すぎると、過度に頻繁にLSPの設定/解除の手順は、制御プレーンで高いオーバーヘッドになります。ターンでは、高いオーバーヘッドは、単方向LSP設定遅延が増加します。率が低すぎる一方、サンプルが完全にGMPLSネットワークの動的なプロビジョニングのパフォーマンスを反映していない可能性があります。適切なラムダと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、エロス、または別の方法との間の複数のルートが存在する場合、例えば、静的構成は、すべての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セットアップ遅延のための方法論として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のセットアップが失敗することがあります。そのような競合を回避するための方法は、この文書の範囲外です。
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.
これは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 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設定遅延の一つの特定のサンプルを取得する方法を定義します。サンプリングパラメータの所与の組の下で骨格メトリックの別個のインスタンスの数を取ることを意味します。 [RFC2330]のように、私たちは、一例として、ポアソンサンプリングを使用します。
Single bidirectional LSP setup delay sample with no LSP in the network
ネットワークにおける無LSPを持つ単一の双方向LSP設定遅延サンプル
o ID0, the ingress LSR ID
O ID0、イングレスLSR ID
o ID1, the egress LSR ID
ID1、出口LSR ID O
o T0, a time
T0、時間O
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は、およびラムダ考えると、擬似ランダムポアソン過程の平均到着率ラムダを、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.
活性測定の場合には、パラメータThが注意深く選択されるべきです。ラムダとのThの組み合わせは、ネットワークの負荷を反映しています。 Thの選択は、ネットワークが次の試験を行うために十分なリソースを持っていることを考慮すべきです。 Thの値は、単純化の考慮事項のための1つのサンプリング処理中に一定であってもよいです。
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保持時間は、実際のトラフィックによって決定されることに留意されたいです。したがって、この場合には、ラムダおよび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、エロス、または別の方法との間の複数のルートが存在する場合、例えば、静的構成は、すべての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.
これはRSVP-TE実装の固有の遅延を反映しているため、ネットワーク内の無LSPを持つ単一の双方向LSP設定遅延は重要です。最小値は、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章では、我々は、複数の双方向のLSP設定遅延のシングルトンメトリックを定義しました。今、私たちは、複数の双方向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、イングレスLSR ID
o ID1, the egress LSR ID
ID1、出口LSR ID O
o T0, a time
T0、時間O
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と、成功した複数の単方向のLSP設定のための最大待機時間
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は、およびラムダ考えると、擬似ランダムポアソン過程の平均到着率ラムダを、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.
パラメータラムダは、「バッチ双方向のLSP設定」操作の到着率として使用されています。これは、各バッチ操作の間に間隔を調節します。第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_mは慎重に選択する必要があります。率が高すぎると、過度に頻繁にLSPの設定/解除の手順は、制御プレーンで高いオーバーヘッドになります。ターンでは、高いオーバーヘッドは、単方向LSP設定遅延が増加します。率が低すぎる一方、サンプルが完全にGMPLSネットワークの動的なプロビジョニングのパフォーマンスを反映していない可能性があります。適切なラムダと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、エロス、または別の方法との間の複数のルートが存在する場合、例えば、静的構成は、すべての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をセットアップ遅延のための方法論として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のセットアップが失敗することがあります。そのような競合を回避するための方法は、この文書の範囲外です。
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優雅な解除遅延のシングルトンメトリックを定義しました。今、私たちは、LSP優雅な解除遅延の一つの特定のサンプルを取得する方法を定義します。我々はまた、例として、ポアソンサンプリングを使用します。
LSP graceful release delay sample
LSP優雅な解除遅延サンプル
o ID0, the ingress LSR ID
O ID0、イングレスLSR ID
o ID1, the egress LSR ID
ID1、出口LSR ID O
o T0, a time
T0、時間O
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は、およびラムダを考えると、我々は、擬似ランダムポアソン過程の平均到着率ラムダを、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、エロス、または別の方法との間の複数のルートが存在する場合、例えば、静的構成は、すべての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優雅な放出遅延のための方法論としてLSPを解放し、そしてLSP優雅な放出遅延の値を取得し、及び
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）は、任意のxに対して、<= xであった総測定値の分数割合を与え、関数F（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の設定/解除の過程では、様々な理由により失敗することがあります。例えば、設定/解除が失敗する可能性があり、制御プレーンが過負荷である場合や、リソース不足が中間ノードのいずれかに存在する場合。設定/解除の失敗は、ネットワーク動作に大きな影響を与えることができるので、適切な操作が可能な実装、構成又は他の欠陥を確認するために行うことができるように、各故障ケースを報告することは価値があります。
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]に記載されているように、データプレーンをインストールするための正しい手順に従っていることを前提としています。すなわち、出力は逆の経路上でデータを送信するための出力を受信し、Pathメッセージを処理する時点で、それが安全である、および入力データを送信するための入口は、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は開始ノードは、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上で操作を監視することで、監視およびレポートメカニズムの実装は慎重でなければなりません。典型的な実装では、ネットワーク管理システム（のNMS）に制限され/収集メトリクス及びMIBへのアクセスを格納する管理情報ベース（MIB）を使用することができます。この場合、パッシブモニタリングは、MIBとの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.
我々は彼らのコメント、助けをダン・リー、牙劉（クリスティン）、Zafarアリ、モニークモロー、エイドリアン・ファレル、デボラBrungard、ルー・バーガー、トーマスD.ナドーに感謝したいです。ルー・バーガーとエイドリアン・ファレルは、この文書にテキスト貢献をしました。
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.
ラインハルトSchrage、アル・モートン、およびヘンクUijterwaal - - このドキュメントを再検討するために私たちは、IPPMとBMWGから専門家に感謝したいです。ラインハルト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胡、Yaohuiジン、および魏郭に感謝したいです。また、中国の国家自然科学基金（NSFC）からの支援と中国の863プログラムに感謝したいです。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ブレーデン、B.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（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.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：LSPトンネルのためのRSVPの拡張"、RFC 3209年12月2001。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]バーガー、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]バーガー、L.、 "一般化マルチプロトコルラベルスイッチング（GMPLS）シグナリング資源予約プロトコル - トラフィックエンジニアリング（RSVP-TE）を拡張"、RFC 3473、2003年1月。
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945]マニー、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]ツバメ、G.、ドレイク、J.、石松、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]サン、W.、張、G.、ガオ、J.、謝、G.、Papneja、R.、区、B.、ウェイ、X.、大谷、T.、およびR.ジン、 「一般化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.
[CAMP-SWITCH]がShiomoto、K.とA.ファレルは、進歩、2009年10月に、仕事を「それは安全であるときのアドバイスは、ラベル上のデータの送信を開始するためにRSVP-TEを使用して確立パスの交換」。
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998.
[RFC2330]パクソン、V.、Almes、G.、Mahdavi、J.、およびM.マティス、 "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]ケース、J.、マンディ、R.、パーテイン、D.、およびB.スチュワート、 "インターネット標準の管理フレームワークのための序論と適用性声明"、RFC 3410、2002年12月。
Appendix A. Authors' Addresses
付録A.著者のアドレス
Jianhua Gao Huawei Technologies Co., LTD. China
G Jイアン花ああああUAは、技術の共同で、株式会社中国
Phone: +86 755 28973237 EMail: gjhhit@huawei.com
電話：+86 755 28973237 Eメール：gjhhit@huawei.com
Guowu Xie University of California, Riverside 900 University Ave. Riverside, CA 92521 USA
カリフォルニア、リバーサイド900大学のAVああ。リバーサイド、CA 92521 USAのGU O 5 X IE大学
Phone: +1 951 237 8825 EMail: xieg@cs.ucr.edu
電話：+1 951 237 8825 Eメール：xieg@cs.ucr.edu
Rajiv Papneja Isocore 12359 Sunrise Valley Drive, STE 100 Reston, VA 20190 USA
ラジブPapneja Isocore 12359日の出バレードライブ、STE 100レストン、VA 20190 USA
Phone: +1 703 860 9273 EMail: rpapneja@isocore.com
電話：+1 703 860 9273 Eメール：rpapneja@isocore.com
Bin Gu IXIA Oriental Kenzo Plaza 8M, 48 Dongzhimen Wai Street, Dongcheng District Beijing 200240 China
ビン区IXIAオリエンタル健三プラザ8M、48東直門ワイ・ストリート、東城区北京200240中国
Phone: +86 13611590766 EMail: BGu@ixiacom.com
電話：+86 13611590766 Eメール：BGu@ixiacom.com
Xueqin Wei Fiberhome Telecommunication Technology Co., Ltd. Wuhan China
X UEプロ魏繊維家庭の通信技術の共同。、株式会社武漢中国
Phone: +86 13871127882 EMail: xqwei@fiberhome.com.cn
電話：+86 13871127882 Eメール：xqwei@fiberhome.com.cn
Tomohiro Otani KDDI R&D Laboratories, Inc. 2-1-15 Ohara Kamifukuoka Saitama 356-8502 Japan
ともひろ おたに Ｋっぢ Ｒ＆Ｄ ぁぼらとりえｓ、 いんｃ。 ２ー１ー１５ おはら かみふくおか さいたま ３５６ー８５０２ じゃぱん
Phone: +81-49-278-7357 EMail: otani@kddilabs.jp
電話：+ 81-49-278-7357 Eメール：otani@kddilabs.jp
Ruiquan Jing China Telecom Beijing Research Institute 118 Xizhimenwai Avenue Beijing 100035 China
道北京100035中国外バウチャーのRu私ジン中国テレコム北京研究所場合は118のξ値
Phone: +86-10-58552000 EMail: jingrq@ctbri.com.cn
電話：+ 86-10-58552000 Eメール：jingrq@ctbri.com.cn
Editors' Addresses
エディタのアドレス
Weiqiang Sun (editor) Shanghai Jiao Tong University 800 Dongchuan Road Shanghai 200240 China
魏強い日（エディタ）道路上海200240中国経由上海J I AOトング大学800洞
Phone: +86 21 3420 5359 EMail: sunwq@mit.edu
電話：+86 21 3420 5359 Eメール：sunwq@mit.edu
Guoying Zhang (editor) China Academy of Telecommunication Research, MIIT, China. No.52 Hua Yuan Bei Lu,Haidian District Beijing 100083 China
GU Oは、電気通信研究の張（編集者）、中国のアカデミー、MI IT、中国。NO.52胡主席は元はIL U、H低ポイント地区北京100083中国でなければなりません
Phone: +86 1062300103 EMail: zhangguoying@mail.ritt.com.cn
電話：+86 1062300103 Eメール：zhangguoying@mail.ritt.com.cn