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
        

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.

この文書では、IPフローを考慮すると、それぞれの最も一般的なMPLSパケット転送シナリオと遅延測定に限定されたマルチプロトコルラベルスイッチング(MPLS)フォワーディング・デバイスのベンチマーキングに特定の方法論を説明しています。これは、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.

著作権(C)2009 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 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 ....................................................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
        
1. Introduction
1. はじめに

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の使用が増加しています。 MPLS、[RFC3031]で定義され、基礎技術や、レイヤ3つのMPLS VPNを、レイヤ2つのMPLS VPNの、および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転送を評価する(例えば、スループット、レイテンシ、フレーム損失率、システムの回復、リセットなど)の一般的な基準を使用して方法を提案しています。

2. Document Scope
2.ドキュメントのスコープ

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フォワーディングの基本であるとして、一つだけのエントリを持っているMPLSラベルスタック[RFC3032]に焦点を当てています。将来の文書は複数のエントリを必要とするなど、レイヤ3 VPN(L3VPN)[RFC4364]、レイヤ2 VPN(L2VPN)[RFC4664]、高速リルート[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ラベルスタックの存在は、(IPパケットは、この文書ごとに、である)MPLSペイロードの長さを変更することを必要としないことに注意してください。現在展開中で観察されるように、したがって、フレームの有効な最大サイズは、Zオクテット(ラベルスタックエントリのZ = 4×数)によって増加させることができます。この文書では、このようなシナリオをベンチマークに焦点を当てています。

3. Key Words To Reflect Requirements
要件を反映するため3.キーワード

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.

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119 [RFC2119]に記載されているように解釈されます。 RFC 2119は、可能な限り明確な標準化過程ドキュメントの意図を支援するために、これらのキーワードの使用を定義します。この文書は、これらのキーワードを使用していますが、この文書では、標準化過程ドキュメントではありません。

4. Test Methodology
4.テスト方法

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は、被試験デバイス(DUT)は、RFC 2544の図1にあったテストツールのテストポートに接続されているサンプル・トポロジを示します。

                          +-----------------+
          +---------+     |                 |     +---------+
          | 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.

Bは、同じテストツールの受信側モジュールを表し、一方、Aは、テストツールの送信側モジュールを表します。もちろん、末尾の数字(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.

DBは、送信側モジュールを示し、一方、同様に、DAは、DUTの受信側モジュールを表します。末尾の数字(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の最大転送スループットは、毎秒100のフレーム(FPS)とポート媒体(例えば、インタフェース)の負荷容量が> = 2が十分に最大フレーム転送をテストするために必要とされ、次いで50のFPS、Pである場合。

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)が報告されるべきです。 RFC 2544のセクション6から図1に続いて第6節で推奨されるが、「テストセットアップ」を参照してください。

4.1. Test Considerations
4.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)、グレースフルリスタートなどは、無効にする必要があります。また、任意の非本質的なトラフィックも避けなければなりません。

4.1.1. Abbreviations Used
4.1.1. 使用される略語

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)

M:デバイス上の=モジュール(すなわち、ラインカードまたはスロット; Aまたは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:=リモートネットワーク(すなわち、モジュールのポートを介して到達可能なネットワーク、モジュールBのポート1を介して到達可能な第一のネットワークを意味するB1RN1又はB2RN5とすることができる、例えば、B1、または第5のネットワーク到達可能のポート2を介してモジュールB、等)。 RNは、MPLSの観点からIPプレフィックスFECであると考えられています。

4.1.2. IGP Support
4.1.2. IGPサポート

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.

これは、そのポート(A1、DA1、DB1、およびA2)の全てのDUTに、テストツールはまた、そこ等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、スタティックなど)、使用される場合、報告されなければなりません。任意の具体的な構成は、試験(すなわち、コントロールプレーンの保護、コントロールプレーンレート等、制限)時の制御プレーンの安定性を維持するために使用される場合にさらに、それも報告しなければなりません。

