[要約] RFC 7325は、MPLS（Multi-Protocol Label Switching）の転送の適合性とパフォーマンス要件に関するガイドラインです。このRFCの目的は、MPLSネットワークの転送機能の一貫性と性能を確保するための要件を定義することです。
Internet Engineering Task Force (IETF) C. Villamizar, Ed.
Request for Comments: 7325 OCCNC
Category: Informational K. Kompella
ISSN: 2070-1721 Juniper Networks
S. Amante
Apple Inc.
A. Malis
Huawei
C. Pignataro
Cisco
August 2014
MPLS Forwarding Compliance and Performance Requirements
MPLS転送のコンプライアンスとパフォーマンスの要件
Abstract
概要
This document provides guidelines for implementers regarding MPLS forwarding and a basis for evaluations of forwarding implementations. Guidelines cover many aspects of MPLS forwarding. Topics are highlighted where implementers might otherwise overlook practical requirements that are unstated or underemphasized, or that are optional for conformance to RFCs but often considered mandatory by providers.
このドキュメントでは、MPLS転送に関する実装者向けのガイドラインと、転送実装の評価の基礎について説明します。ガイドラインは、MPLS転送の多くの側面をカバーしています。トピックは強調されていますが、そうでない場合は、明記されていないか強調されていない、またはRFCへの適合のためにオプションですが、プロバイダーによって必須と見なされることが多い実際的な要件を実装者が見逃す可能性があります。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7325.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7325で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents
このドキュメントは、BCP 78およびIETFドキュメントに関連するIETFトラストの法的規定の対象です。
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
（http://trustee.ietf.org/license-info）このドキュメントの発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction and Document Scope . . . . . . . . . . . . . . . 4
1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Use of Requirements Language . . . . . . . . . . . . . . 8
1.3. Apparent Misconceptions . . . . . . . . . . . . . . . . . 9
1.4. Target Audience . . . . . . . . . . . . . . . . . . . . . 10
2. Forwarding Issues . . . . . . . . . . . . . . . . . . . . . . 11
2.1. Forwarding Basics . . . . . . . . . . . . . . . . . . . . 11
2.1.1. MPLS Special-Purpose Labels . . . . . . . . . . . . . 12
2.1.2. MPLS Differentiated Services . . . . . . . . . . . . 13
2.1.3. Time Synchronization . . . . . . . . . . . . . . . . 14
2.1.4. Uses of Multiple Label Stack Entries . . . . . . . . 14
2.1.5. MPLS Link Bundling . . . . . . . . . . . . . . . . . 15
2.1.6. MPLS Hierarchy . . . . . . . . . . . . . . . . . . . 16
2.1.7. MPLS Fast Reroute (FRR) . . . . . . . . . . . . . . . 16
2.1.8. Pseudowire Encapsulation . . . . . . . . . . . . . . 17
2.1.8.1. Pseudowire Sequence Number . . . . . . . . . . . 17
2.1.9. Layer 2 and Layer 3 VPN . . . . . . . . . . . . . . . 19
2.2. MPLS Multicast . . . . . . . . . . . . . . . . . . . . . 20
2.3. Packet Rates . . . . . . . . . . . . . . . . . . . . . . 21
2.4. MPLS Multipath Techniques . . . . . . . . . . . . . . . . 23
2.4.1. Pseudowire Control Word . . . . . . . . . . . . . . . 24
2.4.2. Large Microflows . . . . . . . . . . . . . . . . . . 24
2.4.3. Pseudowire Flow Label . . . . . . . . . . . . . . . . 25
2.4.4. MPLS Entropy Label . . . . . . . . . . . . . . . . . 25
2.4.5. Fields Used for Multipath Load Balance . . . . . . . 25
2.4.5.1. MPLS Fields in Multipath . . . . . . . . . . . . 26
2.4.5.2. IP Fields in Multipath . . . . . . . . . . . . . 27
2.4.5.3. Fields Used in Flow Label . . . . . . . . . . . . 29
2.4.5.4. Fields Used in Entropy Label . . . . . . . . . . 29
2.5. MPLS-TP and UHP . . . . . . . . . . . . . . . . . . . . . 30
2.6. Local Delivery of Packets . . . . . . . . . . . . . . . . 30
2.6.1. DoS Protection . . . . . . . . . . . . . . . . . . . 31
2.6.2. MPLS OAM . . . . . . . . . . . . . . . . . . . . . . 33
2.6.3. Pseudowire OAM . . . . . . . . . . . . . . . . . . . 34
2.6.4. MPLS-TP OAM . . . . . . . . . . . . . . . . . . . . . 34
2.6.5. MPLS OAM and Layer 2 OAM Interworking . . . . . . . . 35
2.6.6. Extent of OAM Support by Hardware . . . . . . . . . . 36
2.6.7. Support for IPFIX in Hardware . . . . . . . . . . . . 37
2.7. Number and Size of Flows . . . . . . . . . . . . . . . . 37
3. Questions for Suppliers . . . . . . . . . . . . . . . . . . . 38
3.1. Basic Compliance . . . . . . . . . . . . . . . . . . . . 38
3.2. Basic Performance . . . . . . . . . . . . . . . . . . . . 40
3.3. Multipath Capabilities and Performance . . . . . . . . . 41
3.4. Pseudowire Capabilities and Performance . . . . . . . . . 41
3.5. Entropy Label Support and Performance . . . . . . . . . . 42
3.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . 42
3.7. OAM Capabilities and Performance . . . . . . . . . . . . 42
4. Forwarding Compliance and Performance Testing . . . . . . . . 43
4.1. Basic Compliance . . . . . . . . . . . . . . . . . . . . 43
4.2. Basic Performance . . . . . . . . . . . . . . . . . . . . 44
4.3. Multipath Capabilities and Performance . . . . . . . . . 45
4.4. Pseudowire Capabilities and Performance . . . . . . . . . 46
4.5. Entropy Label Support and Performance . . . . . . . . . . 46
4.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . 47
4.7. OAM Capabilities and Performance . . . . . . . . . . . . 47
5. Security Considerations . . . . . . . . . . . . . . . . . . . 48
6. Organization of References Section . . . . . . . . . . . . . 50
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.1. Normative References . . . . . . . . . . . . . . . . . . 50
7.2. Informative References . . . . . . . . . . . . . . . . . 53
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 59
The initial purpose of this document was to address concerns raised on the MPLS WG mailing list about shortcomings in implementations of MPLS forwarding. Documenting existing misconceptions and potential pitfalls might potentially avoid repeating past mistakes. The document has grown to address a broad set of forwarding requirements.
このドキュメントの最初の目的は、MPLSフォワーディングの実装における欠点についてMPLS WGメーリングリストで提起された懸念に対処することでした。既存の誤解と潜在的な落とし穴を文書化することで、過去の過ちを繰り返すことを回避できる可能性があります。この文書は、幅広い転送要件に対応するように成長しました。
The focus of this document is MPLS forwarding, base pseudowire forwarding, and MPLS Operations, Administration, and Maintenance (OAM). The use of pseudowire Control Word and the use of pseudowire Sequence Number are discussed. Specific pseudowire Attachment Circuit (AC) and Native Service Processing (NSP) are out of scope. Specific pseudowire applications, such as various forms of Virtual Private Network (VPN), are out of scope.
このドキュメントの焦点は、MPLS転送、ベース疑似配線転送、およびMPLS運用、管理、および保守（OAM）です。疑似配線制御ワードの使用と疑似配線シーケンス番号の使用について説明します。特定の疑似配線接続回路（AC）およびネイティブサービス処理（NSP）は範囲外です。さまざまな形式の仮想プライベートネットワーク（VPN）などの特定の疑似配線アプリケーションは、範囲外です。
MPLS support for multipath techniques is considered essential by many service providers and is useful for other high-capacity networks. In order to obtain sufficient entropy from MPLS, traffic service providers and others find it essential for the MPLS implementation to interpret the MPLS payload as IPv4 or IPv6 based on the contents of the first nibble of payload. The use of IP addresses, the IP protocol field, and UDP and TCP port number fields in multipath load balancing are considered within scope. The use of any other IP protocol fields, such as tunneling protocols carried within IP, are out of scope.
マルチパス技術のMPLSサポートは、多くのサービスプロバイダーによって不可欠であると考えられており、他の大容量ネットワークで役立ちます。 MPLSから十分なエントロピーを取得するために、トラフィックサービスプロバイダーなどは、MPLS実装がペイロードの最初のニブルの内容に基づいてMPLSペイロードをIPv4またはIPv6として解釈することが不可欠であると認識しています。マルチパスロードバランシングでのIPアドレス、IPプロトコルフィールド、UDPおよびTCPポート番号フィールドの使用は、スコープ内と見なされます。 IP内で伝送されるトンネリングプロトコルなど、他のIPプロトコルフィールドの使用は範囲外です。
Implementation details are a local matter and are out of scope. Most interfaces today operate at 1 Gb/s or greater. It is assumed that all forwarding operations are implemented in specialized forwarding hardware rather than on a general-purpose processor. This is often referred to as "fast path" and "slow path" processing. Some recommendations are made regarding implementing control or management-plane functionality in specialized hardware or with limited assistance from specialized hardware. This advice is based on expected control or management protocol loads and on the need for denial of service (DoS) protection.
実装の詳細はローカルな問題であり、範囲外です。今日のほとんどのインターフェイスは1 Gb / s以上で動作します。すべての転送操作は、汎用プロセッサではなく、専用の転送ハードウェアで実装されると想定されています。これはしばしば「高速パス」および「低速パス」処理と呼ばれます。専用ハードウェアへの制御または管理プレーン機能の実装に関して、または専用ハードウェアからの限られた支援で、いくつかの推奨事項が作成されます。このアドバイスは、予想される制御または管理プロトコルの負荷と、サービス拒否（DoS）保護の必要性に基づいています。
The following abbreviations are used.
以下の略語を使用しています。
AC Attachment Circuit ([RFC3985])
ACアタッチメント回路（[RFC3985]）
ACH Associated Channel Header (pseudowires)
ACH関連チャネルヘッダー（疑似配線）
ACK Acknowledgement (TCP flag and type of TCP packet) AIS Alarm Indication Signal (MPLS-TP OAM)
ACK確認（TCPフラグとTCPパケットのタイプ）AISアラーム表示信号（MPLS-TP OAM）
ATM Asynchronous Transfer Mode (legacy switched circuits)
ATM非同期転送モード（レガシースイッチドサーキット）
BFD Bidirectional Forwarding Detection
BFD双方向転送検出
BGP Border Gateway Protocol
BGPボーダーゲートウェイプロトコル
CC-CV Continuity Check and Connectivity Verification
CC-CVの導通チェックと接続の検証
CE Customer Edge ([RFC4364])
CEカスタマーエッジ（[RFC4364]）
CPU Central Processing Unit (computer or microprocessor)
CPU中央処理装置（コンピューターまたはマイクロプロセッサー）
CT Class Type ([RFC4124])
CTクラスタイプ（[RFC4124]）
CW Control Word ([RFC4385])
CWコントロールワード（[RFC4385]）
DCCP Datagram Congestion Control Protocol
DCCPデータグラム輻輳制御プロトコル
DDoS Distributed Denial of Service
DDoS分散型サービス拒否
DM Delay Measurement (MPLS-TP OAM)
DM遅延測定（MPLS-TP OAM）
DSCP Differentiated Services Code Point ([RFC2474])
DSCP DiffServコードポイント（[RFC2474]）
DWDM Dense Wave Division Multiplexing
DWDM高密度波分割多重
DoS Denial of Service
DoSサービス拒否
E-LSP Explicitly TC-encoded-PSC LSP ([RFC5462])
E-LSP明示的にTCエンコードされたPSC LSP（[RFC5462]）
EBGP External BGP
EBGP外部BGP
ECMP Equal-Cost Multipath
ECMP等コストマルチパス
ECN Explicit Congestion Notification ([RFC3168] and [RFC5129])
ECN明示的輻輳通知（[RFC3168]および[RFC5129]）
EL Entropy Label ([RFC6790])
ELエントロピーラベル（[RFC6790]）
ELI Entropy Label Indicator ([RFC6790])
ELIエントロピーラベルインジケーター（[RFC6790]）
EXP Experimental (field in MPLS renamed to "TC" in [RFC5462])
EXP試験運用版（[RFC5462]でMPLSのフィールドの名前が「TC」に変更）
FEC Forwarding Equivalence Classes ([RFC3031]); also Forward Error Correction in other context
FEC転送同等クラス（[RFC3031]）;他の状況ではエラー訂正も転送します
FR Frame Relay (legacy switched circuits) FRR Fast Reroute ([RFC4090])
FRフレームリレー（レガシースイッチドサーキット）FRR高速リルート（[RFC4090]）
G-ACh Generic Associated Channel ([RFC5586])
G-ACh Generic Associated Channel（[RFC5586]）
GAL Generic Associated Channel Label ([RFC5586])
GAL Generic Associated Channel Label（[RFC5586]）
GFP Generic Framing Procedure (used in OTN)
GFP Generic Framing Procedure（OTNで使用）
GMPLS Generalized MPLS ([RFC3471])
GMPLS汎用MPLS（[RFC3471]）
GTSM Generalized TTL Security Mechanism ([RFC5082])
GTSM一般化TTLセキュリティメカニズム（[RFC5082]）
Gb/s Gigabits per second (billion bits per second)
Gb / sギガビット/秒（10億ビット/秒）
IANA Internet Assigned Numbers Authority
IANA Internet Assigned Numbers Authority
ILM Incoming Label Map ([RFC3031])
ILM受信ラベルマップ（[RFC3031]）
IP Internet Protocol
IPインターネットプロトコル
IPVPN Internet Protocol VPN
IPVPNインターネットプロトコルVPN
IPv4 Internet Protocol version 4
IPv4インターネットプロトコルバージョン4
IPv6 Internet Protocol version 6
IPv6インターネットプロトコルバージョン6
L-LSP Label-Only-Inferred-PSC LSP ([RFC3270])
L-LSPラベルのみ推定PSC LSP（[RFC3270]）
L2VPN Layer 2 VPN
L2VPNレイヤー2 VPN
LDP Label Distribution Protocol ([RFC5036])
LDPラベル配布プロトコル（[RFC5036]）
LER Label Edge Router ([RFC3031])
LERラベルエッジルーター（[RFC3031]）
LM Loss Measurement (MPLS-TP OAM)
LM損失測定（MPLS-TP OAM）
LSP Label Switched Path ([RFC3031])
LSPラベルスイッチドパス（[RFC3031]）
LSR Label Switching Router ([RFC3031])
LSRラベルスイッチングルーター（[RFC3031]）
MP2MP Multipoint to Multipoint
MP2MPマルチポイントからマルチポイント
MPLS Multiprotocol Label Switching ([RFC3031])
MPLSマルチプロトコルラベルスイッチング（[RFC3031]）
MPLS-TP MPLS Transport Profile ([RFC5317])
MPLS-TP MPLSトランスポートプロファイル（[RFC5317]）
Mb/s Megabits per second (million bits per second) NSP Native Service Processing ([RFC3985])
Mb / sメガビット/秒（100万ビット/秒）NSPネイティブサービス処理（[RFC3985]）
NTP Network Time Protocol
NTPネットワークタイムプロトコル
OAM Operations, Administration, and Maintenance ([RFC6291])
OAMの運用、管理、保守（[RFC6291]）
OOB Out-of-band (not carried within a data channel)
OOB Out-of-band（データチャネル内では伝送されません）
OTN Optical Transport Network
OTN光トランスポートネットワーク
P Provider router ([RFC4364])
Pプロバイダールーター（[RFC4364]）
P2MP Point to Multipoint
P2MPポイントツーマルチポイント
PE Provider Edge router ([RFC4364])
PEプロバイダーエッジルーター（[RFC4364]）
PHB Per-Hop Behavior ([RFC2475])
PHBのホップごとの動作（[RFC2475]）
PHP Penultimate Hop Popping ([RFC3443])
PHP最後から2番目のホップの飛び出し（[RFC3443]）
POS PPP over SONET
SONET上のPOS PPP
PSC This abbreviation has multiple interpretations.
PSCこの略語には複数の解釈があります。
1. Packet Switch Capable ([RFC3471]
1. パケットスイッチ対応（[RFC3471]
2. PHB Scheduling Class ([RFC3270])
2. PHBスケジューリングクラス（[RFC3270]）
3. Protection State Coordination ([RFC6378])
3. 保護状態の調整（[RFC6378]）
PTP Precision Time Protocol
PTPプレシジョンタイムプロトコル
PW Pseudowire
ΠΩpseudovir
QoS Quality of Service
QoS QoS
RA Router Alert ([RFC3032])
RAルーターアラート（[RFC3032]）
RDI Remote Defect Indication (MPLS-TP OAM)
RDIリモート障害表示（MPLS-TP OAM）
RSVP-TE RSVP Traffic Engineering
RSVP-TE RSVPトラフィックエンジニアリング
RTP Real-time Transport Protocol
RTPリアルタイム転送プロトコル
SCTP Stream Control Transmission Protocol
SCTPストリーム制御伝送プロトコル
SDH Synchronous Data Hierarchy (European SONET, a form of TDM) SONET Synchronous Optical Network (US SDH, a form of TDM)
SDH同期データ階層（ヨーロッパのSONET、TDMの形式）SONET同期光ネットワーク（US SDH、TDMの形式）
T-LDP Targeted LDP (LDP sessions over more than one hop)
T-LDPターゲットLDP（1ホップ以上のLDPセッション）
TC Traffic Class ([RFC5462])
TCトラフィッククラス（[RFC5462]）
TCP Transmission Control Protocol
TCP伝送制御プロトコル
TDM Time-Division Multiplexing (legacy encapsulations)
TDM時分割多重化（レガシーカプセル化）
TOS Type of Service (see [RFC2474])
TOS Type of Service（[RFC2474]を参照）
TTL Time-to-live (a field in IP and MPLS headers)
TTL存続時間（IPおよびMPLSヘッダーのフィールド）
UDP User Datagram Protocol
UDPユーザーデータグラムプロトコル
UHP Ultimate Hop Popping (opposite of PHP)
UHP Ultimate Hop Popping（PHPの反対）
VCCV Virtual Circuit Connectivity Verification ([RFC5085])
VCCV Virtual Circuit Connectivity Verification（[RFC5085]）
VLAN Virtual Local Area Network (Ethernet)
VLAN仮想ローカルエリアネットワーク（イーサネット）
VOQ Virtual Output Queuing (switch fabric design)
VOQ仮想出力キューイング（スイッチファブリック設計）
VPN Virtual Private Network
VPN仮想プライベートネットワーク
WG Working Group
WGワーキンググループ
This document is Informational. The uppercase [RFC2119] key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are used in this document in the following cases.
このドキュメントは情報提供です。このドキュメントでは、次の場合に大文字の[RFC2119]キーワード「MUST」、「MUST NOT」、「SHOULD」、「SHOULD NOT」、および「MAY」を使用しています。
1. RFC 2119 keywords are used where requirements stated in this document are called for in referenced RFCs. In most cases, the RFC containing the requirement is cited within the statement using an RFC 2119 keyword.
1. RFC 2119キーワードは、このドキュメントに記載されている要件が参照されるRFCで要求される場合に使用されます。ほとんどの場合、要件を含むRFCは、ステートメント内でRFC 2119キーワードを使用して引用されています。
2. RFC 2119 keywords are used where explicitly noted that the keywords indicate that operator experiences indicate a requirement, but there are no existing RFC requirements.
2. RFC 2119キーワードは、演算子の経験が要件を示すことをキーワードが示していることを明示的に示している場合に使用されますが、既存のRFC要件はありません。
Advice provided by this document may be ignored by implementations. Similarly, implementations not claiming conformance to specific RFCs may ignore the requirements of those RFCs. In both cases, implementers should consider the risk of doing so.
このドキュメントによって提供されるアドバイスは、実装によって無視される場合があります。同様に、特定のRFCへの適合を主張しない実装は、それらのRFCの要件を無視する場合があります。どちらの場合も、実装者はそうすることのリスクを考慮する必要があります。
In early generations of forwarding silicon (which might now be behind us), there apparently were some misconceptions about MPLS. The following statements provide clarifications.
フォワーディングシリコンの初期の世代（現在は背後にある可能性があります）では、MPLSについていくつかの誤解があったようです。次のステートメントは、説明を提供します。
1. There are practical reasons to have more than one or two labels in an MPLS label stack. Under some circumstances, the label stack can become quite deep. See Section 2.1.
1. MPLSラベルスタックに1つまたは2つ以上のラベルを付けることには、実際的な理由があります。状況によっては、ラベルスタックが非常に深くなる場合があります。セクション2.1を参照してください。
2. The label stack MUST be considered to be arbitrarily deep. Section 3.27.4 ("Hierarchy: LSP Tunnels within LSPs") of RFC 3031 states "The label stack mechanism allows LSP tunneling to nest to any depth" [RFC3031]. If a bottom of the label stack cannot be found, but sufficient number of labels exist to forward, an LSR MUST forward the packet. An LSR MUST NOT assume the packet is malformed unless the end of packet is found before the bottom of the stack. See Section 2.1.
2. ラベルスタックは、任意の深さと見なす必要があります。 RFC 3031のセクション3.27.4（「階層：LSP内のLSPトンネル」）は、「ラベルスタックメカニズムにより、LSPトンネリングが任意の深さにネストできるようにする」[RFC3031]と述べています。ラベルスタックの下部が見つからないが、転送するのに十分な数のラベルが存在する場合、LSRはパケットを転送する必要があります。 LSRは、スタックの最後の前にパケットの終わりが見つからない限り、パケットが不正な形式であると想定してはなりません（MUST NOT）。セクション2.1を参照してください。
3. In networks where deep label stacks are encountered, they are not rare. Full packet rate performance is required regardless of label stack depth, except where multiple pop operations are required. See Section 2.1.
3. 深いラベルスタックに遭遇するネットワークでは、まれではありません。複数のpop操作が必要な場合を除いて、ラベルスタックの深さに関係なく、完全なパケットレートのパフォーマンスが必要です。セクション2.1を参照してください。
4. Research has shown that long bursts of short packets with 40-byte or 44-byte IP payload sizes in these bursts are quite common. This is due to TCP ACK compression [ACK-compression]. The following two sub-bullets constitute advice that reflects very common nonnegotiable requirements of providers. Implementers may ignore this advice but should consider the risk of doing so.
4. 調査によると、これらのバーストに40バイトまたは44バイトのIPペイロードサイズを持つ短いパケットの長いバーストがよく見られます。これは、TCP ACK圧縮[ACK圧縮]が原因です。次の2つの小冊子は、プロバイダーの非常に一般的な交渉できない要件を反映するアドバイスを構成します。実装者はこのアドバイスを無視できますが、そうすることのリスクを考慮する必要があります。
A. A forwarding engine SHOULD, if practical, be able to sustain an arbitrarily long sequence of small packets arriving at full interface rate.
A.転送エンジンは、可能であれば、フルインターフェースレートで到着する任意の長い一連の小さなパケットを維持できる必要があります。
B. If indefinitely sustained full packet rate for small packets is not practical, a forwarding engine MUST be able to buffer a long sequence of small packets inbound to the on-chip decision engine and sustain full interface rate for some reasonable average packet rate. Absent this small on-chip buffering, QoS-agnostic packet drops can occur.
B.小さいパケットの無制限に維持されるフルパケットレートが実用的でない場合、フォワーディングエンジンは、オンチップの決定エンジンに着信する長い一連の小さいパケットをバッファリングし、ある程度の妥当な平均パケットレートでフルインターフェイスレートを維持できる必要があります。この小さなオンチップバッファリングがないと、QoSに依存しないパケットドロップが発生する可能性があります。
See Section 2.3.
セクション2.3を参照してください。
5. The implementations and system designs MUST support pseudowire Control Word (CW) if MPLS-TP is supported or if ACH [RFC5586] is being used on a pseudowire. The implementation and system designs SHOULD support pseudowire CW even if MPLS-TP and ACH
5. 実装とシステム設計は、MPLS-TPがサポートされている場合、またはACH [RFC5586]が疑似配線で使用されている場合、疑似配線制御ワード（CW）をサポートする必要があります。実装およびシステム設計は、MPLS-TPおよびACHであっても疑似配線CWをサポートする必要があります（SHOULD）。
[RFC5586] are not used, using instead CW and VCCV Type 1 [RFC5085] to allow the use of multipath in the underlying network topology without impacting the PW traffic. [RFC7079] does note that there are still some deployments where the CW is not always used. It also notes that many service providers do enable the CW. See Section 2.4.1 for more discussion on why deployments SHOULD enable the pseudowire CW.
[RFC5586]は使用されず、代わりにCWおよびVCCVタイプ1 [RFC5085]を使用して、PWトラフィックに影響を与えることなく、基盤となるネットワークトポロジでマルチパスを使用できるようにします。 [RFC7079]は、CWが常に使用されるわけではない展開がまだいくつかあることに注意しています。また、多くのサービスプロバイダーがCWを有効にしています。展開で疑似配線CWを有効にする必要がある理由の詳細については、セクション2.4.1を参照してください。
The following statements provide clarification regarding more recent requirements that are often missed.
次のステートメントは、見落とされがちな最近の要件に関する説明です。
1. The implementer and system designer SHOULD support adding a pseudowire Flow Label [RFC6391]. Deployments MAY enable this feature for appropriate pseudowire types. See Section 2.4.3.
1. 実装者とシステム設計者は、疑似配線フローラベル[RFC6391]の追加をサポートする必要があります（SHOULD）。展開は、適切な疑似配線タイプに対してこの機能を有効にする場合があります。セクション2.4.3を参照してください。
2. The implementer and system designer SHOULD support adding an MPLS Entropy Label [RFC6790]. Deployments MAY enable this feature. See Section 2.4.4.
2. 実装者とシステム設計者は、MPLSエントロピーラベル[RFC6790]の追加をサポートする必要があります（SHOULD）。デプロイメントはこの機能を有効にする場合があります。セクション2.4.4を参照してください。
Non-IETF definitions of MPLS exist, and these should not be used as normative texts in place of the relevant IETF RFCs. [RFC5704] documents incompatibilities between the IETF definition of MPLS and one such alternative MPLS definition, which led to significant issues in the resulting non-IETF specification.
MPLSの非IETF定義が存在し、これらは関連するIETF RFCの代わりに規範的なテキストとして使用しないでください。 [RFC5704]は、MPLSのIETF定義とそのような代替MPLS定義の1つとの間の非互換性を文書化しており、その結果、非IETF仕様で重大な問題が発生しました。
This document is intended for multiple audiences: implementer (implementing MPLS forwarding in silicon or in software); systems designer (putting together a MPLS forwarding systems); deployer (running an MPLS network). These guidelines are intended to serve the following purposes:
このドキュメントは複数の読者を対象としています。実装者（シリコンまたはソフトウェアでのMPLS転送の実装）。システム設計者（MPLS転送システムをまとめる）;デプロイヤ（MPLSネットワークを実行）。これらのガイドラインは、次の目的を果たすことを目的としています。
1. Explain what to do and what not to do when a deep label stack is encountered. (audience: implementer)
1. 深いラベルスタックが検出された場合の対処法と対処法を説明します。 （聴衆：実装者）
2. Highlight pitfalls to look for when implementing an MPLS forwarding chip. (audience: implementer)
2. MPLS転送チップを実装する際に注意すべき落とし穴を強調表示します。 （聴衆：実装者）
3. Provide a checklist of features and performance specifications to request. (audience: systems designer, deployer)
3. 要求する機能と性能仕様のチェックリストを提供します。 （聴衆：システム設計者、展開者）
4. Provide a set of tests to perform. (audience: systems designer, deployer).
4. 実行する一連のテストを提供します。 （聴衆：システム設計者、展開者）。
The implementer, systems designer, and deployer have a transitive supplier-customer relationship. It is in the best interest of the supplier to review their product against their customer's checklist and secondary customer's checklist if applicable.
実装者、システム設計者、および配備者は、推移的なサプライヤーと顧客の関係を持っています。顧客のチェックリストおよび該当する場合は二次的な顧客のチェックリストと照らし合わせて製品をレビューすることは、サプライヤーにとって最大の利益になります。
This document identifies and explains many details and potential pitfalls of MPLS forwarding. It is likely that the identified set of potential pitfalls will later prove to be an incomplete set.
このドキュメントでは、MPLS転送の多くの詳細と潜在的な落とし穴を特定して説明します。特定された潜在的な落とし穴のセットは、後で不完全なセットであることが判明する可能性があります。
A brief review of forwarding issues is provided in the subsections that follow. This section provides some background on why some of these requirements exist. The questions to ask of suppliers is covered in Section 3. Some guidelines for testing are provided in Section 4.
次のサブセクションでは、転送の問題について簡単に説明します。このセクションでは、これらの要件が存在する理由についての背景を説明します。サプライヤに尋ねる質問はセクション3で説明されています。テストのガイドラインのいくつかはセクション4で提供されています。
Basic MPLS architecture and MPLS encapsulation, and therefore packet forwarding, are defined in [RFC3031] and [RFC3032]. RFC 3031 and RFC 3032 are somewhat LDP centric. RSVP-TE supports traffic engineering (TE) and fast reroute, features that LDP lacks. The base document for MPLS RSVP-TE is [RFC3209].
基本的なMPLSアーキテクチャとMPLSカプセル化、つまりパケット転送は、[RFC3031]と[RFC3032]で定義されています。 RFC 3031とRFC 3032はLDP中心です。 RSVP-TEは、LDPにはない機能であるトラフィックエンジニアリング（TE）と高速リルートをサポートしています。 MPLS RSVP-TEのベースドキュメントは[RFC3209]です。
A few RFCs update RFC 3032. Those with impact on forwarding include the following.
いくつかのRFCはRFC 3032を更新しています。転送に影響を与えるものには、次のものがあります。
1. TTL processing is clarified in [RFC3443].
1. TTL処理は[RFC3443]で明確にされています。
2. The use of MPLS Explicit NULL is modified in [RFC4182].
2. MPLS Explicit NULLの使用は[RFC4182]で変更されています。
3. Differentiated Services is supported by [RFC3270] and [RFC4124]. The "EXP" field is renamed to "Traffic Class" in [RFC5462], removing any misconception that it was available for experimentation or could be ignored.
3. Differentiated Servicesは、[RFC3270]および[RFC4124]でサポートされています。 [EXP]フィールドは[RFC5462]で[Traffic Class]に名前が変更され、実験に使用できる、または無視できるという誤解がなくなりました。
4. ECN is supported by [RFC5129].
4. ECNは[RFC5129]でサポートされています。
5. The MPLS G-ACh and GAL are defined in [RFC5586].
5. MPLS G-AChとGALは[RFC5586]で定義されています。
6. [RFC5332] redefines the two data link layer codepoints for MPLS packets.
6. [RFC5332]は、MPLSパケットの2つのデータリンク層コードポイントを再定義します。
Tunneling encapsulations carrying MPLS, such as MPLS in IP [RFC4023], MPLS in GRE [RFC4023], MPLS in L2TPv3 [RFC4817], or MPLS in UDP [MPLS-IN-UDP], are out of scope.
IP内のMPLS [RFC4023]、GRE内のMPLS [RFC4023]、L2TPv3内のMPLS [RFC4817]、UDP内のMPLS [MPLS-IN-UDP]など、MPLSを伝送するトンネルカプセル化は範囲外です。
Other RFCs have implications to MPLS Forwarding and do not update RFC 3032 or RFC 3209, including:
他のRFCはMPLS転送に影響を与え、RFC 3032またはRFC 3209を更新しません。
1. The pseudowire (PW) Associated Channel Header (ACH) is defined by [RFC5085] and was later generalized by the MPLS G-ACh [RFC5586].
1. 疑似配線（PW）関連チャネルヘッダー（ACH）は[RFC5085]で定義され、後でMPLS G-ACh [RFC5586]で一般化されました。
2. The Entropy Label Indicator (ELI) and Entropy Label (EL) are defined by [RFC6790].
2. エントロピーラベルインジケーター（ELI）とエントロピーラベル（EL）は、[RFC6790]で定義されています。
A few RFCs update RFC 3209. Those that are listed as updating RFC 3209 generally impact only RSVP-TE signaling. Forwarding is modified by major extensions built upon RFC 3209.
いくつかのRFCはRFC 3209を更新します。RFC3209の更新としてリストされているものは、一般にRSVP-TEシグナリングにのみ影響します。転送は、RFC 3209に基づいて構築された主要な拡張機能によって変更されます。
RFCs that impact forwarding are discussed in the following subsections.
転送に影響を与えるRFCについては、次のサブセクションで説明します。
[RFC3032] specifies that label values 0-15 are special-purpose labels with special meanings. [RFC7274] renamed these from the term "reserved labels" used in [RFC3032] to "special-purpose labels". Three values of NULL label are defined (two of which are later updated by [RFC4182]) and a Router Alert Label is defined. The original intent was that special-purpose labels, except the NULL labels, could be sent to the routing engine CPU rather than be processed in forwarding hardware. Hardware support is required by new RFCs such as those defining Entropy Label and OAM processed as a result of receiving a GAL. For new special-purpose labels, some accommodation is needed for LSRs that will send the labels to a general-purpose CPU or other highly programmable hardware. For example, ELI will only be sent to LSRs that have signaled support for [RFC6790], and a high OAM packet rate must be negotiated among endpoints.
[RFC3032]は、ラベル値0〜15が特別な意味を持つ特別な目的のラベルであることを指定します。 [RFC7274]は、これらを[RFC3032]で使用されている「予約済みラベル」という用語から「特殊用途のラベル」に改名しました。 NULLラベルの3つの値が定義され（そのうちの2つは[RFC4182]によって後で更新されます）、ルーター警告ラベルが定義されます。本来の目的は、NULLラベルを除く特殊用途のラベルを、転送ハードウェアで処理するのではなく、ルーティングエンジンCPUに送信できるようにすることでした。ハードウェアサポートは、GALの受信の結果として処理されるエントロピーラベルやOAMを定義するRFCなどの新しいRFCで必要です。新しい特殊用途のラベルの場合、汎用CPUまたはその他の高度にプログラム可能なハードウェアにラベルを送信するLSRには、いくつかの調整が必要です。たとえば、ELIは[RFC6790]のサポートを通知したLSRにのみ送信され、エンドポイント間で高いOAMパケットレートをネゴシエートする必要があります。
[RFC3429] reserves a label for ITU-T Y.1711; however, Y.1711 does not work with multipath and its use is strongly discouraged.
[RFC3429]はITU-T Y.1711のラベルを予約しています。ただし、Y.1711はマルチパスでは機能せず、その使用はお勧めしません。
The current list of special-purpose labels can be found on the "Multiprotocol Label Switching Architecture (MPLS) Label Values" registry reachable at IANA's pages at <http://www.iana.org>.
特別な目的のラベルの現在のリストは、<http://www.iana.org>のIANAのページにある「マルチプロトコルラベルスイッチングアーキテクチャ（MPLS）ラベル値」レジストリにあります。
[RFC7274] introduces an IANA "Extended Special-Purpose MPLS Label Values" registry and makes use of the "extension" label, label 15, to indicate that the next label is an extended special-purpose label and requires special handling. The range of only 16 values for special-purpose labels allows a table to be used. The range of extended special-purpose labels with 20 bits available for use may have to be handled in some other way in the unlikely event that in the future the range of currently reserved values 256-1048575 is used. If only the Standards Action range, 16-239, and the Experimental range, 240-255, are used, then a table of 256 entries can be used.
[RFC7274]は、IANA「拡張特殊目的MPLSラベル値」レジストリを導入し、「拡張」ラベル、ラベル15を利用して、次のラベルが拡張特殊目的ラベルであり、特別な処理が必要であることを示します。特殊用途のラベルの値が16しかないため、テーブルを使用できます。将来的に現在予約されている値の範囲256〜1048575が使用されるというまれな場合に、使用可能な20ビットの拡張特殊用途ラベルの範囲を別の方法で処理する必要がある場合があります。標準アクション範囲（16〜239）と実験範囲（240〜255）のみを使用する場合は、256エントリのテーブルを使用できます。
Unknown special-purpose labels and unknown extended special-purpose labels are handled the same. When an unknown special-purpose label is encountered or a special purpose label not directly handled in forwarding hardware is encountered, the packet should be sent to a general-purpose CPU by default. If this capability is supported, there must be an option to either drop or rate limit such packets based on the value of each special-purpose label.
不明な専用ラベルと不明な拡張専用ラベルは同じように処理されます。不明な専用ラベルが検出された場合、または転送ハードウェアで直接処理されない専用ラベルが検出された場合、デフォルトでパケットを汎用CPUに送信する必要があります。この機能がサポートされている場合は、各専用ラベルの値に基づいて、そのようなパケットをドロップまたはレート制限するオプションが必要です。
[RFC2474] deprecates the IP Type of Service (TOS) and IP Precedence (Prec) fields and replaces them with the Differentiated Services Field more commonly known as the Differentiated Services Code Point (DSCP) field. [RFC2475] defines the Differentiated Services architecture, which in other forums, is often called a Quality of Service (QoS) architecture.
[RFC2474]は、IP Type of Service（TOS）およびIP Precedence（Prec）フィールドを非推奨にし、Differentiated Services Code Point（DSCP）フィールドとして一般的に知られているDifferentiated Servicesフィールドに置き換えます。 [RFC2475]は、他のフォーラムではしばしばサービス品質（QoS）アーキテクチャと呼ばれる差別化サービスアーキテクチャを定義しています。
MPLS uses the Traffic Class (TC) field to support Differentiated Services [RFC5462]. There are two primary documents describing how DSCP is mapped into TC.
MPLSは、トラフィッククラス（TC）フィールドを使用して、差別化サービス[RFC5462]をサポートします。 DSCPがどのようにTCにマッピングされるかを説明する2つの主要なドキュメントがあります。
1. [RFC3270] defines E-LSP and L-LSP. E-LSP uses a static mapping of DSCP into TC. L-LSP uses a per-LSP mapping of DSCP into TC, with one PHB Scheduling Class (PSC) per L-LSP. Each PSC can use multiple Per-Hop Behavior (PHB) values. For example, the Assured Forwarding service defines three PSCs, each with three PHB [RFC2597].
1. [RFC3270]はE-LSPとL-LSPを定義しています。 E-LSPは、TCへのDSCPの静的マッピングを使用します。 L-LSPは、LSPごとのDSCPからTCへのマッピングを使用し、L-LSPごとに1つのPHBスケジューリングクラス（PSC）を使用します。各PSCは複数のホップ単位の動作（PHB）値を使用できます。たとえば、Assured Forwardingサービスは3つのPSCを定義し、それぞれに3つのPHB [RFC2597]があります。
2. [RFC4124] defines assignment of a class-type (CT) to an LSP, where a per-CT static mapping of TC to PHB is used. [RFC4124] provides a means to support up to eight E-LSP-like mappings of DSCP to TC.
2. [RFC4124]は、LSPへのクラスタイプ（CT）の割り当てを定義します。ここで、TCからPHBへのCTごとの静的マッピングが使用されます。 [RFC4124]は、DSCPからTCへの最大8つのE-LSPのようなマッピングをサポートする手段を提供します。
To meet Differentiated Services requirements specified in [RFC3270], the following forwarding requirements must be met. An ingress LER MUST be able to select an LSP and then apply a per-LSP map of DSCP into TC. A midpoint LSR MUST be able to apply a per-LSP map of TC to PHB. The number of mappings supported will be far less than the number of LSPs supported.
[RFC3270]で指定された差別化サービスの要件を満たすには、次の転送要件を満たす必要があります。入力LERはLSPを選択し、DSCPのLSPごとのマップをTCに適用できる必要があります。中間点のLSRは、TCのLSPごとのマップをPHBに適用できる必要があります。サポートされるマッピングの数は、サポートされるLSPの数よりもはるかに少なくなります。
To meet Differentiated Services requirements specified in [RFC4124], the following forwarding requirements must be met. An ingress LER MUST be able to select an LSP and then apply a per-LSP map of DSCP into TC. A midpoint LSR MUST be able to map LSP number to Class Type (CT), then use a per-CT map to map TC to PHB. Since there are only eight allowed values of CT, only eight maps of TC to PHB need to be supported. The LSP label can be used directly to find the TC-to-PHB mapping, as is needed to support L-LSPs as defined by [RFC3270].
[RFC4124]で指定されている差別化サービス要件を満たすには、次の転送要件を満たす必要があります。入力LERはLSPを選択し、DSCPのLSPごとのマップをTCに適用できる必要があります。ミッドポイントLSRは、LSP番号をクラスタイプ（CT）にマップできなければならず、次に、CTごとのマップを使用してTCをPHBにマップできます。 CTの許容値は8つしかないため、サポートする必要があるのは、TCからPHBへの8つのマップだけです。 [RFC3270]で定義されているL-LSPをサポートするために必要な場合、LSPラベルを直接使用してTCからPHBへのマッピングを見つけることができます。
While support for [RFC4124] and not [RFC3270] would allow support for only eight mappings of TC to PHB, it is common to support both and simply state a limit on the number of unique TC-to-PHB mappings that can be supported.
[RFC3270]ではなく[RFC4124]をサポートすると、TCからPHBへのマッピングは8つしかサポートされなくなりますが、両方をサポートし、サポートできる一意のTCからPHBへのマッピングの数に制限を設けるのが一般的です。
PTP or NTP may be carried over MPLS [TIMING-OVER-MPLS]. Generally, NTP will be carried within IP, and IP will be carried in MPLS [RFC5905]. Both PTP and NTP benefit from accurate timestamping of incoming packets and the ability to insert accurate timestamps in outgoing packets. PTP correction that occurs when forwarding requires updating a timestamp compensation field based on the difference between packet arrival at an LSR and packet transmit time at that same LSR.
PTPまたはNTPは、MPLS [TIMING-OVER-MPLS]を介して伝送されます。通常、NTPはIP内で伝送され、IPはMPLS [RFC5905]で伝送されます。 PTPとNTPはどちらも、着信パケットの正確なタイムスタンプと、発信パケットに正確なタイムスタンプを挿入する機能の恩恵を受けます。 LSRでのパケット到着と同じLSRでのパケット送信時間の差に基づいて、転送がタイムスタンプ補正フィールドを更新する必要がある場合に発生するPTP修正。
Since the label stack depth may vary, hardware should allow a timestamp to be placed in an outgoing packet at any specified byte position. It may be necessary to modify Layer 2 checksums or frame check sequences after insertion. PTP and NTP timestamp formats differ in such a way as to require different implementations of the timestamp correction. If NTP or PTP is carried over UDP/IP or UDP/IP/MPLS, the UDP checksum will also have to be updated.
ラベルスタックの深さが異なる場合があるため、ハードウェアでは、タイムスタンプを送信パケットの指定された任意のバイト位置に配置できるようにする必要があります。挿入後に、レイヤ2チェックサムまたはフレームチェックシーケンスを変更する必要がある場合があります。 PTPとNTPのタイムスタンプ形式は、タイムスタンプ修正の異なる実装が必要になるように異なります。 NTPまたはPTPがUDP / IPまたはUDP / IP / MPLSを介して伝送される場合、UDPチェックサムも更新する必要があります。
Accurate time synchronization, in addition to being generally useful, is required for MPLS-TP Delay Measurement (DM) OAM. See Section 2.6.4.
MPLS-TP遅延測定（DM）OAMには、一般に役立つことに加えて、正確な時刻同期が必要です。セクション2.6.4を参照してください。
MPLS deployments in the early part of the prior decade (circa 2000) tended to support either LDP or RSVP-TE. LDP was favored by some for its ability to scale to a very large number of PE devices at the edge of the network, without adding deployment complexity. RSVP-TE was favored, generally in the network core, where traffic engineering and/or fast reroute were considered important.
前の10年間の早い段階（2000年頃）でのMPLSの展開は、LDPまたはRSVP-TEのいずれかをサポートする傾向がありました。 LDPは、導入の複雑さを増すことなく、ネットワークのエッジで非常に多数のPEデバイスに拡張できるため、一部のユーザーから支持されました。 RSVP-TEは、一般的にネットワークコアで好まれ、トラフィックエンジニアリングや高速リルートが重要と見なされていました。
Both LDP and RSVP-TE are used simultaneously within major service provider networks using a technique known as "LDP over RSVP-TE Tunneling". This technique allows service providers to carry LDP tunnels inside RSVP-TE tunnels. This makes it possible to take advantage of the traffic engineering and fast reroute on more expensive intercity and intercontinental transport paths. The ingress RSVP-TE PE places many LDP tunnels on a single RSVP-TE LSP and carries it to the egress RSVP-TE PE. The LDP PEs are situated further from the core, for example, within a metro network. LDP over RSVP-TE tunneling requires a minimum of two MPLS labels: one each for LDP and RSVP-TE.
LDPとRSVP-TEの両方は、「LDP over RSVP-TEトンネリング」として知られている技術を使用して、主要なサービスプロバイダーネットワーク内で同時に使用されます。この技術により、サービスプロバイダーは、RSVP-TEトンネル内でLDPトンネルを伝送できます。これにより、トラフィックエンジニアリングを利用して、より高価な都市間および大陸間の輸送経路で高速のルート変更を行うことができます。入力RSVP-TE PEは、単一のRSVP-TE LSPに多くのLDPトンネルを配置し、それを出力RSVP-TE PEに伝送します。 LDP PEは、たとえばメトロネットワーク内など、コアから離れた場所にあります。 LDP over RSVP-TEトンネリングには、最低2つのMPLSラベルが必要です。LDPとRSVP-TEにそれぞれ1つずつです。
The use of MPLS FRR [RFC4090] might add one more label to MPLS traffic but only when FRR protection is in use (active). If LDP over RSVP-TE is in use, and FRR protection is in use, then at least three MPLS labels are present on the label stack on the links through which the Bypass LSP traverses. FRR is covered in Section 2.1.7.
MPLS FRR [RFC4090]を使用すると、MPLSトラフィックにラベルが1つ追加されることがありますが、これはFRR保護が使用されている（アクティブである）場合に限られます。 LDP over RSVP-TEが使用されていて、FRR保護が使用されている場合、バイパスLSPが通過するリンク上のラベルスタックに少なくとも3つのMPLSラベルが存在します。 FRRはセクション2.1.7でカバーされています。
LDP L2VPN, LDP IPVPN, BGP L2VPN, and BGP IPVPN added support for VPN services that are deployed by the vast majority of service providers. These VPN services added yet another label, bringing the label stack depth (when FRR is active) to four.
LDP L2VPN、LDP IPVPN、BGP L2VPN、およびBGP IPVPNは、大多数のサービスプロバイダーによって展開されるVPNサービスのサポートを追加しました。これらのVPNサービスはさらに別のラベルを追加し、ラベルスタックの深さ（FRRがアクティブな場合）を4にしました。
Pseudowires and VPN are discussed in further detail in Sections 2.1.8 and 2.1.9.
疑似配線とVPNについては、セクション2.1.8および2.1.9で詳しく説明します。
MPLS hierarchy as described in [RFC4206] and updated by [RFC7074] can in principle add at least one additional label. MPLS hierarchy is discussed in Section 2.1.6.
[RFC4206]で説明され、[RFC7074]で更新されるMPLS階層は、原則として少なくとも1つの追加ラベルを追加できます。 MPLS階層については、2.1.6項で説明します。
Other features such as Entropy Label (discussed in Section 2.4.4) and Flow Label (discussed in Section 2.4.3) can add additional labels to the label stack.
エントロピーラベル（セクション2.4.4で説明）やフローラベル（セクション2.4.3で説明）などの他の機能により、ラベルスタックにラベルを追加できます。
Although theoretical scenarios can easily result in eight or more labels, such cases are rare if they occur at all today. For the purpose of forwarding, only the top label needs to be examined if PHP is used, and a few more if UHP is used (see Section 2.5). For deep label stacks, quite a few labels may have to be examined for the purpose of load balancing across parallel links (see Section 2.4); however, this depth can be bounded by a provider through use of Entropy Label.
理論的なシナリオでは、8つ以上のラベルが簡単に作成される可能性がありますが、そのようなケースが今日発生したとしてもまれです。転送の目的で、PHPが使用されている場合は最上位のラベルのみを、UHPが使用されている場合はさらにいくつかを調べる必要があります（セクション2.5を参照）。深いラベルスタックの場合、並列リンク間で負荷分散を行うためにかなりの数のラベルを調べる必要がある場合があります（セクション2.4を参照）。ただし、この深さは、エントロピーラベルを使用してプロバイダーが制限できます。
Other creative uses of MPLS within the IETF, such as the use of MPLS label stack in source routing, may result in label stacks that are considerably deeper than those encountered today.
ソースルーティングでのMPLSラベルスタックの使用など、IETF内でのMPLSのその他の創造的な使用は、現在のラベルスタックよりもかなり深いラベルスタックになる可能性があります。
MPLS Link Bundling was the first RFC to address the need for multiple parallel links between nodes [RFC4201]. MPLS Link Bundling is notable in that it tried not to change MPLS forwarding, except in specifying the "all-ones" component link. MPLS Link Bundling is seldom if ever deployed. Instead, multipath techniques described in Section 2.4 are used.
MPLSリンクバンドリングは、ノード間の複数の並列リンクの必要性に対処する最初のRFCでした[RFC4201]。 MPLSリンクバンドリングは、「すべて1」のコンポーネントリンクを指定する場合を除いて、MPLS転送を変更しないように試みた点で注目に値します。 MPLSリンクバンドリングが展開されても、めったにありません。代わりに、セクション2.4で説明されているマルチパス技術が使用されます。
MPLS hierarchy is defined in [RFC4206] and updated by [RFC7074]. Although RFC 4206 is considered part of GMPLS, the Packet Switching Capable (PSC) portion of the MPLS hierarchy is applicable to MPLS and may be supported in an otherwise GMPLS-free implementation. The MPLS PSC hierarchy remains the most likely means of providing further scaling in an RSVP-TE MPLS network, particularly where the network is designed to provide RSVP-TE connectivity to the edges. This is the case for envisioned MPLS-TP networks. The use of the MPLS PSC hierarchy can add at least one additional label to a label stack, though it is likely that only one layer of PSC will be used in the near future.
MPLS階層は[RFC4206]で定義され、[RFC7074]によって更新されます。 RFC 4206はGMPLSの一部と見なされていますが、MPLS階層のパケットスイッチング機能（PSC）の部分はMPLSに適用可能であり、それ以外の場合はGMPLSフリーの実装でサポートされる場合があります。 MPLS PSC階層は、特にネットワークがエッジへのRSVP-TE接続を提供するように設計されている場合に、RSVP-TE MPLSネットワークでさらにスケーリングを提供する最も可能性の高い手段であり続けます。これは、想定されるMPLS-TPネットワークの場合です。 MPLS PSC階層を使用すると、少なくとも1つの追加ラベルをラベルスタックに追加できますが、近い将来、PSCの1つの層のみが使用される可能性があります。
Fast reroute is defined by [RFC4090]. Two significantly different methods are defined in RFC 4090: the "One-to-One Backup" method, which uses the "Detour LSP", and the "Facility Backup", which uses a "bypass tunnel". These are commonly referred to as the detour and bypass methods, respectively.
高速リルートは[RFC4090]で定義されています。 RFC 4090では、大きく異なる2つの方法が定義されています。「迂回LSP」を使用する「1対1バックアップ」方法と、「バイパストンネル」を使用する「施設バックアップ」です。これらは一般に、それぞれ迂回法と迂回法と呼ばれます。
The detour method makes use of a presignaled LSP. Hardware assistance may be needed for detour FRR in order to accomplish local repair of a large number of LSPs within the target of tens of milliseconds. For each affected LSP, a swap operation must be reprogrammed or otherwise switched over. The use of detour FRR doubles the number of LSPs terminating at any given hop and will increase the number of LSPs within a network by a factor dependent on the average detour path length.
迂回方式では、事前シグナリングされたLSPを使用します。数十ミリ秒という目標内で多数のLSPをローカルで修復するために、迂回FRRのハードウェア支援が必要になる場合があります。影響を受けるLSPごとに、スワップ操作を再プログラムするか、別の方法で切り替える必要があります。迂回FRRを使用すると、任意のホップで終端するLSPの数が2倍になり、平均迂回パス長に依存する係数によってネットワーク内のLSPの数が増加します。
The bypass method makes use of a tunnel that is unused when no fault exists but may carry many LSPs when a local repair is required. There is no presignaling indicating which working LSP will be diverted into any specific bypass LSP. If interface label space is used, the bypass LSP MUST extend one hop beyond the merge point, except if the merge point is the egress and PHP is used. If the bypass LSPs are not extended in this way, then the merge LSR (egress LSR of the bypass LSP) MUST use platform label space (as defined in [RFC3031]) so that an LSP working path on any given interface can be backed up using a bypass LSP terminating on any other interface. Hardware assistance may be needed to accomplish local repair of a large number of LSPs within the target of tens of milliseconds. For each affected LSP a swap operation must be reprogrammed or otherwise switched over with an additional push of the bypass LSP label. The use of platform label space impacts the size of the LSR ILM for an LSR with a very large number of interfaces.
バイパス方式は、障害が存在しない場合は使用されないが、ローカルでの修復が必要な場合に多くのLSPを伝送する可能性があるトンネルを利用します。どの現用LSPが特定のバイパスLSPに転送されるかを示す事前シグナリングはありません。インターフェイスラベルスペースが使用されている場合、バイパスLSPは、マージポイントが出力でPHPが使用されている場合を除いて、マージポイントを1ホップ超えて拡張する必要があります。バイパスLSPがこの方法で拡張されていない場合、マージLSR（バイパスLSPの出力LSR）はプラットフォームラベルスペース（[RFC3031]で定義されている）を使用して、特定のインターフェイスのLSP作業パスをバックアップできるようにする必要があります他のインターフェイスで終端するバイパスLSPを使用する。数十ミリ秒という目標内で多数のLSPをローカルで修復するには、ハードウェアの支援が必要になる場合があります。影響を受けるLSPごとに、スワップ操作を再プログラムするか、バイパスLSPラベルの追加プッシュで別の方法で切り替える必要があります。プラットフォームラベルスペースの使用は、非常に多数のインターフェイスを持つLSRのLSR ILMのサイズに影響します。
IP/LDP Fast Reroute (IP/LDP FRR) [RFC5714] is also applicable in MPLS networks. ECMP and Loop-Free Alternates (LFAs) [RFC5286] are well-established IP/LDP FRR techniques and were the first methods to be widely deployed. Work on IP/LDP FRR is ongoing within the IETF RTGWG. Two topics actively discussed in RTGWG are microloops and partial coverage of the established techniques in some network topologies. [RFC5715] covers the topic of IP/LDP Fast Reroute microloops and microloop prevention. RTGWG has developed additional IP/LDP FRR techniques to handle coverage concerns. RTGWG is extending LFA through the use of remote LFA [REMOTE-LFA]. Other techniques that require new forwarding paths to be established are also under consideration, including the IPFRR "not-via" technique defined in [RFC6981] and maximally redundant trees (MRT) [MRT]. ECMP, LFA (but not remote LFA), and MRT swap the top label to an alternate MPLS label. The other methods operate in a similar manner to the facility backup described in RFC 4090 and push an additional label. IP/LDP FRR methods that push more than one label have been suggested but are in early discussion.
IP / LDP高速リルート（IP / LDP FRR）[RFC5714]は、MPLSネットワークにも適用できます。 ECMPとループフリー代替（LFA）[RFC5286]は、確立されたIP / LDP FRR技術であり、広く展開された最初の方法でした。 IP / LDP FRRに関する作業はIETF RTGWG内で進行中です。 RTGWGで活発に議論されている2つのトピックは、マイクロループと、一部のネットワークトポロジで確立された技術の部分的なカバーです。 [RFC5715]は、IP / LDP Fast Rerouteマイクロループとマイクロループ防止のトピックをカバーしています。 RTGWGは、カバレッジの問題を処理するために、追加のIP / LDP FRR技術を開発しました。 RTGWGは、リモートLFA [REMOTE-LFA]を使用してLFAを拡張しています。 [RFC6981]で定義されているIPFRR "not-via"手法や最大冗長ツリー（MRT）[MRT]など、新しい転送パスの確立を必要とする他の手法も検討中です。 ECMP、LFA（リモートLFAではない）、およびMRTは、トップラベルを代替MPLSラベルにスワップします。他の方法は、RFC 4090で説明されているファシリティバックアップと同様に動作し、追加のラベルをプッシュします。複数のラベルをプッシュするIP / LDP FRRメソッドが提案されていますが、初期の議論の段階です。
The pseudowire (PW) architecture is defined in [RFC3985]. A pseudowire, when carried over MPLS, adds one or more additional label entries to the MPLS label stack. A PW Control Word is defined in [RFC4385] with motivation for defining the Control Word in [RFC4928]. The PW Associated Channel defined in [RFC4385] is used for OAM in [RFC5085]. The PW Flow Label is defined in [RFC6391] and is discussed further in this document in Section 2.4.3.
疑似配線（PW）アーキテクチャは、[RFC3985]で定義されています。疑似配線は、MPLSを介して伝送されると、1つ以上の追加のラベルエントリをMPLSラベルスタックに追加します。 PW制御ワードは[RFC4385]で定義されており、[RFC4928]で制御ワードを定義する動機があります。 [RFC4385]で定義されたPW関連チャネルは、[RFC5085]のOAMに使用されます。 PWフローラベルは[RFC6391]で定義されており、このドキュメントのセクション2.4.3で詳しく説明されています。
There are numerous pseudowire encapsulations, supporting emulation of services such as Frame Relay, ATM, Ethernet, TDM, and SONET/SDH over packet switched networks (PSNs) using IP or MPLS.
多数の疑似配線カプセル化があり、フレームリレー、ATM、イーサネット、TDM、およびIPまたはMPLSを使用したパケット交換ネットワーク（PSN）上のSONET / SDHなどのサービスのエミュレーションをサポートしています。
The pseudowire encapsulation is out of scope for this document. Pseudowire impact on MPLS forwarding at the midpoint LSR is within scope. The impact on ingress MPLS push and egress MPLS UHP pop are within scope. While pseudowire encapsulation is out of scope, some advice is given on Sequence Number support.
疑似配線のカプセル化は、このドキュメントの範囲外です。ミッドポイントLSRでのMPLS転送に対する疑似配線の影響は範囲内です。入力MPLSプッシュと出力MPLS UHPポップへの影響は範囲内です。疑似配線のカプセル化は範囲外ですが、シーケンス番号のサポートについていくつかアドバイスがあります。
Pseudowire (PW) Sequence Number support is most important for PW payload types with a high expectation of lossless and/or in-order delivery. Identifying lost PW packets and the exact amount of lost payload is critical for PW services that maintain bit timing, such as Time Division Multiplexing (TDM) services since these services MUST compensate lost payload on a bit-for-bit basis.
疑似配線（PW）シーケンス番号のサポートは、無損失および/または順序正しい配信が期待されるPWペイロードタイプにとって最も重要です。失われたPWパケットと失われたペイロードの正確な量を特定することは、時分割多重（TDM）サービスなどのビットタイミングを維持するPWサービスにとって重要です。これらのサービスは失われたペイロードをビット単位で補償する必要があるためです。
With PW services that maintain bit timing, packets that have been received out of order also MUST be identified and MAY be either reordered or dropped. Resequencing requires, in addition to sequence numbering, a "reorder buffer" in the egress PE, and the ability to reorder is limited by the depth of this buffer. The down side of maintaining a large reorder buffer is added end-to-end service delay.
ビットタイミングを維持するPWサービスでは、順不同で受信されたパケットも識別されなければならず（MUST）、並べ替えまたはドロップされる場合があります。リシーケンスには、シーケンス番号付けに加えて、出力PEに「リオーダーバッファー」が必要です。リオーダーする機能は、このバッファーの深さによって制限されます。大きなリオーダーバッファーを維持することのマイナス面は、エンドツーエンドのサービス遅延が追加されることです。
For PW services that maintain bit timing or any other service where jitter must be bounded, a jitter buffer is always necessary. The jitter buffer is needed regardless of whether reordering is done. In order to be effective, a reorder buffer must often be larger than a jitter buffer needs to be, thus creating a tradeoff between reducing loss and minimizing delay.
ビットタイミングを維持するPWサービス、またはジッターを制限する必要があるその他のサービスの場合、ジッターバッファーは常に必要です。リオーダーが行われるかどうかに関係なく、ジッタバッファが必要です。効果的にするために、リオーダーバッファーは、ジッターバッファーよりも大きくなければならないことが多く、損失の削減と遅延の最小化の間にトレードオフが生じます。
PW services that are not timing critical bit streams in nature are cell oriented or frame oriented. Though resequencing support may be beneficial to PW cell- and frame-oriented payloads such as ATM, FR, and Ethernet, this support is desirable but not required. Requirements to handle out-of-order packets at all vary among services and deployments. For example, for Ethernet PW, occasional (very rare) reordering is usually acceptable. If the Ethernet PW is carrying MPLS-TP, then this reordering may be acceptable.
本質的にタイミングクリティカルなビットストリームではないPWサービスは、セル指向またはフレーム指向です。リシーケンスのサポートは、ATM、FR、イーサネットなどのPWセルおよびフレーム指向のペイロードにとって有益な場合がありますが、このサポートは望ましいですが、必須ではありません。順不同のパケットを処理するための要件は、サービスや展開によって異なります。たとえば、イーサネットPWの場合、通常、時々（非常にまれな）並べ替えが許容されます。イーサネットPWがMPLS-TPを伝送している場合、この順序変更は受け入れられる可能性があります。
Reducing jitter is best done by an end-system, given that the tradeoff of loss vs. delay varies among services. For example, with interactive real-time services, low delay is preferred, while with non-interactive (one-way) real-time services, low loss is preferred. The same end-site may be receiving both types of traffic. Regardless of this, bounded jitter is sometimes a requirement for specific deployments.
損失と遅延のトレードオフがサービス間で異なることを考えると、ジッタの低減はエンドシステムで行うのが最適です。たとえば、インタラクティブなリアルタイムサービスでは低遅延が優先され、非インタラクティブ（一方向）リアルタイムサービスでは低損失が優先されます。同じエンドサイトが両方のタイプのトラフィックを受信している可能性があります。これに関係なく、制限されたジッターは、特定の展開の要件になる場合があります。
Packet reordering should be rare except in a small number of circumstances, most of which are due to network design or equipment design errors:
少数の状況を除いて、パケットの並べ替えはまれであるはずです。そのほとんどは、ネットワーク設計または機器設計のエラーが原因です。
1. The most common case is where reordering is rare, occurring only when a network or equipment fault forces traffic on a new path with different delay. The packet loss that accompanies a network or equipment fault is generally more disruptive than any reordering that may occur.
1. 最も一般的なケースは、再順序付けがまれであり、ネットワークまたは機器の障害が異なるパスで新しいパス上のトラフィックを強制した場合にのみ発生します。ネットワークまたは機器の障害に伴うパケット損失は、通常、発生する可能性のある並べ替えよりも破壊的です。
2. A path change can be caused by reasons other than a network or equipment fault, such as an administrative routing change. This may result in packet reordering but generally without any packet loss.
2. パスの変更は、管理ルーティングの変更など、ネットワークまたは機器の障害以外の理由で発生する可能性があります。これにより、パケットの並べ替えが発生する可能性がありますが、通常はパケットの損失はありません。
3. If the edge is not using pseudowire Control Word (CW) and the core is using multipath, reordering will be far more common. If this is occurring, using CW on the edge will solve the problem. Without CW, resequencing is not possible since the Sequence Number is contained in the CW.
3. エッジが疑似配線制御ワード（CW）を使用しておらず、コアがマルチパスを使用している場合は、並べ替えがはるかに一般的です。これが発生している場合は、エッジでCWを使用すると問題が解決します。 CWがないと、シーケンス番号がCWに含まれているため、再シーケンスはできません。
4. Another avoidable case is where some core equipment has multipath and for some reason insists on periodically installing a new random number as the multipath hash seed. If supporting MPLS-TP, equipment MUST provide a means to disable periodic hash reseeding, and deployments MUST disable periodic hash reseeding. Operator experience dictates that even if not supporting MPLS-TP, equipment SHOULD provide a means to disable periodic hash reseeding, and deployments SHOULD disable periodic hash reseeding.
4. 別の回避可能なケースは、一部のコア機器にマルチパスがあり、何らかの理由で定期的に新しい乱数をマルチパスハッシュシードとしてインストールすることを要求する場合です。 MPLS-TPをサポートする場合、機器は定期的なハッシュの再シードを無効にする手段を提供する必要があり、展開は定期的なハッシュの再シードを無効にする必要があります。オペレーターの経験では、MPLS-TPをサポートしていない場合でも、機器は定期的なハッシュの再シードを無効にする手段を提供する必要があり（SHOULD）、展開は定期的なハッシュの再シードを無効にする必要があります（SHOULD）。
In provider networks that use multipath techniques and that may occasionally rebalance traffic or that may change PW paths occasionally for other reasons, reordering may be far more common than loss. Where reordering is more common than loss, resequencing packets is beneficial, rather than dropping packets at egress when out-of-order arrival occurs. Resequencing is most important for PW payload types with a high expectation of lossless delivery since in such cases out-of-order delivery within the network results in PW loss.
マルチパス技術を使用し、トラフィックを再調整する場合や、他の理由でPWパスを変更する場合があるプロバイダーネットワークでは、損失よりも並べ替えの方がはるかに一般的です。順序の変更が損失よりも一般的である場合、順序が乱れた到着が発生したときに出力でパケットをドロップするよりも、パケットの順序を変更する方が有益です。再シーケンスは、ロスレス配信が期待されるPWペイロードタイプの場合に最も重要です。このような場合、ネットワーク内の順序が乱れた配信はPW損失を引き起こすためです。
Layer 2 VPN [RFC4664] and Layer 3 VPN [RFC4110] add one or more label entry to the MPLS label stack. VPN encapsulations are out of scope for this document. Their impact on forwarding at the midpoint LSR are within scope.
レイヤー2 VPN [RFC4664]およびレイヤー3 VPN [RFC4110]は、1つ以上のラベルエントリをMPLSラベルスタックに追加します。 VPNカプセル化は、このドキュメントの範囲外です。ミッドポイントLSRでの転送への影響は範囲内です。
Any of these services may be used on an ingress and egress that are MPLS Entropy Label enabled (see Section 2.4.4 for discussion of Entropy Label); this would add an additional two labels to the MPLS label stack. The need to provide a useful Entropy Label value impacts the requirements of the VPN ingress LER but is out of scope for this document.
これらのサービスはいずれも、MPLSエントロピーラベルが有効になっている入口と出口で使用できます（エントロピーラベルの説明については、セクション2.4.4を参照してください）。これにより、MPLSラベルスタックに2つのラベルが追加されます。有用なエントロピーラベル値を提供する必要性は、VPN入力LERの要件に影響を与えますが、このドキュメントの範囲外です。
MPLS Multicast encapsulation is clarified in [RFC5332]. MPLS Multicast may be signaled using RSVP-TE [RFC4875] or LDP [RFC6388].
MPLSマルチキャストのカプセル化は、[RFC5332]で明確にされています。 MPLSマルチキャストは、RSVP-TE [RFC4875]またはLDP [RFC6388]を使用してシグナリングできます。
[RFC4875] defines a root-initiated RSVP-TE LSP setup rather than the leaf-initiated join used in IP multicast. [RFC6388] defines a leaf-initiated LDP setup. Both [RFC4875] and [RFC6388] define point-to-multipoint (P2MP) LSP setup. [RFC6388] also defined multipoint-to-multipoint (MP2MP) LSP setup.
[RFC4875]は、IPマルチキャストで使用されるリーフ開始結合ではなく、ルート開始RSVP-TE LSPセットアップを定義します。 [RFC6388]は、リーフで開始されるLDPセットアップを定義します。 [RFC4875]と[RFC6388]はどちらも、ポイントツーマルチポイント（P2MP）LSPセットアップを定義しています。 [RFC6388]は、マルチポイントツーマルチポイント（MP2MP）LSPセットアップも定義しました。
The P2MP LSPs have a single source. An LSR may be a leaf node, an intermediate node, or a "bud" node. A bud serves as both a leaf and intermediate. At a leaf, an MPLS pop is performed. The payload may be an IP multicast packet that requires further replication. At an intermediate node, an MPLS swap operation is performed. The bud requires that both a pop operation and a swap operation be performed for the same incoming packet.
P2MP LSPには単一のソースがあります。 LSRは、リーフノード、中間ノード、または「バッド」ノードの場合があります。つぼみは葉と中間物の両方として機能します。リーフでは、MPLSポップが実行されます。ペイロードは、さらに複製が必要なIPマルチキャストパケットである可能性があります。中間ノードでは、MPLSスワップ操作が実行されます。バッドは、同じ着信パケットに対してポップ操作とスワップ操作の両方を実行する必要があります。
One strategy to support P2MP functionality is to pop at the LSR interface serving as ingress to the P2MP traffic and then optionally push labels at each LSR interface serving as egress to the P2MP traffic at that same LSR. A given LSR egress chip may support multiple egress interfaces, each of which requires a copy, but each with a different set of added labels and Layer 2 encapsulation. Some physical interfaces may have multiple sub-interfaces (such as Ethernet VLAN or channelized interfaces), each requiring a copy.
P2MP機能をサポートする1つの戦略は、P2MPトラフィックへの入力として機能するLSRインターフェイスをポップし、オプションで、同じLSRでP2MPトラフィックへの出力として機能する各LSRインターフェイスでラベルをプッシュすることです。特定のLSR出力チップは、複数の出力インターフェイスをサポートする場合があります。各出力インターフェイスにはコピーが必要ですが、それぞれに追加されたラベルのセットとレイヤー2カプセル化が異なります。一部の物理インターフェイスには複数のサブインターフェイス（イーサネットVLANやチャネライズドインターフェイスなど）があり、それぞれにコピーが必要です。
If packet replication is performed at LSR ingress, then the ingress interface performance may suffer. If the packet replication is performed within a LSR switching fabric and at LSR egress, congestion of egress interfaces cannot make use of backpressure to ingress interfaces using techniques such as virtual output queuing (VOQ). If buffering is primarily supported at egress, then the need for backpressure is minimized. There may be no good solution for high volumes of multicast traffic if VOQ is used.
パケット複製がLSR入力で実行されると、入力インターフェイスのパフォーマンスが低下する可能性があります。パケット複製がLSRスイッチングファブリック内およびLSR出力で実行される場合、出力インターフェイスの輻輳は、仮想出力キューイング（VOQ）などの手法を使用して入力インターフェイスへのバックプレッシャーを利用できません。バッファリングが主に出力でサポートされている場合、バックプレッシャーの必要性は最小限に抑えられます。 VOQを使用する場合、大量のマルチキャストトラフィックに適したソリューションはありません。
Careful consideration should be given to the performance characteristics of high-fanout multicast for equipment that is intended to be used in such a role.
このような役割で使用することを目的とした機器の高ファンアウトマルチキャストのパフォーマンス特性については、慎重に検討する必要があります。
MP2MP LSPs differ in that any branch may provide an input, including a leaf. Packets must be replicated onto all other branches. This forwarding is often implemented as multiple P2MP forwarding trees, one for each potential input interface at a given LSR.
MP2MP LSPは、どのブランチもリーフを含む入力を提供できるという点で異なります。パケットは他のすべてのブランチに複製する必要があります。この転送は、多くの場合、複数のP2MP転送ツリーとして実装されます。指定されたLSRの潜在的な入力インターフェイスごとに1つです。
While average packet size of Internet traffic may be large, long sequences of small packets have both been predicted in theory and observed in practice. Traffic compression and TCP ACK compression can conspire to create long sequences of packets of 40-44 bytes in payload length. If carried over Ethernet, the 64-byte minimum payload applies, yielding a packet rate of approximately 150 Mpps (million packets per second) for the duration of the burst on a nominal 100 Gb/s link. The peak rate for other encapsulations can be as high as 250 Mpps (for example, when IP or MPLS is encapsulated using GFP over OTN ODU4).
インターネットトラフィックの平均パケットサイズは大きくなる可能性がありますが、小さなパケットの長いシーケンスが理論的に予測され、実際に観察されています。トラフィック圧縮とTCP ACK圧縮により、ペイロード長が40〜44バイトのパケットの長いシーケンスが作成される可能性があります。イーサネットを介して伝送される場合、64バイトの最小ペイロードが適用され、公称100 Gb / sリンクでのバースト期間中、約150 Mpps（100万パケット/秒）のパケットレートが生成されます。他のカプセル化のピークレートは250 Mppsにもなる可能性があります（たとえば、IPまたはMPLSがGFP over OTN ODU4を使用してカプセル化されている場合）。
It is possible that the packet rates achieved by a specific implementation are acceptable for a minimum payload size, such as a 64-byte (64B) payload for Ethernet, but the achieved rate declines to an unacceptable level for other packet sizes, such as a 65B payload. There are other packet rates of interest besides TCP ACK. For example, a TCP ACK carried over an Ethernet PW over MPLS over Ethernet may occupy 82B or 82B plus an increment of 4B if additional MPLS labels are present.
特定の実装によって達成されたパケットレートは、イーサネットの64バイト（64B）ペイロードなどの最小ペイロードサイズでは許容可能ですが、達成されたレートは、その他のパケットサイズでは許容できないレベルまで低下します。 65Bペイロード。 TCP ACK以外にも、関心のある他のパケットレートがあります。たとえば、追加のMPLSラベルが存在する場合、イーサネットPW over MPLS over Ethernetで伝送されるTCP ACKは、82Bまたは82Bに4Bの増分を加えたものになる可能性があります。
A graph of packet rate vs. packet size often displays a sawtooth. The sawtooth is commonly due to a memory bottleneck and memory widths, sometimes an internal cache, but often a very wide external buffer memory interface. In some cases, it may be due to a fabric transfer width. A fine packing, rounding up to the nearest 8B or 16B will result in a fine sawtooth with small degradation for 65B, and even less for 82B packets. A coarse packing, rounding up to 64B can yield a sharper drop in performance for 65B packets, or perhaps more important, a larger drop for 82B packets.
パケットレートとパケットサイズのグラフには、のこぎり波が表示されることがよくあります。ノコギリ波は一般に、メモリのボトルネックとメモリの幅、時には内部キャッシュによるものですが、多くの場合非常に広い外部バッファメモリインターフェイスが原因です。生地の移り幅が原因の場合もございます。細かいパッキング、最も近い8Bまたは16Bに切り上げると、細かい鋸歯状になり、65Bの場合は劣化が小さく、82Bパケットの場合はさらに劣化します。 64Bに切り上げる粗いパッキングは、65Bパケットのパフォーマンスをより急激に低下させる可能性があります。あるいは、82Bパケットの場合は、より大きな低下をもたらす可能性があります。
The loss of some TCP ACK packets are not the primary concern when such a burst occurs. When a burst occurs, any other packets, regardless of packet length and packet QoS are dropped once on-chip input buffers prior to the decision engine are exceeded. Buffers in front of the packet decision engine are often very small or nonexistent (less than one packet of buffer) causing significant QoS-agnostic packet drop.
このようなバーストが発生した場合、一部のTCP ACKパケットの損失は主要な問題ではありません。バーストが発生すると、決定エンジンの前のオンチップ入力バッファーを超えると、パケット長やパケットQoSに関係なく、他のパケットはすべてドロップされます。多くの場合、パケット決定エンジンの前にあるバッファーは非常に小さいか、存在せず（バッファーの1パケット未満）、QoSに依存しない大きなパケットドロップが発生します。
Internet service providers and content providers at one time specified full rate forwarding with 40-byte payload packets as a requirement. Today, this requirement often can be waived if the provider can be convinced that when long sequences of short packets occur no packets will be dropped.
インターネットサービスプロバイダーとコンテンツプロバイダーは、40バイトのペイロードパケットを要件としてフルレート転送を一度に指定しました。今日、短いパケットの長いシーケンスが発生してもパケットはドロップされないことをプロバイダーが確信できれば、この要件はしばしば放棄されます。
Many equipment suppliers have pointed out that the extra cost in designing hardware capable of processing the minimum size packets at full line rate is significant for very-high-speed interfaces. If hardware is not capable of processing the minimum size packets at full line rate, then that hardware MUST be capable of handling large bursts of small packets, a condition that is often observed. This level of performance is necessary to meet Differentiated Services [RFC2475] requirements; without it, packets are lost prior to inspection of the IP DSCP field [RFC2474] or MPLS TC field [RFC5462].
多くの機器サプライヤは、フルラインレートで最小サイズのパケットを処理できるハードウェアを設計するための追加コストが非常に高速なインターフェイスでは重要であることを指摘しています。ハードウェアが最小サイズのパケットをフルラインレートで処理できない場合、そのハードウェアは小さなパケットの大きなバーストを処理できる必要があり、これはよく見られる状態です。このレベルのパフォーマンスは、差別化サービス[RFC2475]の要件を満たすために必要です。これがないと、IP DSCPフィールド[RFC2474]またはMPLS TCフィールド[RFC5462]を検査する前にパケットが失われます。
With adequate on-chip buffers before the packet decision engine, an LSR can absorb a long sequence of short packets. Even if the output is slowed to the point where light congestion occurs, the packets, having cleared the decision process, can make use of larger VOQ or output side buffers and be dealt with according to configured QoS treatment, rather than dropped completely at random.
パケット決定エンジンの前に適切なオンチップバッファーがあるため、LSRは長いパケットの短いシーケンスを吸収できます。軽い輻輳が発生するまで出力が遅くなった場合でも、決定プロセスをクリアしたパケットは、ランダムに完全にドロップされるのではなく、より大きなVOQまたは出力側のバッファーを利用して、構成されたQoS処理に従って処理できます。
The buffering before the packet decision engine should be arranged such that 1) it can hold a relatively large number of small packets, 2) it can hold a small number of large packets, and 3) it can hold a mix of packets of different sizes.
パケット決定エンジンの前のバッファリングは、1）比較的多数の小さなパケットを保持できる、2）少数の大きなパケットを保持できる、3）異なるサイズのパケットの混合を保持できるように配置する必要があります。 。
These on-chip buffers need not contribute significant delay since they are only used when the packet decision engine is unable to keep up, not in response to congestion, plus these buffers are quite small. For example, an on-chip buffer capable of handling 4K packets of 64 bytes in length, or 256KB, corresponds to 200 microseconds on a 10 Gb/s link and 20 microseconds on a 100 Gb/s link. If the packet decision engine is capable of handling packets at 90% of the full rate for small packets, then the maximum added delay is 20 microseconds and 2 microseconds, respectively, and this delay only applies if a 4K burst of short packets occurs. When no burst of short packets was being processed, no delay is added. These buffers are only needed on high-speed interfaces where it is difficult to process small packets at full line rate.
これらのオンチップバッファーは、輻輳に対応せずにパケット決定エンジンが追いつけない場合にのみ使用されるため、大幅な遅延の原因となる必要はなく、これらのバッファーは非常に小さいです。たとえば、長さが64バイト、つまり256KBの4Kパケットを処理できるオンチップバッファーは、10 Gb / sリンクで200マイクロ秒、100 Gb / sリンクで20マイクロ秒に対応します。パケット決定エンジンが小さいパケットのフルレートの90％でパケットを処理できる場合、追加される最大遅延はそれぞれ20マイクロ秒と2マイクロ秒であり、この遅延は短いパケットの4Kバーストが発生した場合にのみ適用されます。短いパケットのバーストが処理されていなかった場合、遅延は追加されません。これらのバッファは、小さなパケットをフルラインレートで処理することが困難な高速インターフェイスでのみ必要です。
Packet rate requirements apply regardless of which network tier the equipment is deployed in. Whether deployed in the network core or near the network edges, one of the two conditions MUST be met if Differentiated Services requirements are to be met:
パケットレートの要件は、機器が配置されているネットワーク層に関係なく適用されます。ネットワークコアに配置されているか、ネットワークエッジの近くに配置されているかにかかわらず、差別化サービスの要件を満たすには、次の2つの条件のいずれかを満たす必要があります。
1. Packets must be processed at full line rate with minimum-sized packets. -OR-
1. パケットは、最小サイズのパケットでフルラインレートで処理する必要があります。 -または-
2. Packets must be processed at a rate well under generally accepted average packet sizes, with sufficient buffering prior to the packet decision engine to accommodate long bursts of small packets.
2. パケットは、一般に受け入れられている平均パケットサイズを十分に下回る速度で処理する必要があり、パケット決定エンジンの前に十分なバッファリングを行って、小さなパケットの長いバーストに対応する必要があります。
In any large provider, service providers, and content providers, hash-based multipath techniques are used in the core and in the edge. In many of these providers, hash-based multipath is also used in the larger metro networks.
大規模なプロバイダー、サービスプロバイダー、コンテンツプロバイダーでは、ハッシュベースのマルチパス技術がコアとエッジで使用されています。これらのプロバイダーの多くでは、ハッシュベースのマルチパスが大規模なメトロネットワークでも使用されています。
For good reason, the Differentiated Services requirements dictate that packets within a common microflow SHOULD NOT be reordered [RFC2474]. Service providers generally impose stronger requirements, commonly requiring that packets within a microflow MUST NOT be reordered except in rare circumstances such as load balancing across multiple links, path change for load balancing, or path change for other reason.
正当な理由により、Differentiated Servicesの要件により、共通のマイクロフロー内のパケットは並べ替えないでください[RFC2474]。サービスプロバイダーは通常、より強い要件を課します。通常、複数のリンク間でのロードバランシング、ロードバランシングのためのパスの変更、またはその他の理由によるパスの変更などのまれな状況を除いて、マイクロフロー内のパケットを並べ替えてはなりません。
The most common multipath techniques are ECMP applied at the IP forwarding level, Ethernet Link Aggregation Group (LAG) with inspection of the IP payload, and multipath on links carrying both IP and MPLS, where the IP header is inspected below the MPLS label stack. In most core networks, the vast majority of traffic is MPLS encapsulated.
最も一般的なマルチパス技術は、IP転送レベルで適用されるECMP、IPペイロードを検査するイーサネットリンク集約グループ（LAG）、およびIPヘッダーがMPLSラベルスタックの下で検査されるIPとMPLSの両方を伝送するリンク上のマルチパスです。ほとんどのコアネットワークでは、トラフィックの大部分はMPLSカプセル化されています。
In order to support an adequately balanced load distribution across multiple links, IP header information must be used. Common practice today is to reinspect the IP headers at each LSR and use the label stack and IP header information in a hash performed at each LSR. Further details are provided in Section 2.4.5.
複数のリンク間で適切にバランスのとれた負荷分散をサポートするには、IPヘッダー情報を使用する必要があります。今日の一般的な方法は、各LSRでIPヘッダーを再検査し、各LSRで実行されるハッシュでラベルスタックとIPヘッダー情報を使用することです。詳細については、セクション2.4.5を参照してください。
The use of this technique is so ubiquitous in provider networks that lack of support for multipath makes any product unsuitable for use in large core networks. This will continue to be the case in the near future, even as deployment of the MPLS Entropy Label begins to relax the core LSR multipath performance requirements given the existing deployed base of edge equipment without the ability to add an Entropy Label.
この手法の使用はプロバイダーネットワークで広く利用されているため、マルチパスのサポートが不足しているため、大規模なコアネットワークでの使用には不適切な製品になります。 MPLSエントロピーラベルの展開が、エントロピーラベルを追加する機能のない既存の展開されたエッジ機器ベースを前提として、コアLSRマルチパスパフォーマンス要件を緩和し始めたとしても、これは近い将来にも当てはまります。
A generation of edge equipment supporting the ability to add an MPLS Entropy Label is needed before the performance requirements for core LSRs can be relaxed. However, it is likely that two generations of deployment in the future will allow core LSRs to support full packet rate only when a relatively small number of MPLS labels need to be inspected before hashing. For now, don't count on it.
コアLSRのパフォーマンス要件を緩和する前に、MPLSエントロピーラベルを追加する機能をサポートするエッジ機器の世代が必要です。ただし、将来の2世代の展開では、ハッシュ前に比較的少数のMPLSラベルを検査する必要がある場合にのみ、コアLSRがフルパケットレートをサポートできるようになる可能性があります。今のところ、それを当てにしないでください。
Common practice today is to reinspect the packet at each LSR and use information from the packet combined with a hash seed that is selected by each LSR. Where Flow Labels or Entropy Labels are used, a hash seed must be used when creating these labels.
今日の一般的な方法は、各LSRでパケットを再検査し、各LSRによって選択されたハッシュシードと組み合わせたパケットからの情報を使用することです。フローラベルまたはエントロピーラベルが使用される場合、これらのラベルを作成するときにハッシュシードを使用する必要があります。
Within the core of a network, some form of multipath is almost certain to be used. Multipath techniques deployed today are likely to be looking beneath the label stack for an opportunity to hash on IP addresses.
ネットワークの中核では、何らかの形のマルチパスが使用されることがほぼ確実です。今日展開されているマルチパス技術は、IPアドレスをハッシュする機会を探すために、ラベルスタックの下を見ている可能性があります。
A pseudowire encapsulated at a network edge must have a means to prevent reordering within the core if the pseudowire will be crossing a network core, or any part of a network topology where multipath is used (see [RFC4385] and [RFC4928]).
ネットワークエッジでカプセル化された疑似配線は、疑似配線がネットワークコア、またはマルチパスが使用されるネットワークトポロジの一部を横断する場合に、コア内での並べ替えを防ぐ手段が必要です（[RFC4385]および[RFC4928]を参照）。
Not supporting the ability to encapsulate a pseudowire with a Control Word may lock a product out from consideration. A pseudowire capability without Control Word support might be sufficient for applications that are strictly both intra-metro and low bandwidth. However, a provider with other applications will very likely not tolerate having equipment that can only support a subset of their pseudowire needs.
コントロールワードを使用して疑似配線をカプセル化する機能をサポートしないと、製品が検討対象から除外される可能性があります。厳密にメトロ内と低帯域幅の両方であるアプリケーションには、コントロールワードのサポートがない疑似配線機能で十分な場合があります。ただし、他のアプリケーションを使用するプロバイダーは、疑似配線のニーズのサブセットのみをサポートできる機器を使用することを許容しない可能性が非常に高くなります。
Where multipath makes use of a simple hash and simple load balance such as modulo or other fixed allocation (see Section 2.4), there can be the presence of large microflows that each consume 10% of the capacity of a component link of a potentially congested composite link. One such microflow can upset the traffic balance, and more than one can reduce the effective capacity of the entire composite link by more than 10%.
マルチパスが単純なハッシュとモジュロまたは他の固定割り当てなどの単純な負荷分散を使用する場合（セクション2.4を参照）、混雑する可能性のあるコンポジットのコンポーネントリンクの容量の10％をそれぞれ消費する大きなマイクロフローが存在する可能性があります。リンク。そのようなマイクロフローの1つはトラフィックバランスを混乱させる可能性があり、複数のフローは複合リンク全体の有効容量を10％以上減少させる可能性があります。
When even a very small number of large microflows are present, there is a significant probability that more than one of these large microflows could fall on the same component link. If the traffic contribution from large microflows is small, the probability for three or more large microflows on the same component link drops significantly. Therefore, in a network where a significant number of parallel 10 Gb/s links exists, even a 1 Gb/s pseudowire or other large microflow that could not otherwise be subdivided into smaller flows should carry a Flow Label or Entropy Label if possible.
非常に少数の大きなマイクロフローが存在する場合でも、これらの大きなマイクロフローが複数、同じコンポーネントリンクに分類される可能性がかなりあります。大きなマイクロフローによるトラフィックの寄与が小さい場合、同じコンポーネントリンクで3つ以上の大きなマイクロフローが発生する可能性は大幅に低下します。したがって、かなりの数の並列10 Gb / sリンクが存在するネットワークでは、1 Gb / s疑似配線または他の小さなフローに分割できない他の大きなマイクロフローであっても、可能であればフローラベルまたはエントロピーラベルを伝える必要があります。
Active management of the hash space to better accommodate large microflows has been implemented and deployed in the past; however, such techniques are out of scope for this document.
過去には、大規模なマイクロフローに適切に対応するためのハッシュスペースのアクティブ管理が実装および導入されています。ただし、このような手法はこのドキュメントの範囲外です。
Unlike a pseudowire Control Word, a pseudowire Flow Label [RFC6391] is required only for pseudowires that have a relatively large capacity. There are many cases where a pseudowire Flow Label makes sense. Any service such as a VPN that carries IP traffic within a pseudowire can make use of a pseudowire Flow Label.
疑似配線制御ワードとは異なり、疑似配線フローラベル[RFC6391]は、容量が比較的大きい疑似配線にのみ必要です。疑似配線のフローラベルが有効な場合が多くあります。疑似配線内でIPトラフィックを伝送するVPNなどのサービスは、疑似配線フローラベルを利用できます。
Any pseudowire carried over MPLS that makes use of the pseudowire Control Word and does not carry a Flow Label is in effect a single microflow (in the terms defined in [RFC2475]) and may result in the types of problems described in Section 2.4.2.
疑似配線制御ワードを使用し、フローラベルを含まないMPLSを介して転送される疑似配線は、事実上単一のマイクロフローであり（[RFC2475]で定義された用語）、2.4.2で説明されている種類の問題を引き起こす可能性があります。 。
The MPLS Entropy Label simplifies flow group identification [RFC6790] at midpoint LSRs. Prior to the MPLS Entropy Label, midpoint LSRs needed to inspect the entire label stack and often the IP headers to provide an adequate distribution of traffic when using multipath techniques (see Section 2.4.5). With the use of the MPLS Entropy Label, a hash can be performed closer to network edges, placed in the label stack, and used by midpoint LSRs without fully reinspecting the label stack and inspecting the payload.
MPLSエントロピーラベルは、中間点のLSRでのフローグループの識別[RFC6790]を簡素化します。 MPLSエントロピーラベルが導入される前は、ラベルスタック全体と多くの場合IPヘッダーを検査して、マルチパス技術を使用する場合にトラフィックを適切に分散させるために、ミッドポイントLSRが必要でした（セクション2.4.5を参照）。 MPLSエントロピーラベルを使用すると、ハッシュをネットワークエッジの近くで実行し、ラベルスタックに配置し、ラベルスタックを完全に再検査してペイロードを検査することなく、ミッドポイントLSRで使用できます。
The MPLS Entropy Label is capable of avoiding full label stack and payload inspection within the core where performance levels are most difficult to achieve (see Section 2.3). The label stack inspection can be terminated as soon as the first Entropy Label is encountered, which is generally after a small number of labels are inspected.
MPLSエントロピーラベルは、パフォーマンスレベルの達成が最も難しいコア内での完全なラベルスタックとペイロード検査を回避できます（セクション2.3を参照）。ラベルスタックの検査は、最初のエントロピーラベルが検出されるとすぐに終了できます。これは通常、少数のラベルが検査された後です。
In order to provide these benefits in the core, an LSR closer to the edge must be capable of adding an Entropy Label. This support may not be required in the access tier, the tier closest to the customer, but is likely to be required in the edge or the border to the network core. An LSR peering with external networks will also need to be able to add an Entropy Label on incoming traffic.
コアでこれらの利点を提供するには、エッジに近いLSRがエントロピーラベルを追加できる必要があります。このサポートは、顧客に最も近いアクセス層では必要ない場合がありますが、ネットワークコアのエッジまたは境界で必要になる可能性があります。外部ネットワークとのLSRピアリングも、着信トラフィックにエントロピーラベルを追加できる必要があります。
The most common multipath techniques are based on a hash over a set of fields. Regardless of whether a hash is used or some other method is used, there is a limited set of fields that can safely be used for multipath.
最も一般的なマルチパス技術は、一連のフィールドのハッシュに基づいています。ハッシュを使用するか他の方法を使用するかに関係なく、マルチパスに安全に使用できるフィールドのセットは限られています。
If the "outer" or "first" layer of encapsulation is MPLS, then label stack entries are used in the hash. Within a finite amount of time (and for small packets arriving at high speed, that time can be quite limited), only a finite number of label entries can be inspected. Pipelined or parallel architectures improve this, but the limit is still finite.
カプセル化の「外部」または「最初の」層がMPLSの場合、ラベルスタックエントリがハッシュで使用されます。有限の時間内（及び時間は非常に制限され得ることは、高速で到着小さなパケットのため）、ラベルエントリの唯一の有限数を検査することができます。パイプライン化や並列アーキテクチャは、これを改善するが、上限は、まだ有限です。
The following guidelines are provided for use of MPLS fields in multipath load balancing.
マルチパスロードバランシングでのMPLSフィールドの使用について、次のガイドラインが提供されています。
1. Only the 20-bit label field SHOULD be used. The TTL field SHOULD NOT be used. The S bit MUST NOT be used. The TC field (formerly EXP) MUST NOT be used. See text following this list for reasons.
1. 20ビットのラベルフィールドのみを使用する必要があります（SHOULD）。 TTLフィールドは使用しないでください。 Sビットは使用してはなりません（MUST NOT）。 TCフィールド（以前のEXP）は使用してはなりません（MUST NOT）。理由については、このリストに続くテキストを参照してください。
2. If an ELI label is found, then if the LSR supports Entropy Labels, the EL label field in the next label entry (the EL) SHOULD be used, label entries below that label SHOULD NOT be used, and the MPLS payload SHOULD NOT be used. See below this list for reasons.
2. ELIラベルが見つかった場合、LSRがエントロピーラベルをサポートしている場合、次のラベルエントリ（EL）のELラベルフィールドを使用する必要があります（SH）、そのラベルの下のラベルエントリは使用しないでください（SHOULD NOT）、MPLSペイロードは使用しないでください（SHOULD NOT） 。理由については、このリストの下を参照してください。
3. Special-purpose labels (label values 0-15) MUST NOT be used. Extended special-purpose labels (any label following label 15) MUST NOT be used. In particular, GAL and RA MUST NOT be used so that OAM traffic follows the same path as payload packets with the same label stack.
3. 特殊用途のラベル（ラベル値0〜15）は使用してはならない（MUST NOT）。拡張特殊用途ラベル（ラベル15に続くラベル）は使用してはなりません。特に、OALトラフィックが同じラベルスタックのペイロードパケットと同じパスをたどるように、GALおよびRAを使用してはなりません（MUST NOT）。
4. If a new special-purpose label or extended special-purpose label is defined that requires special load-balance processing, then, as is the case for the ELI label, a special action may be needed rather than skipping the special-purpose label or extended special-purpose label.
4. 特別な負荷分散処理を必要とする新しい専用ラベルまたは拡張専用ラベルが定義されている場合、ELIラベルの場合と同様に、専用ラベルまたは拡張ラベルをスキップするのではなく、特別なアクションが必要になる場合があります。専用ラベル。
5. The most entropy is generally found in the label stack entries near the bottom of the label stack (innermost label, closest to S=1 bit). If the entire label stack cannot be used (or entire stack up to an EL), then it is better to use as many labels as possible closest to the bottom of stack.
5. 最もエントロピーは通常、ラベルスタックの下部近くのラベルスタックエントリ（最も内側のラベル、S = 1ビットに最も近い）にあります。ラベルスタック全体（またはELまでのスタック全体）を使用できない場合は、スタックの一番下に最も近いラベルをできるだけ多く使用することをお勧めします。
6. If no ELI is encountered, and the first nibble of payload contains a 4 (IPv4) or 6 (IPv6), an implementation SHOULD support the ability to interpret the payload as IPv4 or IPv6 and extract and use appropriate fields from the IP headers. This feature is considered a nonnegotiable requirement by many service providers. If supported, there MUST be a way to disable it (if, for example, PW without CW are used). This ability to disable this feature is considered a nonnegotiable requirement by many service providers.
6. ELIが検出されず、ペイロードの最初のニブルに4（IPv4）または6（IPv6）が含まれている場合、実装はペイロードをIPv4またはIPv6として解釈し、IPヘッダーから適切なフィールドを抽出して使用する機能をサポートする必要があります。この機能は、多くのサービスプロバイダーによって交渉できない要件と見なされています。サポートされている場合、それを無効にする方法が必要です（たとえば、CWなしのPWが使用されている場合）。この機能を無効にするこの機能は、多くのサービスプロバイダーによって交渉できない要件と見なされています。
Therefore, an implementation has a very strong incentive to support both options.
したがって、実装には両方のオプションをサポートする非常に強いインセンティブがあります。
7. A label that is popped at egress (UHP pop) SHOULD NOT be used. A label that is popped at the penultimate hop (PHP pop) SHOULD be used.
7. 出口でポップされるラベル（UHP pop）は使用しないでください。最後から2番目のホップでポップされたラベル（PHPポップ）を使用する必要があります（SHOULD）。
Apparently, some chips have made use of the TC (formerly EXP) bits as a source of entropy. This is very harmful since it will reorder Assured Forwarding (AF) traffic [RFC2597] when a subset does not conform to the configured rates and is remarked but not dropped at a prior LSR. Traffic that uses MPLS ECN [RFC5129] can also be reordered if TC is used for entropy. Therefore, as stated in the guidelines above, the TC field (formerly EXP) MUST NOT be used in multipath load balancing as it violates Differentiated Services Ordered Aggregate (OA) requirements in these two instances.
明らかに、一部のチップはエントロピーのソースとしてTC（以前のEXP）ビットを使用しています。サブセットが設定されたレートに準拠せず、再マーキングされても前のLSRでドロップされない場合、Assured Forwarding（AF）トラフィック[RFC2597]を並べ替えるので、これは非常に有害です。エントロピーにTCが使用されている場合、MPLS ECN [RFC5129]を使用するトラフィックを並べ替えることもできます。したがって、上記のガイドラインで述べたように、TCフィールド（以前のEXP）は、これら2つのインスタンスでの差別化サービス注文集約（OA）要件に違反するため、マルチパスロードバランシングで使用してはなりません。
Use of the MPLS label entry S bit would result in putting OAM traffic on a different path if the addition of a GAL at the bottom of stack removed the S bit from the prior label.
スタックの最下部にGALを追加すると、前のラベルからSビットが削除された場合、MPLSラベルエントリのSビットを使用すると、OAMトラフィックが別のパスに配置されます。
If an ELI label is found, then if the LSR supports Entropy Labels, the EL label field in the next label entry (the EL) SHOULD be used, and the search for additional entropy within the packet SHOULD be terminated. Failure to terminate the search will impact client MPLS-TP LSPs carried within server MPLS LSPs. A network operator has the option to use administrative attributes as a means to identify LSRs that do not terminate the entropy search at the first EL. Administrative attributes are defined in [RFC3209]. Some configuration is required to support this.
ELIラベルが見つかった場合、LSRがエントロピーラベルをサポートしている場合、次のラベルエントリ（EL）のELラベルフィールドを使用する必要があり（SHOULD）、パケット内の追加のエントロピーの検索を終了する必要があります（SHOULD）。検索を終了しないと、サーバーMPLS LSP内で伝送されるクライアントMPLS-TP LSPに影響します。ネットワークオペレーターは、最初のELでエントロピー検索を終了しないLSRを識別する手段として管理属性を使用するオプションがあります。管理属性は[RFC3209]で定義されています。これをサポートするには、いくつかの構成が必要です。
If the label removed by a PHP pop is not used, then for any PW for which CW is used, there is no basis for multipath load split. In some networks, it is infeasible to put all PW traffic on one component link. Any PW that does not use CW will be improperly split, regardless of whether the label removed by a PHP pop is used. Therefore, the PHP pop label SHOULD be used as recommended above.
PHP popによって削除されたラベルが使用されていない場合、CWが使用されているPWについては、マルチパスロードスプリットの基礎がありません。一部のネットワークでは、すべてのPWトラフィックを1つのコンポーネントリンクに配置することが不可能です。 CWを使用しないPWは、PHPポップによって削除されたラベルが使用されているかどうかに関係なく、不適切に分割されます。したがって、上記で推奨されているように、PHPポップラベルを使用する必要があります。
Inspecting the IP payload provides the most entropy in provider networks. The practice of looking past the bottom of stack label for an IP payload is well accepted and documented in [RFC4928] and in other RFCs.
IPペイロードの検査は、プロバイダーネットワークで最もエントロピーを提供します。 IPペイロードのスタックラベルの下部を通過する方法はよく受け入れられており、[RFC4928]や他のRFCで文書化されています。
Where IP is mentioned in the document, both IPv4 and IPv6 apply. All LSRs MUST fully support IPv6.
ドキュメントでIPが言及されている場合、IPv4とIPv6の両方が適用されます。すべてのLSRはIPv6を完全にサポートする必要があります。
When information in the IP header is used, the following guidelines apply:
IPヘッダーの情報が使用される場合、次のガイドラインが適用されます。
1. Both the IP source address and IP destination address SHOULD be used. There MAY be an option to reverse the order of these addresses, improving the ability to provide symmetric paths in some cases. Many service providers require that both addresses be used.
1. IP送信元アドレスとIP宛先アドレスの両方を使用する必要があります（SHOULD）。これらのアドレスの順序を逆にするオプションがあり、対称パスを提供する機能が向上する場合があります。多くのサービスプロバイダーでは、両方のアドレスを使用する必要があります。
2. Implementations SHOULD allow inspection of the IP protocol field and use of the UDP or TCP port numbers. For many service providers, this feature is considered mandatory, particularly for enterprise, data center, or edge equipment. If this feature is provided, it SHOULD be possible to disable use of TCP and UDP ports. Many service providers consider it a nonnegotiable requirement that use of UDP and TCP ports can be disabled. Therefore, there is a strong incentive for implementations to provide both options.
2. 実装では、IPプロトコルフィールドの検査とUDPまたはTCPポート番号の使用を許可する必要があります（SHOULD）。多くのサービスプロバイダーにとって、この機能は、特に企業、データセンター、またはエッジ機器では必須と見なされています。この機能が提供されている場合、TCPおよびUDPポートの使用を無効にすることが可能であるべきです（SHOULD）。多くのサービスプロバイダーは、UDPおよびTCPポートの使用を無効にできることを交渉できない要件と見なしています。したがって、両方のオプションを提供する実装には強いインセンティブがあります。
3. Equipment suppliers MUST NOT make assumptions that because the IP version field is equal to 4 (an IPv4 packet) that the IP protocol will either be TCP (IP protocol 6) or UDP (IP protocol 17) and blindly fetch the data at the offset where the TCP or UDP ports would be found. With IPv6, TCP and UDP port numbers are not at fixed offsets. With IPv4 packets carrying IP options, TCP and UDP port numbers are not at fixed offsets.
3. 機器サプライヤーは、IPバージョンフィールドが4（IPv4パケット）に等しいため、IPプロトコルがTCP（IPプロトコル6）またはUDP（IPプロトコル17）であり、オフセットで盲目的にデータをフェッチすると仮定してはなりません。 TCPまたはUDPポートが見つかります。 IPv6では、TCPおよびUDPポート番号は固定オフセットではありません。 IPオプションを伝送するIPv4パケットでは、TCPおよびUDPポート番号は固定オフセットではありません。
4. The IPv6 header flow field SHOULD be used. This is the explicit purpose of the IPv6 flow field; however, observed flow fields rarely contain a non-zero value. Some uses of the flow field have been defined, such as [RFC6438]. In the absence of MPLS encapsulation, the IPv6 flow field can serve a role equivalent to the Entropy Label.
4. IPv6ヘッダーフローフィールドを使用する必要があります（SHOULD）。これは、IPv6フローフィールドの明示的な目的です。ただし、観測されたフローフィールドにゼロ以外の値が含まれることはほとんどありません。 [RFC6438]のように、フローフィールドのいくつかの用途が定義されています。 MPLSカプセル化がない場合、IPv6フローフィールドはエントロピーラベルと同等の役割を果たすことができます。
5. Support for other protocols that share a common Layer 4 header such as RTP [RFC3550], UDP-Lite [RFC3828], SCTP [RFC4960], and DCCP [RFC4340] SHOULD be provided, particularly for edge or access equipment where additional entropy may be needed. Equipment SHOULD also use RTP, UDP-lite, SCTP, and DCCP headers when creating an Entropy Label.
5. RTP [RFC3550]、UDP-Lite [RFC3828]、SCTP [RFC4960]、DCCP [RFC4340]などの共通のレイヤー4ヘッダーを共有する他のプロトコルのサポートを提供する必要があります（特に、追加のエントロピーが存在する可能性のあるエッジまたはアクセス機器）。必要。機器は、エントロピーラベルを作成するときに、RTP、UDP-lite、SCTP、およびDCCPヘッダーも使用する必要があります（SHOULD）。
6. The following IP header fields should not or must not be used:
6. 次のIPヘッダーフィールドは使用しないでください。
A. Similar to avoiding TC in MPLS, the IP DSCP, and ECN bits MUST NOT be used.
A. MPLSでのTCの回避と同様に、IP DSCP、およびECNビットは使用してはなりません（MUST NOT）。
B. The IPv4 TTL or IPv6 Hop Count SHOULD NOT be used.
B. IPv4 TTLまたはIPv6ホップカウントは使用しないでください。
C. Note that the IP TOS field was deprecated. ([RFC0791] was updated by [RFC2474].) No part of the IP DSCP field can be used (formerly IP PREC and IP TOS bits).
C. IP TOSフィールドは廃止されていることに注意してください。 （[RFC0791]は[RFC2474]によって更新されました。）IP DSCPフィールドのどの部分も使用できません（以前のIP PRECおよびIP TOSビット）。
7. Some IP encapsulations support tunneling, such as IP-in-IP, GRE, L2TPv3, and IPsec. These provide a greater source of entropy that some provider networks carrying large amounts of tunneled traffic may need, for example, as used in [RFC5640] for GRE and L2TPv3. The use of tunneling header information is out of scope for this document.
7. IP-in-IP、GRE、L2TPv3、IPsecなど、一部のIPカプセル化はトンネリングをサポートしています。これらは、たとえば、[RFC5640]でGREおよびL2TPv3に使用されているように、大量のトンネルトラフィックを伝送する一部のプロバイダーネットワークで必要になる可能性があるエントロピーのより大きなソースを提供します。トンネリングヘッダー情報の使用は、このドキュメントの範囲外です。
This document makes the following recommendations. These recommendations are not required to claim compliance to any existing RFC; therefore, implementers are free to ignore them, but due to service provider requirements should consider the risk of doing so. The use of IP addresses MUST be supported, and TCP and UDP ports (conditional on the protocol field and properly located) MUST be supported. The ability to disable use of UDP and TCP ports MUST be available.
このドキュメントでは、次のことを推奨しています。これらの推奨事項は、既存のRFCへの準拠を主張するために必須ではありません。したがって、実装者はそれらを無視できますが、サービスプロバイダーの要件により、そうすることのリスクを考慮する必要があります。 IPアドレスの使用をサポートする必要があり、TCPおよびUDPポート（プロトコルフィールドに条件があり、適切に配置されている）をサポートする必要があります。 UDPおよびTCPポートの使用を無効にする機能が使用可能である必要があります。
Though potentially very useful in some networks, it is uncommon to support using payloads of tunneling protocols carried over IP. Though the use of tunneling protocol header information is out of scope for this document, it is not discouraged.
一部のネットワークでは非常に役立つ可能性がありますが、IPで伝送されるトンネリングプロトコルのペイロードの使用をサポートすることは一般的ではありません。トンネリングプロトコルヘッダー情報の使用はこのドキュメントの範囲外ですが、推奨されません。
The ingress to a pseudowire (PW) can extract information from the payload being encapsulated to create a Flow Label. [RFC6391] references IP carried in Ethernet as an example. The Native Service Processing (NSP) function defined in [RFC3985] differs with pseudowire type. It is in the NSP function where information for a specific type of PW can be extracted for use in a Flow Label. Determining which fields to use for any given PW NSP is out of scope for this document.
疑似配線（PW）への入口は、カプセル化されているペイロードから情報を抽出して、フローラベルを作成できます。 [RFC6391]は、例としてイーサネットで伝送されるIPを参照しています。 [RFC3985]で定義されているネイティブサービス処理（NSP）関数は、疑似配線タイプによって異なります。これは、特定のタイプのPWに関する情報を抽出してフローラベルで使用できるNSP機能にあります。特定のPW NSPに使用するフィールドの決定は、このドキュメントの範囲外です。
An Entropy Label is added at the ingress to an LSP. The payload being encapsulated is most often MPLS, a PW, or IP. The payload type is identified by the Layer 2 encapsulation (Ethernet, GFP, POS, etc.).
エントロピーラベルは、LSPへの入口で追加されます。カプセル化されるペイロードは、ほとんどの場合MPLS、PW、またはIPです。ペイロードタイプは、レイヤ2カプセル化（イーサネット、GFP、POSなど）によって識別されます。
If the payload is MPLS, then the information used to create an Entropy Label is the same information used for local load balancing (see Section 2.4.5.1). This information MUST be extracted for use in generating an Entropy Label even if the LSR local egress interface is not a multipath.
ペイロードがMPLSの場合、エントロピーラベルの作成に使用される情報は、ローカルロードバランシングに使用される情報と同じです（2.4.5.1を参照）。 LSRローカル出力インターフェースがマルチパスでない場合でも、この情報を抽出してエントロピーラベルを生成する必要があります。
Of the non-MPLS payload types, only payloads that are forwarded are of interest. For example, payloads using the Address Resolution Protocol (ARP) are not forwarded, and payloads using the Connectionless-mode Network Protocol (CLNP), which is used only for IS-IS, are not forwarded.
非MPLSペイロードタイプのうち、転送されるのはペイロードのみです。たとえば、アドレス解決プロトコル（ARP）を使用するペイロードは転送されず、IS-ISでのみ使用されるコネクションレスモードネットワークプロトコル（CLNP）を使用するペイロードは転送されません。
The non-MPLS payload types of greatest interest are IPv4 and IPv6. The guidelines in Section 2.4.5.2 apply to fields used to create an Entropy Label.
最も重要な非MPLSペイロードタイプはIPv4とIPv6です。セクション2.4.5.2のガイドラインは、エントロピーラベルの作成に使用されるフィールドに適用されます。
The IP tunneling protocols mentioned in Section 2.4.5.2 may be more applicable to generation of an Entropy Label at the edge or access where deep packet inspection is practical due to lower interface speeds than in the core where deep packet inspection may be impractical.
セクション2.4.5.2で言及されているIPトンネリングプロトコルは、インターフェイス速度が遅いため、ディープパケットインスペクションが非現実的であるコアよりも、エッジまたはアクセスでのエントロピーラベルの生成に適用できます。
MPLS-TP introduces forwarding demands that will be extremely difficult to meet in a core network. Most troublesome is the requirement for Ultimate Hop Popping (UHP), the opposite of Penultimate Hop Popping (PHP). Using UHP opens the possibility of one or more MPLS pop operations plus an MPLS swap operation for each packet. The potential for multiple lookups and multiple counter instances per packet exists.
MPLS-TPは、コアネットワークでの対応が非常に難しい転送要求を導入します。最も厄介なのは、Ultimate Hop Popping（UHP）の要件であり、Penultimate Hop Popping（PHP）の反対です。 UHPを使用すると、1つ以上のMPLSポップ操作と各パケットのMPLSスワップ操作の可能性が広がります。パケットごとに複数のルックアップと複数のカウンターインスタンスが存在する可能性があります。
As networks grow and tunneling of LDP LSPs into RSVP-TE LSPs is used, and/or RSVP-TE hierarchy is used, the requirement to perform one or more MPLS pop operations plus an MPLS swap operation (and possibly a push or two) increases. If MPLS-TP LM (link monitoring) OAM is enabled at each layer, then a packet and byte count MUST be maintained for each pop and swap operation so as to offer OAM for each layer.
ネットワークが成長し、LDP LSPからRSVP-TE LSPへのトンネリングが使用されたり、RSVP-TE階層が使用されたりすると、1つ以上のMPLSポップ操作とMPLSスワップ操作（および場合によってはプッシュまたは2つ）を実行する要件が増加します。 。 MPLS-TP LM（リンクモニタリング）OAMが各レイヤーで有効になっている場合、各レイヤーにOAMを提供するために、各ポップアンドスワップ操作でパケットとバイトカウントを維持する必要があります。
There are a number of situations in which packets are destined to a local address or where a return packet must be generated. There is a need to mitigate the potential for outage as a result of either attacks on network infrastructure, or in some cases unintentional misconfiguration resulting in processor overload. Some hardware assistance is needed for all traffic destined to the general-purpose CPU that is used in processing of the MPLS control protocol or the network management protocol and in most cases to other general-purpose CPUs residing on an LSR. This is due to the ease of overwhelming such a processor with traffic arriving on LSR high-speed interfaces, whether the traffic is malicious or not.
パケットの宛先がローカルアドレスである場合や、返信パケットを生成する必要がある場合がいくつかあります。ネットワークインフラストラクチャに対する攻撃、または場合によっては意図しない構成の誤りが原因でプロセッサが過負荷になり、停止の可能性を軽減する必要があります。 MPLS制御プロトコルまたはネットワーク管理プロトコルの処理に使用される汎用CPU、およびほとんどの場合、LSRに存在する他の汎用CPUを宛先とするすべてのトラフィックには、いくつかのハードウェア支援が必要です。これは、トラフィックが悪意のあるものであるかどうかにかかわらず、LSR高速インターフェイスに到着するトラフィックでそのようなプロセッサを圧倒しやすいためです。
Denial of service (DoS) protection is an area requiring hardware support that is often overlooked or inadequately considered. Hardware assists are also needed for OAM, particularly the more demanding MPLS-TP OAM.
サービス拒否（DoS）保護は、ハードウェアサポートを必要とする領域であり、しばしば見落とされたり不適切に考慮されたりします。 OAM、特に要求の厳しいMPLS-TP OAMにはハードウェアアシストも必要です。
Modern equipment supports a number of control-plane and management-plane protocols. Generally, no single means of protecting network equipment from DoS attacks is sufficient, particularly for high-speed interfaces. This problem is not specific to MPLS but is a topic that cannot be ignored when implementing or evaluating MPLS implementations.
最新の機器は、多くのコントロールプレーンおよび管理プレーンプロトコルをサポートしています。一般的に、DoS攻撃からネットワーク機器を保護するための単一の手段では、特に高速インターフェイスでは十分ではありません。この問題はMPLSに固有のものではありませんが、MPLS実装を実装または評価するときに無視できないトピックです。
Two types of protections are often cited as the primary means of protecting against attacks of all kinds.
あらゆる種類の攻撃から保護するための主要な手段として、2種類の保護がよく引用されます。
Isolated Control/Management Traffic Control and management traffic can be carried out-of-band (OOB), meaning not intermixed with payload. For MPLS, use of G-ACh and GAL to carry control and management traffic provides a means of isolation from potentially malicious payloads. Used alone, the compromise of a single node, including a small computer at a network operations center, could compromise an entire network. Implementations that send all G-ACh/GAL traffic directly to a routing engine CPU are subject to DoS attack as a result of such a compromise.
分離された制御/管理トラフィック制御および管理トラフィックは、アウトオブバンド（OOB）で実行できます。つまり、ペイロードと混合されません。 MPLSの場合、G-AChとGALを使用して制御トラフィックと管理トラフィックを伝送することにより、悪意のある可能性のあるペイロードから分離することができます。単独で使用すると、ネットワークオペレーションセンターにある小さなコンピューターを含む単一ノードの侵害により、ネットワーク全体が侵害される可能性があります。すべてのG-ACh / GALトラフィックをルーティングエンジンCPUに直接送信する実装は、このような妥協の結果としてDoS攻撃を受ける可能性があります。
Cryptographic Authentication Cryptographic authentication can very effectively prevent malicious injection of control or management traffic. Cryptographic authentication can in some circumstances be subject to DoS attack by overwhelming the capacity of the decryption with a high volume of malicious traffic. For very-low-speed interfaces, cryptographic authentication can be performed by the general-purpose CPU used as a routing engine. For all other cases, cryptographic hardware may be needed. For very-high-speed interfaces, even cryptographic hardware can be overwhelmed.
暗号化認証暗号化認証は、制御または管理トラフィックの悪意のある注入を非常に効果的に防止できます。暗号化認証は、状況によっては、大量の悪意のあるトラフィックによって復号化の能力を圧倒することにより、DoS攻撃を受ける可能性があります。非常に低速なインターフェイスの場合、暗号化認証は、ルーティングエンジンとして使用される汎用CPUによって実行できます。他のすべてのケースでは、暗号化ハードウェアが必要になる場合があります。非常に高速なインターフェイスの場合、暗号化ハードウェアでさえ過負荷になる可能性があります。
Some control and management protocols are often carried with payload traffic. This is commonly the case with BGP, T-LDP, and SNMP. It is often the case with RSVP-TE. Even when carried over G-ACh/GAL, additional measures can reduce the potential for a minor breach to be leveraged to a full network attack.
一部の制御および管理プロトコルは、ペイロードトラフィックで伝送されることがよくあります。これは、BGP、T-LDP、およびSNMPの一般的なケースです。 RSVP-TEの場合がよくあります。 G-ACh / GALを介して実行される場合でも、追加の対策により、軽微な違反が完全なネットワーク攻撃に利用される可能性を減らすことができます。
Some of the additional protections are supported by hardware packet filtering.
追加の保護の一部は、ハードウェアパケットフィルタリングによってサポートされています。
GTSM [RFC5082] defines a mechanism that uses the IPv4 TTL or IPv6 Hop Limit fields to ensure control traffic that can only originate from an immediate neighbor is not forged and is not originating from a distant source. GTSM can be applied to many control protocols that are routable, for example, LDP [RFC6720].
GTSM [RFC5082]は、IPv4 TTLまたはIPv6ホップ制限フィールドを使用して、直接のネイバーからのみ発信できる制御トラフィックが偽造されず、遠いソースから発信されないようにするメカニズムを定義しています。 GTSMは、LDP [RFC6720]など、ルーティング可能な多くの制御プロトコルに適用できます。
IP Filtering At the very minimum, packet filtering plus classification and use of multiple queues supporting rate limiting is needed for traffic that could potentially be sent to a general-purpose CPU used as a routing engine. The first level of filtering only allows connections to be initiated from specific IP prefixes to specific destination ports and then preferably passes traffic directly to a cryptographic engine and/or rate limits. The second level of filtering passes connected traffic, such as TCP connections having received at least one authenticated SYN or having been locally initiated. The second level of filtering only passes traffic to specific address and port pairs to be checked for cryptographic authentication.
IPフィルタリング最低でも、ルーティングエンジンとして使用される汎用CPUに送信される可能性のあるトラフィックには、パケットフィルタリングに加えて、レート制限をサポートする複数のキューの分類と使用が必要です。フィルタリングの最初のレベルでは、特定のIPプレフィックスから特定の宛先ポートへの接続のみを開始でき、トラフィックを暗号化エンジンやレート制限に直接渡すことができます。 2番目のレベルのフィルタリングは、TCP接続などの接続されたトラフィックを通過させます。TCP接続は、少なくとも1つの認証済みSYNを受信したか、ローカルで開始されたものです。 2番目のレベルのフィルタリングでは、暗号化認証をチェックする特定のアドレスとポートのペアにのみトラフィックを渡します。
The cryptographic authentication is generally the last resort in DoS attack mitigation. If a packet must be first sent to a general-purpose CPU, then sent to a cryptographic engine, a DoS attack is possible on high-speed interfaces. Only where hardware can fully process a cryptographic authentication without intervention from a general-purpose CPU (to find the authentication field and to identify the portion of packet to run the cryptographic algorithm over) is cryptographic authentication beneficial in protecting against DoS attacks.
暗号化認証は一般に、DoS攻撃を緩和する最後の手段です。パケットをまず汎用CPUに送信し、次に暗号化エンジンに送信する必要がある場合、高速インターフェイスでDoS攻撃が可能です。暗号化認証がDoS攻撃からの保護に役立つのは、ハードウェアが汎用CPUの介入なしに暗号化認証を完全に処理できる場合（認証フィールドを見つけ、暗号化アルゴリズムを実行するパケットの部分を識別するため）だけです。
For chips supporting multiple 100 Gb/s interfaces, only a very large number of parallel cryptographic engines can provide the processing capacity to handle a large-scale DoS or distributed DoS (DDoS) attack. For many forwarding chips, this much processing power requires significant chip real estate and power, and therefore reduces system space and power density. For this reason, cryptographic authentication is not considered a viable first line of defense.
複数の100 Gb / sインターフェイスをサポートするチップの場合、大規模なDoSまたは分散DoS（DDoS）攻撃を処理する処理能力を提供できるのは、非常に多数の並列暗号化エンジンだけです。多くのフォワーディングチップでは、これだけの処理能力のためにかなりのチップ面積と電力が必要になるため、システムスペースと電力密度が低下します。このため、暗号化認証は実行可能な最初の防御線とは見なされません。
For some networks, the first line of defense is some means of supporting OOB control and management traffic. In the past, this OOB channel might make use of overhead bits in SONET or OTN or a dedicated DWDM wavelength. G-ACh and GAL provide an alternative OOB mechanism that is independent of underlying layers. In other networks, including most IP/MPLS networks, perimeter filtering serves a similar purpose, though it is less effective without extreme vigilance.
一部のネットワークでは、防御の第一線はOOB制御および管理トラフィックをサポートするいくつかの手段です。以前は、このOOBチャネルはSONETやOTN、または専用のDWDM波長のオーバーヘッドビットを利用していました。 G-AChとGALは、下層に依存しない代替OOBメカニズムを提供します。ほとんどのIP / MPLSネットワークを含む他のネットワークでは、境界フィルタリングは同様の目的を果たしますが、極端な警戒を怠ると効果が低下します。
A second line of defense is filtering, including GTSM. For protocols such as EBGP, GTSM and other filtering are often the first line of defense. Cryptographic authentication is usually the last line of defense and insufficient by itself to mitigate DoS or DDoS attacks.
防御の2番目のラインは、GTSMを含むフィルタリングです。 EBGPなどのプロトコルでは、GTSMやその他のフィルタリングが防御の最前線になることがよくあります。暗号化認証は通常、防御の最後の行であり、それ自体ではDoSまたはDDoS攻撃を緩和するには不十分です。
[RFC4377] defines requirements for MPLS OAM that predate MPLS-TP.
[RFC4379] defines what is commonly referred to as LSP Ping and LSP
Traceroute. [RFC4379] is updated by [RFC6424], which supports MPLS
tunnels and stitched LSP and P2MP LSP. [RFC4379] is updated by
[RFC6425], which supports P2MP LSP. [RFC4379] is updated by
[RFC6426] to support MPLS-TP connectivity verification (CV) and route
tracing.
[RFC4950] extends the ICMP format to support TTL expiration that may occur when using IP Traceroute within an MPLS tunnel. The ICMP message generation can be implemented in forwarding hardware, but if the ICMP packets are sent to a general-purpose CPU, this packet flow must be rate limited to avoid a potential DoS attack.
[RFC4950]は、ICMP形式を拡張して、MPLSトンネル内でIP Tracerouteを使用するときに発生する可能性のあるTTL有効期限をサポートします。 ICMPメッセージ生成は転送ハードウェアに実装できますが、ICMPパケットが汎用CPUに送信される場合、このパケットフローは、潜在的なDoS攻撃を回避するためにレート制限する必要があります。
[RFC5880] defines Bidirectional Forwarding Detection (BFD), a protocol intended to detect faults in the bidirectional path between two forwarding engines. [RFC5884] and [RFC5885] define BFD for MPLS. BFD can provide failure detection on any kind of path between systems, including direct physical links, virtual circuits, tunnels, MPLS Label Switched Paths (LSPs), multihop routed paths, and unidirectional links as long as there is some return path.
[RFC5880]は、2つの転送エンジン間の双方向パスで障害を検出することを目的としたプロトコルである双方向転送検出（BFD）を定義しています。 [RFC5884]および[RFC5885]は、MPLSのBFDを定義します。 BFDは、直接物理リンク、仮想回線、トンネル、MPLSラベルスイッチドパス（LSP）、マルチホップルーテッドパス、および単方向リンクを含む、システム間のあらゆる種類のパスで障害検出を提供できます。
The processing requirements for BFD are less than for LSP Ping, making BFD somewhat better suited for relatively high-rate proactive monitoring. BFD does not verify that the data plane matches the control plane, where LSP Ping does. LSP Ping is somewhat better suited for on-demand monitoring including relatively low-rate periodic verification of the data plane and as a diagnostic tool.
BFDの処理要件はLSP Pingの場合よりも少ないため、BFDは比較的高速なプロアクティブモニタリングにいくぶん適しています。 BFDは、データプレーンがLSP Pingが行うコントロールプレーンと一致することを確認しません。 LSP Pingは、データプレーンの比較的低速の定期的な検証を含むオンデマンドモニタリングや診断ツールとして、いくらか適しています。
Hardware assistance is often provided for BFD response where BFD setup or parameter change is not involved and may be necessary for relatively high-rate proactive monitoring. If both BFD and LSP Ping are recognized in filtering prior to passing traffic to a general-purpose CPU, appropriate DoS protection can be applied (see Section 2.6.1). Failure to recognize BFD and LSP Ping and at least to rate limit creates the potential for misconfiguration to cause outages rather than cause errors in the misconfigured OAM.
多くの場合、BFDのセットアップやパラメーターの変更が関係しないBFD応答にはハードウェア支援が提供され、比較的高速の予防的監視に必要になる場合があります。トラフィックを汎用CPUに渡す前に、BFDとLSPの両方のPingがフィルタリングで認識される場合、適切なDoS保護を適用できます（2.6.1項を参照）。 BFDとLSPのpingを認識できず、少なくともレート制限がないと、誤った構成のOAMでエラーが発生するのではなく、誤った構成で停止が発生する可能性があります。
Pseudowire OAM makes use of the control channel provided by Virtual Circuit Connectivity Verification (VCCV) [RFC5085]. VCCV makes use of the pseudowire Control Word. BFD support over VCCV is defined by [RFC5885]. [RFC5885] is updated by [RFC6478] in support of static pseudowires. [RFC4379] is updated by [RFC6829] to support LSP Ping for Pseudowire FEC advertised over IPv6.
疑似配線OAMは、Virtual Circuit Connectivity Verification（VCCV）[RFC5085]によって提供される制御チャネルを利用します。 VCCVは、疑似配線制御ワードを使用します。 VCCVでのBFDサポートは、[RFC5885]で定義されています。 [RFC5885]は、静的な疑似配線をサポートするために[RFC6478]によって更新されています。 [RFC4379]は[RFC6829]によって更新され、IPv6でアドバタイズされた疑似配線FECのLSP Pingをサポートします。
G-ACh/GAL (defined in [RFC5586]) is the preferred MPLS-TP OAM control channel and applies to any MPLS-TP endpoints, including pseudowire. See Section 2.6.4 for an overview of MPLS-TP OAM.
G-ACh / GAL（[RFC5586]で定義）は優先MPLS-TP OAM制御チャネルであり、疑似配線を含むすべてのMPLS-TPエンドポイントに適用されます。 MPLS-TP OAMの概要については、セクション2.6.4を参照してください。
[RFC6669] summarizes the MPLS-TP OAM toolset, the set of protocols supporting the MPLS-TP OAM requirements specified in [RFC5860] and supported by the MPLS-TP OAM framework defined in [RFC6371].
[RFC6669]は、[RFC5860]で指定され、[RFC6371]で定義されたMPLS-TP OAMフレームワークでサポートされるMPLS-TP OAM要件をサポートする一連のプロトコルであるMPLS-TP OAMツールセットをまとめたものです。
The MPLS-TP OAM toolset includes:
MPLS-TP OAMツールセットには、次のものが含まれます。
CC-CV [RFC6428] defines BFD extensions to support proactive Continuity Check and Connectivity Verification (CC-CV) applications. [RFC6426] provides LSP Ping extensions that are used to implement on-demand connectivity verification.
CC-CV [RFC6428]は、予防的なContinuity Check and Connectivity Verification（CC-CV）アプリケーションをサポートするBFD拡張を定義しています。 [RFC6426]は、オンデマンド接続検証の実装に使用されるLSP Ping拡張機能を提供します。
RDI Remote Defect Indication (RDI) is triggered by failure of proactive CC-CV, which is BFD based. For fast RDI, RDI SHOULD be initiated and handled by hardware if BFD is handled in forwarding hardware. [RFC6428] provides an extension for BFD that includes the RDI in the BFD format and a specification of how this indication is to be used.
RDIリモート障害表示（RDI）は、BFDベースのプロアクティブCC-CVの障害によってトリガーされます。高速RDIの場合、BFDが転送ハードウェアで処理される場合、RDIを開始してハードウェアで処理する必要があります（SHOULD）。 [RFC6428]は、BFD形式のRDIとこの表示の使用方法の仕様を含むBFDの拡張機能を提供します。
Route Tracing [RFC6426] specifies that the LSP Ping enhancements for MPLS-TP on-demand connectivity verification include information on the use of LSP Ping for route tracing of an MPLS-TP path.
ルートトレース[RFC6426]は、MPLS-TPオンデマンド接続検証のLSP Ping拡張機能に、MPLS-TPパスのルートトレースにLSP Pingを使用することに関する情報が含まれていることを指定しています。
Alarm Reporting [RFC6427] describes the details of a new protocol supporting Alarm Indication Signal (AIS), Link Down Indication (LDI), and fault management. Failure to support this functionality in forwarding hardware can potentially result in failure to meet protection recovery time requirements; therefore, support of this functionality is strongly recommended.
アラームレポート[RFC6427]では、アラーム表示信号（AIS）、リンクダウン表示（LDI）、および障害管理をサポートする新しいプロトコルの詳細について説明しています。転送ハードウェアでこの機能をサポートしないと、保護回復時間の要件を満たせなくなる可能性があります。したがって、この機能のサポートを強くお勧めします。
Lock Instruct Lock instruct is initiated on demand and therefore need not be implemented in forwarding hardware. [RFC6435] defines a lock instruct protocol.
ロック指示ロック指示はオンデマンドで開始されるため、転送ハードウェアに実装する必要はありません。 [RFC6435]は、ロック指示プロトコルを定義しています。
Lock Reporting [RFC6427] covers lock reporting. Lock reporting need not be implemented in forwarding hardware.
ロックレポート[RFC6427]は、ロックレポートについて説明しています。転送ハードウェアにロックレポートを実装する必要はありません。
Diagnostic [RFC6435] defines protocol support for loopback. Loopback initiation is on demand and therefore need not be implemented in forwarding hardware. Loopback of packet traffic SHOULD be implemented in forwarding hardware on high-speed interfaces.
診断[RFC6435]は、ループバックのプロトコルサポートを定義します。ループバックの開始はオンデマンドであるため、転送ハードウェアに実装する必要はありません。パケットトラフィックのループバックは、高速インターフェイスの転送ハードウェアに実装する必要があります（SHOULD）。
Packet Loss and Delay Measurement [RFC6374] and [RFC6375] define a protocol and profile for Packet Loss Measurement (LM) and Delay Measurement (DM). LM requires a very accurate capture and insertion of packet and byte counters when a packet is transmitted and capture of packet and byte counters when a packet is received. This capture and insertion MUST be implemented in forwarding hardware for LM OAM if high accuracy is needed. DM requires very accurate capture and insertion of a timestamp on transmission and capture of timestamp when a packet is received. This timestamp capture and insertion MUST be implemented in forwarding hardware for DM OAM if high accuracy is needed.
パケット損失および遅延測定[RFC6374]および[RFC6375]は、パケット損失測定（LM）および遅延測定（DM）のプロトコルとプロファイルを定義します。 LMは、パケットが送信されるときのパケットとバイトカウンターの非常に正確なキャプチャと挿入、およびパケットが受信されるときのパケットとバイトカウンターのキャプチャを必要とします。高精度が必要な場合は、このキャプチャと挿入をLM OAMの転送ハードウェアに実装する必要があります。 DMでは、送信時のタイムスタンプの非常に正確なキャプチャと挿入、およびパケット受信時のタイムスタンプのキャプチャが必要です。高精度が必要な場合、このタイムスタンプのキャプチャと挿入は、DM OAMの転送ハードウェアに実装する必要があります。
See Section 2.6.2 for discussion of hardware support necessary for BFD and LSP Ping.
BFDおよびLSP pingに必要なハードウェアサポートの説明については、セクション2.6.2を参照してください。
CC-CV and alarm reporting is tied to protection and therefore SHOULD be supported in forwarding hardware in order to provide protection for a large number of affected LSPs within target response intervals. When using MPLS-TP, since CC-CV is supported by BFD, providing hardware assistance for BFD processing helps ensure that protection recovery time requirements can be met even for faults affecting a large number of LSPs.
CC-CVとアラームレポートは保護に関連付けられているため、ターゲット応答間隔内で影響を受ける多数のLSPを保護するために、転送ハードウェアでサポートする必要があります（SHOULD）。 MPLS-TPを使用する場合、CC-CVはBFDでサポートされているため、BFD処理にハードウェア支援を提供すると、多数のLSPに影響を与える障害に対しても、保護回復時間の要件を満たすことができます。
MPLS-TP Protection State Coordination (PSC) is defined by [RFC6378] and updated by [RFC7324], which corrects some errors in [RFC6378].
MPLS-TP保護状態調整（PSC）は[RFC6378]によって定義され、[RFC7324]によって更新され、[RFC6378]のいくつかのエラーを修正します。
[RFC6670] provides the reasons for selecting a single MPLS-TP OAM solution and examines the consequences were ITU-T to develop a second OAM solution that is based on Ethernet encodings and mechanisms.
[RFC6670]は、単一のMPLS-TP OAMソリューションを選択する理由を示し、ITU-Tがイーサネットエンコーディングとメカニズムに基づく2番目のOAMソリューションを開発した結果を調べます。
[RFC6310] and [RFC7023] specify the mapping of defect states between many types of hardware Attachment Circuits (ACs) and associated pseudowires (PWs). This functionality SHOULD be supported in forwarding hardware.
[RFC6310]および[RFC7023]は、多くのタイプのハードウェア接続回路（AC）と関連する疑似配線（PW）の間の欠陥状態のマッピングを指定します。この機能は転送ハードウェアでサポートされるべきです（SHOULD）。
It is beneficial if an MPLS OAM implementation can interwork with the underlying server layer and provide a means to interwork with a client layer. For example, [RFC6427] specifies an inter-layer propagation of AIS and LDI from MPLS server layer to client MPLS layers. Where the server layer uses a Layer 2 mechanism, such as Ethernet, PPP over SONET/SDH, or GFP over OTN, interwork among layers is also beneficial. For high-speed interfaces, supporting this interworking in forwarding hardware helps ensure that protection based on this interworking can meet recovery time requirements even for faults affecting a large number of LSPs.
MPLS OAM実装が基礎となるサーバー層と相互に作用し、クライアント層と相互に作用する手段を提供できる場合、それは有益です。たとえば、[RFC6427]は、MPLSサーバーレイヤーからクライアントMPLSレイヤーへのAISおよびLDIのレイヤー間伝播を指定します。サーバーレイヤーがイーサネット、PPP over SONET / SDH、GFP over OTNなどのレイヤー2メカニズムを使用している場合、レイヤー間の相互作用も有益です。高速インターフェイスの場合、フォワーディングハードウェアでこのインターワーキングをサポートすると、このインターワーキングに基づく保護が、多数のLSPに影響を与える障害に対しても、リカバリ時間の要件を満たすことができます。
Where certain requirements must be met, such as relatively high CC-CV rates and a large number of interfaces, or strict protection recovery time requirements and a moderate number of affected LSPs, some OAM functionality must be supported by forwarding hardware. In other cases, such as highly accurate LM and DM OAM or strict protection recovery time requirements with a large number of affected LSPs, OAM functionality must be entirely implemented in forwarding hardware.
比較的高いCC-CVレートと多数のインターフェイス、または厳密な保護回復時間の要件と適度な数の影響を受けるLSPなどの特定の要件を満たす必要がある場合は、一部のOAM機能を転送ハードウェアでサポートする必要があります。他のケースでは、非常に正確なLMおよびDM OAMや、影響を受けるLSPが多数ある場合の厳密な保護回復時間の要件など、OAM機能を完全に転送ハードウェアに実装する必要があります。
Where possible, implementation in forwarding hardware should be in programmable hardware such that if standards are later changed or extended these changes are likely to be accommodated with hardware reprogramming rather than replacement.
可能な場合、転送ハードウェアでの実装はプログラム可能なハードウェアで行う必要があります。これにより、標準が後で変更または拡張された場合に、これらの変更が交換ではなくハードウェアの再プログラミングで対応できるようになります。
For some functionality, there is a strong case for an implementation in dedicated forwarding hardware. Examples include packet and byte counters needed for LM OAM as well as needed for management protocols. Similarly, the capture and insertion of packet and byte counts or timestamps needed for transmitted LM or DM or time synchronization packets MUST be implemented in forwarding hardware if high accuracy is required.
一部の機能については、専用の転送ハードウェアでの実装が強く求められます。例には、LM OAMに必要なパケットカウンタとバイトカウンタ、および管理プロトコルに必要なものが含まれます。同様に、送信されたLMまたはDMまたは時間同期パケットに必要なパケットとバイトカウントまたはタイムスタンプのキャプチャと挿入は、高い精度が必要な場合、転送ハードウェアに実装する必要があります。
For some functions, there is a strong case to provide limited support in forwarding hardware, but an external general-purpose processor may be used if performance criteria can be met. For example, origination of RDI triggered by CC-CV, response to RDI, and Protection State Coordination (PSC) functionality may be supported by hardware, but expansion to a large number of client LSPs and transmission of AIS or RDI to the client LSPs may occur in a general-purpose processor. Some forwarding hardware supports one or more on-chip general-purpose processors that may be well suited for such a role. [RFC7324], being a very recent document that affects a protection state machine that requires hardware support, underscores the importance of having a degree of programmability in forwarding hardware.
一部の機能については、転送ハードウェアで限定的なサポートを提供する強力なケースがありますが、パフォーマンス基準を満たすことができる場合は、外部の汎用プロセッサを使用できます。たとえば、CC-CVによってトリガーされるRDIの発信、RDIへの応答、および保護状態調整（PSC）機能はハードウェアでサポートされますが、多数のクライアントLSPへの拡張とクライアントLSPへのAISまたはRDIの送信は、汎用プロセッサで発生します。一部の転送ハードウェアは、1つ以上のオンチップの汎用プロセッサをサポートしており、そのような役割に適している場合があります。 [RFC7324]は、ハードウェアサポートを必要とする保護ステートマシンに影響を与える非常に最近のドキュメントであり、ハードウェアの転送にある程度のプログラマビリティを持たせることの重要性を強調しています。
The customer (system supplier or provider) should not dictate design, but should independently validate target functionality and performance. However, it is not uncommon for service providers and system implementers to insist on reviewing design details (under a non-disclosure agreement) due to past experiences with suppliers and to reject suppliers who are unwilling to provide details.
顧客（システムサプライヤーまたはプロバイダー）は設計を指示するのではなく、ターゲットの機能とパフォーマンスを個別に検証する必要があります。ただし、サプライヤーとの過去の経験により、サービスプロバイダーとシステムインプリメンターが設計の詳細の確認（機密保持契約に基づく）を主張し、詳細を提供したくないサプライヤーを拒否することは珍しくありません。
The IPFIX architecture is defined by [RFC5470]. IPFIX supports per-flow statistics. IPFIX information elements (IEs) are defined in [RFC7012] and include IEs for MPLS.
IPFIXアーキテクチャは[RFC5470]で定義されています。 IPFIXはフローごとの統計をサポートします。 IPFIX情報要素（IE）は[RFC7012]で定義されており、MPLSのIEが含まれています。
The forwarding chips used in core routers are not optimized for high-touch applications like IPFIX. Often, support for IPFIX in core routers is limited to optional IPFIX metering, which involves a 1-in-N packet sampling, limited filtering support, and redirection to either an internal CPU or an external interface. The CPU or device at the other end of the external interface then implements the full IPFIX filtering and IPFIX collector functionality.
コアルーターで使用される転送チップは、IPFIXのようなハイタッチアプリケーション用に最適化されていません。多くの場合、コアルーターでのIPFIXのサポートは、1-in-Nパケットサンプリング、制限されたフィルタリングサポート、および内部CPUまたは外部インターフェイスへのリダイレクトを含む、オプションのIPFIXメータリングに制限されています。外部インターフェイスの反対側にあるCPUまたはデバイスは、完全なIPFIXフィルタリングとIPFIXコレクター機能を実装します。
LSRs that are intended to be deployed further from the core may support lower-capacity interfaces but support higher-touch applications on the forwarding hardware and may provide dedicated hardware to support a greater subset of IPFIX functionality before handing off to a general-purpose CPU. In some cases, far from the core the entire IPFIX functionality up to and including the collector may be implemented in hardware and firmware in the forwarding silicon. It is also worth noting that at lower speeds a general-purpose CPU may become adequate to implement IPFIX, particularly if metering is used.
コアからさらに展開することを目的としたLSRは、低容量インターフェイスをサポートしますが、フォワーディングハードウェア上のタッチの高いアプリケーションをサポートし、汎用CPUに引き渡す前にIPFIX機能のより大きなサブセットをサポートする専用ハードウェアを提供します。場合によっては、コアから離れて、コレクターまでのIPFIX機能全体が、転送シリコンのハードウェアとファームウェアに実装されることがあります。特にメータリングを使用している場合は、低速で汎用CPUがIPFIXを実装するのに十分になる可能性があることにも注意してください。
Service provider networks may carry up to hundreds of millions of flows on 10 Gb/s links. Most flows are very short lived, many under a second. A subset of the flows are low capacity and somewhat long lived. When Internet traffic dominates capacity, a very small subset of flows are high capacity and/or very long lived.
サービスプロバイダーのネットワークは、10 Gb / sリンク上で最大数億のフローを伝送できます。ほとんどのフローは非常に短命で、多くは1秒未満です。フローのサブセットは、容量が少なく、長命です。インターネットトラフィックが容量を支配している場合、フローの非常に小さなサブセットが大容量であるか、非常に長命です。
Two types of limitations with regard to number and size of flows have been observed.
フローの数とサイズに関する2つのタイプの制限が確認されています。
1. Some hardware cannot handle some high-capacity flows because of internal paths that are limited, such as per-packet backplane paths or paths internal or external to chips such as buffer memory paths. Such designs can handle aggregates of smaller flows. Some hardware with acknowledged limitations has been successfully deployed but may be increasingly problematic if the capacity of large microflows in deployed networks continues to grow.
1. 一部のハードウェアは、パケットごとのバックプレーンパスや、バッファーメモリパスなどのチップの内部または外部のパスなど、内部パスが制限されているため、一部の大容量フローを処理できません。このような設計では、より小さなフローの集合体を処理できます。認められた制限のある一部のハードウェアは正常に展開されましたが、展開されたネットワークで大規模なマイクロフローの容量が増加し続けると、ますます問題が発生する可能性があります。
2. Some hardware approaches cannot handle a large number of flows, or a large number of large flows, due to attempting to count per flow, rather than deal with aggregates of flows. Hash techniques scale with regard to number of flows due to a fixed hash size with many flows falling into the same hash bucket. Techniques that identify individual flows have been implemented but have never successfully deployed for Internet traffic.
2. 一部のハードウェアアプローチでは、フローの集約を処理するのではなく、フローごとにカウントしようとするため、多数のフローまたは多数の大きなフローを処理できません。ハッシュテクニックは、多くのフローが同じハッシュバケットに分類される固定ハッシュサイズのため、フローの数に関してスケーリングします。個々のフローを識別する手法が実装されていますが、インターネットトラフィック用に正常に展開されたことはありません。
The following questions should be asked of a supplier. These questions are grouped into broad categories and are intended to be open-ended questions to the supplier. The tests in Section 4 are intended to verify whether the supplier disclosed any compliance or performance limitations completely and accurately.
サプライヤーに以下の質問をする必要があります。これらの質問は幅広いカテゴリにグループ化されており、サプライヤーへの自由回答形式の質問を対象としています。セクション4のテストは、サプライヤーがコンプライアンスまたはパフォーマンスの制限を完全かつ正確に開示したかどうかを検証することを目的としています。
Q#1 Can the implementation forward packets with an arbitrarily large stack depth? What limitations exist, and under what circumstances do further limitations come into play (such as high packet rate or specific features enabled or specific types of packet processing)? See Section 2.1.
Q＃1実装は、任意の大きなスタック深度でパケットを転送できますか？どのような制限が存在し、どのような状況でさらに制限が生じますか（高パケットレート、有効になっている特定の機能、特定の種類のパケット処理など）？セクション2.1を参照してください。
Q#2 Is the entire set of basic MPLS functionality described in Section 2.1 supported?
Q＃2セクション2.1で説明されている基本的なMPLS機能のセット全体がサポートされていますか？
Q#3 Is the set of MPLS special-purpose labels handled correctly and with adequate performance? Are extended special-purpose labels handled correctly and with adequate performance? See Section 2.1.1.
Q＃3 MPLS専用ラベルのセットは適切に処理され、適切なパフォーマンスが得られますか？拡張された専用ラベルは適切に処理され、適切なパフォーマンスが得られますか？セクション2.1.1を参照してください。
Q#4 Are mappings of label value and TC to PHB handled correctly, including L-LSP mappings (RFC 3270) and CT mappings (RFC 4124) to PHB? See Section 2.1.2.
Q＃4 L-LSPマッピング（RFC 3270）およびCTマッピング（RFC 4124）からPHBへのマッピングを含め、ラベル値とTCからPHBへのマッピングは正しく処理されますか？セクション2.1.2を参照してください。
Q#5 Is time synchronization adequately supported in forwarding hardware?
Q＃5転送ハードウェアで時間同期は適切にサポートされていますか？
A. Are both PTP and NTP formats supported?
A. PTP形式とNTP形式の両方がサポートされていますか？
B. Is the accuracy of timestamp insertion and incoming stamping sufficient?
B.タイムスタンプの挿入と受信スタンプの精度は十分ですか？
See Section 2.1.3.
セクション2.1.3を参照してください。
Q#6 Is link bundling supported?
Q＃6リンクバンドリングはサポートされていますか？
A. Can an LSP be pinned to specific components?
A. LSPを特定のコンポーネントに固定できますか？
B. Is the "all-ones" component link supported?
B.「すべて1」のコンポーネントリンクはサポートされていますか？
See Section 2.1.5.
セクション2.1.5を参照してください。
Q#7 Is MPLS hierarchy supported?
Q＃7 MPLS階層はサポートされていますか？
A. Are both PHP and UHP supported? What limitations exist on the number of pop operations with UHP?
A. PHPとUHPの両方がサポートされていますか？ UHPのポップ操作の数にはどのような制限がありますか？
B. Are the pipe, short-pipe, and uniform models supported? Are TTL and TC values updated correctly at egress where applicable?
B.パイプ、ショートパイプ、ユニフォームモデルはサポートされていますか？該当する場合、TTLおよびTC値は出口で正しく更新されますか？
See Section 2.1.6 regarding MPLS hierarchy. See [RFC3443] regarding PHP, UHP, and pipe, short-pipe, and uniform models.
MPLS階層については、セクション2.1.6を参照してください。 PHP、UHP、パイプ、ショートパイプ、ユニフォームモデルについては、[RFC3443]を参照してください。
Q#8 Is FRR supported?
Q＃8 FRRはサポートされていますか？
A. Are both "One-to-One Backup" and "Facility Backup" supported?
A.「One-to-One Backup」と「Facility Backup」の両方がサポートされていますか？
B. What forms of IP/LDP FRR are supported?
B.どの形式のIP / LDP FRRがサポートされていますか？
C. How quickly does protection recovery occur?
C.保護回復はどのくらいの速さで発生しますか？
D. Does protection recovery speed increase when a fault affects a large number of protected LSPs? And if so, by how much?
D.障害が多数の保護されたLSPに影響を与える場合、保護の回復速度は向上しますか？もしそうなら、どれだけ？
See Section 2.1.7.
セクション2.1.7を参照してください。
Q#9 Are pseudowire Sequence Numbers handled correctly? See Section 2.1.8.1.
Q＃9疑似配線シーケンス番号は正しく処理されますか？セクション2.1.8.1を参照してください。
Q#10 Is VPN LER functionality handled correctly and without performance issues? See Section 2.1.9.
Q＃10 VPN LER機能は正しく処理され、パフォーマンスの問題はありませんか？セクション2.1.9を参照してください。
Q#11 Is MPLS multicast (P2MP and MP2MP) handled correctly?
Q＃11 MPLSマルチキャスト（P2MPおよびMP2MP）は正しく処理されますか？
A. Are packets dropped on uncongested outputs if some outputs are congested?
A.一部の出力が輻輳している場合、輻輳していない出力でパケットはドロップされますか？
B. Is performance limited in high-fanout situations?
B.ファンアウトの多い状況でパフォーマンスは制限されますか？
See Section 2.2.
セクション2.2を参照してください。
Q#12 Can very small packets be forwarded at full line rate on all interfaces indefinitely? What limitations exist? And under what circumstances do further limitations come into play (such as specific features enabled or specific types of packet processing)?
Q＃12すべてのインターフェイスで非常に小さなパケットをフルラインレートで無期限に転送できますか？どのような制限がありますか？また、どのような状況で、特定の機能が有効になるか、特定の種類のパケット処理など、さらに制限が発生しますか？
Q#13 Customers must decide whether to relax the prior requirement and to what extent. If the answer to the prior question indicates that limitations exist, then:
Q＃13お客様は、以前の要件を緩和するかどうか、およびどの程度緩和するかを決定する必要があります。前の質問への回答が制限が存在することを示している場合、次のようになります。
A. What is the smallest packet size where full line rate forwarding can be supported?
A.フルラインレートフォワーディングをサポートできる最小のパケットサイズはいくつですか。
B. What is the longest burst of full-rate small packets that can be supported?
B.サポートできるフルレートの小さなパケットの最長バーストは何ですか？
Specify circumstances (such as specific features enabled or specific types of packet processing) that often impact these rates and burst sizes.
これらのレートとバーストサイズに影響を与えることが多い状況（特定の機能が有効になっている、特定のタイプのパケット処理など）を指定します。
Q#14 How many pop operations can be supported along with a swap operation at full line rate while maintaining per-LSP packet and byte counts for each pop and swap? This requirement is particularly relevant for MPLS-TP.
Q＃14ポップとスワップごとにLSPごとのパケット数とバイト数を維持しながら、フルラインレートでのスワップ操作とともに、いくつのポップ操作をサポートできますか？この要件は、特にMPLS-TPに関連しています。
Q#15 How many label push operations can be supported. While this limitation is rarely an issue, it applies to both PHP and UHP, unlike the pop limit that applies to UHP.
Q＃15サポートできるラベルプッシュ操作の数。この制限がめったに問題になることはありませんが、UHPに適用されるポップ制限とは異なり、PHPとUHPの両方に適用されます。
Q#16 For a worst case where all packets arrive on one LSP, what is the counter overflow time? Are any means provided to avoid polling all counters at short intervals? This applies to both MPLS and MPLS-TP.
Q＃16すべてのパケットが1つのLSPに到着する最悪の場合、カウンターオーバーフロー時間はどれくらいですか？短い間隔ですべてのカウンターをポーリングしないようにするための手段はありますか？これは、MPLSとMPLS-TPの両方に適用されます。
Multipath capabilities and performance do not apply to MPLS-TP, but they apply to MPLS and apply if MPLS-TP is carried in MPLS.
マルチパス機能とパフォーマンスはMPLS-TPには適用されませんが、MPLSに適用され、MPLS-TPがMPLSで伝送される場合に適用されます。
Q#17 How are large microflows accommodated? Is there active management of the hash space mapping to output ports? See Section 2.4.2.
Q＃17大きなマイクロフローにはどのように対応しますか？出力ポートへのハッシュ空間マッピングのアクティブな管理はありますか？セクション2.4.2を参照してください。
Q#18 How many MPLS labels can be included in a hash based on the MPLS label stack?
Q＃18 MPLSラベルスタックに基づいて、ハッシュにMPLSラベルをいくつ含めることができますか？
Q#19 Is packet rate performance decreased beyond some number of labels?
Q＃19パケットレートのパフォーマンスは、いくつかのラベルを超えると低下しますか？
Q#20 Can the IP header and payload information below the MPLS stack be used in the hash? If so, which IP fields, payload types, and payload fields are supported?
Q＃20 MPLSスタックの下のIPヘッダーとペイロード情報をハッシュで使用できますか？その場合、どのIPフィールド、ペイロードタイプ、およびペイロードフィールドがサポートされますか？
Q#21 At what maximum MPLS label stack depth can Bottom of Stack and an IP header appear without impacting packet rate performance?
Q＃21パケットレートパフォーマンスに影響を与えずに、スタックの最下部とIPヘッダーを表示できる最大MPLSラベルスタック深度はどれくらいですか？
Q#22 Are special-purpose labels excluded from the label stack hash? Are extended special-purpose labels excluded from the label stack hash? See Section 2.4.5.1.
Q＃22特殊用途のラベルはラベルスタックハッシュから除外されますか？拡張特殊用途ラベルはラベルスタックハッシュから除外されますか？セクション2.4.5.1を参照してください。
Q#23 How is multipath performance affected by high-capacity flows, an extremely large number of flows, or very short-lived flows? See Section 2.7.
Q＃23マルチパスのパフォーマンスは、大容量フロー、非常に多数のフロー、または非常に短命なフローによってどのように影響を受けますか？セクション2.7を参照してください。
Q#24 Is the pseudowire Control Word supported?
Q＃24疑似配線制御ワードはサポートされていますか？
Q#25 What is the maximum rate of pseudowire encapsulation and decapsulation? Apply the same questions as in Section 3.2 ("Basic Performance") for any packet-based pseudowire, such as IP VPN or Ethernet.
Q＃25疑似配線のカプセル化とカプセル解放の最大レートはいくつですか？ IP VPNやイーサネットなどのパケットベースの疑似配線に対して、セクション3.2（「基本パフォーマンス」）と同じ質問を適用します。
Q#26 Does inclusion of a pseudowire Control Word impact performance?
Q＃26疑似配線制御ワードを含めるとパフォーマンスに影響がありますか？
Q#27 Are Flow Labels supported?
Q＃27フローラベルはサポートされていますか？
Q#28 If so, what fields are hashed on for the Flow Label for different types of pseudowires?
Q＃28その場合、さまざまなタイプの疑似配線のフローラベルに対してどのフィールドがハッシュされますか？
Q#29 Does inclusion of a Flow Label impact performance?
Q＃29フローラベルを含めるとパフォーマンスに影響がありますか？
Q#30 Can an Entropy Label be added when acting as an ingress LER, and can it be removed when acting as an egress LER?
Q＃30入力LERとして機能するときにエントロピーラベルを追加できますか。また、出力LERとして機能するときに削除できますか？
Q#31 If an Entropy Label can be added, what fields are hashed on for the Entropy Label?
Q＃31エントロピーラベルを追加できる場合、エントロピーラベルにはどのフィールドがハッシュされますか？
Q#32 Does adding or removing an Entropy Label impact packet rate performance?
Q＃32エントロピーラベルの追加または削除はパケットレートのパフォーマンスに影響しますか？
Q#33 Can an Entropy Label be detected in the label stack, used in the hash, and properly terminate the search for further information to hash on?
Q＃33エントロピーラベルがラベルスタックで検出され、ハッシュで使用され、ハッシュする追加情報の検索を適切に終了できますか？
Q#34 Does using an Entropy Label have any negative impact on performance? It should have no impact or a positive impact.
Q＃34エントロピーラベルを使用すると、パフォーマンスに悪影響がありますか？影響がないか、プラスの影響があるはずです。
Q#35 For each control- and management-plane protocol in use, what measures are taken to provide DoS attack hardening?
Q＃35使用中のコントロールプレーンおよび管理プレーンのプロトコルごとに、DoS攻撃を強化するためにどのような対策が取られていますか？
Q#36 Have DoS attack tests been performed?
Q＃36 DoS攻撃テストは実施されましたか？
Q#37 Can compromise of an internal computer on a management subnet be leveraged for any form of attack including DoS attack?
Q＃37管理サブネット上の内部コンピューターの侵害は、DoS攻撃を含むあらゆる形式の攻撃に利用できますか？
Q#38 What OAM proactive and on-demand mechanisms are supported?
Q＃38サポートされているOAMプロアクティブメカニズムとオンデマンドメカニズムは何ですか？
Q#39 What performance limits exist under high proactive monitoring rates?
Q＃39予防的な監視率が高い場合、どのようなパフォーマンスの制限がありますか？
Q#40 Can excessively high proactive monitoring rates impact control-plane performance or cause control-plane instability?
Q＃40プロアクティブな監視率が高すぎると、コントロールプレーンのパフォーマンスに影響したり、コントロールプレーンが不安定になったりする可能性はありますか？
Q#41 Ask the prior questions for each of the following.
Q＃41次のそれぞれについて、前の質問をします。
A. MPLS OAM
A. MPLS OAM
B. Pseudowire OAM
B.疑似配線OAM
C. MPLS-TP OAM D. Layer 2 OAM Interworking
C. MPLS-TP OAM D.レイヤー2 OAMインターワーキング
See Section 2.6.
セクション2.6を参照してください。
Packet rate performance of equipment supporting a large number of 10 Gb/s or 100 Gb/s links is not possible using desktop computers or workstations. The use of high-end workstations as a source of test traffic was barely viable 20 years ago but is no longer at all viable. Though custom microcode has been used on specialized router forwarding cards to serve the purpose of generating test traffic and measuring it, for the most part, performance testing will require specialized test equipment. There are multiple sources of suitable equipment.
多数の10 Gb / sまたは100 Gb / sリンクをサポートする機器のパケットレートパフォーマンスは、デスクトップコンピューターまたはワークステーションでは使用できません。テストトラフィックのソースとしてのハイエンドワークステーションの使用は、20年前にはほとんど実行できませんでしたが、もはや実行可能ではありません。カスタムマイクロコードは、テストトラフィックを生成して測定する目的で専用のルーターフォワーディングカードで使用されていますが、ほとんどの場合、パフォーマンステストには専用のテスト機器が必要です。適切な機器の複数のソースがあります。
The set of tests listed here do not correspond one-to-one to the set of questions in Section 3. The same categorization is used, and these tests largely serve to validate answers provided to the prior questions. They can also provide answers where a supplier is unwilling to disclose compliance or performance.
ここにリストされている一連のテストは、セクション3の一連の質問に1対1で対応していません。同じ分類が使用され、これらのテストは主に、前の質問に対する回答の検証に役立ちます。また、サプライヤーがコンプライアンスやパフォーマンスを開示することを望まない場合の回答も提供できます。
Performance testing is the domain of the IETF Benchmark Methodology Working Group (BMWG). Below are brief descriptions of conformance and performance tests. Some very basic tests, specified in [RFC5695], partially cover only the basic performance test T#3.
パフォーマンステストは、IETFベンチマーク方法論ワーキンググループ（BMWG）のドメインです。以下は、適合性テストとパフォーマンステストの簡単な説明です。 [RFC5695]で指定されている一部の非常に基本的なテストは、基本的なパフォーマンステストT＃3のみを部分的にカバーしています。
The following tests should be performed by the systems designer or deployer; or, if it is not practical for the potential customer to perform the tests directly, they may be performed by the supplier on their behalf. These tests are grouped into broad categories.
以下のテストは、システム設計者または配備担当者が実行する必要があります。または、潜在的な顧客が直接テストを実行することが実用的でない場合は、サプライヤーに代わってテストを実行する場合があります。これらのテストは、幅広いカテゴリに分類されています。
The tests in Section 4.1 should be repeated under various conditions to retest basic performance when critical capabilities are enabled. Complete repetition of the performance tests enabling each capability and combinations of capabilities would be very time intensive; therefore, a reduced set of performance tests can be used to gauge the impact of enabling specific capabilities.
重要な機能が有効になっている場合、セクション4.1のテストをさまざまな条件下で繰り返して、基本的なパフォーマンスを再テストする必要があります。各機能と機能の組み合わせを有効にするパフォーマンステストを完全に繰り返すと、非常に時間がかかります。したがって、特定の機能を有効にした場合の影響を測定するために、パフォーマンステストの数を減らすことができます。
T#1 Test forwarding at a high rate for packets with varying number of label entries. While packets with more than a dozen label entries are unlikely to be used in any practical scenario today, it is useful to know if limitations exists.
T＃1さまざまな数のラベルエントリを持つパケットの高速転送をテストします。 1ダースを超えるラベルエントリを持つパケットは、今日の実際のシナリオではほとんど使用されませんが、制限が存在するかどうかを知ることは役立ちます。
T#2 For each of the questions listed under "Basic Compliance" in Section 3, verify the claimed compliance. For any functionality considered critical to a deployment, the applicable performance using each capability under load should be verified in addition to basic compliance.
T＃2セクション3の「基本コンプライアンス」に記載されている各質問について、主張されているコンプライアンスを確認します。展開に不可欠と見なされる機能については、基本的なコンプライアンスに加えて、負荷がかかった状態で各機能を使用して適用できるパフォーマンスを確認する必要があります。
T#3 Test packet forwarding at full line rate with small packets. See [RFC5695]. The most likely case to fail is the smallest packet size. Also, test with packet sizes in 4-byte increments ranging from payload sizes of 40 to 128 bytes.
T＃3小さなパケットでフルラインレートでパケット転送をテストします。 [RFC5695]を参照してください。失敗する可能性が最も高いのは、最小のパケットサイズです。また、ペイロードサイズが40〜128バイトの4バイト単位のパケットサイズでテストします。
T#4 If the prior tests did not succeed for all packet sizes, then perform the following tests.
T＃4前のテストがすべてのパケットサイズに対して成功しなかった場合は、次のテストを実行します。
A. Increase the packet size by 4 bytes until a size is found that can be forwarded at full rate.
A.フルレートで転送できるサイズが見つかるまで、パケットサイズを4バイト増やします。
B. Inject bursts of consecutive small packets into a stream of larger packets. Allow some time for recovery between bursts. Increase the number of packets in the burst until packets are dropped.
B.連続する小さなパケットのバーストを大きなパケットのストリームに注入します。バースト間の回復にはしばらく時間がかかります。パケットがドロップされるまで、バースト内のパケット数を増やします。
T#5 Send test traffic where a swap operation is required. Also set up multiple LSPs carried over other LSPs where the device under test (DUT) is the egress of these LSPs. Create test packets such that the swap operation is performed after pop operations, increasing the number of pop operations until forwarding of small packets at full line rate can no longer be supported. Also, check to see how many pop operations can be supported before the full set of counters can no longer be maintained. This requirement is particularly relevant for MPLS-TP.
T＃5スワップ操作が必要な場所にテストトラフィックを送信します。また、他のLSPを介して伝送される複数のLSPをセットアップします。テスト対象のデバイス（DUT）は、これらのLSPの出力です。 pop操作の後にswap操作が実行されるようにテストパケットを作成し、フルラインレートでの小さなパケットの転送がサポートされなくなるまでpop操作の数を増やします。また、カウンターの完全なセットを維持できなくなる前に、いくつのポップ操作をサポートできるかを確認してください。この要件は、特にMPLS-TPに関連しています。
T#6 Send all traffic on one LSP and see if the counters become inaccurate. Often, counters on silicon are much smaller than the 64-bit packet and byte counters in various IETF MIBs. System developers should consider what counter polling rate is necessary to maintain accurate counters and whether those polling rates are practical. Relevant MIBs for MPLS are discussed in [RFC4221] and [RFC6639].
T＃6 1つのLSPですべてのトラフィックを送信し、カウンターが不正確になるかどうかを確認します。多くの場合、シリコン上のカウンターは、さまざまなIETF MIBの64ビットパケットおよびバイトカウンターよりもはるかに小さいです。システム開発者は、正確なカウンターを維持するために必要なカウンターポーリングレートと、それらのポーリングレートが実用的かどうかを検討する必要があります。 MPLSに関連するMIBについては、[RFC4221]および[RFC6639]で説明されています。
T#7 [RFC6894] provides a good basis for MPLS FRR testing. Similar testing should be performed to determine restoration times; however, this testing is far more difficult to perform due to the need for a simulated test topology that is capable of simulating the signaling used in restoration. The simulated topology should be comparable with the target deployment in the number of nodes and links and in resource usage flooding and setup delays. Some commercial test equipment can support this type of testing.
T＃7 [RFC6894]は、MPLS FRRテストの優れた基礎を提供します。復元時間を決定するには、同様のテストを実行する必要があります。ただし、復元で使用されるシグナリングをシミュレートできるシミュレートされたテストトポロジが必要なため、このテストははるかに困難です。シミュレートされたトポロジは、ノードとリンクの数、およびリソース使用量のフラッディングとセットアップの遅延において、ターゲット展開と同等でなければなりません。一部の商用テスト機器は、このタイプのテストをサポートできます。
Multipath capabilities do not apply to MPLS-TP but apply to MPLS and apply if MPLS-TP is carried in MPLS.
マルチパス機能はMPLS-TPには適用されませんが、MPLSに適用され、MPLS-TPがMPLSで伝送される場合に適用されます。
T#8 Send traffic at a rate well exceeding the capacity of a single multipath component link, and where entropy exists only below the top of stack. If only the top label is used, this test will fail immediately.
T＃8単一のマルチパスコンポーネントリンクの容量を十分に超える速度でトラフィックを送信します。エントロピーはスタックの最上部の下にのみ存在します。トップラベルのみが使用されている場合、このテストはすぐに失敗します。
T#9 Move the labels with entropy down in the stack until either the full forwarding rate can no longer be supported or most or all packets try to use the same component link.
T＃9エントロピー付きのラベルをスタック内で下に移動し、完全な転送レートがサポートされなくなるか、ほとんどまたはすべてのパケットが同じコンポーネントリンクを使用しようとするまで待ちます。
T#10 Repeat the two tests above with the entropy contained in IP headers or IP payload fields below the label stack rather than in the label stack. Test with the set of IP headers or IP payload fields considered relevant to the deployment or to the target market.
T＃10ラベルスタックではなく、ラベルスタックの下のIPヘッダーまたはIPペイロードフィールドに含まれるエントロピーを使用して、上記の2つのテストを繰り返します。展開またはターゲット市場に関連すると見なされるIPヘッダーまたはIPペイロードフィールドのセットを使用してテストします。
T#11 Determine whether traffic that contains a pseudowire Control Word is interpreted as IP traffic. Information in the payload MUST NOT be used in the load balancing if the first nibble of the packet is not 4 or 6 (IPv4 or IPv6).
T＃11疑似配線制御ワードを含むトラフィックがIPトラフィックとして解釈されるかどうかを確認します。パケットの最初のニブルが4または6（IPv4またはIPv6）ではない場合、ペイロードの情報をロードバランシングで使用してはなりません（MUST NOT）。
T#12 Determine whether special-purpose labels and extended special-purpose labels are excluded from the label stack hash. They MUST be excluded.
T＃12特殊用途ラベルと拡張特殊用途ラベルがラベルスタックハッシュから除外されるかどうかを決定します。それらは除外されなければなりません。
T#13 Perform testing in the presence of combinations of:
T＃13次の組み合わせがある場合にテストを実行します。
A. Very large microflows.
A.非常に大きなマイクロフロー。
B. Relatively short-lived high-capacity flows.
B.比較的短期間の大容量フロー。
C. Extremely large numbers of flows.
C.非常に多数のフロー。
D. Very short-lived small flows.
D.非常に短命な小さな流れ。
T#14 Ensure that pseudowire can be set up with a pseudowire label and pseudowire Control Word added at ingress and the pseudowire label and pseudowire Control Word removed at egress.
T＃14疑似配線が、入力で追加された疑似配線ラベルと疑似配線制御ワード、および出力で削除された疑似配線ラベルと疑似配線制御ワードでセットアップできることを確認します。
T#15 For pseudowire that contains variable-length payload packets, repeat performance tests listed under "Basic Performance" for pseudowire ingress and egress functions.
T＃15可変長ペイロードパケットを含む疑似配線の場合、疑似配線の入出力機能について、「基本的なパフォーマンス」に記載されているパフォーマンステストを繰り返します。
T#16 Repeat pseudowire performance tests with and without a pseudowire Control Word.
T＃16疑似配線制御ワードを使用して、または使用せずに疑似配線パフォーマンステストを繰り返します。
T#17 Determine whether pseudowire can be set up with a pseudowire label, Flow Label, and pseudowire Control Word added at ingress and the pseudowire label, Flow Label, and pseudowire Control Word removed at egress.
T＃17疑似配線を、入力で追加された疑似配線ラベル、フローラベル、および疑似配線制御ワードで設定でき、出力で削除された疑似配線ラベル、フローラベル、および疑似配線制御ワードで設定できるかどうかを決定します。
T#18 Determine which payload fields are used to create the Flow Label and whether the set of fields and algorithm provide sufficient entropy for load balancing.
T＃18フローラベルの作成に使用されるペイロードフィールドと、フィールドとアルゴリズムのセットがロードバランシングに十分なエントロピーを提供するかどうかを決定します。
T#19 Repeat pseudowire performance tests with Flow Labels included.
T＃19フローラベルを含めて、疑似配線パフォーマンステストを繰り返します。
T#20 Determine whether Entropy Labels can be added at ingress and removed at egress.
T＃20エントロピーラベルを入口で追加し、出口で削除できるかどうかを決定します。
T#21 Determine which fields are used to create an Entropy Label. Labels further down in the stack, including Entropy Labels further down and IP headers or IP payload fields where applicable, should be used. Determine whether the set of fields and algorithm provide sufficient entropy for load balancing.
T＃21エントロピーラベルの作成に使用するフィールドを決定します。スタックのさらに下のラベル（さらに下のエントロピーラベル、該当する場合はIPヘッダーまたはIPペイロードフィールドなど）を使用する必要があります。フィールドとアルゴリズムのセットがロードバランシングに十分なエントロピーを提供するかどうかを判断します。
T#22 Repeat performance tests under "Basic Performance" when Entropy Labels are used, where ingress or egress is the device under test (DUT).
T＃22エントロピーラベルが使用されている場合、「基本パフォーマンス」の下でパフォーマンステストを繰り返します。ここで、入力または出力はテスト対象デバイス（DUT）です。
T#23 Determine whether an ELI is detected when acting as a midpoint LSR and whether the search for further information on which to base the load balancing is used. Information below the Entropy Label SHOULD NOT be used.
T＃23中点LSRとして機能しているときにELIが検出されるかどうか、およびロードバランシングのベースとなる詳細情報の検索が使用されるかどうかを決定します。エントロピーラベルの下の情報は使用しないでください。
T#24 Ensure that the Entropy Label indicator and Entropy Label (ELI and EL) are removed from the label stack during UHP and PHP operations.
T＃24エントロピーラベルインジケーターとエントロピーラベル（ELIおよびEL）がUHPおよびPHP操作中にラベルスタックから削除されていることを確認します。
T#25 Ensure that operations on the TC field when adding and removing Entropy Label are correctly carried out. If TC is changed during a swap operation, the ability to transfer that change MUST be provided. The ability to suppress the transfer of TC MUST also be provided. See the pipe, short-pipe, and uniform models in [RFC3443].
T＃25エントロピーラベルを追加および削除するときのTCフィールドの操作が正しく実行されることを確認します。スワップ操作中にTCが変更された場合、その変更を転送する機能を提供する必要があります。 TCの転送を抑制する機能も提供する必要があります。 [RFC3443]のパイプ、ショートパイプ、ユニフォームモデルを参照してください。
T#26 Repeat performance tests for a midpoint LSR with Entropy Labels found at various label stack depths.
T＃26さまざまなラベルスタックの深さにあるエントロピーラベルを使用して、ミッドポイントLSRのパフォーマンステストを繰り返します。
T#27 Actively attack LSRs under high protocol churn load and determine control-plane performance impact or successful DoS under test conditions. Specifically, test for the following.
T＃27プロトコルチャーンの負荷が高い状態でLSRを積極的に攻撃し、テスト条件下でコントロールプレーンのパフォーマンスへの影響または成功したDoSを特定します。具体的には、以下についてテストします。
A. TCP SYN attack against control-plane and management-plane protocols using TCP, including CLI access (typically SSH-protected login), NETCONF, etc.
A. CLIアクセス（通常はSSHで保護されたログイン）、NETCONFなどを含む、TCPを使用したコントロールプレーンおよび管理プレーンプロトコルに対するTCP SYN攻撃
B. High traffic volume attack against control-plane and management-plane protocols not using TCP.
B. TCPを使用しないコントロールプレーンおよび管理プレーンプロトコルに対する大量のトラフィック攻撃。
C. Attacks that can be performed from a compromised management subnet computer, but not one with authentication keys.
C.侵害された管理サブネットコンピューターから実行できるが、認証キーを持つコンピューターからは実行できない攻撃。
D. Attacks that can be performed from a compromised peer within the control plane (internal domain and external domain). Assume that keys that are per peering and keys that are per router ID, rather than network-wide keys, are in use.
D.コントロールプレーン（内部ドメインおよび外部ドメイン）内の侵害されたピアから実行できる攻撃。ネットワーク全体のキーではなく、ピアリングごとのキーとルーターIDごとのキーが使用されていると想定します。
See Section 2.6.1.
セクション2.6.1を参照してください。
T#28 Determine maximum sustainable rates of BFD traffic. If BFD requires CPU intervention, determine both maximum rates and CPU loading when multiple interfaces are active.
T＃28 BFDトラフィックの最大持続可能レートを決定します。 BFDがCPUの介入を必要とする場合、複数のインターフェイスがアクティブな場合の最大レートとCPU負荷の両方を決定します。
T#29 Verify LSP Ping and LSP Traceroute capability.
T＃29 LSP pingおよびLSP Traceroute機能を確認します。
T#30 Determine maximum rates of MPLS-TP CC-CV traffic. If CC-CV requires CPU intervention, determine both maximum rates and CPU loading when multiple interfaces are active.
T＃30 MPLS-TP CC-CVトラフィックの最大レートを決定します。 CC-CVでCPUの介入が必要な場合は、複数のインターフェイスがアクティブな場合の最大レートとCPU負荷の両方を決定します。
T#31 Determine MPLS-TP DM precision.
T＃31 MPLS-TP DMの精度を決定します。
T#32 Determine MPLS-TP LM accuracy.
T＃32 MPLS-TP LMの精度を決定します。
T#33 Verify MPLS-TP AIS/RDI and Protection State Coordination (PSC) functionality, protection speed, and AIS/RDI notification speed when a large number of Maintenance Entities (MEs) must be notified with AIS/RDI.
T＃33多数のメンテナンスエンティティ（ME）にAIS / RDIで通知する必要がある場合は、MPLS-TP AIS / RDIおよび保護状態調整（PSC）機能、保護速度、およびAIS / RDI通知速度を確認します。
This document reviews forwarding behavior specified elsewhere and points out compliance and performance requirements. As such, it introduces no new security requirements or concerns.
このドキュメントでは、他の場所で指定されている転送動作を確認し、コンプライアンスとパフォーマンスの要件を指摘します。そのため、新しいセキュリティ要件や懸念事項はありません。
Discussion of hardware support and other equipment hardening against DoS attack can be found in Section 2.6.1. Section 3.6 provides a list of questions regarding DoS to be asked of suppliers. Section 4.6 suggests types of testing that can provide some assurance of the effectiveness of a supplier's claims about DoS hardening.
DoS攻撃に対するハードウェアサポートおよびその他の機器の強化については、2.6.1項を参照してください。セクション3.6は、サプライヤーに尋ねられるDoSに関する質問のリストを提供します。セクション4.6は、DoS強化に関するサプライヤーの主張の有効性をある程度保証できる種類のテストを提案しています。
Knowledge of potential performance shortcomings may serve to help new implementations avoid pitfalls. It is unlikely that such knowledge could be the basis of new denial of service, as these pitfalls are already widely known in the service provider community and among leading equipment suppliers. In practice, extreme data and packet rates are needed to affect existing equipment and to affect networks that may be still vulnerable due to failure to implement adequate protection. The extreme data and packet rates make this type of denial of service unlikely and make undetectable denial of service of this type impossible.
潜在的なパフォーマンスの欠点の知識は、新しい実装が落とし穴を回避するのに役立つ可能性があります。これらの落とし穴は、サービスプロバイダーコミュニティや主要な機器サプライヤーの間ですでに広く知られているため、このような知識が新しいサービス拒否の基礎になる可能性は低いです。実際には、既存の機器に影響を与えたり、適切な保護の実装に失敗したために依然として脆弱である可能性があるネットワークに影響を及ぼしたりするには、極端なデータおよびパケットレートが必要です。極端なデータレートとパケットレートにより、このタイプのサービス拒否は起こりにくくなり、このタイプの検出不能なサービス拒否は不可能になります。
Each normative reference contains security considerations. A brief summarization of MPLS security considerations applicable to forwarding follows:
各規範的な参照には、セキュリティに関する考慮事項が含まれています。転送に適用できるMPLSセキュリティの考慮事項の簡単な要約は次のとおりです。
1. MPLS encapsulation does not support an authentication extension. This is reflected in the security section of [RFC3032]. Documents that clarify MPLS header fields such as TTL [RFC3443], the explicit null label [RFC4182], renaming EXP to TC [RFC5462], ECN for MPLS [RFC5129], and MPLS Ethernet encapsulation [RFC5332] make no changes to security considerations in [RFC3032].
1. MPLSカプセル化は、認証拡張機能をサポートしていません。これは[RFC3032]のセキュリティセクションに反映されています。 TTL [RFC3443]、明示的なnullラベル[RFC4182]、EXPのTCへの名前変更[RFC5462]、MPLSのECN [RFC5129]、MPLSイーサネットカプセル化[RFC5332]などのMPLSヘッダーフィールドを明確にするドキュメントでは、セキュリティに関する考慮事項に変更はありません。 [RFC3032]。
2. Some cited RFCs are related to Diffserv forwarding. [RFC3270] refers to MPLS and Diffserv security. [RFC2474] mentions theft of service and denial of service due to mismarking. [RFC2474] mentions IPsec interaction, but with MPLS, not being carried by IP, the type of interaction in [RFC2474] is not relevant.
2. 引用されているRFCの一部は、Diffserv転送に関連しています。 [RFC3270]は、MPLSおよびDiffservセキュリティを指します。 [RFC2474]は、誤認によるサービスの盗難とサービス拒否について言及しています。 [RFC2474]はIPsecインタラクションについて言及していますが、IPによって運ばれないMPLSでは、[RFC2474]でのインタラクションのタイプは関係ありません。
3. [RFC3209] is cited here due only to make-before-break forwarding requirements. This is related to resource sharing and the theft-of-service and denial-of-service concerns in [RFC2474] apply.
3. [RFC3209]は、make-before-break転送要件のみのためにここで引用されています。これはリソース共有に関連し、[RFC2474]のサービスの盗難とサービス拒否の懸念が適用されます。
4. [RFC4090] defines FRR, which provides protection but does not add security concerns. RFC 4201 defines link bundling but raises no additional security concerns.
4. [RFC4090]はFRRを定義します。これは保護を提供しますが、セキュリティ上の懸念を追加しません。 RFC 4201はリンクバンドリングを定義していますが、追加のセキュリティ上の問題はありません。
5. Various OAM control channels are defined in [RFC4385] (PW CW), [RFC5085] (VCCV), and [RFC5586] (G-Ach and GAL). These documents describe potential abuse of these OAM control channels.
5. さまざまなOAM制御チャネルが[RFC4385]（PW CW）、[RFC5085]（VCCV）、および[RFC5586]（G-AchおよびGAL）で定義されています。これらのドキュメントは、これらのOAM制御チャネルの潜在的な乱用について説明しています。
6. [RFC4950] defines ICMP extensions when MPLS TTL expires and the payload is IP. This provides MPLS header information that is of no use to an IP attacker, but sending this information can be suppressed through configuration.
6. [RFC4950]は、MPLS TTLが期限切れになり、ペイロードがIPである場合のICMP拡張を定義します。これにより、IP攻撃者にとって役に立たないMPLSヘッダー情報が提供されますが、この情報の送信は構成によって抑制できます。
7. GTSM [RFC5082] provides a means to improve protection against high traffic volume spoofing as a form of DoS attack.
7. GTSM [RFC5082]は、DoS攻撃の一形態として、大量のトラフィックのなりすましに対する保護を改善する手段を提供します。
8. BFD [RFC5880] [RFC5884] [RFC5885] provides a form of OAM used in MPLS and MPLS-TP. The security considerations related to the OAM control channel are relevant. The BFD payload supports authentication. The MPLS encapsulation, the MPLS control channel, or the PW control channel, which BFD may be carried in, do not support authentication. Where an IP return OAM path is used, IPsec is suggested as a means of securing the return path.
8. BFD [RFC5880] [RFC5884] [RFC5885]は、MPLSおよびMPLS-TPで使用されるOAMの形式を提供します。 OAM制御チャネルに関連するセキュリティの考慮事項が関連します。 BFDペイロードは認証をサポートします。 BFDが含まれる可能性のあるMPLSカプセル化、MPLS制御チャネル、またはPW制御チャネルは、認証をサポートしていません。 IPリターンOAMパスが使用される場合、リターンパスを保護する手段としてIPsecが推奨されます。
9. Other forms of OAM are supported by [RFC6374] [RFC6375] (Loss and Delay Measurement), [RFC6428] (Continuity Check/Verification based on BFD), and [RFC6427] (Fault Management). The security considerations related to the OAM control channel are relevant. IP return paths, where used, can be secured with IPsec.
9. 他の形式のOAMは、[RFC6374] [RFC6375]（損失および遅延測定）、[RFC6428]（BFDに基づく継続性チェック/検証）、および[RFC6427]（障害管理）でサポートされています。 OAM制御チャネルに関連するセキュリティの考慮事項が関連します。使用される場合、IPリターンパスはIPsecで保護できます。
10. Linear protection is defined by [RFC6378] and updated by [RFC7324]. Security concerns related to MPLS encapsulation and OAM control channels apply. Security concerns reiterate [RFC5920] as applied to protection switching.
10. 線形保護は[RFC6378]によって定義され、[RFC7324]によって更新されます。 MPLSカプセル化およびOAM制御チャネルに関連するセキュリティ上の懸念が適用されます。セキュリティの懸念は、保護切り替えに適用される[RFC5920]を繰り返します。
11. The PW Flow Label [RFC6391] and MPLS Entropy Label [RFC6790] affect multipath load balancing. Security concerns reiterate [RFC5920]. Security impacts would be limited to load distribution.
11. PWフローラベル[RFC6391]およびMPLSエントロピーラベル[RFC6790]は、マルチパスロードバランシングに影響します。セキュリティの懸念は繰り返します[RFC5920]。セキュリティへの影響は、負荷分散に限定されます。
MPLS security including data-plane security is discussed in greater detail in [RFC5920] (MPLS/GMPLS Security Framework). The MPLS-TP security framework [RFC6941] builds upon this, focusing largely on the MPLS-TP OAM additions and OAM channels with some attention given to using network management in place of control-plane setup. In both security framework documents, MPLS is assumed to run within a "trusted zone", defined as being where a single service provider has total operational control over that part of the network.
データプレーンセキュリティを含むMPLSセキュリティは、[RFC5920]（MPLS / GMPLSセキュリティフレームワーク）でより詳細に説明されています。 MPLS-TPセキュリティフレームワーク[RFC6941]はこれに基づいて構築されており、主にMPLS-TP OAMの追加とOAMチャネルに焦点を当て、コントロールプレーンのセットアップの代わりにネットワーク管理を使用することに注意を払っています。どちらのセキュリティフレームワークドキュメントでも、MPLSは「信頼ゾーン」内で実行されると想定されています。これは、単一のサービスプロバイダーがネットワークのその部分を完全に運用制御する場所として定義されています。
If control-plane security and management-plane security are sufficiently robust, compromise of a single network element may result in chaos in the data plane anywhere in the network through denial-of-service attacks, but not a Byzantine security failure in which other network elements are fully compromised.
コントロールプレーンのセキュリティと管理プレーンのセキュリティが十分に堅牢である場合、単一のネットワーク要素の侵害により、サービス拒否攻撃によってネットワークのどこかにデータプレーンの混乱が生じる可能性がありますが、他のネットワークでのビザンチンセキュリティの障害は発生しません要素は完全に危険にさらされています。
MPLS security, or lack thereof, can affect whether traffic can be misrouted and lost, or intercepted, or intercepted and reinserted (a man-in-the-middle attack), or spoofed. End-user applications, including control-plane and management-plane protocols used by the service provider, are expected to make use of appropriate end-to-end authentication and, where appropriate, end-to-end encryption.
MPLSのセキュリティまたはその欠如は、トラフィックが誤ってルーティングされて失われたり、傍受されたり、傍受されて再挿入されたり（中間者攻撃）、スプーフィングされたりするかどうかに影響します。サービスプロバイダーが使用するコントロールプレーンおよび管理プレーンプロトコルを含むエンドユーザーアプリケーションは、適切なエンドツーエンドの認証と、必要に応じてエンドツーエンドの暗号化を利用することが期待されています。
The References section is split into Normative and Informative subsections. References that directly specify forwarding encapsulations or behaviors are listed as normative. References that describe signaling only, though normative with respect to signaling, are listed as informative. They are informative with respect to MPLS forwarding.
参照セクションは、規範的および情報的サブセクションに分かれています。転送のカプセル化または動作を直接指定する参照は、標準としてリストされています。シグナリングに関しては規範的ですが、シグナリングのみを説明している参考資料は、参考として記載されています。これらは、MPLS転送に関して参考になります。
[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月。
[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。、フェドルコフ、G。、レクター、Y。、ファリナッチ、D。、リー、T。、およびA.コンタ、「MPLSラベルスタックエンコーディング」、RFC 3032、2001年1月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：Extensions for RSVP for LSP Tunnels」、RFC 3209、12月2001年。
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[RFC3270] Le Faucheur、F.、Wu、L.、Davie、B.、Davari、S.、Vaananen、P.、Krishnan、R.、Cheval、P.、J. Heinanen、 "マルチプロトコルラベルスイッチング（MPLS）Support of Differentiated Services」、RFC 3270、2002年5月。
[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）ネットワークにおけるTime To Live（TTL）処理」、RFC 3443、2003年1月。
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090]パン、P。、スワロー、G。、およびA.アトラス、「LSPトンネル用のRSVP-TEへの高速リルート拡張」、RFC 4090、2005年5月。
[RFC4182] Rosen, E., "Removing a Restriction on the use of MPLS Explicit NULL", RFC 4182, September 2005.
[RFC4182]ローゼン、E。、「MPLS明示的NULLの使用に関する制限の削除」、RFC 4182、2005年9月。
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4201] Kompella、K.、Rekhter、Y。、およびL. Berger、「MPLSトラフィックエンジニアリング（TE）におけるリンクバンドリング」、RFC 4201、2005年10月。
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006.
[RFC4385]ブライアント、S。、スワロー、G。、マティーニ、L。、およびD.マクファーソン、「MPLS PSNで使用する疑似配線エミュレーションエッジツーエッジ（PWE3）制御ワード」、RFC 4385、2006年2月。
[RFC4950] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP Extensions for Multiprotocol Label Switching", RFC 4950, August 2007.
[RFC4950] Bonica、R.、Gan、D.、Tappan、D。、およびC. Pignataro、「ICMP Extensions for Multiprotocol Label Switching」、RFC 4950、2007年8月。
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007.
[RFC5082] Gill、V.、Heasley、J.、Meyer、D.、Savola、P。、およびC. Pignataro、「一般化されたTTLセキュリティメカニズム（GTSM）」、RFC 5082、2007年10月。
[RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.
[RFC5085]ナドー、T。およびC.ピグナタロ、「疑似配線仮想回線接続検証（VCCV）：疑似配線の制御チャネル」、RFC 5085、2007年12月。
[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion Marking in MPLS", RFC 5129, January 2008.
[RFC5129]デイビー、B。、ブリスコー、B。、およびJ.テイ、「MPLSでの明示的輻輳マーキング」、RFC 5129、2008年1月。
[RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS Multicast Encapsulations", RFC 5332, August 2008.
[RFC5332] Eckert、T.、Rosen、E.、Aggarwal、R。、およびY. Rekhter、「MPLSマルチキャストカプセル化」、RFC 5332、2008年8月。
[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic Associated Channel", RFC 5586, June 2009.
[RFC5586] Bocci、M.、Vigoureux、M。、およびS. Bryant、「MPLS Generic Associated Channel」、RFC 5586、2009年6月。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010.
[RFC5880] Katz、D。およびD. Ward、「Bidirectional Forwarding Detection（BFD）」、RFC 5880、2010年6月。
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010.
[RFC5884] Aggarwal、R.、Kompella、K.、Nadeau、T。、およびG. Swallow、「MPLSラベルスイッチドパス（LSP）の双方向転送検出（BFD）」、RFC 5884、2010年6月。
[RFC5885] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", RFC 5885, June 2010.
[RFC5885]ナドー、T。およびC.ピグナタロ、「疑似配線仮想回線接続検証（VCCV）のための双方向転送検出（BFD）」、RFC 5885、2010年6月。
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, September 2011.
[RFC6374] Frost、D。およびS. Bryant、「MPLSネットワークのパケット損失および遅延測定」、RFC 6374、2011年9月。
[RFC6375] Frost, D. and S. Bryant, "A Packet Loss and Delay Measurement Profile for MPLS-Based Transport Networks", RFC 6375, September 2011.
[RFC6375] Frost、D。、およびS. Bryant、「MPLSベースのトランスポートネットワークのパケット損失および遅延測定プロファイル」、RFC 6375、2011年9月。
[RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear Protection", RFC 6378, October 2011.
[RFC6378] Weingarten、Y.、Bryant、S.、Osborne、E.、Sprecher、N。、およびA. Fulignoli、「MPLS Transport Profile（MPLS-TP）Linear Protection」、RFC 6378、2011年10月。
[RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, J., and S. Amante, "Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network", RFC 6391, November 2011.
[RFC6391]ブライアント、S。、フィルスフィルス、C。、ドラフズ、U。、コンペラ、V。、リーガン、J。、およびS.アマンテ、「MPLSパケット交換ネットワーク上の疑似配線のフロー対応トランスポート」、RFC 6391 、2011年11月。
[RFC6427] Swallow, G., Fulignoli, A., Vigoureux, M., Boutros, S., and D. Ward, "MPLS Fault Management Operations, Administration, and Maintenance (OAM)", RFC 6427, November 2011.
[RFC6427] Swallow、G.、Fulignoli、A.、Vigoureux、M.、Boutros、S。、およびD. Ward、「MPLS Fault Management Operations、Administration、and Maintenance（OAM）」、RFC 6427、2011年11月。
[RFC6428] Allan, D., Swallow Ed. , G., and J. Drake Ed. , "Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile", RFC 6428, November 2011.
[RFC6428]アラン、D。、スワローエド。 、G.、J。ドレイクエド。 、「MPLSトランスポートプロファイルのプロアクティブ接続検証、継続性チェック、およびリモート障害表示」、RFC 6428、2011年11月。
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, November 2012.
[RFC6790] Kompella、K.、Drake、J.、Amante、S.、Henderickx、W。、およびL. Yong、「The Use of Entropy Labels in MPLS Forwarding」、RFC 6790、2012年11月。
[RFC7324] Osborne, E., "Updates to MPLS Transport Profile Linear Protection", RFC 7324, July 2014.
[RFC7324] Osborne、E。、「Updates to MPLS Transport Profile Linear Protection」、RFC 7324、2014年7月。
[ACK-compression] Zhang, L., Shenker, S., and D. Clark, "Observations and Dynamics of a Congestion Control Algorithm: The Effects of Two-Way Traffic", Proc. ACM SIGCOMM, ACM Computer Communications Review (CCR) Vol. 21, No. 4, pp. 133-147., 1991.
[ACK圧縮] Zhang、L.、Shenker、S。、およびD. Clark、「輻輳制御アルゴリズムの観察とダイナミクス：双方向トラフィックの影響」、Proc。 ACM SIGCOMM、ACM Computer Communications Review（CCR）Vol。 21、No。4、133-147ページ、1991年。
[MPLS-IN-UDP] Xu, X., Sheth, N., Yong, L., Pignataro, C., and F. Yongbing, "Encapsulating MPLS in UDP", Work in Progress, January 2014.
[MPLS-IN-UDP] Xu、X.、Sheth、N.、Yong、L.、Pignataro、C。、およびF. Yongbing、「UDPでのMPLSのカプセル化」、進行中の作業、2014年1月。
[MRT] Atlas, A., Kebler, R., Bowers, C., Envedi, G., Csaszar, A., Tantsura, J., Konstantynowicz, M., and R. White, "An Architecture for IP/LDP Fast-Reroute Using Maximally Redundant Trees", Work in Progress, July 2014.
[MRT] Atlas、A.、Kebler、R.、Bowers、C.、Envedi、G.、Csaszar、A.、Tantsura、J.、Konstantynowicz、M。、およびR. White、「An Architecture for IP / LDP最大限に冗長なツリーを使用した高速ルート変更」、作業中、2014年7月。
[REMOTE-LFA] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and S. Ning, "Remote LFA FRR", Work in Progress, May 2014.
[REMOTE-LFA]ブライアント、S。、フィルスフィルス、C。、プレビディ、S。、シャンド、M。、およびS.ニン、「リモートLFA FRR」、作業中、2014年5月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「Definition of the Differentiated Services Field（DS Field）in the IPv4 and IPv6 Headers」、RFC 2474、1998年12月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z。、およびW. Weiss、「An Architecture for Differentiated Services」、RFC 2475、1998年12月。
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC2597] Heinanen、J.、Baker、F.、Weiss、W。、およびJ. Wroclawski、「Assured Forwarding PHB Group」、RFC 2597、1999年6月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]ローゼン、E。、ヴィスワナサン、A。、およびR.キャロン、「マルチプロトコルラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168]ラマクリシュナン、K。、フロイド、S。、およびD.ブラック、「IPへの明示的輻輳通知（ECN）の追加」、RFC 3168、2001年9月。
[RFC3429] Ohta, H., "Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions", RFC 3429, November 2002.
[RFC3429]太田浩一郎、「マルチプロトコルラベルスイッチングアーキテクチャ（MPLS）運用および保守（OAM）機能のための「OAMアラートラベル」の割り当て」、RFC 3429、2002年11月。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471] Berger、L。、「Generalized Multi-Protocol Label Switching（GMPLS）Signaling Functional Description」、RFC 3471、2003年1月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、2003年7月。
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004.
[RFC3828] Larzon、L-A。、Degermark、M.、Pink、S.、Jonsson、L-E。、およびG. Fairhurst、「The Lightweight User Datagram Protocol（UDP-Lite）」、RFC 3828、2004年7月。
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985]ブライアント、S。およびP.パテ、「疑似ワイヤーエミュレーションエッジツーエッジ（PWE3）アーキテクチャ」、RFC 3985、2005年3月。
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005.
[RFC4023] Worster、T.、Rekhter、Y。、およびE. Rosen、「IPまたはGeneric Routing Encapsulation（GRE）でのMPLSのカプセル化」、RFC 4023、2005年3月。
[RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4110, July 2005.
[RFC4110] Callon、R。およびM.鈴木、「A Layer Framework for Layer 3 Provider-Provisioned Virtual Private Networks（PPVPNs）」、RFC 4110、2005年7月。
[RFC4124] Le Faucheur, F., "Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering", RFC 4124, June 2005.
[RFC4124] Le Faucheur、F。、「Diffserv対応のMPLSトラフィックエンジニアリングをサポートするためのプロトコル拡張」、RFC 4124、2005年6月。
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC4206] Kompella、K。、およびY. Rekhter、「Label Switched Paths（LSP）Hierarchy with Generalized Multi-Protocol Label Switching（GMPLS）Traffic Engineering（TE）」、RFC 4206、2005年10月。
[RFC4221] Nadeau, T., Srinivasan, C., and A. Farrel, "Multiprotocol Label Switching (MPLS) Management Overview", RFC 4221, November 2005.
[RFC4221] Nadeau、T.、Srinivasan、C。、およびA. Farrel、「Multiprotocol Label Switching（MPLS）Management Overview」、RFC 4221、2005年11月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340] Kohler、E.、Handley、M。、およびS. Floyd、「Datagram Congestion Control Protocol（DCCP）」、RFC 4340、2006年3月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]ローゼン、E。およびY.レクター、「BGP / MPLS IP仮想プライベートネットワーク（VPN）」、RFC 4364、2006年2月。
[RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. Matsushima, "Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks", RFC 4377, February 2006.
[RFC4377] Nadeau、T.、Morrow、M.、Swallow、G.、Allan、D。、およびS. Matsushima、「Operations and Management（OAM）Requirements for Multi-Protocol Label Switched（MPLS）Networks」、RFC 4377 、2006年2月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379] Kompella、K。およびG. Swallow、「Detecting Multi-Protocol Label Switched（MPLS）Data Plane Failures」、RFC 4379、2006年2月。
[RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006.
[RFC4664] Andersson、L.およびE. Rosen、「Framework for Layer 2 Virtual Private Networks（L2VPNs）」、RFC 4664、2006年9月。
[RFC4817] Townsley, M., Pignataro, C., Wainner, S., Seely, T., and J. Young, "Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3", RFC 4817, March 2007.
[RFC4817] Townsley、M.、Pignataro、C.、Wainner、S.、Seely、T。、およびJ. Young、「MPLS over Layer 2 Tunneling Protocol Version 3」、RFC 4817、2007年3月。
[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC4875] Aggarwal、R.、Papadimitriou、D。、およびS. Yasukawa、「Extensions to Resource Reservation Protocol-Traffic Engineering（RSVP-TE）for Point-to-Multipoint TE Label Switched Paths（LSPs）」、RFC 4875、 2007年5月。
[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、「Amping Equal Cost Multipath Treatment in MPLS Networks」、BCP 128、RFC 4928、2007年6月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R。、「Stream Control Transmission Protocol」、RFC 4960、2007年9月。
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007.
[RFC5036] Andersson、L.、Minei、I。、およびB. Thomas、「LDP仕様」、RFC 5036、2007年10月。
[RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, September 2008.
[RFC5286] Atlas、A。およびA. Zinin、「IP Fast Rerouteの基本仕様：ループフリー代替」、RFC 5286、2008年9月。
[RFC5317] Bryant, S. and L. Andersson, "Joint Working Team (JWT) Report on MPLS Architectural Considerations for a Transport Profile", RFC 5317, February 2009.
[RFC5317]ブライアント、S。およびL.アンダーソン、「トランスポートプロファイルのMPLSアーキテクチャに関する考慮事項に関する共同作業チーム（JWT）レポート」、RFC 5317、2009年2月。
[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。およびR. Asati、「Multiprotocol Label Switching（MPLS）Label Stack Entry： "EXP" Field Renamed to "Traffic Class" Field」、RFC 5462、2009年2月。
[RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture for IP Flow Information Export", RFC 5470, March 2009.
[RFC5470] Sadasivan、G.、Brownlee、N.、Claise、B。、およびJ. Quittek、「Architecture for IP Flow Information Export」、RFC 5470、2009年3月。
[RFC5640] Filsfils, C., Mohapatra, P., and C. Pignataro, "Load-Balancing for Mesh Softwires", RFC 5640, August 2009.
[RFC5640] Filsfils、C.、Mohapatra、P。、およびC. Pignataro、「メッシュソフトワイヤーのロードバランシング」、RFC 5640、2009年8月。
[RFC5695] Akhter, A., Asati, R., and C. Pignataro, "MPLS Forwarding Benchmarking Methodology for IP Flows", RFC 5695, November 2009.
[RFC5695] Akhter、A.、Asati、R。、およびC. Pignataro、「IPフローのMPLS転送ベンチマーク手法」、RFC 5695、2009年11月。
[RFC5704] Bryant, S., Morrow, M., and IAB, "Uncoordinated Protocol Development Considered Harmful", RFC 5704, November 2009.
[RFC5704]ブライアント、S。、モロー、M。、およびIAB、「有害な非協調型プロトコル開発」、RFC 5704、2009年11月。
[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 5714, January 2010.
[RFC5714] Shand、M。、およびS. Bryant、「IP Fast Reroute Framework」、RFC 5714、2010年1月。
[RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free Convergence", RFC 5715, January 2010.
[RFC5715] Shand、M。およびS. Bryant、「A Loopwork for Loop-Free Convergence」、RFC 5715、2010年1月。
[RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks", RFC 5860, May 2010.
[RFC5860] Vigoureux、M.、Ward、D。、およびM. Betts、「MPLSトランスポートネットワークの運用、管理、および保守（OAM）の要件」、RFC 5860、2010年5月。
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.
[RFC5905] Mills、D.、Martin、J.、Burbank、J。、およびW. Kasch、「Network Time Protocol Version 4：Protocol and Algorithms Specification」、RFC 5905、2010年6月。
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920] Fang、L。、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、2010年7月。
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, D., and S. Mansfield, "Guidelines for the Use of the "OAM" Acronym in the IETF", BCP 161, RFC 6291, June 2011.
[RFC6291] Andersson、L.、van Helvoort、H.、Bonica、R.、Romascanu、D。、およびS. Mansfield、「IETFでの「OAM」の頭字語の使用に関するガイドライン」、BCP 161、RFC 6291 、2011年6月。
[RFC6310] Aissaoui, M., Busschbach, P., Martini, L., Morrow, M., Nadeau, T., and Y(J). Stein, "Pseudowire (PW) Operations, Administration, and Maintenance (OAM) Message Mapping", RFC 6310, July 2011.
[RFC6310] Aissaoui、M.、Busschbach、P.、Martini、L.、Morrow、M.、Nadeau、T.、and Y（J）。 Stein、「Pseudowire（PW）Operations、Administration、and Maintenance（OAM）Message Mapping」、RFC 6310、2011年7月。
[RFC6371] Busi, I. and D. Allan, "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, September 2011.
[RFC6371] Busi、I。およびD. Allan、「Operations、Administration、and Maintenance Framework for MPLS-Based Transport Networks」、RFC 6371、2011年9月。
[RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, November 2011.
[RFC6388] Wijnands、IJ。、Minei、I.、Kompella、K。、およびB. Thomas、「ポイントツーマルチポイントおよびマルチポイントツーマルチポイントラベルスイッチドパスのラベル配布プロトコル拡張」、RFC 6388、2011年11月。
[RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for Performing Label Switched Path Ping (LSP Ping) over MPLS Tunnels", RFC 6424, November 2011.
[RFC6424] Bahadur、N.、Kompella、K。、およびG. Swallow、「MPLSトンネルを介したラベルスイッチドパスPing（LSP Ping）の実行メカニズム」、RFC 6424、2011年11月。
[RFC6425] Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa, S., and T. Nadeau, "Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 6425, November 2011.
[RFC6425] Saxena、S.、Swallow、G.、Ali、Z.、Farrel、A。、安川S、およびT. Nadeau、「ポイントツーマルチポイントMPLSでのデータプレーン障害の検出-LSPの拡張Ping」、RFC 6425、2011年11月。
[RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS On-Demand Connectivity Verification and Route Tracing", RFC 6426, November 2011.
[RFC6426]グレイ、E、バハドゥール、N、ブトロス、S、およびRアガーワル、「MPLSオンデマンド接続検証およびルートトレース」、RFC 6426、2011年11月。
[RFC6435] Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux, M., and X. Dai, "MPLS Transport Profile Lock Instruct and Loopback Functions", RFC 6435, November 2011.
[RFC6435] Boutros、S.、Sivabalan、S.、Aggarwal、R.、Vigoureux、M.、and X. Dai、 "MPLS Transport Profile Lock Instruct and Loopback Functions"、RFC 6435、November 2011。
[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels", RFC 6438, November 2011.
[RFC6438] Carpenter、B。およびS. Amante、「IPv6フローラベルを使用したトンネルでの等コストマルチパスルーティングおよびリンク集約」、RFC 6438、2011年11月。
[RFC6478] Martini, L., Swallow, G., Heron, G., and M. Bocci, "Pseudowire Status for Static Pseudowires", RFC 6478, May 2012.
[RFC6478]マティーニ、L。、スワロー、G。、ヘロン、G。、およびM.ボッチ、「静的な疑似配線の疑似配線ステータス」、RFC 6478、2012年5月。
[RFC6639] King, D. and M. Venkatesan, "Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-Based Management Overview", RFC 6639, June 2012.
[RFC6639] King、D。、およびM. Venkatesan、「Multiprotocol Label Switching Transport Profile（MPLS-TP）MIB-Based Management Overview」、RFC 6639、2012年6月。
[RFC6669] Sprecher, N. and L. Fang, "An Overview of the Operations, Administration, and Maintenance (OAM) Toolset for MPLS-Based Transport Networks", RFC 6669, July 2012.
[RFC6669] Sprecher、N。およびL. Fang、「MPLSベースのトランスポートネットワークの運用、管理、および保守（OAM）ツールセットの概要」、RFC 6669、2012年7月。
[RFC6670] Sprecher, N. and KY. Hong, "The Reasons for Selecting a Single Solution for MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM)", RFC 6670, July 2012.
[RFC6670] Sprecher、N.、KY。 Hong、「MPLSトランスポートプロファイル（MPLS-TP）運用、管理、および保守（OAM）の単一ソリューションを選択する理由」、RFC 6670、2012年7月。
[RFC6720] Pignataro, C. and R. Asati, "The Generalized TTL Security Mechanism (GTSM) for the Label Distribution Protocol (LDP)", RFC 6720, August 2012.
[RFC6720] Pignataro、C。およびR. Asati、「Label Distribution Protocol（LDP）の一般化されたTTLセキュリティメカニズム（GTSM）」、RFC 6720、2012年8月。
[RFC6829] Chen, M., Pan, P., Pignataro, C., and R. Asati, "Label Switched Path (LSP) Ping for Pseudowire Forwarding Equivalence Classes (FECs) Advertised over IPv6", RFC 6829, January 2013.
[RFC6829] Chen、M.、Pan、P.、Pignataro、C。、およびR. Asati、「IPv6経由でアドバタイズされる疑似回線転送等価クラス（FEC）のラベルスイッチドパス（LSP）ping」、RFC 6829、2013年1月。
[RFC6894] Papneja, R., Vapiwala, S., Karthik, J., Poretsky, S., Rao, S., and JL. Le Roux, "Methodology for Benchmarking MPLS Traffic Engineered (MPLS-TE) Fast Reroute Protection", RFC 6894, March 2013.
[RFC6894] Papneja、R.、Vapiwala、S.、Kartik、J.、Poretsky、S.、Rao、S。、およびJL。 Le Roux、「MPLSトラフィックエンジニアリング（MPLS-TE）高速リルート保護のベンチマーク手法」、RFC 6894、2013年3月。
[RFC6941] Fang, L., Niven-Jenkins, B., Mansfield, S., and R. Graveman, "MPLS Transport Profile (MPLS-TP) Security Framework", RFC 6941, April 2013.
[RFC6941] Fang、L.、Niven-Jenkins、B.、Mansfield、S。、およびR. Graveman、「MPLS Transport Profile（MPLS-TP）Security Framework」、RFC 6941、2013年4月。
[RFC6981] Bryant, S., Previdi, S., and M. Shand, "A Framework for IP and MPLS Fast Reroute Using Not-Via Addresses", RFC 6981, August 2013.
[RFC6981] Bryant、S.、Previdi、S。、およびM. Shand、「Not-Viaアドレスを使用したIPおよびMPLS高速リルートのフレームワーク」、RFC 6981、2013年8月。
[RFC7012] Claise, B. and B. Trammell, "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, September 2013.
[RFC7012] Claise、B。およびB. Trammell、「IPフロー情報エクスポート（IPFIX）の情報モデル」、RFC 7012、2013年9月。
[RFC7023] Mohan, D., Bitar, N., Sajassi, A., DeLord, S., Niger, P., and R. Qiu, "MPLS and Ethernet Operations, Administration, and Maintenance (OAM) Interworking", RFC 7023, October 2013.
[RFC7023] Mohan、D.、Bitar、N.、Sajassi、A.、DeLord、S.、Niger、P。、およびR. Qiu、「MPLS and Ethernet Operations、Administration、and Maintenance（OAM）Interworking」、RFC 7023、2013年10月。
[RFC7074] Berger, L. and J. Meuric, "Revised Definition of the GMPLS Switching Capability and Type Fields", RFC 7074, November 2013.
[RFC7074] Berger、L.およびJ. Meuric、「改訂されたGMPLSスイッチング機能とタイプフィールドの定義」、RFC 7074、2013年11月。
[RFC7079] Del Regno, N. and A. Malis, "The Pseudowire (PW) and Virtual Circuit Connectivity Verification (VCCV) Implementation Survey Results", RFC 7079, November 2013.
[RFC7079] Del Regno、N。およびA. Malis、「Pseudowire（PW）and Virtual Circuit Connectivity Verification（VCCV）Implementation Survey Results」、RFC 7079、2013年11月。
[RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating and Retiring Special-Purpose MPLS Labels", RFC 7274, June 2014.
[RFC7274] Kompella、K.、Andersson、L。、およびA. Farrel、「特別な目的のMPLSラベルの割り当てと廃止」、RFC 7274、2014年6月。
[TIMING-OVER-MPLS] Davari, S., Oren, A., Bhatia, M., Roberts, P., and L. Montini, "Transporting Timing messages over MPLS Networks", Work in Progress, April 2014.
[TIMING-OVER-MPLS] Davari、S.、Oren、A.、Bhatia、M.、Roberts、P.、L。Montini、「Transporting Timing messages over MPLS Networks」、Work in Progress、2014年4月。
Numerous very useful comments have been received in private email. Some of these contributions are acknowledged here, approximately in chronologic order.
非常に多くの役立つコメントがプライベートメールで受信されました。これらの貢献のいくつかは、ほぼ年代順にここで認められています。
Paul Doolan provided a brief review resulting in a number of clarifications, most notably regarding on-chip vs. system buffering, 100 Gb/s link speed assumptions in the 150 Mpps figure, and handling of large microflows. Pablo Frank reminded us of the sawtooth effect in PPS vs. packet-size graphs, prompting the addition of a few paragraphs on this. Comments from Lou Berger at IETF 85 prompted the addition of Section 2.7.
Paul Doolanは、特にオンチップとシステムのバッファリング、150 Mppsの数値での100 Gb / sリンク速度の仮定、および大規模なマイクロフローの処理に関して、いくつかの明確化をもたらす簡単なレビューを提供しました。パブロ・フランクは、PPS対パケットサイズのグラフにおけるのこぎり波効果を思い出させ、これにいくつかの段落の追加を促しました。 IETF 85のLou Bergerからのコメントにより、セクション2.7が追加されました。
Valuable comments were received on the BMWG mailing list. Jay Karthik pointed out testing methodology hints that after discussion were deemed out of scope and were removed but may benefit later work in BMWG.
BMWGメーリングリストで貴重なコメントが寄せられました。 Jay Karthik氏は、テスト方法論は、議論後は範囲外と見なされ削除されたが、後のBMWGでの作業に役立つ可能性があるというヒントを指摘した。
Nabil Bitar pointed out the need to cover QoS (Differentiated Services), MPLS multicast (P2MP and MP2MP), and MPLS-TP OAM. Nabil also provided a number of clarifications to the questions and tests in Sections 3 and 4.
Nabil Bitarは、QoS（Differentiated Services）、MPLSマルチキャスト（P2MPおよびMP2MP）、およびMPLS-TP OAMをカバーする必要性を指摘しました。 Nabilはまた、セクション3と4の質問とテストについて多くの説明を提供しました。
Mark Szczesniak provided a thorough review and a number of useful comments and suggestions that improved the document.
Mark Szczesniakは、徹底的なレビューと、ドキュメントを改善するための多数の有用なコメントと提案を提供しました。
Gregory Mirsky and Thomas Beckhaus provided useful comments during the review by the MPLS Review Team.
Gregory MirskyとThomas Beckhausは、MPLSレビューチームによるレビュー中に有益なコメントを提供しました。
Tal Mizrahi provided comments that prompted clarifications regarding timestamp processing, local delivery of packets, and the need for hardware assistance in processing OAM traffic.
Tal Mizrahiは、タイムスタンプ処理、パケットのローカル配信、およびOAMトラフィックの処理におけるハードウェア支援の必要性に関する説明を促すコメントを提供しました。
Alexander (Sasha) Vainshtein pointed out errors in Section 2.1.8.1 and suggested new text that, after lengthy discussion, resulted in restating the summarization of requirements from PWE3 RFCs and more clearly stating the benefits and drawbacks of packet resequencing based on PW Sequence Number.
Alexander（Sasha）Vainshteinは、2.1.8.1項でエラーを指摘し、長い議論の結果、PWE3 RFCからの要件の要約を再説明し、PWシーケンス番号に基づくパケットの再シーケンスの利点と欠点をより明確に述べる新しいテキストを提案しました。
Loa Anderson provided useful comments and corrections prior to WGLC. Adrian Farrel provided useful comments and corrections prior as part of the AD review.
Loa Andersonは、WGLCの前に有用なコメントと修正を提供しました。 Adrian Farrelは、ADレビューの一部として、有用なコメントと修正を事前に提供しました。
Discussion with Steve Kent during SecDir review resulted in expansion of Section 5, briefly summarizing security considerations related to forwarding in normative references. Tom Petch pointed out some editorial errors in private email plus an important math error. Al Morton during OpsDir review prompted clarification in the section about the target audience, suggested more clear wording in places, and found numerous editorial errors.
SecDirのレビュー中にSteve Kentと話し合った結果、セクション5が拡張され、標準的な参照での転送に関連するセキュリティの考慮事項が簡潔に要約されました。 Tom Petchは、プライベートメールの編集上のエラーと重要な数学のエラーを指摘しました。 OpsDirのレビュー中にアルモートンは、対象読者に関するセクションの明確化を促し、場所により明確な表現を提案し、多数の編集エラーを発見しました。
Discussion with Stewart Bryant and Alia Atlas as part of IESG review resulted in coverage of IPFIX and improvements to document coverage of MPLS FRR, and IP/LDP FRR, plus some corrections to the text elsewhere.
IESGレビューの一部としてのスチュワートブライアントとアリアアトラスとのディスカッションの結果、IPFIXのカバレッジとMPLS FRR、IP / LDP FRRのドキュメントカバレッジの改善に加えて、他のテキストへのいくつかの修正が行われました。
Authors' Addresses
著者のアドレス
Curtis Villamizar (editor) Outer Cape Cod Network Consulting, LLC
Curtis Villamizar（編集者）Outer Cape Cod Network Consulting、LLC
EMail: curtis@occnc.com
Kireeti Kompella Juniper Networks
キリーティコンペラジュニパーネットワークス
EMail: kireeti@juniper.net
Shane Amante Apple Inc. 1 Infinite Loop Cupertino, California 95014
シェーンアマンテアップル社1無限ループクパチーノ、カリフォルニア95014
EMail: amante@apple.com
Andrew Malis Huawei Technologies
Andrew Malis Huawei Technologies
EMail: agmalis@gmail.com
Carlos Pignataro Cisco Systems 7200-12 Kit Creek Road Research Triangle Park, NC 27709 US
Carlos Pignataro Cisco Systems 7200-12 Kit Creek Road Research Triangle Park、NC 27709 US
EMail: cpignata@cisco.com