[要約] RFC 5695は、IPフローのMPLS転送のベンチマーク方法論に関するものです。このRFCの目的は、MPLSネットワークでのIPフローのパフォーマンスを評価するための一貫した方法を提供することです。
Network Working Group A. Akhter
Request for Comments: 5695 R. Asati
Category: Informational C. Pignataro
Cisco Systems
November 2009
MPLS Forwarding Benchmarking Methodology for IP Flows
IPフローのMPLS転送メソッド
Abstract
概要
This document describes a methodology specific to the benchmarking of Multiprotocol Label Switching (MPLS) forwarding devices, limited to the most common MPLS packet forwarding scenarios and delay measurements for each, considering IP flows. It builds upon the tenets set forth in RFC 2544, RFC 1242, and other IETF Benchmarking Methodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the MPLS paradigm.
このドキュメントでは、最も一般的なMPLSパケット転送シナリオに限定されたマルチプロトコルラベルスイッチング（MPLS）転送デバイスのベンチマークに固有の方法論について説明し、IPフローを考慮して、それぞれの測定を遅延させます。これは、RFC 2544、RFC 1242、およびその他のIETFベンチマークメソッドワーキンググループ（BMWG）の取り組みに記載されている教義に基づいています。この文書は、これらの努力をMPLSパラダイムに拡大しようとしています。
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、BSDライセンスに記載されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................2
2. Document Scope ..................................................3
3. Key Words To Reflect Requirements ...............................4
4. Test Methodology ................................................4
4.1. Test Considerations ........................................5
4.1.1. Abbreviations Used ..................................5
4.1.2. IGP Support .........................................6
4.1.3. Label Distribution Support ..........................6
4.1.4. Frame Formats .......................................7
4.1.5. Frame Sizes .........................................9
4.1.6. Time-to-Live (TTL) or Hop Limit ....................12
4.1.7. Trial Duration .....................................12
4.1.8. Traffic Verification ...............................12
4.1.9. Address Resolution and Dynamic Protocol State ......13
5. Reporting Format ...............................................13
6. MPLS Forwarding Benchmarking Tests .............................14
6.1. Throughput ................................................15
6.1.1. Throughput for MPLS Label Push .....................16
6.1.2. Throughput for MPLS Label Swap .....................17
6.1.3. Throughput for MPLS Label Pop (Unlabeled) ..........18
6.1.4. Throughput for MPLS Label Pop (Aggregate) ..........19
6.1.5. Throughput for MPLS Label Pop (PHP) ................20
6.2. Latency Measurement .......................................21
6.3. Frame-Loss Rate (FLR) Measurement .........................22
6.4. System Recovery ...........................................23
6.5. Reset .....................................................23
7. Security Considerations ........................................25
8. Acknowledgement ................................................25
9. References .....................................................25
9.1. Normative References ......................................25
9.2. Informative References ....................................26
Over the past several years, there has been an increase in the use of MPLS as a forwarding architecture in new and existing network designs. MPLS, defined in [RFC3031], is a foundation technology and the basis for many advanced technologies such as Layer 3 MPLS VPNs, Layer 2 MPLS VPNs, and MPLS Traffic Engineering.
過去数年にわたって、新しいネットワークデザインの転送アーキテクチャとしてMPLSの使用が増加しています。[RFC3031]で定義されているMPLSは、レイヤー3 MPLS VPNS、レイヤー2 MPLS VPNS、MPLSトラフィックエンジニアリングなどの多くの高度な技術の基礎であり、基礎となっています。
However, there is no standard method defined to compare and contrast the foundational MPLS packet forwarding capabilities of network devices. This document proposes a methodology using common criteria (such as throughput, latency, frame-loss rate, system recovery, reset, etc.) to evaluate MPLS forwarding of any implementation.
ただし、ネットワークデバイスの基礎MPLSパケット転送機能を比較対照するための標準的な方法はありません。このドキュメントは、実装のMPLS転送を評価するために、共通の基準（スループット、レイテンシ、フレームロスレート、システムリカバリ、リセットなど）を使用した方法論を提案します。
The benchmarking methodology principles outlined in RFC 2544 [RFC2544] are independent of forwarding techniques; however, they don't fully address MPLS benchmarking. The workload on network forwarding device resources that MPLS forwarding places is different from that of IP forwarding; therefore, MPLS forwarding benchmarking specifics are desired.
RFC 2544 [RFC2544]で概説されているベンチマーク方法論の原則は、転送技術とは無関係です。ただし、MPLSベンチマークに完全に対応していません。MPLS転送場所がIP転送のリソースとは異なるネットワーク転送デバイスリソースのワークロード。したがって、MPLS転送ベンチマークの詳細が必要です。
The purpose of this document is to describe a methodology specific to the benchmarking of MPLS forwarding devices. The methods described are limited in scope to the most common MPLS packet forwarding scenarios and corresponding performance measurements in a laboratory setting. It builds upon the tenets set forth in RFC 2544 [RFC2544], RFC 1242 [RFC1242], and other IETF Benchmarking Methodology Working Group (BMWG) efforts. In other words, this document is not a replacement for, but a complement to, RFC 2544.
このドキュメントの目的は、MPLS転送デバイスのベンチマークに固有の方法論を説明することです。説明されている方法は、最も一般的なMPLSパケット転送シナリオと、実験室の設定での対応するパフォーマンス測定の範囲に限定されています。これは、RFC 2544 [RFC2544]、RFC 1242 [RFC1242]、およびその他のIETFベンチマークメソジーワーキンググループ（BMWG）の取り組みに記載されている教義に基づいています。言い換えれば、このドキュメントはRFC 2544に代わるものではなく、補完的なものです。
This document focuses on the MPLS label stack [RFC3032] that has only one entry, as it is the fundamental of MPLS forwarding. It is expected that future documents may cover the benchmarking of MPLS applications such as Layer 3 VPN (L3VPN) [RFC4364], Layer 2 VPN (L2VPN) [RFC4664], Fast ReRoute [RFC4090], etc., which require more than one entry in the MPLS label stack.
このドキュメントは、MPLS転送の基本であるため、1つのエントリのみがあるMPLSラベルスタック[RFC3032]に焦点を当てています。将来のドキュメントは、レイヤー3 VPN（L3VPN）[RFC4364]、レイヤー2 VPN（L2VPN）[RFC4664]、Fast Reroute [RFC4090]などのMPLSアプリケーションのベンチマークをカバーすることが期待されます。MPLSラベルスタックで。
Moreover, to address the majority of current deployments' needs, this document focuses on having IP packets as the MPLS payload. In other words, label distribution for IP Forwarding Equivalence Class (FEC) [RFC3031] is prescribed (see Section 4.1.3) by this document. It is expected that future documents may focus on having non-IP packets as the MPLS payload.
さらに、現在の展開のニーズの大部分に対処するために、このドキュメントは、MPLSペイロードとしてIPパケットを持つことに焦点を当てています。言い換えれば、IP転送等価クラス（FEC）[RFC3031]のラベル分布が規定されています（セクション4.1.3を参照）。将来のドキュメントは、MPLSペイロードとして非IPパケットを持つことに焦点を当てることが期待されています。
Note that the presence of an MPLS label stack does not require the length of MPLS payload (which is an IP packet, per this document) to be changed; hence, the effective maximum size of a frame can increase by Z octets (where Z = 4 x number of label stack entries), as observed in current deployments. This document focuses on benchmarking such a scenario.
MPLSラベルスタックの存在では、MPLSペイロードの長さ（このドキュメントごとにIPパケットである）の長さを変更する必要はないことに注意してください。したがって、現在の展開で観察されるように、フレームの有効な最大サイズはzオクテット（z = 4 xラベルスタックエントリの数）で増加する可能性があります。このドキュメントは、このようなシナリオのベンチマークに焦点を当てています。
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 BCP 14, RFC 2119 [RFC2119]. RFC 2119 defines the use of these key words to help make the intent of Standards Track documents as clear as possible. While this document uses these keywords, this document is not a Standards Track document.
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC 2119 [RFC2119]に記載されているように解釈される。RFC 2119は、これらのキーワードの使用を定義して、標準の意図を可能な限り明確に追跡するのに役立ちます。このドキュメントではこれらのキーワードを使用していますが、このドキュメントは標準トラックドキュメントではありません。
The set of methodologies described in this document will use the topology described in this section. An effort has been made to exclude superfluous equipment needs such that each test can be carried out with a minimal number of devices. Figure 1 illustrates the sample topology in which the Device Under Test (DUT) is connected to the test ports on the test tool in accord with Figure 1 of RFC 2544.
このドキュメントで説明されている方法論のセットは、このセクションで説明されているトポロジを使用します。最小限のデバイスで各テストを実行できるように、余分な機器のニーズを除外する努力がなされています。図1は、RFC 2544の図1に従って、テスト中のデバイス（DUT）がテストツールのテストポートに接続されているサンプルトポロジを示しています。
+-----------------+
+---------+ | | +---------+
| Test | | | | Test |
| Port A1 +-----+ DA1 DB1 +-----+ Port B1 |
+---------+ | | +---------+
+---------+ | DUT | +---------+
| Test | | | | Test |
| Port A2 +-----+ DA2 DB2 +-----+ Port B2 |
+---------+ | | +---------+
... | ... ... | ...
+---------+ | | +---------+
| Test | | | | Test |
| Port Ap +-----+ DAp DBp +-----+ Port Bp |
+---------+ +-----------------+ +---------+
Figure 1: Topology for MPLS Forwarding Benchmarking
図1：MPLS転送ベンチマークのトポロジー
A represents a Tx-side Module of the test tool, whereas B represents an Rx-side Module of the same test tool. Of course, the suffixed numbers (1, 2, ..., p) represent ports on a Module.
aはテストツールのTX側モジュールを表しますが、Bは同じテストツールのRX側モジュールを表します。もちろん、接尾辞数（1、2、...、p）はモジュール上のポートを表します。
Similarly, DA represents an Rx-side Module of the DUT, whereas DB represents a Tx-side Module. The suffixed numbers (1, 2, ..., p) represent ports on a Module.
同様に、DAはDUTのRX側モジュールを表しますが、DBはTX側モジュールを表します。接尾辞数（1、2、...、p）は、モジュール上のポートを表します。
p = the number of {DA, DB} pair ports on the DUT. It is determined by the maximum unidirectional forwarding throughput of the DUT and the load capacity of the port media (e.g., interface) connecting the DUT to the test tool.
p = DUTの{da、db}ペアポートの数。DUTをテストツールに接続するポートメディア（たとえば、インターフェイス）のDUTの最大単方向転送スループットと負荷容量によって決定されます。
For example, if the DUT's maximum forwarding throughput is 100 frames per second (fps) and the load capacity of the port media (e.g., interface) is 50 fps, then p >= 2 is needed to sufficiently test the maximum frame forwarding.
たとえば、DUTの最大転送スループットが1秒あたり100フレーム（FPS）であり、ポートメディアの負荷容量（インターフェイスなど）が50 fpsの場合、最大フレーム転送を十分にテストするにはp> = 2が必要です。
The exact throughput is a measured quantity obtained through testing. Throughput may vary depending on the number of ports used and other factors. The number of ports (p) used SHOULD be reported. Please see "Test Setup" in Section 6. Following Figure 1 from Section 6 of RFC 2544 is recommended.
正確なスループットは、テストを通じて得られた測定量です。スループットは、使用するポートの数やその他の要因によって異なる場合があります。使用するポートの数（P）を報告する必要があります。セクション6の「テストセットアップ」を参照してください。RFC2544のセクション6の図1に次のことが推奨されます。
This methodology assumes a full-duplex, uniform medium topology. The medium used MUST be reported in each test result. Issues regarding mixed transmission media, speed mismatches, media header differences, etc., are not under consideration. Traffic affecting features such as Flow control, Quality of Service (QoS), Graceful Restart, etc. MUST be disabled, unless explicitly requested in the test case. Additionally, any non-essential traffic MUST also be avoided.
この方法論は、全二重の均一な中程度のトポロジを想定しています。使用される媒体は、各テスト結果で報告する必要があります。混合トランスミッションメディア、速度の不一致、メディアヘッダーの違いなどに関する問題は考慮されていません。テストケースで明示的に要求されない限り、フロー制御、サービス品質（QOS）、優雅な再起動などの機能に影響を与える機能は無効にする必要があります。さらに、必須でないトラフィックも避ける必要があります。
The terms used in this document remain consistent with those defined in "Benchmarking Terminology for Network Interconnect Devices" RFC 1242 [RFC1242]. This terminology SHOULD be consulted before using or applying the recommendations of this document.
このドキュメントで使用される用語は、「ネットワーク相互接続デバイスのベンチマーク用語」RFC 1242 [RFC1242]で定義されている用語と一致しています。この用語は、このドキュメントの推奨事項を使用または適用する前に相談する必要があります。
Please refer to Figure 1 for a topology view of the network. The following abbreviations are used in this document:
ネットワークのトポロジビューについては、図1を参照してください。このドキュメントでは、次の略語が使用されています。
M := Module on a device (i.e., Line-Card or Slot; could be A or B)
p := Port number (i.e., port on the Module; could be 1, 2, etc.)
p：=ポート番号（つまり、モジュールのポート、1、2などになる可能性があります）
RN := Remote Network (i.e., network that is reachable via a port of a module; could be B1RN1 or B2RN5 to mean the first network reachable via port 1 of module B, e.g., B1, or the fifth network reachable via port 2 of module B, etc.). RN is considered to be the IP Prefix FEC from the MPLS perspective.
RN：=リモートネットワーク（つまり、モジュールのポートを介して到達可能なネットワーク。B1RN1またはB2RN5は、モジュールBのポート1を介して到達可能な最初のネットワークを意味する可能性があります。モジュールBなど）。RNは、MPLSの観点からのIPプレフィックスFECと見なされます。
It is RECOMMENDED that all of the ports (A1, DA1, DB1, and A2) on the DUT and test tool support a dynamic Interior Gateway Protocol (IGP) for routing such as IS-IS, OSPF, RIP, etc. Furthermore, there are testing considerations in this document that the device be able to provide a stable control plane during heavy forwarding workloads. In particular, the procedures defined in Section 11.3 of RFC 2544 must be followed. This is to ensure that control plane instability during load conditions is not the contributing factor towards frame forwarding performance.
DUTおよびテストツールのすべてのポート（A1、DA1、DB1、およびA2）は、IS-IS、OSPF、RIPなどのルーティングの動的なインテリアゲートウェイプロトコル（IGP）をサポートすることをお勧めします。このドキュメントでは、デバイスが重い転送ワークロード中に安定した制御プレーンを提供できるという考慮事項をテストしています。特に、RFC 2544のセクション11.3で定義されている手順に従う必要があります。これは、負荷条件中のコントロールプレーンの不安定性が、フレーム転送パフォーマンスに対する寄与要因ではないことを保証するためです。
The route distribution method (OSPF, IS-IS, Enhanced Interior Gateway Routing Protocol (EIGRP), RIP, Static, etc.), if used, MUST be reported. Furthermore, if any specific configuration is used to maintain control plane stability during the test (i.e., Control Plane Protection, Control Plane Rate Limiting, etc.), then it MUST also be reported.
ルート分布方法（OSPF、IS-IS、強化されたインテリアゲートウェイルーティングプロトコル（EIGRP）、RIP、静的など）は、使用する場合は報告する必要があります。さらに、テスト中に制御プレーンの安定性を維持するために特定の構成を使用している場合（つまり、コントロールプレーンの保護、制御プレーンレートの制限など）、報告する必要があります。
The DUT and test tool must support at least one protocol for exchanging MPLS label/FEC bindings for Prefix Forwarding Equivalence Class (FEC) [RFC3031]. The DUT and test tool MUST be capable of learning and advertising MPLS label/FEC bindings via the chosen protocol(s) and use them during packet forwarding all the time (including when the label/FEC bindings change). The most commonly used protocols are Label Distribution Protocol (LDP) [RFC5036], Resource Reservation Protocol-Traffic Engineering (RSVP-TE) [RFC3209], and Border Gateway Protocol (BGP) [RFC3107].
DUTおよびテストツールは、プレフィックス転送等価クラス（FEC）[RFC3031]のMPLSラベル/FECバインディングを交換するための少なくとも1つのプロトコルをサポートする必要があります。DUTおよびテストツールは、選択したプロトコルを介してMPLSラベル/FECバインディングを学習および広告することができ、パケット転送中に常に使用する必要があります（ラベル/FECバインディングの変更を含む）。最も一般的に使用されるプロトコルは、ラベル分布プロトコル（LDP）[RFC5036]、リソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）[RFC3209]、および境界ゲートウェイプロトコル（BGP）[RFC3107]です。
All of the ports (A1, DA1, DB1, B1, etc.) either on the DUT or the test tool used in the testing SHOULD support LDP, RSVP-TE, and BGP for IPv4 or IPv6 Prefix Forwarding Equivalence Classes (FECs).
テストで使用されるDUTまたはテストツールのいずれかのすべてのポート（A1、DA1、DB1、B1など）は、IPv4またはIPv6プレフィックス転送等価クラス（FEC）のLDP、RSVP-TE、およびBGPをサポートする必要があります。
Static labels SHOULD NOT be used to establish the MPLS label switched paths (LSPs), unless specified explicitly by the test case.
テストケースで明示的に指定されていない限り、静的ラベルをMPLSラベルスイッチ付きパス（LSP）を確立するために使用しないでください。
This is because the use of a static label is quite uncommon in the production networks.
これは、静的ラベルの使用が生産ネットワークではまったくまれであるためです。
The IPv4 and IPv6 Explicit NULL labels (label values 0 and 2) are sometimes used to identify the payload of an MPLS packet on an LSP [RFC3032]. Explicit NULL labels are not used in the tests described in this document because the tests are limited to the use of no more than one non-reserved MPLS label in the label stack of all packets to, from, or through the DUT.
IPv4およびIPv6の明示的なヌルラベル（ラベル値0および2）は、LSP [RFC3032]のMPLSパケットのペイロードを識別するために使用されることがあります。このドキュメントで説明されているテストでは、明示的なヌルラベルは、すべてのパケットのラベルスタックで、またはDUTから、またはDUTを介して1つの非予測されたMPLSラベルの使用に限定されているため、このドキュメントで説明されているテストでは使用されません。
This section explains the frame formats for IP and MPLS packets (Section 4.1.4.1), the usage of IP as the mandatory Layer 3 protocol and as the MPLS packet payload (Section 4.1.4.2), change in frame format during forwarding (Section 4.1.4.3), and recommended frame formats for the MPLS benchmarking (Section 4.1.4.4).
このセクションでは、IPおよびMPLSパケットのフレームフォーマット（セクション4.1.4.1）、必須レイヤー3プロトコルとしてのIPの使用、およびMPLSパケットペイロード（セクション4.1.4.2）として、転送中のフレーム形式の変更について説明します（セクション4.1.4.3）、およびMPLSベンチマークに推奨されるフレーム形式（セクション4.1.4.4）。
A test frame carrying an IP packet is illustrated in Figure 2 below. Note that RFC 2544 [RFC2544] prescribes using such a frame as the test frame over the chosen Layer 2 media.
IPパケットを運ぶテストフレームを以下の図2に示します。RFC 2544 [RFC2544]は、選択したレイヤー2メディアのテストフレームとしてそのようなフレームを使用して規定していることに注意してください。
+---------+--------------+-----------------------+
| Layer 2 | Layer 3 = IP | Layer 4 = UDP |
+---------+--------------+-----------------------+
Figure 2: Frame Format for IP Packets
図2：IPパケットのフレーム形式
Unlike a test frame carrying an IP packet, a test frame carrying an MPLS packet contains an "MPLS label stack" [RFC3032] immediately after the Layer 2 header (and before the IP header, if any) as illustrated in Figure 3 below.
IPパケットを運ぶテストフレームとは異なり、MPLSパケットを運ぶテストフレームには、以下の図3に示すように、レイヤー2ヘッダーの直後（およびIPヘッダーの前）の直後（およびIPヘッダーの前）の直後に「MPLSラベルスタック」[RFC3032]が含まれています。
+---------+-------+--------------+-----------------------+
| Layer 2 | MPLS | Layer 3 = IP | Layer 4 = UDP |
+---------+-------+--------------+-----------------------+
Figure 3: Frame Format for MPLS Packets
図3：MPLSパケットのフレーム形式
The MPLS label stack is represented as a sequence of "label stack entries", where each label stack entry is 4 octets, as illustrated in Figure 1 of [RFC3032]. This document requires exactly one entry in the MPLS label stack in an MPLS packet.
MPLSラベルスタックは、[RFC3032]の図1に示すように、各ラベルスタックエントリが4オクテットである「ラベルスタックエントリ」のシーケンスとして表されます。このドキュメントでは、MPLSパケットのMPLSラベルスタックに正確に1つのエントリが必要です。
MPLS label values used in any test case MUST be outside the reserved label value (0-15) unless stated otherwise.
テストケースで使用されるMPLSラベル値は、特に明記しない限り、予約ラベル値（0-15）の外側でなければなりません。
This document prescribes using an IP packet as the MPLS payload (as illustrated in Figure 3 above). Generically speaking, this document mandates the test frame to include IP (either IPv4 or IPv6) as the Layer 3 protocol, in accord with Section 8 of [RFC2544] and independent of the MPLS label stack presence, for three reasons: 1. This enables using IP Prefix Forwarding Equivalence Class (FEC) [RFC3031], which is a must for every MPLS network.
このドキュメントは、IPパケットをMPLSペイロードとして使用して規定しています（上記の図3に示すように）。一般的に言えば、このドキュメントは、[RFC2544]のセクション8に従って、レイヤー3プロトコルとしてIP（IPv4またはIPv6）をレイヤー3プロトコルとして含めるようにテストフレームを義務付けています。IPプレフィックス転送等価クラス（FEC）[RFC3031]を使用します。これは、すべてのMPLSネットワークに必須です。
2. This provides the foundation or baseline for the benchmarking of various other MPLS applications such as L3VPN, L2VPN, TE-FRR, etc.
2. これにより、L3VPN、L2VPN、TE-FRRなど、他のさまざまなMPLSアプリケーションのベンチマークの基礎またはベースラインが提供されます。
3. This enables leveraging RFC 2544 [RFC2544], which prescribes using IP packets with UDP data as the test frames. (Note that [RFC5180] also uses this prescription for IPv6 benchmarking).
3. これにより、RFC 2544 [RFC2544]を活用することができます。これは、UDPデータを使用してIPパケットをテストフレームとして使用することを規定しています。（[RFC5180]は、この処方箋もIPv6ベンチマークに使用していることに注意してください）。
While the usage of non-IP payloads is possible, it requires an MPLS application, e.g., L2VPN, whose benchmarking may be covered in separate BMWG documents (MPLS L2VPN Benchmarking, for example) in the future. This is also explained in Section 2.
非IPペイロードの使用は可能ですが、将来、ベンチマークが別々のBMWGドキュメント（MPLS L2VPNベンチマークなど）でベンチマークをカバーすることができるMPLSアプリケーション、たとえばL2VPNが必要です。これについては、セクション2でも説明されています。
A frame carrying an IP or MPLS packet may go through any of the three MPLS forwarding operations: label push (or LSP Ingress), label swap, and label pop (or LSP Egress), as defined in [RFC3031]. It is important to understand the change of the frame format from IP to MPLS or vice versa depending on the forwarding operation.
IPまたはMPLSパケットを運ぶフレームは、[RFC3031]で定義されているように、ラベルプッシュ（またはLSP Swap）、ラベルスワップ、およびラベルPOP（またはLSP Egress）の3つのMPLS転送操作のいずれかを通過できます。転送操作に応じて、IPからMPLSまたはその逆へのフレーム形式の変更を理解することが重要です。
In a label push (or LSP Ingress) operation, the DUT receives a frame containing an IP packet and forwards a frame containing an MPLS packet if the corresponding forwarding lookup for the IP destination points to a label push operation.
ラベルプッシュ（またはLSP Ingress）操作では、DUTはIPパケットを含むフレームを受け取り、MPLSパケットを含むフレームを転送し、IP宛先ポイントの対応する転送ルックアップがラベルプッシュ操作に転送されます。
In a label swap operation, the DUT receives a frame containing an MPLS packet and forwards a frame containing an MPLS packet if the corresponding forwarding lookup for the label value points to a label swap operation.
ラベルスワップ操作では、DUTはMPLSパケットを含むフレームを受信し、ラベルバリューポイントの対応する転送ルックアップがラベルスワップ操作にある場合、MPLSパケットを含むフレームを転送します。
In a label pop (or LSP Egress) operation, the DUT receives a frame containing an MPLS packet and forwards a frame containing an IP packet if the corresponding forwarding lookup for the label value points to a label pop operation.
ラベルPOP（またはLSP Egress）操作では、DUTはMPLSパケットを含むフレームを受信し、ラベル値の対応する転送検索がラベルPOP操作にポイントする場合、IPパケットを含むフレームを転送します。
This document prescribes using two test frame formats to appropriately test the forwarding operations: (1) Frame format for IP and (2) Frame format for MPLS. Both formats are explained in Section 4.1.4.1. Additionally, the format of the test frame may change depending on the forwarding operation.
このドキュメントでは、2つのテストフレーム形式を使用して、転送操作を適切にテストします。（1）IPのフレーム形式、（2）MPLSのフレーム形式。両方の形式については、セクション4.1.4.1で説明しています。さらに、テストフレームの形式は、転送操作に応じて変更される場合があります。
1. For test cases involving the label push operation, the test tool must use the frame format for IP packets (Figure 2) to send the test frames to the DUT, and must use the frame format for MPLS packets (Figure 3) to receive the test frames from the DUT.
1. ラベルプッシュ操作を含むテストケースの場合、テストツールはIPパケットのフレーム形式を使用し（図2）、テストフレームをDUTに送信する必要があり、MPLSパケットのフレーム形式（図3）を使用してテストを受信する必要があります。DUTからのフレーム。
2. For test cases involving the label swap operation, the test tool must use the frame format for MPLS packets (Figure 3) to send the test frames to the DUT, and must use the frame format for MPLS packets (Figure 3) to receive the test frames from the DUT.
2. ラベルスワップ操作を含むテストケースの場合、テストツールはMPLSパケットのフレーム形式を使用して（図3）、テストフレームをDUTに送信する必要があり、MPLSパケットのフレーム形式（図3）を使用してテストを受信する必要があります。DUTからのフレーム。
3. For test cases involving the label pop operation, the test tool must use the frame format for MPLS packets (Figure 3) to send the test frames to the DUT, and must use the frame format for IP packets (Figure 2) to receive the test frames from the DUT.
3. ラベルポップ操作を含むテストケースの場合、テストツールはMPLSパケットのフレーム形式を使用して（図3）、テストフレームをDUTに送信する必要があり、IPパケットのフレーム形式（図2）を使用してテストを受信する必要があります。DUTからのフレーム。
Two types of port media are commonly deployed: Ethernet and POS (Packet Over Synchronous Optical Network). This section identifies the frame sizes that SHOULD be used for each media type, if supported by the DUT; Section 4.1.5.1 covers Ethernet and Section 4.1.5.2 covers POS.
通常、2種類のポートメディアが展開されています：イーサネットとPOS（同期光ネットワーク上のパケット）。このセクションでは、DUTによってサポートされている場合、各メディアタイプに使用する必要があるフレームサイズを識別します。セクション4.1.5.1はイーサネットをカバーし、セクション4.1.5.2はPOSをカバーしています。
First, it is important to note the possible increase in frame size due to the presence of an MPLS label stack in the frame (as explained in Section 4.1.4.3).
まず、フレーム内にMPLSラベルスタックが存在するため、フレームサイズの増加の可能性に注意することが重要です（セクション4.1.4.3で説明しているように）。
As observed in the current deployments, presence of an MPLS label stack in a Layer 2 frame is assumed to be transparent to Layer3=IP, which continues to follow the conventional maximum frame payload size [RFC3032] (1500 octets for Ethernet, say). This means that the effective maximum frame payload size [RFC3032] of the resulting Layer 2 frame is Z octets more than the conventional maximum frame payload size, where Z = 4 x number of entries in the label stack.
現在の展開で観察されたように、レイヤー2フレームでのMPLSラベルスタックの存在は、layer3 = IPに対して透明であると想定されています。これは、結果のレイヤー2フレームの有効な最大フレームペイロードサイズ[RFC3032]は、z = 4 xラベルスタックのエントリの数がz = 4 x zオクターであることを意味します。
Hence, to ensure successful delivery of Layer 2 frames carrying MPLS packets and realistic benchmarking, it is RECOMMENDED to set the media MTU value to the effective maximum frame payload size [RFC3032], which equals Z octets + conventional maximum frame payload size. It is expected that such a change in the media MTU value only impacts the effective Maximum Frame Payload Size for MPLS packets, but not for IP packets.
したがって、MPLSパケットとリアルなベンチマークを運ぶレイヤー2フレームの配信を成功させるために、Zオクテットの従来の最大フレームペイロードサイズに等しく、メディアMTU値を有効な最大フレームペイロードサイズ[RFC3032]に設定することをお勧めします。メディアMTU値のこのような変更は、MPLSパケットの有効な最大フレームペイロードサイズにのみ影響を与えるが、IPパケットでは影響しないことが予想されます。
Note that this document requires exactly a single entry in the MPLS label stack in an MPLS packet. In other words, the depth of the label stack is set to one, e.g., Z = 4 x 1 = 4 octets. Furthermore, in accord with Sections 9 and 9.1 of RFC 2544, this document prescribes that each test case is run with different (Layer 2) frame sizes in different trials. Additionally, results MAY also be collected with multiple simultaneous frame sizes (sometimes referred to as an Interactive Multimodal Information Extraction (IMIX) to simulate real network traffic according to the frame size ordering and usage). There is no standard for mixtures of frame sizes, and the results are subject to wide interpretation (see Section 18 of RFC 2544). When running trials using multiple simultaneous frame sizes, the DUT configuration MUST remain the same.
このドキュメントには、MPLSパケットのMPLSラベルスタックに正確に単一のエントリが必要であることに注意してください。言い換えれば、ラベルスタックの深さは1つに設定されています。たとえば、z = 4 x 1 = 4オクテットです。さらに、RFC 2544のセクション9および9.1に従って、このドキュメントは、各テストケースが異なる試行で異なる（レイヤー2）フレームサイズで実行されることを規定しています。さらに、結果は、複数の同時フレームサイズ（フレームサイズの順序と使用状況に応じて実際のネットワークトラフィックをシミュレートするためのインタラクティブなマルチモーダル情報抽出（IMIX）と呼ばれることもあります）で収集される場合があります。フレームサイズの混合物の標準はありません。結果は、幅広い解釈の対象となります（RFC 2544のセクション18を参照）。複数の同時フレームサイズを使用して試行を実行する場合、DUT構成は同じままでなければなりません。
Ethernet media, in all its types, has become the most commonly deployed port media in MPLS networks. If any test case execution (such as the Label Push case) requires the test tool to send (or receive) a Layer 2 frame containing an IP packet, then the following frame sizes SHOULD be used for benchmarking over Ethernet media: 64, 128, 256, 512, 1024, 1280, and 1518 octets. This is in-line with Sections 9 and 9.1 of RFC 2544. Figure 4 illustrates the header sizes for an untagged Ethernet frame containing an IP payload (per RFC 2544).
すべてのタイプのイーサネットメディアは、MPLSネットワークで最も一般的に展開されているポートメディアになりました。テストケースの実行（ラベルプッシュケースなど）では、IPパケットを含むレイヤー2フレームを送信（または受信）するテストツールが必要な場合は、次のフレームサイズをイーサネットメディア経由のベンチマークに使用する必要があります：64、128、256、512、1024、1280、および1518オクテット。これは、RFC 2544のセクション9および9.1とインラインで行われます。図4は、IPペイロードを含むUntaggedイーサネットフレームのヘッダーサイズ（RFC 2544ごと）を示しています。
<----------------64-1518B------------------------>
<--18B---><-----------46-1500B------------------->
+---------+---------+----------------------------+
| Layer 2 | Layer 3 | Layer 4 (and higher) |
+---------+---------+----------------------------+
Figure 4: Frame Size for Label Push Cases
図4：ラベルプッシュケースのフレームサイズ
Note 1: The 64- and 1518-octet frame size represents the minimum and maximum length of an untagged Ethernet frame, as per IEEE 802.3 [IEE8023]. A frame size commonly used in operational environments may range from 68 to 1522 octets, which are the minimum and maximum lengths of a single VLAN-tagged frame, as per IEEE 802.1D [IEE8021].
注1：IEEE 802.3 [IEE8023]によると、64および1518-OCTETフレームのサイズは、攻撃されていないイーサネットフレームの最小長と最大長を表します。運用環境で一般的に使用されるフレームサイズは、IEEE 802.1d [IEE8021]に従って、68〜1522オクテットの範囲であり、1つのVLANタグ付きフレームの最小値と最大長です。
Note 2: While jumbo frames are outside the scope of the 802.3 IEEE standard, tests SHOULD be executed with the frame sizes that are supported by the DUT. Examples of commonly used jumbo (Ethernet) frame sizes are: 4096, 8192, and 9216 octets.
注2：ジャンボフレームは802.3 IEEE標準の範囲外にありますが、DUTによってサポートされているフレームサイズでテストを実行する必要があります。一般的に使用されるジャンボ（イーサネット）フレームサイズの例は、4096、8192、および9216オクテットです。
If any test case execution (such as Label Swap and Label Pop cases) requires the test tool to transmit (or receive) a Layer 2 frame containing an MPLS packet, then the untagged Layer 2 frame must include an additional 4 octets for the MPLS header, resulting in the following frame sizes to be used for benchmarking over Ethernet media: 68, 132, 260, 516, 1028, 1284, and 1522 octets. Figure 5 illustrates the header sizes for an untagged Ethernet frame containing an MPLS packet.
テストケースの実行（ラベルスワップやラベルポップケースなど）には、MPLSパケットを含むレイヤー2フレームを送信（または受信）するテストツールが必要な場合、Untaggedレイヤー2フレームには、MPLSヘッダーの追加の4オクテットを含める必要があります。、次のフレームサイズをイーサネットメディア経由のベンチマークに使用します：68、132、260、516、1028、1284、および1522オクテット。図5は、MPLSパケットを含むタグ付きイーサネットフレームのヘッダーサイズを示しています。
<------------------68-1522B------------------------------>
<--18B---><--4B--><-----------46-1500B------------------->
+---------+-------+---------+----------------------------+
| Layer 2 | MPLS | Layer 3 | Layer 4 (and higher) |
+---------+-------+---------+----------------------------+
Figure 5: Frame Size for Label Swap and Pop Cases
図5：ラベルスワップおよびポップケースのフレームサイズ
Note: The Media MTU on the link between the test tool and the DUT must be changed, if needed, to accommodate the effective maximum frame payload size [RFC3032] resulting from adding an MPLS label stack to the IP packet. As clarified in Section 3.1 of RFC 3032, most Layer 2 media drivers are capable of sending and receiving Layer 2 frames with effective maximum frame payload size. Many vendors also allow the Media MTU to be changed for MPLS, without changing it for IP. The recommended link MTU value for MPLS is Z octets more than the conventional maximum frame payload size [RFC3032] (for example, the conventional maximum frame payload size for Ethernet is 1500 octets). This document prescribes Z=4 octets. If a vendor DUT doesn't allow such an MTU change, then the benchmarking cannot be performed for the true maximum frame payload size [RFC3032] and this must be reported.
注：IPパケットにMPLSラベルスタックを追加した結果として、有効な最大フレームペイロードサイズ[RFC3032]に対応するために、必要に応じて、テストツールとDUTの間のリンクに関するメディアMTUを変更する必要があります。RFC 3032のセクション3.1で明確にされているように、ほとんどのレイヤー2メディアドライバーは、有効な最大フレームペイロードサイズのレイヤー2フレームを送信および受信できます。また、多くのベンダーは、MPLのMPLの変更を変更することなく、メディアMTUを変更することも許可しています。MPLSの推奨リンクMTU値は、従来の最大フレームペイロードサイズ[RFC3032]よりもZオクテットです（たとえば、イーサネットの従来の最大フレームペイロードサイズは1500オクテットです）。このドキュメントはz = 4オクテットを規定しています。ベンダーDUTがそのようなMTUの変更を許可しない場合、真の最大フレームペイロードサイズ[RFC3032]に対してベンチマークを実行できず、これを報告する必要があります。
Packet over SONET (POS) media are commonly used for edge uplinks and high-bandwidth core links. POS may use one of various encapsulations techniques (such as PPP, High-Level Data Link Control (HDLC), Frame Relay, etc.), resulting in the Layer 2 header (~4 octets) being less than that of the Ethernet media. The rest of the frame format (illustrated in Figures 2 and 3) remains pretty much unchanged.
SONET（POS）メディア上のパケットは、一般的にエッジアップリンクと高帯域幅コアリンクに使用されます。POSは、さまざまなカプセル化手法（PPP、高レベルのデータリンクコントロール（HDLC）、フレームリレーなど）のいずれかを使用して、レイヤー2ヘッダー（〜4オクテット）がイーサネットメディアのヘッダーよりも少ないことがあります。フレーム形式の残りの部分（図2および3に示す）は、ほとんど変化していません。
If the MPLS forwarding characterization of POS interfaces on the DUT is desired, then the following frame sizes SHOULD be used:
DUTでのPOSインターフェイスのMPLS転送の特性評価が必要な場合、次のフレームサイズを使用する必要があります。
Label Push test cases: 47, 64, 128, 256, 512, 1024, 1280, 1518, 2048, and 4096 octets.
ラベルプッシュテストケース：47、64、128、256、512、1024、1280、1518、2048、および4096オクテット。
Label Swap and Pop test cases: 51, 68, 132, 260, 516, 1028, 1284, 1522, 2052, and 4100 octets.
ラベルスワップおよびポップテストケース：51、68、132、260、516、1028、1284、1522、2052、および4100オクテット。
The TTL value in the frame header MUST be large enough to allow a TTL decrement to happen and still be forwarded through the DUT. The aforementioned TTL field may be referring to either the MPLS TTL, IPv4 TTL, or IPv6 Hop Limit depending on the exact forwarding scenario under evaluation.
フレームヘッダーのTTL値は、TTLの減少を可能にし、DUTを通じて転送するのに十分な大きさでなければなりません。前述のTTLフィールドは、評価中の正確な転送シナリオに応じて、MPLS TTL、IPv4 TTL、またはIPv6ホップ制限のいずれかを参照している場合があります。
If TTL/Hop Limit decrement, as specified in [RFC3443], is a configurable option on the DUT, the setting SHOULD be reported.
[RFC3443]で指定されているように、TTL/ホップ制限の減少がDUTで構成可能なオプションである場合、設定を報告する必要があります。
Unless otherwise specified, the test portion of each trial SHOULD be no less than 30 seconds when static routing is in place, and no less than 200 seconds when a dynamic routing protocol and LDP (default LDP holddown timer is 180 seconds) are being used. If the holddown timer default value is changed, then it should be reported and the trial duration should still be 20 seconds more than the holddown timer value.
特に指定されていない限り、各トライアルのテスト部分は、静的ルーティングが整っている場合は30秒以上、動的ルーティングプロトコルとLDP（デフォルトのLDPホールドダウンタイマーが180秒）が使用される場合は200秒以上でなければなりません。ホールドダウンタイマーのデフォルト値が変更された場合、報告する必要があり、トライアル期間はホールドダウンタイマー値よりも20秒多い必要があります。
The longer trial time used for dynamic routing protocols is to verify that the DUT is able to maintain a stable control plane when the data-forwarding plane is under stress.
ダイナミックルーティングプロトコルに使用されるより長い試行時間は、DUTがデータに向けてストレスにさらされているときに、DUTが安定した制御プレーンを維持できることを確認することです。
In all cases, sent traffic MUST be accounted for, whether it was received on the wrong port, the correct port, or not received at all. Specifically, traffic loss (also referred to as frame loss) is defined as the traffic (i.e., one or more frames) not received where expected (i.e., received on the incorrect port, or received with incorrect Layer 2 or above header information, etc.). In addition, the presence or absence of the MPLS label stack, every field value inside the label stack, if present, ethertype (0x8847 or 0x8848 versus 0x0800 or 0x86DD), frame sequencing, and frame check sequence (FCS) MUST be verified in the received frame.
すべての場合において、間違ったポート、正しいポート、またはまったく受信されていないかどうかにかかわらず、送信されたトラフィックを考慮する必要があります。具体的には、トラフィックの損失（フレームロスとも呼ばれます）は、予想される場所（つまり、1つ以上のフレーム）として定義されます（つまり、誤ったポートで受信するか、誤ったレイヤー2以下のヘッダー情報などで受信されます。。）。さらに、MPLSラベルスタックの存在または不在、ラベルスタック内のすべてのフィールド値、存在する場合、EtherType（0x8847または0x8848対0x0800または0x86DD）、フレームチェックシーケンス（FCS）を確認する必要があります。受信フレーム。
Many test tools may, by default, only verify that they have received the embedded signature on the receive side. However, for MPLS header presence verification, some tests will require the MPLS header to be pushed while others will require a swap or pop. Hence, this document requires the test tool to verify the MPLS stack depth. An even greater level of verification would be to check if the correct label was pushed. However, some test tools are not capable of checking the received label value for correctness. Test tools SHOULD verify that the packets received carry the expected MPLS label.
多くのテストツールは、デフォルトでは、受信側に埋め込まれた署名を受信したことを確認する場合があります。ただし、MPLSヘッダーの存在検証の場合、一部のテストではMPLSヘッダーをプッシュする必要がありますが、他のテストではスワップまたはPOPが必要です。したがって、このドキュメントでは、MPLSスタックの深さを検証するためのテストツールが必要です。さらに大きなレベルの検証は、正しいラベルがプッシュされたかどうかを確認することです。ただし、一部のテストツールでは、受信したラベル値を正しさのためにチェックすることはできません。テストツールは、受信したパケットが予想されるMPLSラベルを運ぶことを確認する必要があります。
If a test setup utilizes any dynamic protocols for control plane signaling (e.g., ARP, PPP (including MPLSCP), OSPF, LDP, etc.), then all state for the protocols MUST be pre-established before the test case is executed (i.e., packet streams are started).
テストセットアップがコントロールプレーンシグナル伝達に動的プロトコル（例：ARP、PPP（MPLSCPを含む）、OSPF、LDPなど）を使用する場合、テストケースが実行される前に、プロトコルのすべての状態を事前に確立する必要があります（つまり、、パケットストリームが開始されます）。
For each test case, it is RECOMMENDED that the following variables be reported in addition to the specific parameters requested by the test case:
各テストケースについて、テストケースで要求された特定のパラメーターに加えて、次の変数を報告することをお勧めします。
Parameter Units or Examples
パラメーターユニットまたは例
Prefix Forwarding Equivalence IPv4, IPv6, Both Class (FEC)
プレフィックス転送等価IPv4、IPv6、両方のクラス（FEC）
Label Distribution Protocol LDP, RSVP-TE, BGP (or combinations)
ラベル分布プロトコルLDP、RSVP-TE、BGP（または組み合わせ）
MPLS Forwarding Operation Push, Swap, Pop
MPLS転送操作プッシュ、スワップ、ポップ
IGP ISIS, OSPF, EIGRP, RIP, static.
IGP ISIS、OSPF、EIGRP、RIP、静的。
Throughput Frames per second and bits per second
スループットフレームあたりのフレームと1秒あたりのビット
Port Media GigE (Gigabit Ethernet), POS, ATM, etc.
ポートメディアギゲ（ギガビットイーサネット）、POS、ATMなど。
Port Speed 1 gbps, 100 Mbps, etc.
ポートスピード1 Gbps、100 Mbpsなど。
Interface Encapsulation Ethernet, Ethernet VLAN, PPP, HDLC, etc.
インターフェイスカプセル化イーサネット、イーサネットVLAN、PPP、HDLCなど。
Frame Size (Section 4.1.5) Octets
フレームサイズ（セクション4.1.5）オクテット
p (Number of {DA, DB} pair 1,2, etc. ports per Figure 1)
P（{da、db}ペア1,2などの数。図1あたりのポート）
The individual test cases may have additional reporting requirements that may refer to other RFCs.
個々のテストケースには、他のRFCを参照する可能性のある追加の報告要件がある場合があります。
MPLS is a different forwarding paradigm from IP. Unlike IP packets and IP forwarding, an MPLS packet may contain more than one MPLS header and may go through one of three forwarding operations: push (or LSP Ingress), swap, or pop (or LSP Egress), as defined in [RFC3031]. Such characteristics desire further granularity in MPLS forwarding benchmarking than those described in RFC 2544. Thus, the benchmarking may include, but is not limited to:
MPLSは、IPとは異なる転送パラダイムです。IPパケットやIP転送とは異なり、MPLSパケットには複数のMPLSヘッダーが含まれている場合があり、[RFC3031]で定義されているように、3つの転送操作のいずれかを通過する場合があります：プッシュ（またはLSPイングレス）、スワップ、またはPOP（またはLSP Egress）。このような特性は、RFC 2544で説明されているものよりもMPLS転送ベンチマークにおいてさらなる粒度を望んでいます。したがって、ベンチマークには以下が含まれる場合がありますが、これらに限定されません。
1. Throughput
1. スループット
2. Latency
2. 遅延
3. Frame-Loss Rate
3. フレームロスレート
4. System Recovery
4. システムの回復
5. Reset
5. リセット
6. MPLS TC (previously known as EXP [RFC5462]) field Operations (including explicit-null cases)
6. MPLS TC（以前はEXP [RFC5462]として知られていました）フィールド操作（明示的なヌルの場合を含む）
7. Negative Scenarios (TTL expiry, etc.)
7. ネガティブシナリオ（TTL有効期限など）
8. Multicast
8. マルチキャスト
However, this document focuses only on the first five categories, inline with the spirit of RFC 2544. All the benchmarking test cases described in this document are expected to, at a minimum, follow the "Test Setup" and "Test Procedure" below:
ただし、このドキュメントは、RFC 2544のスピリットとインラインな最初の5つのカテゴリにのみ焦点を当てています。このドキュメントで説明されているすべてのベンチマークテストケースは、少なくとも以下の「テストセットアップ」と「テスト手順」に従うことが期待されています。
Test Setup
テスト設定
Referring to Figure 1, a single port (p = 1) on both A and B Modules SHOULD be used. However, if the forwarding throughput of the DUT is more than that of the media rate of a single port, then additional ports on A and B Modules MUST be enabled as follows: if the DUT can be configured with the A and B ports so as to exceed the DUT's forwarding throughput without overloading any B ports, then those MUST be enabled; if, on the other hand, the DUT's forwarding throughput capacity is greater than what can be achieved enabling all ports, then all An and Bn ports MUST be enabled. In the case where more than one A and B port is enabled, the procedures described in Section 16 of RFC 2544 must be followed to accommodate the multi-port scenario. The frame formats transmitted and received must be in accord with Sections 4.1.4.3 and 4.1.4.4, and frame sizes must be in accord with Section 4.1.5.
図1を参照すると、AモジュールとBモジュールの両方の単一のポート（p = 1）を使用する必要があります。ただし、DUTの転送スループットが単一のポートのメディアレートよりも多い場合、AおよびBモジュールの追加ポートを次のように有効にする必要があります。Bポートを過負荷にすることなくDUTの転送スループットを超えるには、それらを有効にする必要があります。一方、DUTの転送スループット容量がすべてのポートを有効にすることを実現できるものよりも大きい場合、すべてのANおよびBNポートを有効にする必要があります。複数のAとBポートが有効になっている場合、RFC 2544のセクション16で説明されている手順に従って、マルチポートシナリオに対応する必要があります。送信および受信されたフレーム形式は、セクション4.1.4.3および4.1.4.4と一致している必要があり、フレームサイズはセクション4.1.5と一致する必要があります。
Note: The test tool must be configured not to advertise a prefix or FEC to the DUT on more than one port. In other words, the DUT must associate a FEC with one and only one DB port. The Equal Cost Multi-Path (ECMP) behavior in MPLS networks uses heuristics [RFC4928]; hence, the usage of ECMP is NOT permitted by this document to ensure the deterministic forwarding behavior during benchmarking.
注：テストツールは、複数のポートでDUTにプレフィックスまたはFECを宣伝しないように構成する必要があります。言い換えれば、DUTはFECを1つのDBポートに1つだけ関連付ける必要があります。MPLSネットワークの等しいコストマルチパス（ECMP）動作は、ヒューリスティックを使用します[RFC4928]。したがって、ベンチマーク中の決定論的転送挙動を確保するために、このドキュメントではECMPの使用は許可されていません。
Test Procedure
テスト手順
In accord with Section 26 of RFC 2544 [RFC2544], the traffic is sent from test tool port(s) Ap to the DUT at a constant load for a fixed-time interval, and is received from the DUT on test tool port(s) Bp. As described in Section 4.1.4.3, the frame may contain either an IP packet or an MPLS packet depending on the test case need. Furthermore, the IP packet must be either an IPv4 or IPv6 packet, depending on whether the MPLS benchmarking is done for IPv4 or IPv6.
RFC 2544 [RFC2544]のセクション26に従って、トラフィックはテストツールポートからDUTに固定時間間隔で一定の負荷でDUTに送信され、テストツールポート（s）から受信されます（s）BP。セクション4.1.4.3で説明されているように、フレームには、テストケースの必要性に応じて、IPパケットまたはMPLSパケットのいずれかを含めることができます。さらに、IPパケットは、MPLSベンチマークがIPv4またはIPv6に対して行われるかどうかに応じて、IPv4またはIPv6パケットのいずれかでなければなりません。
If any frame loss is detected, then a new iteration is needed where the offered load is decreased and the sender will transmit again. An iterative search algorithm MUST be used to determine the maximum offered frame rate with a zero frame loss.
フレームの損失が検出された場合、提供された負荷が減少し、送信者が再び送信される場合、新しい反復が必要です。反復検索アルゴリズムを使用して、フレーム損失がゼロで提供される最大フレームレートを決定する必要があります。
This maximum offered frame rate that results in zero frame loss through the DUT is defined as the Throughput in Section 3.17 of [RFC1242] for that test case. Informally, this rate is referred to as the No-Drop Rate (NDR).
DUTを介してゼロフレーム損失をもたらすこの最大提供フレームレートは、そのテストケースの[RFC1242]のセクション3.17のスループットとして定義されます。非公式には、このレートはノードロップレート（NDR）と呼ばれます。
Each iteration should involve varying the offered load of the traffic, while keeping the other parameters (test duration, number of ports, number of addresses, frame size, etc.) constant, until the maximum rate at which none of the offered frames are dropped is determined.
各反復には、提供されるトラフィックの負荷を変更する必要がありますが、他のパラメーター（テスト期間、ポート数、アドレス数、フレームサイズなど）を一定に保ちます。決定されます。
This section contains the description of the tests that are related to the characterization of a DUT's MPLS traffic forwarding.
このセクションには、DUTのMPLSトラフィック転送の特性評価に関連するテストの説明が含まれています。
Objective
目的
To obtain the DUT's Throughput (as per RFC 2544) during label push or LSP Ingress forwarding operation (i.e., IP to MPLS).
ラベルプッシュまたはLSPイングレス転送操作（つまり、MPLからIP）中にDUTのスループット（RFC 2544に従って）を取得します。
Test Setup
テスト設定
In addition to the "Test Setup" described in Section 6, the test tool must advertise the IP prefix(es), i.e., RNx (using a routing protocol as per Section 4.1.2) and associated MPLS label-FEC binding(s) (using a label distribution protocol as per Section 4.1.3) on its receive ports Bp to the DUT. The test tool may learn the IP prefix(es) on its transmit ports Ap from the DUT.
セクション6で説明されている「テストセットアップ」に加えて、テストツールはIPプレフィックス（ES）、つまりRNX（セクション4.1.2に従ってルーティングプロトコルを使用）および関連するMPLSラベルFECバインディング（S）を宣伝する必要があります。（セクション4.1.3に従って、ラベル分布プロトコルを使用して）DUTへの受信ポートBPについて。テストツールは、DUTから送信ポートAPのIPプレフィックス（ES）を学習できます。
MPLS and/or the label distribution protocol must be enabled only on the test tool receive ports Bp and DUT transmit ports DBp.
MPLSおよび/またはラベル分布プロトコルは、テストツールでのみ有効にする必要があります。
Discussion
考察
The DUT's MPLS forwarding table (also referred to as Incoming Label Map (ILM) to Next Hop Label Forwarding Entry (NHLFE) mapping table per Section 3.11 of [RFC3031]) must contain a non-reserved MPLS label value as the outgoing label for each learned IP prefix corresponding to the label-FEC binding, resulting in the DUT performing the IP-to-MPLS forwarding operation. The test tool must receive MPLS packets on receive ports Bp (from the DUT) with the same label values that were advertised.
DUTのMPLS転送テーブル（[RFC3031]のセクション3.11ごとに、次のホップラベル転送エントリ（NHLFE）マッピングテーブルから次のホップラベル転送エントリ（NHLFE）と呼ばれる）のMPLS転送テーブルは、それぞれの発信ラベルとして非予約されたMPLSラベル値を含める必要があります。ラベルFECバインディングに対応する学習IPプレフィックスで、DUTがIPからMPLS転送操作を実行します。テストツールは、宣伝された同じラベル値を持つ受信ポートBP（DUTから）のMPLSパケットを受信する必要があります。
Procedure
手順
Please see "Test Procedure" in Section 6. Additionally, the test tool MUST send the frames containing IP packets (with the IP destination belonging to the advertised IP prefix(es)) on transmit ports Ap, and expect to receive frames containing MPLS packets on receive ports Bp, as described in Section 4.1.4.4.
セクション6の「テスト手順」を参照してください。さらに、テストツールは、IPパケットを含むフレームを送信する必要があります。セクション4.1.4.4で説明されているように、受信ポートBPについて。
Reporting Format
レポート形式
The result should be reported as per Section 5 and RFC 2544.
結果は、セクション5およびRFC 2544に従って報告する必要があります。
Results for each test SHOULD be in the form of a table with a row for each of the tested frame sizes. Additional columns SHOULD include offered load and measured throughput.
各テストの結果は、テストされたフレームサイズごとに行を持つテーブルの形式でなければなりません。追加の列には、提供された負荷と測定されたスループットを含める必要があります。
Objective
目的
To obtain the DUT's Throughput (as per RFC 2544) during label swapping operation (i.e., MPLS-to-MPLS).
ラベルスワッピング操作（つまり、MPLS-to-MPLS）中にDUTのスループット（RFC 2544に従って）を取得する。
Test Setup
テスト設定
In addition to the setup described in Section 6, the test tool must advertise IP prefix(es) (using a routing protocol as per Section 4.1.2) and associated MPLS label-FEC bindings (using a label distribution protocol as per Section 4.1.3) on the receive ports Bp, and then learn the IP prefix(es) as well as the label-FEC binding(s) on the transmit ports Ap. The test tool must use the learned MPLS label values and learned IP prefix values in the frames transmitted on ports Ap to the DUT.
セクション6で説明したセットアップに加えて、テストツールは、IPプレフィックス（ES）（セクション4.1.2に従ってルーティングプロトコルを使用）および関連するMPLSラベルFECバインディング（セクション4.1に従ってラベル分布プロトコルを使用して宣伝する必要があります。3）受信ポートBPで、IPプレフィックス（ES）と送信ポートAPのラベルFECバインディングを学習します。テストツールは、学習したMPLSラベル値と、ポートAPで送信されたフレーム内の学習したIPプレフィックス値をDUTに使用する必要があります。
MPLS and/or label distribution protocol must be enabled on the test tool ports Bp and Ap, and the DUT ports DBp and DAp.
MPLSおよび/またはラベル分布プロトコルは、テストツールポートBPおよびAP、およびDUTポートDBPおよびDAPで有効にする必要があります。
Discussion
考察
The DUT's MPLS forwarding table (also referred to as ILM to NHLFE mapping table per Section 3.11 of [RFC3031]) must contain non-reserved MPLS label values as the outgoing and incoming labels for the learned IP prefixes, resulting in an MPLS-to-MPLS forwarding operation, e.g., label swap. The test tool must receive MPLS packets on receive ports Bp (from the DUT) with the same label values that were advertised using the label distribution protocol. The received frames must contain the same number of MPLS headers as those of transmitted frames.
DUTのMPLS転送テーブル（[RFC3031]のセクション3.11ごとにNHLFEマッピングテーブルと呼ばれるILMとも呼ばれます）は、学習したIPプレフィックスの発信および着信ラベルとして非予定のMPLSラベル値を含める必要があります。MPLS転送操作、例えばラベルスワップ。テストツールは、ラベル配布プロトコルを使用して宣伝された同じラベル値を持つ、受信ポートBP（DUTから）のMPLSパケットを受信する必要があります。受信したフレームには、送信されたフレームと同じ数のMPLSヘッダーが含まれている必要があります。
Procedure
手順
Please see "Test Procedure" in Section 6. Additionally, the test tool must send frames containing MPLS packets (with the IP destination belonging to the advertised IP prefix(es)) on its transmit ports Ap, and expect to receive frames containing MPLS packets on its receive ports Bp, as described in Section 4.1.4.4.
セクション6の「テスト手順」を参照してください。さらに、テストツールはMPLSパケットを含むフレームを送信する必要があります。セクション4.1.4.4で説明されているように、受信ポートBPで。
Reporting Format
レポート形式
The result should be reported as per Section 5 and RFC 2544.
結果は、セクション5およびRFC 2544に従って報告する必要があります。
Results for each test SHOULD be in the form of a table with a row for each of the tested frame sizes.
各テストの結果は、テストされたフレームサイズごとに行を持つテーブルの形式でなければなりません。
Objective
目的
To obtain the DUT's Throughput (as per RFC 2544) during label pop or LSP Egress forwarding operation (i.e., MPLS-to-IP) using "Unlabeled" outgoing label.
「ラベルのない」発信ラベルを使用して、ラベルPOPまたはLSP Egress転送操作（つまりMPLS-to-IP）中にDUTのスループット（RFC 2544に従って）を取得します。
Test Setup
テスト設定
In addition to the setup described in Section 6, the test tool must advertise the IP prefix(es) (using a routing protocol as per Section 4.1.2) without any MPLS label-FEC bindings on the receive ports Bp, and then learn the IP prefix(es) as well as the FEC-label binding(s) on the transmit ports Ap. The test tool must use the learned MPLS label values and learned IP prefix values in the frames transmitted on ports Ap.
セクション6で説明されているセットアップに加えて、テストツールは、受信ポートBPにMPLSラベルFECバインディングなしで、IPプレフィックス（ES）（セクション4.1.2に従ってルーティングプロトコルを使用）を宣伝する必要があります。IPプレフィックス（ES）と送信ポートAPのFEC-Label結合（S）。テストツールは、学習したMPLSラベル値を使用し、Ports APに送信されたフレームで学習したIPプレフィックス値を使用する必要があります。
MPLS and/or label distribution protocol must be enabled only on the test tool port(s) Ap and DUT port(s) DAp.
MPLSおよび/またはラベル配布プロトコルは、テストツールポートおよびDUTポートDAPでのみ有効にする必要があります。
Discussion
考察
The DUT's MPLS forwarding table (also referred to as ILM to NHLFE mapping table per Section 3.11 of [RFC3031]) must contain an Unlabeled outgoing label (also known as untagged) for the learned IP prefix, resulting in an MPLS-to-IP forwarding operation.
DUTのMPLS転送テーブル（[RFC3031]のセクション3.11ごとにNHLFEマッピングテーブルと呼ばれるILMとも呼ばれます）には、学習したIPプレフィックスのラベルのない発信ラベル（Untaggedとも呼ばれます）が含まれている必要があります。手術。
Procedure
手順
Please see "Test Procedure" in Section 6. Additionally, the test tool must send frames containing MPLS packets on its transmit ports Ap (with the IP destination belonging to the IP prefix(es) advertised on port Bp), and expect to receive frames containing IP packets on its receive ports Bp, as described in Section 4.1.4.4.
セクション6の「テスト手順」を参照してください。さらに、テストツールは、送信ポートAPにMPLSパケットを含むフレームを送信する必要があります。セクション4.1.4.4で説明されているように、受信ポートBPにIPパケットが含まれています。
Reporting Format
レポート形式
The result should be reported as per Section 5 and RFC 2544.
結果は、セクション5およびRFC 2544に従って報告する必要があります。
Results for each test SHOULD be in the form of a table with a row for each of the tested frame sizes.
各テストの結果は、テストされたフレームサイズごとに行を持つテーブルの形式でなければなりません。
Objective
目的
To obtain the DUT's Throughput (as per RFC 2544) during label pop or LSP Egress forwarding operation (i.e., MPLS-to-IP) using the "Aggregate" outgoing label [RFC3031].
「集計」発信ラベル[RFC3031]を使用して、ラベルPOPまたはLSP Egress転送操作（つまりMPLS-to-IP）中にDUTのスループット（RFC 2544に従って）を取得するには。
Test Setup
テスト設定
In addition to the setup described in Section 6, the DUT must be provisioned such that it allocates an aggregate outgoing label (please see Section 3.20 in [RFC3031]) to an IP prefix, which aggregates a set of prefixes learned on ports DBp from the test tool. The prefix aggregation can be performed using BGP aggregation (Section 9.2.2.2 of [RFC4271]), IGP aggregation (Section 16.5 of [RFC2328]), etc.
セクション6で説明されているセットアップに加えて、DUTは、集計発信ラベル（[RFC3031]のセクション3.20を参照）をIPプレフィックスに割り当てるようにプロビジョニングする必要があります。テストツール。接頭辞集約は、BGP凝集（[RFC4271]のセクション9.2.2.2）、IGP凝集（[RFC2328]のセクション16.5）などを使用して実行できます。
The DUT must advertise the aggregating IP prefix along with the associated MPLS label-FEC binding on ports DAp to the test tool.
DUTは、ポートDAPの関連するMPLSラベルFECバインディングとともに、集約IPプレフィックスをテストツールに宣伝する必要があります。
The test tool then must use the learned MPLS label values and learned IP prefix values in frames transmitted on ports Ap to the DUT. The test tool must receive frames containing IP packets on ports Bp from the DUT.
テストツールは、学習したMPLSラベル値を使用し、ポートAPで送信されたフレームで学習したIPプレフィックス値をDUTに使用する必要があります。テストツールは、DUTからポートBPのIPパケットを含むフレームを受信する必要があります。
MPLS and/or label distribution protocol must be enabled only on the test tool port(s) Ap and DUT port(s) DAp.
MPLSおよび/またはラベル配布プロトコルは、テストツールポートおよびDUTポートDAPでのみ有効にする必要があります。
Discussion
考察
The DUT's MPLS forwarding table (also referred to as ILM to NHLFE mapping table per Section 3.11 of [RFC3031]) must contain an aggregate outgoing label and IP forwarding table must contain a valid entry for the learned prefix(es), resulting in MPLS-to-IP forwarding operation (i.e., MPLS header removal followed by IP lookup).
DUTのMPLS転送テーブル（[RFC3031]のセクション3.11ごとにNHLFEマッピングテーブルと呼ばれるILMとも呼ばれます）には、集計ラベルが含まれている必要があり、IP転送テーブルには、MPLS-をもたらす学習プレフィックスの有効なエントリが含まれている必要があります。To-IP転送操作（つまり、MPLSヘッダーの削除に続いてIPルックアップが続きます）。
Procedure
手順
Please see "Test Procedure" in Section 6. Additionally, the test tool must send frames containing MPLS packets on its transmit ports Ap (with IP destination belonging to the IP prefix(es) advertised on port Bp), and expect to receive frames containing IP packets on its receive ports Bp, as described in Section 4.1.4.4.
セクション6の「テスト手順」を参照してください。さらに、テストツールは、送信ポートAPにMPLSパケットを含むフレームを送信する必要があります。セクション4.1.4.4で説明されているように、受信ポートBPのIPパケット。
Reporting Format
レポート形式
The result should be reported as per Section 5 and RFC 2544.
結果は、セクション5およびRFC 2544に従って報告する必要があります。
Results for each test SHOULD be in the form of a table with a row for each of the tested frame sizes.
各テストの結果は、テストされたフレームサイズごとに行を持つテーブルの形式でなければなりません。
Objective
目的
To obtain the DUT's Throughput (as per RFC 2544) during label pop (i.e., MPLS-to-IP) or penultimate hop popping (PHP) using the "imp-null" outgoing label.
「Imp-null」発信ラベルを使用して、ラベルPOP（つまり、MPLSからIP）または最後から2番目のホップポップ（PHP）中にDUTのスループット（RFC 2544に従って）を取得するには。
Test Setup
テスト設定
In addition to the setup described in Section 6, the test tool must be set up to advertise the IP prefix(es) (using a routing protocol as per Section 4.1.2) and associated MPLS label-FEC binding with a reserved MPLS label value = 3 (using a label distribution protocol as per Section 4.1.3) on its receive ports Bp. The test tool must learn the IP prefix(es) as well as the MPLS label-FEC bindings on its transmit ports Ap. The test tool then must use the learned MPLS label values and learned IP prefix values in the frames transmitted on ports Ap to the DUT. The test tool must receive frames containing IP packets on receive ports Bp (from the DUT).
セクション6で説明されているセットアップに加えて、テストツールは、IPプレフィックス（ES）を宣伝するために設定する必要があります（セクション4.1.2に従ってルーティングプロトコルを使用）および関連するMPLSラベルFECバインディングを予約したMPLSラベル値でバインディングする必要があります。= 3（セクション4.1.3に従ってラベル分布プロトコルを使用）受信ポートBPで。テストツールは、IPプレフィックス（ES）とその送信ポートAPのMPLSラベルFECバインディングを学習する必要があります。テストツールは、学習したMPLSラベル値を使用し、ポートAPに送信されたフレーム内の学習IPプレフィックス値をDUTに使用する必要があります。テストツールは、受信ポートBP（DUTから）にIPパケットを含むフレームを受信する必要があります。
MPLS and/or label distribution protocol must be enabled on the test tool ports Bp and Ap, and DUT ports DBp and DAp.
MPLSおよび/またはラベル分布プロトコルは、テストツールポートBPおよびAP、およびDUTポートDBPおよびDAPで有効にする必要があります。
Discussion
考察
This test case characterizes Penultimate Hop Popping (PHP), which is described in RFC 3031.
このテストケースは、RFC 3031で説明されている最後から2番目のホップポップ（PHP）を特徴付けます。
The DUT's MPLS forwarding table (also referred to as ILM to NHLFE mapping table per Section 3.11 of [RFC3031]) must contain a reserved MPLS label value = 3 (e.g., pop or imp-null) as the outgoing label for the learned prefix(es), resulting in MPLS-to-IP forwarding operation.
DUTのMPLS転送テーブル（[RFC3031]のセクション3.11ごとのNHLFEマッピングテーブルと呼ばれるILMとも呼ばれます）は、学習プレフィックスの発行ラベルとして予約されたMPLSラベル値= 3（例：POPまたはIMP-Null）を含める必要があります（ES）、MPLSからIPへの転送操作をもたらします。
This test case characterizes DUT's penultimate hop popping (PHP) functionality.
このテストケースは、DUTの最後から2番目のホップポップ（PHP）機能を特徴づけています。
Procedure
手順
Please see "Test Procedure" in Section 6. Additionally, the test tool must send frames containing MPLS packets on its transmit ports Ap (with IP destination belonging to advertised IP prefix(es)), and expect to receive frames containing IP packets on its receive ports Bp, as described in Section 4.1.4.4.
セクション6の「テスト手順」を参照してください。さらに、テストツールは、送信ポートAPにMPLSパケットを含むフレームを送信する必要があります。セクション4.1.4.4で説明されているように、ポートBPを受け取ります。
Reporting Format
レポート形式
The result should be reported as per Section 5 and RFC 2544.
結果は、セクション5およびRFC 2544に従って報告する必要があります。
Results for each test SHOULD be in the form of a table with a row for each of the tested frame sizes.
各テストの結果は、テストされたフレームサイズごとに行を持つテーブルの形式でなければなりません。
Latency measurement measures the time taken by the DUT to forward the MPLS packet during various MPLS switching paths such as IP-to-MPLS, MPLS-to-MPLS, or MPLS-to-IP involving an MPLS label stack.
Latency測定は、MPLSラベルスタックを含むIP-T-MPLS、MPLS-to-MPLS、またはMPLS-to-IPなどのさまざまなMPLSスイッチングパス中にMPLSパケットを転送するためにDUTが取った時間を測定します。
Objective
目的
To obtain the average latency induced by the DUT during MPLS packet forwarding for each of five forwarding operations.
5つの転送操作のそれぞれについて、MPLSパケット転送中にDUTによって引き起こされる平均遅延を取得するため。
Test Setup
テスト設定
Follow the "Test Setup" guidelines established for each of the five MPLS forwarding operations in Sections 6.1.1 (for IP-to-MPLS), 6.1.2 (for MPLS-to-MPLS), 6.1.3 (for MPLS-to-IP Unlabeled), 6.1.4 (for MPLS-to-IP Aggregate), and 6.1.5 (for MPLS-to-IP PHP), one by one.
セクション6.1.1（IP-to-MPLSの場合）、6.1.2（MPLS-to-MPLSの場合）、6.1.3（MPLS-to-toの場合）の5つのMPLS転送操作のそれぞれについて確立された「テストセットアップ」ガイドラインに従ってください-IP Unlabeled）、6.1.4（MPLS-to-IP集計の場合）、6.1.5（MPLS-to-IP PHPの場合）、1つずつ。
Procedure
手順
Please refer to Section 26.2 in RFC 2544 in addition to following the associated procedure for each MPLS forwarding operation in accord with the test setup described earlier:
前述のテストセットアップに従って、各MPLS転送操作の関連手順に従って、次のテストのセットアップに従って、RFC 2544のセクション26.2を参照してください。
IP-to-MPLS forwarding (Push) Section 6.1.1 MPLS-to-MPLS forwarding (Swap) Section 6.1.2 MPLS-to-IP forwarding (Pop) Section 6.1.3 MPLS-to-IP forwarding (Aggregate) Section 6.1.4 MPLS-to-IP forwarding (PHP) Section 6.1.5
IP-T-MPLS転送（プッシュ）セクション6.1.1 MPLS-to-MPLSフォワーディング（SWAP）セクション6.1.2 MPLS-T-T-T-FOWROWNING（POP）セクション6.1.3 MPLSからIPへの転送（Aggregate）セクション6.1.4 MPLS-to-IP転送（PHP）セクション6.1.5
Reporting Format
レポート形式
The result should be reported as per Section 5 and RFC 2544.
結果は、セクション5およびRFC 2544に従って報告する必要があります。
Frame-Loss Rate (FLR) measurement measures the percentage of MPLS frames that were not forwarded during various switching paths such as IP-to-MPLS (push), MPLS-to-IP (swap), or MPLS-IP (pop) by the DUT under overloaded state.
フレームロスレート（FLR）測定測定IP-T-MPLS（プッシュ）、MPLS-IP（SWAP）、またはMPLS-IP（POP）などのさまざまなスイッチングパスで転送されなかったMPLSフレームの割合を測定します。過負荷状態のDUT。
Please refer to RFC 2544, Section 26.3, for more details.
詳細については、RFC 2544、セクション26.3を参照してください。
Objective
目的
To obtain the frame-loss rate, as defined in RFC 1242, for each of the three MPLS forwarding operations of a DUT, throughout the range of input data rates and frame sizes.
RFC 1242で定義されているように、DUTの3つのMPLS転送操作のそれぞれについて、入力データレートとフレームサイズの範囲全体で、フレームロスレートを取得します。
Test Setup
テスト設定
Follow the "Test Setup" guidelines established for each of the five MPLS forwarding operations in Sections 6.1.1 (for IP-to-MPLS), 6.1.2 (for MPLS-to-MPLS), 6.1.3 (for MPLS-to-IP Unlabeled), 6.1.4 (for MPLS-to-IP Aggregate), and 6.1.5 (for MPLS-to-IP PHP), one by one.
セクション6.1.1（IP-to-MPLSの場合）、6.1.2（MPLS-to-MPLSの場合）、6.1.3（MPLS-to-toの場合）の5つのMPLS転送操作のそれぞれについて確立された「テストセットアップ」ガイドラインに従ってください-IP Unlabeled）、6.1.4（MPLS-to-IP集計の場合）、6.1.5（MPLS-to-IP PHPの場合）、1つずつ。
Procedure
手順
Please refer to Section 26.3 of RFC 2544 [RFC2544] and follow the associated procedure for each MPLS forwarding operation one-by-one in accord with the test setup described earlier:
RFC 2544 [RFC2544]のセクション26.3を参照し、前述のテストセットアップに従って、各MPLS転送操作の関連手順に従ってください。
IP-to-MPLS forwarding (Push) Section 6.1.1 MPLS-to-MPLS forwarding (Swap) Section 6.1.2 MPLS-to-IP forwarding (Pop) Section 6.1.3 MPLS-to-IP forwarding (Aggregate) Section 6.1.4 MPLS-to-IP forwarding (PHP) Section 6.1.5
IP-T-MPLS転送（プッシュ）セクション6.1.1 MPLS-to-MPLSフォワーディング（SWAP）セクション6.1.2 MPLS-T-T-T-FOWROWNING（POP）セクション6.1.3 MPLSからIPへの転送（Aggregate）セクション6.1.4 MPLS-to-IP転送（PHP）セクション6.1.5
A misdirected frame, that is, a frame received on the wrong Bn, is considered lost. If the test tool is capable of checking received MPLS label values, a frame with the wrong MPLS label is considered lost.
誤った方向のフレーム、つまり、間違ったBNで受信されたフレームは失われたと見なされます。テストツールが受信したMPLSラベル値をチェックできる場合、間違ったMPLSラベルを持つフレームが失われたと見なされます。
Reporting Format
レポート形式
The result should be reported as per Section 5 and RFC 2544.
結果は、セクション5およびRFC 2544に従って報告する必要があります。
Objective
目的
To characterize the speed at which a DUT recovers from an overload condition.
DUTが過負荷状態から回復する速度を特徴付ける。
Test Setup
テスト設定
Follow the "Test Setup" guidelines established for each of the five MPLS forwarding operations in Sections 6.1.1 (for IP-to-MPLS), 6.1.2 (for MPLS-to-MPLS), 6.1.3 (for MPLS-to-IP Unlabeled), 6.1.4 (for MPLS-to-IP Aggregate), and 6.1.5 (for MPLS-to-IP PHP), one by one.
セクション6.1.1（IP-to-MPLSの場合）、6.1.2（MPLS-to-MPLSの場合）、6.1.3（MPLS-to-toの場合）の5つのMPLS転送操作のそれぞれについて確立された「テストセットアップ」ガイドラインに従ってください-IP Unlabeled）、6.1.4（MPLS-to-IP集計の場合）、6.1.5（MPLS-to-IP PHPの場合）、1つずつ。
Procedure
手順
Please refer to Section 26.5 of RFC 2544 and follow the associated procedure for each MPLS forwarding operation in the referenced sections one-by-one in accord with the test setup described earlier:
RFC 2544のセクション26.5を参照し、前述のテストセットアップに従って参照されたセクションの各MPLS転送操作の関連手順に従ってください。
IP-to-MPLS forwarding (Push) Section 6.1.1 MPLS-to-MPLS forwarding (Swap) Section 6.1.2 MPLS-to-IP forwarding (Pop) Section 6.1.3 MPLS-to-IP forwarding (Aggregate) Section 6.1.4 MPLS-to-IP forwarding (PHP) Section 6.1.5
IP-T-MPLS転送（プッシュ）セクション6.1.1 MPLS-to-MPLSフォワーディング（SWAP）セクション6.1.2 MPLS-T-T-T-FOWROWNING（POP）セクション6.1.3 MPLSからIPへの転送（Aggregate）セクション6.1.4 MPLS-to-IP転送（PHP）セクション6.1.5
Reporting Format
レポート形式
The result should be reported as per Section 5 and RFC 2544.
結果は、セクション5およびRFC 2544に従って報告する必要があります。
The "reset" aspects of benchmarking are described in [RFC2544], but these procedures need to be clarified in order to ensure consistency. This document does not specify the reset procedures. These need to be addressed in a separate document and will more generally apply to IP and MPLS test cases.
ベンチマークの「リセット」の側面は[RFC2544]で説明されていますが、一貫性を確保するためにこれらの手順を明確にする必要があります。このドキュメントでは、リセット手順を指定しません。これらは別のドキュメントで対処する必要があり、より一般的にはIPおよびMPLSテストケースに適用されます。
The text below describes the MPLS forwarding benchmarking-specific setup that will have to be used in conjunction with the procedures from the separate document to make this test case meaningful.
以下のテキストでは、このテストケースを意味のあるものにするために、個別のドキュメントの手順と併用する必要があるMPLS転送ベンチマーク固有のセットアップについて説明します。
Objective
目的
To characterize the speed at which a DUT recovers from a device or software reset.
DUTがデバイスまたはソフトウェアリセットから回復する速度を特徴付ける。
Test Setup
テスト設定
Follow the "Test Setup" guidelines established for each of the five MPLS forwarding operations in Sections 6.1.1 (for IP-to-MPLS), 6.1.2 (for MPLS-to-MPLS), 6.1.3 (for MPLS-to-IP Unlabeled), 6.1.4 (for MPLS-to-IP Aggregate), and 6.1.5 (for MPLS-to-IP PHP), one by one.
セクション6.1.1（IP-to-MPLSの場合）、6.1.2（MPLS-to-MPLSの場合）、6.1.3（MPLS-to-toの場合）の5つのMPLS転送操作のそれぞれについて確立された「テストセットアップ」ガイドラインに従ってください-IP Unlabeled）、6.1.4（MPLS-to-IP集計の場合）、6.1.5（MPLS-to-IP PHPの場合）、1つずつ。
For this test case, the requirements of LDP and a routing protocol are removed and replaced by static configurations. For the IP-to-MPLS forwarding, static route configurations should be applied. For the MPLS-to-MPLS and MPLS-to-IP, static label configurations must be applied.
このテストケースでは、LDPの要件とルーティングプロトコルの要件が削除され、静的構成に置き換えられます。IP-to-MPLS転送の場合、静的ルート構成を適用する必要があります。MPLS-to-MPLSおよびMPLS-to-IPの場合、静的ラベル構成を適用する必要があります。
For this test, all Graceful Restart features MUST be disabled.
このテストでは、すべての優雅な再起動機能を無効にする必要があります。
Discussion
考察
This test case is intended to provide insight into how long an MPLS device could take to be fully operational after any of the reset events. It is quite likely that the time an IP/MPLS device takes to become fully operational after any of the reset events may be different from that of an IP-only device.
このテストケースは、MPLSデバイスがリセットイベントの後に完全に動作するためにどれだけ時間がかかるかについての洞察を提供することを目的としています。リセットイベントのいずれかがIPのみのデバイスのイベントとは異なる可能性がある後、IP/MPLSデバイスが完全に動作するのにかかる時間がかかる可能性が非常に高いです。
Modern devices now have many more reset options that were not available when Section 26.6 of RFC 2544 was published. Moreover, different reset events on modern devices may produce different results, hence, needing clarity and consistency in reset procedures beyond what's specified in RFC 2544.
最新のデバイスには、RFC 2544のセクション26.6が公開されたときに利用できないリセットオプションがさらに多くあります。さらに、最新のデバイスで異なるリセットイベントは異なる結果をもたらす可能性があるため、RFC 2544で指定されているものを超えて、リセット手順の明確さと一貫性が必要になります。
Procedure
手順
Please follow the procedure from the separate document for each MPLS forwarding operation one-by-one:
各MPLS転送操作の個別のドキュメントから1つずつ手順に従ってください。
IP-to-MPLS forwarding (Push) Section 6.1.1 MPLS-to-MPLS forwarding (Swap) Section 6.1.2 MPLS-to-IP forwarding (Pop) Section 6.1.3 MPLS-to-IP forwarding (Aggregate) Section 6.1.4 MPLS-to-IP forwarding (PHP) Section 6.1.5
IP-T-MPLS転送（プッシュ）セクション6.1.1 MPLS-to-MPLSフォワーディング（SWAP）セクション6.1.2 MPLS-T-T-T-FOWROWNING（POP）セクション6.1.3 MPLSからIPへの転送（Aggregate）セクション6.1.4 MPLS-to-IP転送（PHP）セクション6.1.5
Reporting Format
レポート形式
The result should be reported as per Section 5 and as per the separate document.
結果は、セクション5に従って、および別のドキュメントに従って報告する必要があります。
Benchmarking activities, as described in this memo, are limited to technology characterization using controlled stimuli in a laboratory environment, with dedicated address space and the constraints specified in the sections above.
このメモに記載されているように、ベンチマークアクティビティは、実験室環境で制御された刺激を使用した技術特性評価に限定されており、上記のセクションで指定された専用のアドレス空間と制約があります。
The benchmarking network topology will be an independent test setup and MUST NOT be connected to devices that may forward the test traffic into a production network or misroute traffic to the test management network.
ベンチマークネットワークトポロジは、独立したテストセットアップとなり、テストトラフィックを生産ネットワークに転送したり、トラフィックをテスト管理ネットワークに誤って転送したりするデバイスに接続してはなりません。
Furthermore, benchmarking is performed on a "black-box" basis, relying solely on measurements observable external to the DUT/SUT (System Under Test).
さらに、ベンチマークは「ブラックボックス」ベースで実行され、DUT/SUT（テスト中のシステム）の外部に観察可能な測定のみに依存しています。
Special capabilities SHOULD NOT exist in the DUT/SUT specifically for benchmarking purposes. Any implications for network security arising from the DUT/SUT SHOULD be identical in the lab and in production networks.
特別な能力は、ベンチマークの目的で特別にDUT/SUTに存在するべきではありません。DUT/SUTから生じるネットワークセキュリティへの影響は、ラボと生産ネットワークで同一である必要があります。
There are no specific security considerations within the scope of this document.
このドキュメントの範囲内に特定のセキュリティ上の考慮事項はありません。
The authors would like to thank Mo Khalid, who motivated us to write this document. We would like to thank Rodney Dunn, Chip Popoviciu, Jeff Byzek, Jay Karthik, Rajiv Papneja, Samir Vapiwala, Silvija Andrijic Dry, Scott Bradner, Al Morton, and Bill Cerveny for their careful review and suggestions.
著者は、この文書を書くように私たちに動機付けたMo Khalidに感謝したいと思います。ロドニー・ダン、チップ・ポポビチウ、ジェフ・バイゼク、ジェイ・カルティク、ラジブ・パプネジャ、サミール・ヴァピワラ、シルヴィジャ・アンドリジック・ドライ、スコット・ブラッドナー、アル・モートン、ビル・セルベニーの慎重なレビューと提案に感謝します。
This document was originally prepared using 2-Word-v2.0.template.dot.
このドキュメントは、もともと2ワード-V2.0.template.dotを使用して準備されていました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999.
[RFC2544] Bradner、S。およびJ. McQuaid、「ネットワーク相互接続デバイスのベンチマーク方法論」、RFC 2544、1999年3月。
[RFC1242] Bradner, S., "Benchmarking Terminology for Network Interconnection Devices", RFC 1242, July 1991.
[RFC1242] Bradner、S。、「ネットワーク相互接続デバイスのベンチマーク用語」、RFC 1242、1991年7月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032] Rosen、E.、Tappan、D.、Fedorkow、G.、Rekhter、Y.、Farinacci、D.、Li、T。、およびA. conta、「Mpls Label Stack Encoding」、RFC 3032、2001年1月。
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001.
[RFC3107] Rekhter、Y。およびE. Rosen、「BGP-4でのラベル情報の運搬」、RFC 3107、2001年5月。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[RFC5036] Andersson、L.、ed。、Minei、I.、ed。、およびB. Thomas、ed。、「LDP仕様」、RFC 5036、2007年10月。
[RFC5180] Popoviciu, C., Hamza, A., Van de Velde, G., and D. Dugatkin, "IPv6 Benchmarking Methodology for Network Interconnect Devices", RFC 5180, May 2008.
[RFC5180] Popoviciu、C.、Hamza、A.、Van de Velde、G。、およびD. Dugatkin、「ネットワーク相互接続デバイスのIPv6ベンチマーク方法」、RFC 5180、2008年5月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、 "RSVP-TE：LSP TunnelsのRSVPへの拡張"、RFC 3209、12月2001年。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364] Rosen、E。およびY. Rekhter、「BGP/MPLS IP仮想ネットワーク（VPNS）」、RFC 4364、2006年2月。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y.、Ed。、Li、T.、ed。、およびS. Hares、ed。、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
[RFC4664] Andersson, L., Ed., and E. Rosen, Ed., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006.
[RFC4664] Andersson、L.、ed。、およびE. Rosen、ed。、「レイヤー2仮想プライベートネットワーク（L2VPNS）のフレームワーク」、RFC 4664、2006年9月。
[IEE8021] Mick Seaman (editor), "IEEE Std 802.1D-2004, MAC Bridges", Feb 2004.
[IEE8021] Mick Seaman（編集者）、「IEEE STD 802.1D-2004、Mac Bridges」、2004年2月。
[IEE8023] LAN/MAN Standards Committee of the IEEE Computer Society, "IEEE Std 802.3as-2006, Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications, Amendment 3: Frame format extensions", Nov 2006.
[IEE8023] IEEE Computer SocietyのLAN/Man Standards Committee、「IEEE STD 802.3AS-2006、パート3：キャリアセンス衝突検出による複数アクセス（CSMA/CD）アクセス方法と物理層の仕様、修正3：フレームフォーマット拡張機能"、2006年11月。
[RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, January 2003.
[RFC3443] Agarwal、P。およびB. Akyol、「マルチプロトコルラベルスイッチング（MPLS）ネットワークでのライブ（TTL）処理」、RFC 3443、2003年1月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, February 2009.
[RFC5462] Andersson、L。and R. Asati、「マルチプロトコルラベルスイッチング（MPLS）ラベルスタックエントリ：「Exp」フィールド「トラフィッククラス」フィールドに改名されたフィールド、RFC 5462、2009年2月。
[RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal Cost Multipath Treatment in MPLS Networks", BCP 128, RFC 4928, June 2007.
[RFC4928] Swallow、G.、Bryant、S。、およびL. Andersson、「MPLSネットワークでの等しいコストマルチパス治療を回避」、BCP 128、RFC 4928、2007年6月。
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090] Pan、P.、Ed。、Ed。、Swallow、G.、ed。、およびA. Atlas、ed。、「LSP TunnelsのRSVP-TEへの高速リルート拡張」、RFC 4090、2005年5月。
Authors' Addresses
著者のアドレス
Aamer Akhter Cisco Systems 7025 Kit Creek Road RTP, NC 27709 USA
Aamer Akhter Cisco Systems 7025 Kit Creek Road RTP、NC 27709 USA
EMail: aakhter@cisco.com
Rajiv Asati Cisco Systems 7025 Kit Creek Road RTP, NC 27709 USA
Rajiv Asati Cisco Systems 7025 Kit Creek Road RTP、NC 27709 USA
EMail: rajiva@cisco.com
Carlos Pignataro Cisco Systems 7200-12 Kit Creek Road RTP, NC 27709 USA
Carlos Pignataro Cisco Systems 7200-12 Kit Creek Road RTP、NC 27709 USA
EMail: cpignata@cisco.com