4.1.3. Label Distribution Support
4.1.3. ラベル配布のサポート

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バインディングを交換するための少なくとも一つのプロトコルをサポートしなければなりません。 DUTとテストツールは、選択したプロトコル(複数可)を経由して学習や広告MPLSラベル/ FECバインディングできることと、(ラベル/ FECバインディングが変更されたときを含む)すべての時間をパケット転送の際にそれらを使用しなければなりません。最も一般的に使用されるプロトコルは、ラベル配布プロトコル(LDP)[RFC5036]、あるリソース予約プロトコル - トラフィックエンジニアリング(RSVP-TE)[RFC3209]、およびBorder Gateway Protocol(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.

テストケースによって明示的に指定しない限り、静的ラベルは、パス(LSPを)切り替えMPLSラベルを確立するために使用されるべきではありません。

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明示的NULLラベル(ラベルは、値0と2)時にはLSP [RFC3032]にMPLSパケットのペイロードを識別するために使用されます。試験をする、から、またはDUTを通る全てのパケットのラベルスタック内のない複数の非予約MPLSラベルの使用に限定されているため、明示的NULLラベルは、本文書に記載の試験に使用されていません。

4.1.4. Frame Formats
4.1.4. フレームフォーマット

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).

このセクションでは、必須のレイヤ3プロトコルとして及びMPLSパケットペイロード(セクション4.1.4.2)とIPとMPLSパケット(セクション4.1.4.1)のためのフレームフォーマット、IPの使用を説明し、転送中のフレームフォーマットの変更(4.1節.4.3)、およびMPLSのベンチマーク(セクション4.1.4.4)のためのフレームフォーマットをお勧めします。

4.1.4.1. Frame Format for IP versus MPLS
4.1.4.1。 MPLS対IPのためのフレーム形式

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に示すように(およびIPヘッダの前に、もしあれば)、レイヤ2ヘッダの後に「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.

[RFC3032]の図1に示すように、MPLSラベルスタックは、各ラベルスタックエントリは4つのオクテットである「ラベルスタックエントリ」のシーケンスとして表されます。この文書では、MPLSパケットにMPLSラベルスタックで正確に一つのエントリが必要です。

MPLS label values used in any test case MUST be outside the reserved label value (0-15) unless stated otherwise.

特に明記しない限り、任意のテストケースに使用されるMPLSラベル値が予約されたラベル値(0-15)の外側でなければなりません。

4.1.4.2. MPLS Packet Payload
4.1.4.2。 MPLSパケットペイロード

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:

この文書では、(上記の図3に示すように)MPLSペイロードとしてIPパケットを用いて規定しています。一般的に言えば、この文書は三つの理由のために、[RFC2544]のセクション8とMPLSラベルスタックの存在とは無関係と一致して、レイヤ3プロトコルとしてIP(IPv4またはIPv6のいずれか)を含むように試験フレームを義務付け。

1. This enables using IP Prefix Forwarding Equivalence Class (FEC) [RFC3031], which is a must for every MPLS network.

1.これは、すべてのMPLSネットワークのための絶対必要であるIPプレフィックス転送等価クラス(FEC)[RFC3031]を使用可能にします。

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.これはテストフレームとしてUDPデータとIPパケットを使用して規定するRFC 2544 [RFC2544]を、活用が可能となります。 ([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ペイロードの使用が可能であるが、それは、そのベンチマーク将来的に(例えば、MPLS L2VPNベンチマーク)別BMWG文書に覆われていてもよい、例えばMPLSアプリケーション、L2VPNを必要とします。これは、第2節で説明されています。

4.1.4.3. Change in Frame Format Due to MPLS Push and Pop
4.1.4.3。 MPLSプッシュとポップにフレーム形式の変更

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.

[RFC3031]で定義されるように、ラベルのプッシュ(またはLSPイングレス)、ラベルスワップ、およびラベルポップ(又はLSP出力):IPまたはMPLSパケットを運ぶフレームは、操作を転送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イングレス)動作において、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.

ラベルポップ(又はLSP出力)動作において、DUTは、MPLSパケットを含むフレームを受信し、IPパケットを含むフレームを転送する場合、ラベルポップ操作にラベル値のポイントに対応する転送参照。

4.1.4.4. Frame Formats to Be Used for Benchmarking
4.1.4.4。フレームフォーマットは、ベンチマークに使用します

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.

MPLSのためのIP(1)フレームフォーマットと、(2)フレームフォーマット:この文書は、適切に転送操作をテストするために2つのテストフレームフォーマットを使用して規定します。どちらの形式は、セクション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.ラベルプッシュ操作を伴うテストケースは、テストツールは、DUTにテストフレームを送信するIPパケットのフレームフォーマット(図2)を使用する必要があり、そして受信するために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.ラベルスワップ操作を伴うテストケースは、テストツールは、DUTにテストフレームを送信するMPLSパケットのフレームフォーマット(図3)を使用する必要があり、そして受信するために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.ラベルポップ操作を伴うテストケースは、テストツールは、DUTにテストフレームを送信するMPLSパケットのフレームフォーマット(図3)を使用する必要があり、および受信するIPパケットのフレームフォーマット(図2)を使用する必要がありますDUTからのテストフレーム。

4.1.5. Frame Sizes
4.1.5. フレームサイズ

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.

イーサネットおよびPOS(パケットオーバー同期光ネットワーク):ポートの2種類の媒体は、一般的に配備されています。このセクションでは、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).

(セクション4.1.4.3で説明したように)まず、フレーム内のMPLSラベルスタックの存在によるフレームサイズ増加の可能性に注意することが重要です。

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ラベルスタックの存在は、従来の最大フレームペイロードサイズ[RFC3032](イーサネット(登録商標)1500オクテット、言う)を追従し続けるレイヤ3 = IPに対して透明であると仮定されます。これは、得られたレイヤ2フレームの有効な最大フレームペイロードサイズ[RFC3032]は、従来の最大フレームペイロードサイズ、よりZオクテット以上であることを意味するラベルスタックのエントリのZ = 4×番号。

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オクテット+従来の最大フレームペイロードサイズに等しく効果的な最大フレームペイロードサイズ[RFC3032]にメディアMTU値を設定することが推奨されます。それはではなく、IPパケットのための、メディアMTU値のような変化が唯一の影響MPLSパケットのための効果的な最大フレームペイロードサイズをすることを期待されています。

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ラベルスタックで正確に単一のエントリが必要であることに注意してください。換言すれば、ラベルスタックの深さは、一つ、例えば、Z = 4×1 = 4オクテットに設定されています。さらに、セクション9及びRFC 2544の9.1に従って、このドキュメントは、各テストケースは、異なる試験では異なる(レイヤ2)のフレームサイズを使用して実行されることを規定しています。また、結果はまた、同時に複数のフレームサイズを用いて収集されてもよい(時々フレームサイズの順序と用途に応じて実際のネットワークトラフィックをシミュレートするために対話型マルチモーダル情報抽出(IMIX)と呼ばれます)。そこフレームサイズの混合物のための標準がなく、その結果、広い解釈(RFC 2544のセクション18を参照)の対象となっています。複数の同時のフレームサイズを使用して臨床試験を実行する場合、DUTの構成は同じでなければなりません。

4.1.5.1. Frame Sizes To Be Used on Ethernet Media
4.1.5.1。フレームサイズは、イーサネットメディア上で使用します

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オクテット。これはセクションとインラインで9及びRFCの9.1 2544図4は、(RFC 2544あたり)IPペイロードを含むタグなしイーサネットフレームのヘッダ・サイズを示します。

            <----------------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:64〜1518オクテットのフレームサイズはIEEE 802.3 [IEE8023]に従って、最小値およびタグなしイーサネットフレームの最大長を表します。一般的動作環境で使用されるフレーム・サイズは、[IEE8021] IEEE 802.1Dに従って、単一VLANタグ付きフレームの最小値と最大長である68 1522オクテット、の範囲であってもよいです。

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フレームは、タグなしレイヤ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.

注:テストツールとDUTとの間のリンク上のメディアMTUは、必要に応じて、変更する必要があり、IPパケットにMPLSラベルスタックを加算した効果的な最大フレームペイロードサイズ[RFC3032]を収容します。 RFC 3032の3.1節で明らかなように、ほとんどのレイヤ2つのメディア・ドライバは、効果的な最大フレームペイロードサイズを有するレイヤ2つのフレームを送受信することが可能です。多くのベンダーはまた、メディアMTUはIPのためにそれを変更することなく、MPLSのために変更することを可能にします。 MPLSの推奨リンクMTU値は、従来の最大フレームペイロードサイズ[RFC3032](例えば、イーサネット(登録商標)のための従来の最大フレームペイロードサイズが1500オクテットである)よりもZオクテット以上です。この文書では、Z = 4オクテットを規定しています。ベンダーDUTは、MTUの変更を許可しない場合、ベンチマークは、真の最大フレームペイロードサイズ[RFC3032]のために行うことができず、これは報告されなければなりません。

4.1.5.2. Frame Sizes to Be Used on POS Media
4.1.5.2。フレームサイズは、POSメディア上で使用します

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は、イーサネットメディアのそれ未満であるレイヤ2ヘッダー(〜4つのオクテット)で得られた、(等PPP、ハイレベルデータリンク制御(HDLC)、フレームリレー、等)の様々なカプセル化技術のいずれかを使用してもよいです。 (図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オクテット。

4.1.6. Time-to-Live (TTL) or Hop Limit
4.1.6. タイム・ツー・ライブ(TTL)またはホップリミット

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.

TTL /ホップリミット減少は、[RFC3443]で指定されるように、DUTに構成可能なオプションである場合、設定が報告されるべきです。

4.1.7. Trial Duration
4.1.7. 試用期間

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.

動的ルーティングプロトコルおよびLDP(デフォルトLDPホールドダウンタイマーが180秒である)場合に特に指定のスタティックルーティングが適所にあるとき、各試験の試験部分は全く30秒未満であってはならない場合を除き、無未満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がデータ転送プレーンに負荷がかかっているときに安定した制御プレーンを維持することが可能であることを確認することです。

4.1.8. Traffic Verification
4.1.8. 交通検証

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ラベルスタックの存在下または非存在下、ラベルスタック内のすべてのフィールド値は、存在する場合、イーサタイプ(0x8847又は0x0800で又は0x86DD対0x8848)、フレームシーケンシング、及びフレームチェックシーケンス(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ヘッダの存在確認のために、いくつかのテストは、他のものは、スワップまたはPOPを必要とするであろうしながらプッシュするMPLSヘッダを必要とするであろう。したがって、このドキュメントは、MPLSスタックの深さを確認するためのテスト・ツールが必要です。検証の一層のレベルは正しいラベルが押されたかどうかを確認することです。しかし、いくつかのテストツールは、正当性受信したラベル値を確認することができません。テストツールは、パケットが期待されるMPLSラベルを運ぶ受け取ったことを確認する必要があります。

4.1.9. Address Resolution and Dynamic Protocol State
4.1.9. 分解能とダイナミックプロトコル状態アドレス

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、(等MPLSCP)、OSPF、LDP、を含むPPP)テストケースが実行される前に、その後のプロトコルのすべての状態が事前に確立されなければならない(すなわちするための任意の動的プロトコルを利用する場合、パケットストリーム)が開始されます。

5. Reporting Format
5.レポートフォーマット

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

スループットフレーム毎秒毎秒のビット

Port Media GigE (Gigabit Ethernet), POS, ATM, etc.

ポートメディアのGigE(ギガビットイーサネット)、POS、ATMなど

Port Speed 1 gbps, 100 Mbps, etc.

ポート速度1Gbpsの、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を参照してもよい追加の報告要件を有することができます。

6. MPLS Forwarding Benchmarking Tests
6. MPLSフォワーディングベンチマークテスト

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ヘッダを含んでいてもよい三の転送操作の1つを通過することができる:[RFC3031]で定義されるように、プッシュ(またはLSPイングレス)、スワップ、またはPOP(またはLSP出口) 。このような特性は、このように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)

(明示的なヌル場合を含む)フィールド操作(以前EXP [RFC5462]として知られている)6. MPLS TC

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

図1を参照すると、AとBの両方のモジュール上の単一のポート(P = 1)が使用されるべきです。 DUTの転送スループットは、単一ポートのメディアレートのそれよりも大きい場合は、次のようしかし、次にAとBモジュールに追加のポートを有効にする必要があり:DUTのようにAとBポートを構成することができる場合任意のBポートをオーバーロードすることなく、DUTの転送能力を超えて、それらを有効にする必要があります。一方、DUTの転送スループット容量はすべてのポートを有効に達成することができるものよりも大きい場合には、すべてのAnとBnのポートを有効にする必要があります。複数のAとBポートがイネーブルされる場合には、RFC 2544のセクション16に記載された手順でなければなりません

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.

マルチポートのシナリオに対応するために続きます。送受信フレームフォーマットは、セクション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は、唯一のDBポートでFECを関連付ける必要があります。 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にテストツールポート(S)APから送信され、テストツールポート上のDUT(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.

提供フレームのいずれも廃棄されていない最大レートまで、一定の他のパラメータ(試験時間、ポート番号、アドレスの数、フレームサイズ、等)を維持しながら、各反復は、トラフィックのオファードロードを変える含むべきです決定されます。

6.1. Throughput
6.1. スループット

This section contains the description of the tests that are related to the characterization of a DUT's MPLS traffic forwarding.

このセクションでは、DUTのMPLSトラフィック転送の特性に関連したテストの記述が含まれています。

6.1.1. Throughput for MPLS Label Push
6.1.1. 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入力転送操作中に(RFC 2544に従って)DUTのスループットを得るために(すなわち、IPは、MPLSします)。

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結合(単数または複数) BPはDUTへの受信ポート上(セクション4.1.3に従ってラベル配布プロトコルを使用して)。テストツールは、その送信ポート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及び/又はラベル配布プロトコルは、テストツールで有効にする必要があり、ポートBPおよびDUT送信ポートDBPを受け取ります。

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.

(また、[RFC3031]のセクション3.11当たりのネクストホップラベル転送エントリ(NHLFE)マッピングテーブルに着信ラベルマップ(ILM)と称する)DUTのMPLS転送テーブルは、それぞれの発信ラベルとして非予約MPLSラベル値を含まなければなりませんIPとMPLS転送動作を行うDUT、その結果、結合ラベル-FECに対応するIPプレフィックスを学びました。テストツールは、広告された同一のラベル値とポート塩基対(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.

また、テストツールは、送信ポートAPの(アドバタイズされたIP接頭語(es)に属するIP先との)IPパケットを含むフレームを送信し、MPLSパケットを含むフレームを受信することを期待しなければならない第6節に「試験手順」を参照してください上のセクション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.

各テストの結果は、試験したフレームサイズのそれぞれの行を有するテーブルの形でなければなりません。追加の列が与えられた負荷と測定されたスループットを含むべきです。

6.1.2. Throughput for MPLS Label Swap
6.1.2. MPLSラベルスワップのためのスループット

Objective

目的

To obtain the DUT's Throughput (as per RFC 2544) during label swapping operation (i.e., MPLS-to-MPLS).

ラベルスワッピング動作中(RFC 2544に従って)DUTのスループットを得るために(すなわち、MPLSツーMPLS)。

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に記載のセットアップに加えて、テストツールは、セクション4.1に従ってラベル配布プロトコルを使用して、((セクション4.1.2に従ってルーティングプロトコルを使用して)IPプレフィックス(ES)と関連したMPLSラベル-FECバインディングをアドバタイズしなければなりません。 3)受信ポートのBPは、その後、IP接頭語(es)、ならびにラベル-FEC S(結合)送信ポートAPのを学びます。テストツールは、学んだMPLSラベル値を使用し、DUTへのポートAP上で送信されたフレーム内のIPプレフィックス値を学びましたしなければなりません。

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.

(また、[RFC3031]のセクション3.11当たりILM NHLFEへのマッピング・テーブルと称する)DUTのMPLS転送テーブルは、MPLS対で、その結果、学習したIPプレフィクスのための発信および着信ラベルとしてMPLSラベル値を非予約含まれている必要がありますMPLSフォワーディングの動作、例えば、ラベルスワップ。テストツールは、ラベル配布プロトコルを使用してアドバタイズされた同一のラベル値を有する受信ポート(DUT)からのBpに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.

また、テストツールは、その送信ポートAPの(アドバタイズされたIP接頭語(es)に属するIP先との)MPLSパケットを含むフレームを送信し、MPLSパケットを含むフレームを受信することを期待しなければならない第6節に「試験手順」を参照してくださいその受信ポートにBpを、セクション4.1.4.4で説明したように。

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.

各テストの結果は、試験したフレームサイズのそれぞれの行を有するテーブルの形でなければなりません。

6.1.3. Throughput for MPLS Label Pop (Unlabeled)
6.1.3. MPLSラベルポップのスループット(ラベルなし)

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.

「ラベルなし」の発信ラベルを用いてラベルポップ又はLSP出口転送操作(すなわち、MPLSとIP)の間(RFC 2544に従って)DUTのスループットを得ることができます。

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バインディングなし(セクション4.1.2に従ってルーティングプロトコルを使用して)IPプレフィックス(ES)をアドバタイズし、次いで学ばなければなりませんIPプレフィックス(ES)ならびに送信ポートAPの結合FECラベル(S)。テストツールは、学んだMPLSラベル値を使用して、ポート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及び/又はラベル配布プロトコルは、テストツールポート(S)APとDUTポート(S)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.

(また、[RFC3031]のセクション3.11当たりNHLFEマッピングテーブルにILMと称する)DUTのMPLS転送テーブルは、MPLSとIPフォワーディング、その結果、学習した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 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.

また、テストツールは、その送信ポート(IPプレフィックスに属するIP先との(ES)ポートのBpで宣伝)AP上のMPLSパケットを含むフレームを送信し、フレームを受信することを期待しなければならない第6節に「試験手順」を参照してくださいセクション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.

各テストの結果は、試験したフレームサイズのそれぞれの行を有するテーブルの形でなければなりません。

6.1.4. Throughput for MPLS Label Pop (Aggregate)
6.1.4. MPLSラベルポップ(集約)のスループット

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].

ラベルPOPまたはLSP出口転送操作中に(RFC 2544に従って)DUTのスループットを得るために(すなわち、MPLSとIP)「集計」転出ラベル[RFC3031]を使用。

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からポートDBPに学習されたプレフィクスのセットを集約するIPプレフィックスに([RFC3031]セクション3.20を参照してください)、それが集約発信ラベルを割り当てるようにプロビジョニングされなければなりませんテストツール。接頭集約は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は、関連するMPLSラベル-FECは、テストツールのポートDAPに結合と一緒に集約する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ラベル値を使用し、DUTへのポートAP上で送信されたフレーム内のIPプレフィックス値を学びましたしなければなりません。テストツールは、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及び/又はラベル配布プロトコルは、テストツールポート(S)APとDUTポート(S)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).

(また、[RFC3031]のセクション3.11あたりILM NHLFEへのマッピングテーブルと呼ぶ)DUTのMPLSフォワーディングテーブルは、集約出ラベルとIPフォワーディングテーブルはMPLS-その結果、学んだ接頭語(ES)のための有効なエントリが含まれている必要があります含まれている必要があります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.

(ポートBpの上で公示IP宛先がIP接頭語(es)に所属して)テスト・ツールは、その送信ポートAP上のMPLSパケットを含むフレームを送信する必要があり、さらに、第6節では、「試験手順」を参照してください、と含むフレームを受信することを期待してくださいその受信ポート上のIPパケットBpを、セクション4.1.4.4で説明したように。

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.

各テストの結果は、試験したフレームサイズのそれぞれの行を有するテーブルの形でなければなりません。

6.1.5. Throughput for MPLS Label Pop (PHP)
6.1.5. MPLSラベルポップのスループット(PHP)

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.

ラベルポップ(すなわち、MPLS-に-IP)または「IMP-ヌル」発信ラベルを使用して最後から二番目のホップポップ(PHP)の間(RFC 2544に従って)DUTのスループットを得るためには。

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).

予約されたMPLSラベル値との結合項6に記載の設定に加えて、テストツールは(セクション4.1.2に従ってルーティングプロトコルを使用して)IPプレフィックス(ES)をアドバタイズするように設定されなければならず、関連するMPLSラベル-FEC = 3(セクション4.1.3に従ってラベル配布プロトコルを使用して)、その受信ポートBpをオン。テストツールは、IP接頭語(es)だけでなく、その送信ポートAP上のMPLSラベル-FECバインディングを学ばなければなりません。テストツールは、学んだMPLSラベル値を使用し、DUTへのポートAP上で送信されたフレーム内のIPプレフィックス値を学びましたしなければなりません。テストツールは、(DUT)から受信ポートのBpに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に記載されている最後から二番目のホップポッピング(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と呼ぶ)= 3(例えば、ポップやIMP-ヌル)の予約MPLSラベル値が含まれている必要があり学んプレフィックス(のための出ラベルとしてES)、MPLSとIP転送動作が得られます。

This test case characterizes DUT's penultimate hop popping (PHP) functionality.

このテストケースは、DUTの最後から二番目のホップのポッピング(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.

テストツールは、(IP宛先がアドバタイズされたIP接頭語(es)に所属して)、その送信ポートAP上のMPLSパケットを含むフレームを送信する必要があり、さらに、第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.

各テストの結果は、試験したフレームサイズのそれぞれの行を有するテーブルの形でなければなりません。

6.2. Latency Measurement
6.2. レイテンシ測定

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.

待ち時間測定は、IPとMPLS、MPLSツーMPLS、またはMPLSとIP MPLSラベルスタックを含むような経路を切り替える種々の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.

(IP-に-MPLSのために)、セクション6.1.1で事業を転送5つのMPLSごとに設置した「テストセットアップ」のガイドラインに従って、6.1.2(MPLS-に-MPLSのために)、6.1.3(MPLS-のため-IP非標識)、6.1.4(のための)集約MPLS-IP-に、および6.1.5(MPLSツーIP PHP)、一つずつのため。

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とMPLSフォワーディング(プッシュ)6.1.1項MPLSツーMPLSフォワーディング(スワップ)6.1.2項MPLS-に-IPフォワーディング(ポップ)、セクション6.1.3 MPLS-に-IPフォワーディング(集約)6.1節0.4 MPLS-に-IPフォワーディング(PHP)6.1.5項

Reporting Format

レポーティングフォーマット

The result should be reported as per Section 5 and RFC 2544.

結果は第5節およびRFC 2544に従って報告されるべきです。

6.3. Frame-Loss Rate (FLR) Measurement
6.3. フレーム損失率(FOR)測定

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とMPLS(プッシュ)、MPLSとIP(スワップ)、または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.

入力データレートとフレームサイズの範囲にわたって、DUTの動作を転送3つのMPLSのそれぞれについて、RFC 1242で定義されるように、フレーム損失率を得ることができます。

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.

(IP-に-MPLSのために)、セクション6.1.1で事業を転送5つのMPLSごとに設置した「テストセットアップ」のガイドラインに従って、6.1.2(MPLS-に-MPLSのために)、6.1.3(MPLS-のため-IP非標識)、6.1.4(のための)集約MPLS-IP-に、および6.1.5(MPLSツーIP PHP)、一つずつのため。

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とMPLSフォワーディング(プッシュ)6.1.1項MPLSツーMPLSフォワーディング(スワップ)6.1.2項MPLS-に-IPフォワーディング(ポップ)、セクション6.1.3 MPLS-に-IPフォワーディング(集約)6.1節0.4 MPLS-に-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に従って報告されるべきです。

6.4. System Recovery
6.4. システム回復

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.

(IP-に-MPLSのために)、セクション6.1.1で事業を転送5つのMPLSごとに設置した「テストセットアップ」のガイドラインに従って、6.1.2(MPLS-に-MPLSのために)、6.1.3(MPLS-のため-IP非標識)、6.1.4(のための)集約MPLS-IP-に、および6.1.5(MPLSツーIP PHP)、一つずつのため。

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とMPLSフォワーディング(プッシュ)6.1.1項MPLSツーMPLSフォワーディング(スワップ)6.1.2項MPLS-に-IPフォワーディング(ポップ)、セクション6.1.3 MPLS-に-IPフォワーディング(集約)6.1節0.4 MPLS-に-IPフォワーディング(PHP)6.1.5項

Reporting Format

レポーティングフォーマット

The result should be reported as per Section 5 and RFC 2544.

結果は第5節およびRFC 2544に従って報告されるべきです。

6.5. Reset
6.5. リセット

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.

(IP-に-MPLSのために)、セクション6.1.1で事業を転送5つのMPLSごとに設置した「テストセットアップ」のガイドラインに従って、6.1.2(MPLS-に-MPLSのために)、6.1.3(MPLS-のため-IP非標識)、6.1.4(のための)集約MPLS-IP-に、および6.1.5(MPLSツーIP PHP)、一つずつのため。

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とMPLSフォワーディングの場合は、スタティックルートの設定が適用されるべきです。 MPLSツーMPLSおよびMPLS-に-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 / MPLSデバイスがリセットイベントのいずれかの後に、完全に動作可能になるのにかかる時間はIPのみのデバイスのそれとは異なる場合があることは非常に可能性があります。

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:

それぞれが1対1の転送操作を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とMPLSフォワーディング(プッシュ)6.1.1項MPLSツーMPLSフォワーディング(スワップ)6.1.2項MPLS-に-IPフォワーディング(ポップ)、セクション6.1.3 MPLS-に-IPフォワーディング(集約)6.1節0.4 MPLS-に-IPフォワーディング(PHP)6.1.5項

Reporting Format

レポーティングフォーマット

The result should be reported as per Section 5 and as per the separate document.

結果は第5節ごとに、個別の文書ごとに報告されるべきです。

7. Security Considerations
7.セキュリティの考慮事項

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.

ベンチマークネットワークトポロジは、独立したテストのセットアップになり、テスト管理ネットワークへの生産ネットワークやmisrouteトラフィックにテストトラフィックを転送することができるデバイスに接続しないでください。

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.

この文書の範囲内には特定のセキュリティの考慮事項はありません。

8. Acknowledgement
8.謝辞

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ハリドを、感謝したいと思います。私たちは、彼らの慎重な検討と提案のためにロドニー・ダン、チップPopoviciu、ジェフByzek、ジェイカルティク、ラジブPapneja、サミールVapiwala、Silvija Andrijicドライ、スコット・ブラッドナー、アル・モートン、およびビルCervenyに感謝したいと思います。

This document was originally prepared using 2-Word-v2.0.template.dot.

この文書は、もともと2-Word-v2.0.template.dotを用いて調製しました。

9. References
9.参考文献
9.1. Normative References
9.1. 引用規格

[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月。

[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999.

、RFC 2544、1999年3月 "ネットワーク相互接続デバイスのためのベンチマーキング方法論" [RFC2544]ブラドナー、S.とJ. McQuaid、。

[RFC1242] Bradner, S., "Benchmarking Terminology for Network Interconnection Devices", RFC 1242, July 1991.

[RFC1242]ブラドナーの、S.、 "ネットワーク相互接続デバイスのためのベンチマーキング用語"、RFC 1242、1991年7月。

[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.

[RFC3031]ローゼン、E.、Viswanathanの、A.、およびR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、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]ローゼン、E.、タッパン、D.、Fedorkow、G.、Rekhter、Y.、ファリナッチ、D.、李、T.、およびA.コンタ、 "MPLSラベルスタックエンコーディング"、RFC 3032、2001年1月。

[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001.

[RFC3107] Rekhter、Y.、およびE.ローゼン、 "BGP-4でラベル情報を運ぶ"、RFC 3107、2001年5月。

[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.

[RFC5036]アンデション、L.、エド。、Minei、I.、エド。、およびB.トーマス、エド。、 "LDP仕様"、RFC 5036、2007年10月。

9.2. Informative References
9.2. 参考文献

[RFC5180] Popoviciu, C., Hamza, A., Van de Velde, G., and D. Dugatkin, "IPv6 Benchmarking Methodology for Network Interconnect Devices", RFC 5180, May 2008.

[RFC5180]、RFC 5180、2008年5月 "ネットワーク相互接続デバイスのIPv6ベンチマーキング方法論" Popoviciu、C.、ハムザ、A.、ヴァン・デ・ヴェルデ、G.、およびD. Dugatkin、。

[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。

[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.

[RFC4364]ローゼン、E.およびY. Rekhter、 "BGP / MPLS IP仮想プライベートネットワーク(VPN)"、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.、エド。、李、T.、エド。、およびS.野兎、編、 "ボーダーゲートウェイプロトコル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]アンデション、L.、エド。、およびE.ローゼン、エド。、RFC 4664 "レイヤ2個の仮想プライベートネットワーク(のL2VPN)のためのフレームワーク"、2006年9月。

[IEE8021] Mick Seaman (editor), "IEEE Std 802.1D-2004, MAC Bridges", Feb 2004.

[IEE8021]ミック・シーマン(編集者)、 "IEEE 802.1D STD-2004、MACブリッジ"、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コンピュータ社会のLAN / MAN標準委員会、「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]モイ、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]アンデション、L.および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]ツバメ、G.、ブライアント、S.、およびL.アンダーソン、 "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]パン、P.、エド。、ツバメ、G.、エド。、およびA.アトラス編、 "高速リルート機能拡張LSPトンネルのための-TEをRSVPする"、RFC 4090、2005年5月。

Authors' Addresses

著者のアドレス

Aamer Akhter Cisco Systems 7025 Kit Creek Road RTP, NC 27709 USA

Aamer Akhterシスコシステムズ7025キットクリーク道路RTP、NC 27709 USA

EMail: aakhter@cisco.com

メールアドレス:aakhter@cisco.com

Rajiv Asati Cisco Systems 7025 Kit Creek Road RTP, NC 27709 USA

ラジブAsatiシスコシステムズ7025キットクリーク道路RTP、NC 27709彼

EMail: rajiva@cisco.com

メールアドレス:rajiva@cisco.com

Carlos Pignataro Cisco Systems 7200-12 Kit Creek Road RTP, NC 27709 USA

カルロスPignataroシスコシステムズ7200から12キットクリーク道路RTP、NC 27709 USA

EMail: cpignata@cisco.com

メールアドレス:cpignata@cisco.com