Internet Engineering Task Force (IETF) S. Bryant, Ed.
Request for Comments: 6391 C. Filsfils
Category: Standards Track Cisco Systems
ISSN: 2070-1721 U. Drafz
Deutsche Telekom
V. Kompella
J. Regan
Alcatel-Lucent
S. Amante
Level 3 Communications, LLC
November 2011
Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network
MPLSパケット交換ネットワークを介したスードワイヤの流れを意識し交通
Abstract
抽象
Where the payload of a pseudowire comprises a number of distinct flows, it can be desirable to carry those flows over the Equal Cost Multiple Paths (ECMPs) that exist in the packet switched network. Most forwarding engines are able to generate a hash of the MPLS label stack and use this mechanism to balance MPLS flows over ECMPs.
疑似回線のペイロードが異なるフロー数を含む場合、パケット交換ネットワーク内に存在する等コストマルチパス（ECMPs）上にこれらのフローを搬送することが望ましいです。ほとんどのフォワーディングエンジンは、MPLSラベルスタックのハッシュを生成し、MPLSはECMPs上を流れるバランスをとるために、このメカニズムを使用することができます。
This document describes a method of identifying the flows, or flow groups, within pseudowires such that Label Switching Routers can balance flows at a finer granularity than individual pseudowires. The mechanism uses an additional label in the MPLS label stack.
この文書は、ラベルスイッチングルータの個々スードワイヤより細かい粒度での流れのバランスをとることができるように疑似回線内で、流れ、又はフローグループを同定する方法を記載しています。メカニズムは、MPLSラベルスタックに追加ラベルを使用しています。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6391.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6391で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Requirements Language ......................................4
1.2. ECMP in Label Switching Routers ............................4
1.3. Flow Label .................................................4
2. Native Service Processing Function ..............................5
3. Pseudowire Forwarder ............................................6
3.1. Encapsulation ..............................................7
4. Signalling the Presence of the Flow Label .......................8
4.1. Structure of Flow Label Sub-TLV ............................9
5. Static Pseudowires ..............................................9
6. Multi-Segment Pseudowires .......................................9
7. Operations, Administration, and Maintenance (OAM) ..............10
8. Applicability of PWs Using Flow Labels .........................11
8.1. Equal Cost Multiple Paths .................................12
8.2. Link Aggregation Groups ...................................13
8.3. Multiple RSVP-TE Paths ....................................13
8.4. The Single Large Flow Case ................................14
8.5. Applicability to MPLS-TP ..................................15
8.6. Asymmetric Operation ......................................15
9. Applicability to MPLS LSPs .....................................15
10. Security Considerations .......................................16
11. IANA Considerations ...........................................16
12. Congestion Considerations .....................................16
13. Acknowledgements ..............................................17
14. References ....................................................17
14.1. Normative References .....................................17
14.2. Informative References ...................................18
A pseudowire (PW) [RFC3985] is normally transported over one single network path, even if multiple Equal Cost Multiple Paths (ECMPs) exist between the ingress and egress PW provider edge (PE) equipment [RFC4385] [RFC4928]. This is required to preserve the characteristics of the emulated service (e.g., to avoid misordering Structure-Agnostic Time Division Multiplexing over Packet (SAToP) PW packets [RFC4553] or subjecting the packets to unusable inter-arrival times). The use of a single path to preserve order remains the default mode of operation of a PW. The new capability proposed in this document is an OPTIONAL mode that may be used when the use of ECMPs is known to be beneficial (and not harmful) to the operation of the PW.
疑似回線（PW）[RFC3985]は、通常、複数の等コストマルチパス（ECMPs）は入力および出力PWプロバイダエッジ（PE）装置[RFC4385]、[RFC4928]の間に存在しても、一つのネットワークパスを介して転送されます。これは、（パケット（のSAToP）PWパケット[RFC4553]上の構造に依存しない時分割多重化を誤った順序または使用不能到着時間間隔にパケットを施す回避するために、例えば）のエミュレートサービスの特性を維持するために必要とされます。秩序を維持するために、単一パスの使用は、PWのデフォルトの動作モードのままです。この文書で提案された新しい機能がECMPsの使用が（有害ではない）に有益であることが知られているときにPWの操作に使用することができるOPTIONALモードです。
Some PWs are used to transport large volumes of IP traffic between routers. One example of this is the use of an Ethernet PW to create a virtual direct link between a pair of routers. Such PWs may carry from hundreds of Mbps to Gbps of traffic. These PWs only require packet ordering to be preserved within the context of each individual transported IP flow. They do not require packet ordering to be preserved between all packets of all IP flows within the pseudowire.
いくつかのPWSがルータ間のIPトラフィックを大量に輸送するのに使用されています。この一例は、ルーターのペア間の仮想直接リンクを作成するためのイーサネットPWを使用することです。このようなPWSがトラフィックのGbpsに数百Mbpsから運ぶことができます。これらのPWSが唯一のIPフローを転送パケット順序は、個々のコンテキスト内に保存されることを必要とします。彼らは、疑似回線内のすべてのIPフローのすべてのパケットの間で保存されるように、パケットの順序を必要としません。
The ability to explicitly configure such a PW to leverage the availability of multiple ECMPs allows for better capacity planning, as the statistical multiplexing of a larger number of smaller flows is more efficient than with a smaller set of larger flows.
小さい流れの多数の統計的多重化が大きな流れの小さいセットよりもより効率的であるとして明示的に複数ECMPsの可用性を活用するためにこのようなPWを設定する能力は、より良好な容量計画を可能にします。
Typically, forwarding hardware can deduce that an IP payload is being directly carried by an MPLS label stack, and it is capable of looking at some fields in packets to construct hash buckets for conversations or flows. However, when the MPLS payload is a PW, an intermediate node has no information on the type of PW being carried in the packet. This limits the forwarder at the intermediate node to only being able to make an ECMP choice based on a hash of the MPLS label stack. In the case of a PW emulating a high-bandwidth trunk, the granularity obtained by hashing the label stack is inadequate for satisfactory load balancing. The ingress node, however, is in the special position of being able to understand the unencapsulated packet header to assist with spreading flows among any available ECMPs, or even any Loop-Free Alternates [RFC5286]. This document defines a method to introduce granularity on the hashing of traffic running over PWs by introducing an additional label, chosen by the ingress node, and placed at the bottom of the label stack.
典型的には、転送ハードウェアは、IPペイロードを直接MPLSラベルスタックによって運ばれていることを推測することができ、それは会話又はフローのハッシュバケットを構築するためにパケットの一部のフィールドを見ることが可能です。 MPLSペイロードがPWである場合しかし、中間ノードは、パケットで搬送されるPWの種類に関する情報を有していません。これは、MPLSラベルスタックのハッシュに基づくECMPの選択をすることができることに、中間ノードでフォワーダを制限します。高帯域幅のトランクをエミュレートPWの場合は、ラベルスタックをハッシュ化した粒度は十分な負荷分散のためには不十分です。入口ノードは、しかし、任意の利用可能なECMPs、あるいは任意のループフリーのAlternates [RFC5286]の間で流れを拡散を支援する非カプセル化パケットヘッダを理解することができるという特別な位置にあります。この文書では、入口ノードによって選択された追加のラベルを導入することによってのPW上で動作するトラフィックのハッシュに粒度を導入する方法を定義し、ラベルスタックの底に置きました。
In addition to providing an indication of the flow structure for use in ECMP forwarding decisions, the mechanism described in the document may also be used to select flows for distribution over an IEEE 802.1AX-2008 (originally specified as IEEE 802.3ad-2000) Link Aggregation Group (LAG) that has been used in an MPLS network.
ECMPフォワーディングの決定に使用するためのフロー構造の指標を提供することに加えて、また、選択するために使用することができる文書で説明されたメカニズムは、リンク（元々IEEE 802.3adの-2000として指定される）IEEE 802.1AX-2008上分布のために流れます。 MPLSネットワークで使用されてきた集約グループ（LAG）。
NOTE: Although Ethernet is frequently referenced as a use case in this RFC, the mechanisms described in this document are general mechanisms that may be applied to any PW type in which there are identifiable flows, and in which there is no requirement to preserve the order between those flows.
注：イーサネットは、しばしば、このRFCにユースケースとして参照されているが、本書で説明されたメカニズムが識別流れ存在する任意のPWタイプに適用することができる一般的なメカニズムがあり、順序を維持する必要はありませんこれらのフローの間。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
Label Switching Routers (LSRs) commonly generate a hash of the label stack or some elements of the label stack as a method of discriminating between flows and use this to distribute those flows over the available ECMPs that exist in the network. Since the label at the bottom of the stack is usually the label most closely associated with the flow, this normally provides the greatest entropy, and hence is usually included in the hash. This document describes a method of adding an additional Label Stack Entry (LSE) at the bottom of the stack in order to facilitate the load balancing of the flows within a PW over the available ECMPs. A similar design for general MPLS use has also been proposed [MPLS-ENTROPY]; see Section 9 of this document.
ラベルスイッチングルータ（LSRの）は、一般的にフローを区別する方法として、ラベルスタックのハッシュまたはラベルスタックのいくつかの要素を生成し、ネットワーク内に存在する利用可能なECMPs上にこれらのフローを配布するためにこれを使用します。スタックの底部のラベルので、これは、通常、最大エントロピーを提供し、従って通常ハッシュに含まれ、通常最も密接フローに関連付けられたラベルです。この文書は、利用可能なECMPs上PW内の流れの負荷分散を容易にするために、スタックの一番下に追加のラベルスタックエントリ（LSE）を添加する方法が記載されています。一般的なMPLSを使用するための同様の設計はまた、[MPLSエントロピー]提案されています。このドキュメントのセクション9を参照してください。
An alternative method of load balancing by creating a number of PWs and distributing the flows amongst them was considered, but was rejected because:
PW数を作成し、それらの間で流れを分散させることにより、負荷分散の代替方法が考えられたが、拒否されたため。
o It did not introduce as much entropy as can be introduced by adding an additional LSE.
Oそれは追加のLSEを追加することにより導入することができる限り多くのエントロピーを導入していませんでした。
o It required additional PWs to be set up and maintained.
Oそれはセットアップし、維持するために追加のPWが必要。
An additional LSE [RFC3032] is interposed between the PW LSE and the control word, or if the control word is not present, between the PW LSE and the PW payload. This additional LSE is called the flow LSE, and the label carried by the flow LSE is called the flow label.
追加LSE [RFC3032]はPW LSEと制御ワードとの間に介在されるか、または制御ワードがPW LSEとPWペイロードとの間に、存在しない場合。この追加LSEは、フローLSEと呼ばれ、フローLSEによって運ばれるラベルは、フローラベルと呼ばれています。
Indivisible flows within the PW MUST be mapped to the same flow label by the ingress PE. The flow label stimulates the correct ECMP load-balancing behaviour in the packet switched network (PSN). On receipt of the PW packet at the egress PE (which knows a flow LSE is present), the flow LSE is discarded without processing.
PW内不可分フローが入口PEによって同じフローラベルにマッピングされなければなりません。フローラベルはパケット内の正しいECMPロードバランシング動作がネットワーク（PSN）を切り替え刺激します。 （LSEが存在する流れを知っている）出口PEでのPWパケットの受信時に、フローLSEは処理されずに廃棄されます。
Note that the flow label MUST NOT be an MPLS reserved label (values in the range 0..15) [RFC3032], but is otherwise unconstrained by the protocol.
フローラベルは、MPLSてはならないことに注意すると、ラベル（範囲0..15の値）[RFC3032]を予約したが、プロトコルによって別段の制約なしです。
It is useful to give consideration to the choice of Time to Live (TTL) value in the flow LSE [RFC3032]. The flow LSE is at the bottom of the label stack; therefore, even when penultimate hop popping is employed, it will always be preceded by the PW label on arrival at the PE. If, due to an error condition, the flow LSE becomes the top of the stack, it might be examined as if it were a normal LSE, and the packet might then be forwarded. This can be prevented by setting the flow LSE TTL to 1, thereby forcing the packet to be discarded by the forwarder. Note that setting the TTL to 1 regardless of the payload may be considered a departure from the TTL procedures defined in [RFC3032] that apply to the general MPLS case.
フローLSE [RFC3032]で（TTL）値を生存時間の選択に配慮する便利です。流れLSEは、ラベルスタックの最下部にあります。そのため、最後から二番目のホップのポッピングを採用した場合であっても、それは常にPEの到着時にPWラベルが先行されます。がエラー状態に、流れLSEは、スタックの最上位になり、場合、それは通常LSEたかのように検査される可能性があり、パケットは転送されるかもしれません。これによりフォワーダによって破棄されるパケットを強制的に1に流れLSEのTTLを設定することによって防止することができます。ペイロードに関係なく1にTTLを設定する一般的なMPLSの場合に適用される[RFC3032]で定義されたTTL手順からの逸脱と見なすことができることに留意されたいです。
This document does not define a use for the Traffic Class (TC) field [RFC5462] (formerly known as the Experimental Use (EXP) bits [RFC3032]) in the flow label. Future documents may define a use for these bits; therefore, implementations conforming to this specification MUST set the TC field to zero at the ingress and MUST ignore them at the egress.
この文書では、フローラベルで（以前は実験的な使用（EXP）ビット[RFC3032]として知られている）トラフィッククラス（TC）フィールド[RFC5462]のための使用を定義していません。将来の文書は、これらのビットのための使用を定義することができ、従って、この仕様に準拠した実装は、入力でゼロにTCフィールドを設定しなければならないと出口でそれらを無視しなければなりません。
The Native Service Processing (NSP) function [RFC3985] is a component of a PE that has knowledge of the structure of the emulated service and is able to take action on the service outside the scope of the PW. In this case, it is REQUIRED that the NSP in the ingress PE identify flows, or groups of flows within the service, and indicate the flow (group) identity of each packet as it is passed to the pseudowire forwarder. As an example, where the PW type is an Ethernet, the NSP might parse the ingress Ethernet traffic and consider all of the IP traffic. This traffic could then be categorised into flows by considering all traffic with the same source and destination address pair to be a single indivisible flow. Since this is an NSP function, by definition, the method used to identify a flow is outside the scope of the PW design. Similarly, since the NSP is internal to the PE, the method of flow indication to the PW forwarder is outside the scope of this document.
ネイティブサービス処理（NSP）関数[RFC3985]はエミュレートされたサービスの構造の知識を有し、PWの範囲外サービスに行動を取ることが可能であるPEの構成要素です。この場合、入力PEでNSPは、サービス内のフローの流れ、またはグループを識別し、それは疑似回線フォワーダに渡され、各パケットのフロー（群）の同一性を示すことが必要です。 PWタイプがイーサネットである例として、NSPは入力イーサネットトラフィックを解析し、IPトラフィックのすべてを検討するかもしれません。このトラフィックは、単一不可分の流れであることを、同じソースと宛先アドレスのペアを持つすべてのトラフィックを考慮してフローに分類することができます。これはNSP関数であるので、定義によって、フローを識別するために使用される方法は、PW設計の範囲外です。 NSPは、PEの内部にあるため、同様に、PWフォワーダにフロー表示の方法は、この文書の範囲外です。
The PW forwarder must be provided with a method of mapping flows to load-balanced paths.
PWフォワーダは、マッピングの方法で提供されなければならない負荷分散パスに流れます。
The forwarder must generate a label for the flow or group of flows. How the flow label values are determined is outside the scope of this document; however, the flow label allocated to a flow MUST NOT be an MPLS reserved label and SHOULD remain constant for the life of the flow. It is RECOMMENDED that the method chosen to generate the load-balancing labels introduce a high degree of entropy in their values, to maximise the entropy presented to the ECMP selection mechanism in the LSRs in the PSN, and hence distribute the flows as evenly as possible over the available PSN ECMP. The forwarder at the ingress PE prepends the PW control word (if applicable), and then pushes the flow label, followed by the PW label.
フォワーダは、フローの流れやグループのラベルを生成する必要があります。どのようにフローラベル値が決定され、この文書の範囲外です。しかし、フローに割り当てられたフローラベルは、MPLSラベルに予約してはならず、流れの生活のために一定のままでなければなりません。選択された方法は、負荷分散ラベルがPSNでのLSRでECMP選択機構に提示エントロピーを最大化し、したがってできるだけ均等に流れを分配するために、それらの値にエントロピーの高度を導入生成することが推奨されます利用可能PSN ECMPを超えます。入口PEにフォワーダはPW制御ワード（該当する場合）を付加し、その後、フローラベルを押し、PWラベルが続きます。
NOTE: Although this document does not attempt to specify any hash algorithms, it is suggested that any such algorithm should be based on the assumption that there will be a high degree of entropy in the values assigned to the flow labels.
注：このドキュメントでは、任意のハッシュアルゴリズムを指定しようとしませんが、それはどのようなアルゴリズムは、フローラベルに割り当てられた値のエントロピー度が高いがあるだろうという仮定に基づくべきであることが示唆されました。
The forwarder at the egress PE uses the pseudowire label to identify the pseudowire. From the context associated with the pseudowire label, the egress PE can determine whether a flow LSE is present. If a flow LSE is present, it MUST be checked to determine whether it carries a reserved label. If it is a reserved label, the packet is processed according to the rules associated with that reserved label; otherwise, the LSE is discarded.
出口PEでフォワーダは、疑似回線を識別するために、疑似回線ラベルを使用します。疑似回線ラベルに関連付けられたコンテキストから、出口PEは、フローLSEが存在するか否かを判断することができます。フローLSEが存在する場合、予約ラベルを運ぶかどうかを決定するためにチェックしなければなりません。それは予約ラベルである場合、パケットはその予約ラベルに関連付けられたルールに従って処理されます。そうでない場合は、LSEが破棄されます。
All other PW forwarding operations are unmodified by the inclusion of the flow LSE.
他の全てのPW転送動作は、フローLSEを含めることによって変更されません。
The PWE3 Protocol Stack Reference Model modified to include flow LSE is shown in Figure 1.
PWE3プロトコルスタック参照モデルは、LSEは、図1に示されているフローを含むように修正しました。
+-------------+ +-------------+
| Emulated | | Emulated |
| Ethernet | | Ethernet |
| (including | Emulated Service | (including |
| VLAN) |<==============================>| VLAN) |
| Services | | Services |
+-------------+ +-------------+
| Flow | | Flow |
+-------------+ Pseudowire +-------------+
|Demultiplexer|<==============================>|Demultiplexer|
+-------------+ +-------------+
| PSN | PSN Tunnel | PSN |
| MPLS |<==============================>| MPLS |
+-------------+ +-------------+
| Physical | | Physical |
+-----+-------+ +-----+-------+
Figure 1: PWE3 Protocol Stack Reference Model
図1：PWE3プロトコルスタック参照モデル
The encapsulation of a PW with a flow LSE is shown in Figure 2.
フローLSEとPWのカプセル化は、図2に示されています。
+---------------------------+
| |
| Payload |
| | n octets
| |
+---------------------------+
| Optional Control Word | 4 octets
+---------------------------+
| Flow LSE | 4 octets
+---------------------------+
| PW LSE | 4 octets
+---------------------------+
| MPLS Tunnel LSE (s) | n*4 octets (four octets per LSE)
+---------------------------+
Figure 2: Encapsulation of a Pseudowire with a Pseudowire Flow LSE
図2：擬似回線フローLSEとの擬似回線のカプセル化
When using the signalling procedures in [RFC4447], a new Pseudowire Interface Parameter Sub-TLV, the Flow Label Sub-TLV (FL Sub-TLV), is used to synchronise the flow label states between the ingress and egress PEs.
[RFC4447]でシグナリング手順、新たな疑似回線インタフェースパラメータサブTLV、フローラベルサブTLV（FLサブTLV）を使用する場合、入口および出口PE間のフローラベル状態を同期するために使用されます。
The absence of an FL Sub-TLV indicates that the PE is unable to process flow labels. An ingress PE that is using PW signalling and that does not send an FL Sub-TLV MUST NOT include a flow label in the PW packet. An ingress PE that is using PW signalling and that does not receive an FL Sub-TLV from its egress peer MUST NOT include a flow label in the PW packet. This preserves backwards compatibility with existing PW specifications.
FLサブTLVが存在しないことは、PEがフローラベルを処理することができないことを示しています。 PWシグナリングを使用して、それがFLサブTLVを送信しない入口PEはPWパケット内のフローラベルを含んではいけません。 PWシグナリングを使用しており、それは、その出口ピアからFLサブTLVを受信しない入口PEはPWパケット内のフローラベルを含んではいけません。これは、既存のPW仕様との下位互換性を維持します。
A PE that wishes to send a flow label in a PW packet MUST include in its label mapping message an FL Sub-TLV with T = 1 (see Section 4.1).
PWパケットにフローラベルを送信したいPEは、ラベルマッピングメッセージT = 1とFLサブTLV（セクション4.1を参照）に含める必要があります。
A PE that is willing to receive a flow label MUST include in its label mapping message an FL Sub-TLV with R = 1 (see Section 4.1).
フローラベルを受信する意思があるPEは、ラベルマッピングメッセージR = 1とFLサブTLV（セクション4.1を参照）に含める必要があります。
A PE that receives a label mapping message containing an FL Sub-TLV with R = 0 MUST NOT include a flow label in the PW packet.
R = 0とFLサブTLVを含むラベルマッピングメッセージを受信したPEはPWパケット内のフローラベルを含んではいけません。
Thus, a PE sending an FL Sub-TLV with T = 1 and receiving an FL Sub-TLV with R = 1 MUST include a flow label in the PW packet. Under all other combinations of FL Sub-TLV signalling, a PE MUST NOT include a flow label in the PW packet.
従って、T = 1とFLサブTLVを送信し、R = 1とFLサブTLVを受信したPEはPWパケット内のフローラベルを含まなければなりません。 FLサブTLVシグナリングの全ての他の組み合わせの下で、PEはPWパケット内のフローラベルを含んではいけません。
The signalling procedures in [RFC4447] state that "Processing of the interface parameters should continue when unknown interface parameters are encountered, and they MUST be silently ignored". The signalling procedure described here is therefore backwards compatible with existing implementations.
「未知のインタフェースパラメータに遭遇したとき、インタフェースパラメータの処理は継続すべきである、と彼らは黙って無視されなければならない」という[RFC4447]の状態での信号手順。ここで説明するシグナリング手順は、したがって、既存の実装との後方互換性があります。
Note that what is signalled is the desire to include the flow LSE in the label stack. The value of the flow label is a local matter for the ingress PE, and the label value itself is not signalled.
何を知らされることはラベルスタック内の流れLSEを含めるしたいという願望であることに注意してください。フローラベルの値は、入口PEのローカル問題であり、ラベル値自体が通知されません。
The structure of the Flow Label Sub-TLV is shown in Figure 3.
フローラベルサブTLVの構造は、図3に示されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FL=0x17 | Length |T|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Flow Label Sub-TLV
図3：フローラベルサブTLV
Where:
どこ：
o FL (value 0x17) is the Flow Label Sub-TLV identifier assigned by IANA (see Section 11).
O FL（0x17の値）は、IANAによって割り当てられたフローラベルサブTLVの識別子である（セクション11を参照）。
o Length is the length of the Sub-TLV in octets and is 4.
Oの長さは、オクテット内のサブTLVの長さであり、4です。
o When T = 1, the PE is requesting the ability to send a PW packet that includes a flow label. When T = 0, the PE is indicating that it will not send a PW packet containing a flow label.
T = 1の場合、O、PEは、フローラベルを含むPWパケットを送信する機能を要求しています。ときT = 0、PEは、それがフローラベルを含むPWパケットを送信しないことを示しています。
o When R = 1, the PE is able to receive a PW packet with a flow label present. When R = 0, the PE is unable to receive a PW packet with the flow label present.
O R = 1、PEは、フローラベルの存在とPWパケットを受信することができる場合。 R = 0は、PEは、フローラベル存在とPWパケットを受信できない場合。
o Reserved bits MUST be zero on transmit and MUST be ignored on receive.
O予約ビットは、送信にゼロでなければならないし、受信時には無視されなければなりません。
If PWE3 signalling [RFC4447] is not in use for a PW, then whether the flow label is used MUST be identically provisioned in both PEs at the PW endpoints. If there is no provisioning support for this option, the default behaviour is not to include the flow label.
PWE3は、[RFC4447]をシグナリングするPWのために使用されていない場合は、フローラベルが使用されているかどうかを同じPWエンドポイントの両方のPEでプロビジョニングされなければなりません。このオプションには、プロビジョニングのサポートがない場合は、デフォルトの動作は、フローラベルを含めることではありません。
The flow label mechanism described in this document works on multi-segment PWs without requiring modification to the Switching PEs (S-PEs). This is because the flow LSE is transparent to the label swap operation, and because interface parameter Sub-TLV signalling is transitive.
本書で説明したフローラベル機構は、スイッチングのPE（S-PES）への変更を必要とせずに、マルチセグメントのPWで動作します。フローLSEラベルスワップ操作に対して透明であるため、インターフェイスパラメータサブTLVシグナリングが推移的であるためです。
The following OAM considerations apply to this method of load balancing.
次OAMの考慮事項は、負荷分散のこの方法に適用されます。
Where the OAM is only to be used to perform a basic test to verify that the PWs have been configured at the PEs, Virtual Circuit Connectivity Verification (VCCV) [RFC5085] messages may be sent using any load balance PW path, i.e., using any value for the flow label.
OAMのみPWSはのPEで構成されていることを確認するための基本的なテストを実行するために使用されるように、仮想回線接続検証（VCCV）[RFC5085]メッセージは、任意のものを使用して、すなわち、任意の負荷バランスPWパスを使用して送信することができるされますフローラベルの値。
Where it is required to verify that a pseudowire is fully functional for all flows, a VCCV [RFC5085] connectivity verification message MUST be sent over each ECMP path to the pseudowire egress PE. This solution may be difficult to achieve and scales poorly. Under these circumstances, it may be sufficient to send VCCV messages using any load balance pseudowire path, because if a failure occurs within the PSN, the failure will normally be detected and repaired by the PSN. That is, the PSN's Interior Gateway Protocol (IGP) link/node failure detection mechanism (loss of light, bidirectional forwarding detection [RFC5880], or IGP hello detection) and the IGP convergence will naturally modify the ECMP set of network paths between the ingress and egress PEs. Hence, the PW is only impacted during the normal IGP convergence time. Note that this period may be reduced if a fast re-route or fast convergence technology is deployed in the network [RFC4090] [RFC5286].
それは疑似回線は、すべてのフローのための完全に機能的であることを確認する必要がある場合、VCCV [RFC5085]の接続確認メッセージが疑似回線出口PEにそれぞれECMPパスを介して送信されなければなりません。このソリューションでは達成が困難なことや不十分なスケールがあります。このような状況下では、障害がPSN内で発生した場合、障害が正常に検出され、PSNによって修復されるので、任意の負荷バランス疑似回線パスを使用してVCCVメッセージを送信するのに十分であってもよいです。すなわち、PSNのインテリアゲートウェイプロトコル（IGP）リンク/ノード障害検出機構である（光の損失、双方向フォワーディング検出[RFC5880]、またはIGPハロー検出）と天然に入口との間のネットワーク経路のECMPセットを修正するIGPコンバージェンスそして、出口のPE。したがって、PWは、通常IGP収束時間の間に影響を受けます。 [RFC5286]、[RFC4090]高速再ルートまたは高速コンバージェンス技術がネットワークに配備されている場合は、この期間を低減することができることに留意されたいです。
If the failure is related to the individual corruption of a Label Forwarding Information Base (LFIB) entry in a router, then only the network path using that specific entry is impacted. If the PW is load-balanced over multiple network paths, then this failure can only be detected if, by chance, the transported OAM flow is mapped onto the impacted network path, or if all paths are tested. Since testing all paths may present problems as noted above, other mechanisms to detect this type of error may need to be developed, such as a Label Switched Path (LSP) self-test technology.
障害がルータのラベル転送情報ベース（LFIB）エントリの個々の破損に関連している場合、その特定のエントリを使用して、唯一のネットワーク経路が影響を受けます。 PWは、複数のネットワーク経路上に負荷分散されている場合、この失敗は、偶然、搬送OAMフローが影響を受けるネットワーク・パスにマッピングされている、場合にのみ検出することができ、またはすべてのパスをテストする場合。上述したようにこのタイプのエラーを検出するために、問題を提示することができる他の機構のすべてのパスをテストするため、このようなラベルスイッチパス（LSP）セルフテスト技術として、開発される必要があるかもしれません。
To troubleshoot the MPLS PSN, including multiple paths, the techniques described in [RFC4378] and [RFC4379] can be used.
複数のパスを含むMPLS PSNを、トラブルシューティングするために、[RFC4378]及び[RFC4379]に記載された技術を使用することができます。
Where the PW OAM is carried out of band (VCCV Type 2) [RFC5085], it is necessary to insert an "MPLS Router Alert Label" in the label stack. The resultant label stack is as follows:
PW OAMがバンド（VCCVタイプ2）[RFC5085]から搬出されている場合、ラベルスタックに「MPLSルータアラートラベル」を挿入する必要があります。次のように得られたラベルスタックは次のようになります。
+-------------------------------+
| |
| VCCV Message | n octets
| |
+-------------------------------+
| Optional Control Word | 4 octets
+-------------------------------+
| Flow LSE | 4 octets
+-------------------------------+
| PW LSE | 4 octets
+-------------------------------+
| Router Alert LSE | 4 octets
+-------------------------------+
| MPLS Tunnel LSE(s) | n*4 octets (four octets per label)
+-------------------------------+
Figure 4: Use of Router Alert Label
図4：ルータアラートラベルの使用
Note that, depending on the number of labels hashed by the LSR, the inclusion of the Router Alert label may cause the OAM packet to be load-balanced to a different path from that taken by the data packets with identical flow and PW labels.
LSRによってハッシュされたラベルの数に応じて、ルータ警告ラベルを含めることがOAMパケットを負荷分散同じフローとPWラベル付きデータ・パケットによって撮影されたものとは異なるパスにさせてもよいことに留意されたいです。
A node within the PSN is not able to perform deep packet inspection (DPI) of the PW, as the PW technology is not self-describing: the structure of the PW payload is only known to the ingress and egress PE devices. The method proposed in this document provides a statistical mitigation of the problem of load balance in those cases where a PE is able to discern flows embedded in the traffic received on the attachment circuit.
PWペイロードの構造のみ入力および出力PEデバイスに知られている：PW技術は自己記述ないようPSN内のノードは、PWのディープパケットインスペクション（DPI）を実行することができません。この文献で提案された方法は、PEが接続回線上で受信されたトラフィックに埋め込まれたフローを識別することが可能である場合における負荷バランスの問題の統計的な緩和を提供します。
The methods described in this document are transparent to the PSN and as such do not require any new capability from the PSN.
この文書に記載された方法は、PSNに透明であり、そのようにPSNからの新しい機能を必要としません。
The requirement to load-balance over multiple PSN paths occurs when the ratio between the PW access speed and the PSN's core link bandwidth is large (e.g., >= 10%). ATM and Frame Relay are unlikely to meet this property. Ethernet may have this property, and for that reason this document focuses on Ethernet. Applications for other high-access-bandwidth PWs may be defined in the future.
要求は、ロードバランスするために複数のPSNパスオーバーが発生PWアクセス速度とPSNのコアリンク帯域幅との比が大きい（例えば、> = 10％）である場合。 ATMとフレームリレーは、この特性を満たすことはほとんどありません。イーサネットは、この性質を有していてもよく、そしてその理由については、このドキュメントでは、イーサネットに焦点を当てています。他の高アクセス帯域幅のPWのためのアプリケーションは、将来的に定義されてもよいです。
This design applies to MPLS PWs where it is meaningful to de-construct the packets presented to the ingress PE into flows. The mechanism described in this document promotes the distribution of flows within the PW over different network paths. In turn, this means that whilst packets within a flow are delivered in order (subject to normal IP delivery perturbations due to topology variation), order is no longer maintained for all packets sent over the PW. It is not proposed to associate a different sequence number with each flow. If sequence number support is required, the flow label mechanism MUST NOT be used.
この設計は、脱構築するフローに入口PEに提示されるパケットを意味があるMPLSのPWに適用されます。本書で説明されたメカニズムは、異なるネットワーク経路上PW内の流れの分配を促進します。今度は、これは、フロー内のパケットが（トポロジー変化に起因する通常のIP配信摂動を受ける）ために送達される一方、順序がもはやPWを介して送信されるすべてのパケットに対して維持されることを意味しません。各フローと異なるシーケンス番号を関連付けることが提案されていません。シーケンス番号のサポートが必要な場合は、フローラベルのメカニズムを使用してはいけません。
Where it is known that the traffic carried by the Ethernet PW is IP, the flows can be identified and mapped to an ECMP. Such methods typically include hashing on the source and destination addresses, the protocol ID and higher-layer flow-dependent fields such as TCP/UDP ports, Layer 2 Tunneling Protocol version 3 (L2TPv3) Session IDs, etc.
イーサネットPWで運ばトラフィックがIPであることが知られている場合は、フローを識別し、ECMPにマッピングすることができます。このような方法は、典型的には、送信元アドレスと宛先アドレスにハッシュとしては、例えば、TCP / UDPポート、レイヤ2トンネリングプロトコルバージョン3（L2TPv3の）セッションのID、等のプロトコルID及び上位層フロー依存フィールド
Where it is known that the traffic carried by the Ethernet PW is non-IP, techniques used for link bundling between Ethernet switches may be reused. In this case, however, the latency distribution would be larger than is found in the link bundle case. The acceptability of the increased latency is for further study. Of particular importance, the Ethernet control frames SHOULD always be mapped to the same PSN path to ensure in-order delivery.
それは、イーサネットPWによって運ばれるトラフィックは、非IPであることが知られている場合、イーサネットスイッチ間のリンクバンドルに使用される技術は、再利用することができます。しかし、この場合には、待ち時間の分布は、リンクバンドル場合に見られるよりも大きいであろう。待ち時間の増加の受容性は、今後の検討課題です。特に重要なのは、イーサネット（登録商標）制御フレームは常にインオーダー配信を保証するために、同じPSNパスにマッピングされるべきです。
ECMP in packet switched networks is statistical in nature. The mapping of flows to a particular path does not take into account the bandwidth of the flow being mapped or the current bandwidth usage of the members of the ECMP set. This simplification works well when the distribution of flows is evenly spread over the ECMP set and there are a large number of flows that have low bandwidth relative to the paths. The random allocation of a flow to a path provides a good approximation to an even spread of flows, provided that polarisation effects are avoided. The method defined in this document has the same statistical properties as an IP PSN.
パケット交換網におけるECMPは、自然の中での統計です。特定の経路に流れるのマッピングは、アカウントにマッピングされるフロー又はECMPセットのメンバーの現在の帯域幅の使用の帯域幅を取りません。流れの分布が均一ECMPセット上に広げ、パスに対して低い帯域幅を有するフローの数が多い場合、この簡略化はうまく機能します。経路への流れのランダムな割り当ても流れの普及に良好な近似を提供する、偏光の影響が回避されることを条件とします。この文書で定義された方法は、IP PSNと同じ統計的性質を持っています。
ECMP is a load-sharing mechanism that is based on sharing the load over a number of layer 3 paths through the PSN. Often, however, multiple links exist between a pair of LSRs that are considered by the IGP to be a single link. These are known as link bundles. The mechanism described in this document can also be used to distribute the flows within a PW over the members of the link bundle by using the flow label value to identify candidate flows. How that mapping takes place is outside the scope of this specification. Similar considerations apply to Link Aggregation Groups.
ECMPは、PSNを介してレイヤ3つの経路の数にわたって負荷を共有に基づいて負荷分散機構です。しばしば、しかし、複数のリンクを単一のリンクであるとIGPによって考慮されるのLSRの対の間に存在します。これらは、リンクバンドルとして知られています。本書で説明されたメカニズムはまた、候補フローを識別するために、フローラベル値を用いてリンクバンドルのメンバー上PW内に流れを分配するために使用することができます。そのマッピングがどのように行われるか、この仕様の範囲外です。同様の考察は、リンクアグリゲーショングループに適用されます。
There is no mechanism currently defined to indicate the bandwidths in use by specific flows using the fields of the MPLS shim header. Furthermore, since the semantics of the MPLS shim header are fully defined in [RFC3032] and [RFC5462], those fields cannot be assigned
現在MPLSシムヘッダのフィールドを使用して、特定のフローによって使用中の帯域幅を示すために定義されたメカニズムはありません。 MPLSシムヘッダのセマンティクスが完全に[RFC3032]及び[RFC5462]で定義されているので、これらのフィールドを割り当てることができません
semantics to carry this information. This document does not define any semantic for use in the TTL or TC fields of the label entry that carries the flow label, but requires that the flow label itself be selected with a high degree of entropy suggesting that the label value should not be overloaded with additional meaning in any subsequent specification.
セマンティクスこの情報を運ぶために。この文書では、フローラベルを担持ラベルエントリのTTL又はTCフィールドに使用するための任意のセマンティックを定義するが、フローラベル自体がラベル値で過負荷にされるべきではないことを示唆しているエントロピーの高度で選択されることを必要としませんそれ以降の仕様では、追加の意味。
A different type of load balancing is the desire to carry a PW over a set of PSN links in which the bandwidth of members of the link set is less than the bandwidth of the PW. Proposals to address this problem have been made in the past [PWBONDING]. Such a mechanism can be considered complementary to this mechanism.
負荷分散の異なるタイプは、リンクセットのメンバーの帯域幅はPWの帯域幅未満であるPSNのリンクのセットの上にPWを運ぶための願望です。この問題に対処するための提案は、過去[PWBONDING]で行われています。このようなメカニズムは、このメカニズムを補完考えることができます。
A Link Aggregation Group (LAG) is used to bond together several physical circuits between two adjacent nodes so they appear to higher-layer protocols as a single, higher-bandwidth "virtual" pipe. These may coexist in various parts of a given network. An advantage of LAGs is that they reduce the number of routing and signalling protocol adjacencies between devices, reducing control plane processing overhead. As with ECMP, the key problem related to LAGs is that due to inefficiencies in LAG load-distribution algorithms, a particular component of a LAG may experience congestion. The mechanism proposed here may be able to assist in producing a more uniform flow distribution.
それらは、単一の高帯域幅の「仮想」パイプなどの上位層プロトコルに見えるように、リンクアグリゲーショングループ（LAG）は、2つの隣接ノード間の複数の物理回線を結合するために使用されます。これらは、特定のネットワークの様々な部分に共存させてもよいです。 LAGの利点は、制御プレーン処理オーバーヘッドを低減、デバイス間のルーティングおよびシグナリングプロトコル隣接の数を減らすことです。 ECMPと同様、のLAGに関連する重要な問題は、LAG負荷分散アルゴリズムにおける非効率性に起因して、LAGの特定の成分は、輻輳を経験する可能性があることです。ここで提案されたメカニズムは、より均一な流れ分布を生成するのを助けることができるかもしれません。
The same considerations requiring a flow to go over a single member of an ECMP set apply to a member of a LAG.
ECMPの単一メンバーの上に行くために流れを必要と同じ考慮はLAGのメンバーに適用される設定します。
In some networks, it is desirable for a Label Edge Router (LER) to be able to load-balance a PW across multiple Resource Reservation Protocol - Traffic Engineering (RSVP-TE) tunnels. The flow label mechanism described in this document may be used to provide the LER with the required flow information and necessary entropy to provide this type of load balancing. An example of such a case is the use of the flow label mechanism in networks using a link bundle with the all ones component [RFC4201].
いくつかのネットワークでは、複数のリソース予約プロトコル間でPWをロード・バランスをとることができるようにラベルエッジルータ（LER）のために望ましい - トラフィックエンジニアリング（RSVP-TE）トンネル。本書で説明したフローラベル機構は、負荷分散のこのタイプを提供するために必要なフロー情報と必要なエントロピーとLERを提供するために使用され得ます。このような場合の例は、すべてのものの成分[RFC4201]とのリンクバンドルを使用して、ネットワークにおけるフローラベル機構を使用することです。
Methods by which the LER is configured to apply this type of ECMP are outside the scope of this document.
LERは、ECMPのこのタイプを適用するように構成される方法は、この文書の範囲外です。
Clearly, the operator should make sure that the service offered using PW technology and the method described in this document do not exceed the maximum planned link capacity, unless it can be guaranteed that they conform to the Internet traffic profile of a very large number of small flows.
彼らは小さな、非常に多数ののインターネットトラフィックプロファイルに準拠していることを保証することができない限り、明らかに、オペレータは、サービスがPWの技術を使用して提供し、この文書に記載された方法は、最大計画リンク容量を超えないようにしてください流れ。
If the NSP cannot access sufficient information to distinguish flows, perhaps because the protocol stack required parsing further into the packet than it is able, then the functionality described in this document does not give any benefits. The most common case where a single flow dominates the traffic on a PW is when it is used to transport enterprise traffic. Enterprise traffic may well consist of a single, large TCP flow, or encrypted flows that cannot be handled by the methods described in this document.
NSPは、それができているよりも、パケットにさらに解析するプロトコルスタックが必要かもしれないので、流れを区別するために十分な情報にアクセスすることができない場合は、この文書で説明する機能は、任意の恩恵を与えるものではありません。企業のトラフィックを転送するために使用されている場合、単一のフローはPW上のトラフィックを支配する最も一般的なケースです。エンタープライズ・トラフィックも、この文書に記載された方法で扱うことができない単一の大きなTCPフロー、または暗号化されたフローから構成されてもよいです。
An operator has four options under these circumstances:
オペレータは、このような状況下で、4つのオプションがあります。
1. The operator can choose to do nothing, and the system will work as it does without the flow label.
1.オペレータは何もしないことを選択することができ、それがフローラベルなしで行うようにシステムが動作します。
2. The operator can make the customer aware that the service offering has a restriction on flow bandwidth and police flows to that restriction. This would allow customers offering multiple flows to use a larger fraction of their access bandwidth, whilst preventing a single flow from consuming a fraction of internal link bandwidth that the operator considered excessive.
2.事業者は、サービスの提供は、フローの帯域幅と警察に制限はその制限に流れていることを顧客に認識させることができます。これは、複数のフローを提供する顧客は、オペレータが過大と考えていること内部リンクの帯域幅の一部を消費するから、単一の流れを阻止しながら、自分のアクセス帯域幅の大きな部分を使用することができるようになります。
3. The operator could configure the ingress PE to assign a constant flow label to all high-bandwidth flows so that only one path was affected by these flows.
3.オペレータは、唯一の経路は、これらの流れの影響を受けたように、すべての高帯域幅フローに一定のフローラベルを割り当てる入口PEを設定することができました。
4. The operator could configure the ingress PE to assign a random flow label to all high-bandwidth flows so as to minimise the disruption to the network at the cost of out-of-order traffic to the user.
4.オペレータは、ユーザにアウトオブオーダトラフィックのコストでネットワークの中断を最小限に抑えるように、すべての高帯域幅フローにランダムなフローラベルを割り当てる入口PEを設定することができました。
The issues described above are mitigated by the following two factors:
上記課題は、次の2つの要因によって軽減されます。
o Firstly, the customer of a high-bandwidth PW service has an incentive to get the best transport service, because an inefficient use of the PSN leads to jitter and eventually to loss to the PW's payload.
PSNの非効率的な使用は、PWのペイロードにジッタに、最終的に損失につながるため、Oまず、高帯域幅PWサービスの顧客は、最高の輸送サービスを取得するためのインセンティブを持っています。
o Secondly, the customer is usually able to tailor their applications to generate many flows in the PSN. A well-known example is massive data transport between servers that use many parallel TCP sessions. This same technique can be used by any transport protocol: multiple UDP ports, multiple L2TPv3 Session IDs, or multiple Generic Routing Encapsulation (GRE) keys may be used to decompose a large flow into smaller components. This approach may be applied to IPsec [RFC4301] where multiple Security Parameter Indexes (SPIs) may be allocated to the same security association.
O第二に、顧客は通常、PSNで多くのフローを生成するためにアプリケーションを調整することができます。よく知られた例は、多くの並列TCPセッションを使用するサーバー間で大量のデータ転送です。この同じ技術は、任意のトランスポートプロトコルによって使用することができる：複数のUDPポート、複数のL2TPv3セッションID、または複数の総称ルーティングカプセル化（GRE）キーは、より小さなコンポーネントに大流量を分解するために使用することができます。このアプローチは、複数のセキュリティパラメータインデックス（SPIの）が同じセキュリティアソシエーションに割り当てられるのIPsec [RFC4301]に適用されてもよいです。
The MPLS Transport Profile (MPLS-TP) [RFC5654] Requirement 44 states that "MPLS-TP MUST support mechanisms that ensure the integrity of the transported customer's service traffic as required by its associated Service Level Agreement (SLA). Loss of integrity may be defined as packet corruption, reordering, or loss during normal network conditions". In addition, MPLS-TP makes extensive use of the fate sharing between OAM and data packets, which is defeated by the flow LSE. The flow-aware transport of a PW reorders packets and therefore MUST NOT be deployed in a network conforming to MPLS-TP, unless these integrity requirements specified in the SLA can be satisfied.
MPLS-TPは、それに関連するサービスレベル契約（SLA）で必要とされる輸送、顧客のサービストラフィックの整合性を確保するためのメカニズムをサポートしなければならない」というMPLSトランスポートプロファイル（MPLS-TP）[RFC5654]要件44個の状態。完全性の損失であってもよいですパケットの破損、並べ替え、または通常のネットワーク状況」中の損失として定義されます。加えて、MPLS-TPは、フローLSEによって打ち負かされるOAMパケットとデータパケットとの間の運命共有の広範な利用します。 PWの流れを意識したトランスポートは、パケットを並べ替え、したがって、SLAで指定されたこれらの整合性の要件を満たすことができない限り、MPLS-TPに準拠したネットワークに配置してはなりません。
The protocol defined in this document supports the asymmetric inclusion of the flow LSE. Asymmetric operation can be expected when there is asymmetry in the bandwidth requirements making it unprofitable for one PE to perform the flow classification, or when that PE is otherwise unable to perform the classification but is able to receive flow labeled packets from its peer. Asymmetric operation of the PW may also be required when one PE has a high transmission bandwidth requirement, but has a need to receive the entire PW on a single interface in order to perform a processing operation that requires the context of the complete PW (for example, policing of the egress traffic).
この文書で定義されたプロトコルは、フローLSEの非対称含めることをサポートしています。非対称性は、それが不採算1個のPEがフロー分類を実行する、またはそのPEは、分類を実行するためにそうでなければできないが、そのピアからのフローラベル付きパケットを受信することができる場合の製造帯域幅の要件である場合、非対称動作が期待できます。 1つのPEが高伝送帯域幅要件を有するが、例えば、完全なPW（のコンテキストを必要とする処理動作を実行するために単一のインターフェイス上で全体PWを受信する必要がある場合PWの非対称動作も必要とされ得ます出トラフィックのポリシング）。
An extension of this technique is to create a basis for hash diversity without having to peek below the label stack for IP traffic carried over Label Distribution Protocol (LDP) LSPs. The generalisation of this extension to MPLS has been described in [MPLS-ENTROPY]. This generalisation can be regarded as a
この技術の延長は、ラベル配布プロトコル（LDP）のLSP上で行わIPトラフィックのラベルスタックの下を覗き見することなく、ハッシュ多様性の基礎を作成することです。 MPLSへのこの拡張の一般化は[MPLSエントロピー]に記載されています。この一般化はとみなすことができます
complementary, but distinct, approach from the technique described in this document. While similar consideration may apply to the identification of flows and the allocation of flow label values, the flow labels are imposed by different network components, and the associated signalling mechanisms are different.
相補的な、しかし別個の、本文書に記載された技術からのアプローチ。同様の考察は、フローの識別およびフローラベル値の割り当てに適用され得るが、フローラベルは、異なるネットワークコンポーネントによって課される、および関連するシグナル伝達機構は異なるされています。
The PW generic security considerations described in [RFC3985] and the security considerations applicable to a specific PW type (for example, in the case of an Ethernet PW [RFC4448]) apply. The security considerations in [RFC5920] also apply.
[RFC3985]で説明PW汎用セキュリティ上の考慮事項および特定のPWタイプ（例えば、イーサネット（登録商標）PWの場合には[RFC4448]）に適用可能なセキュリティ問題当てはまります。 [RFC5920]のセキュリティの考慮事項も適用されます。
Section 1.3 describes considerations that apply to the TTL value used in the flow LSE. The use of a TTL value of one prevents the accidental forwarding of a packet based on the label value in the flow LSE.
第1.3節では、フローLSEで使用するTTL値に適用される考慮事項について説明します。一方のTTL値を使用することは、フローLSEのラベル値に基づいてパケットの偶発的な転送を防止します。
IANA maintains the registry "Pseudowire Name Spaces (PWE3)" with sub-registry "Pseudowire Interface Parameters Sub-TLV type Registry". IANA has registered the Flow Label Sub-TLV type in this registry.
IANAは、サブレジストリ「スードワイヤインターフェイスパラメータサブTLVタイプレジストリ」とレジストリ「スードワイヤ名前空間（PWE3）」を維持しています。 IANAは、このレジストリ内のフローラベルサブTLVタイプが登録されています。
Parameter ID Length Description Reference
------------------------------------------------------
0x17 4 Flow Label RFC 6391
The congestion considerations applicable to PWs as described in [RFC3985] apply to this design.
[RFC3985]で説明したようにPWのに適用渋滞考慮事項は、この設計に適用されます。
The ability to explicitly configure a PW to leverage the availability of multiple ECMPs is beneficial to capacity planning as, all other parameters being constant, the statistical multiplexing of a larger number of smaller flows is more efficient than with a smaller number of larger flows.
他の全てのパラメータが一定であるとして明示的に複数ECMPsの可用性を活用するPWを設定する機能は、容量計画に有益である、より小さなフローの多数の統計的多重化は、より大きなフロー数の少ないよりも効率的です。
Note that if the classification into flows is only performed on IP packets, the behaviour of those flows in the face of congestion will be as already defined by the IETF for packets of that type, and no additional congestion processing is required.
フローへの分類は、IPパケットのみに対して実行された場合に、輻輳に直面して、それらのフローの挙動は、既にそのタイプのパケットのためにIETFによって定義され、追加の輻輳処理が必要とされないことに留意されたいです。
Where flows that are not IP are classified, PW congestion avoidance must be applied to each non-IP load balance group.
IPでないフローが分類されている場合は、PWの輻輳回避は、各非IP負荷分散グループに適用する必要があります。
The authors wish to thank Mary Barnes, Eric Grey, Kireeti Kompella, Joerg Kuechemann, Wilfried Maas, Luca Martini, Mark Townsley, Rolf Winter, and Lucy Yong for valuable comments on this document.
作者はこのドキュメントの貴重なコメントのためにメアリー・バーンズ、エリックグレー、Kireeti Kompella、イェルクKuechemann、ウィルフリード・マース、ルカ・マルティーニ、マークTownsley、ロルフ冬、そしてルーシー龍に感謝したいです。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032]ローゼン、E.、タッパン、D.、Fedorkow、G.、Rekhter、Y.、ファリナッチ、D.、李、T.、およびA.コンタ、 "MPLSラベルスタックエンコーディング"、RFC 3032、2001年1月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379] Kompella、K.とG.ツバメ、2006年2月、RFC 4379 "を検出マルチプロトコルラベルは（MPLS）データプレーン障害をスイッチ"。
[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月。
[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4447]、RFC 4447マティーニ、L.、エド。、ローゼン、E.、エルAawar、N.、スミス、T.、およびG.サギ、 "ラベル配布プロトコル（LDP）を使用して疑似回線の設定とメンテナンス" 、2006年4月。
[RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006.
[RFC4448]マティーニ、L.、エド。、ローゼン、E.、エル・Aawar、N.、およびG.サギ、 "MPLSネットワーク上のイーサネットの輸送のためのカプセル化方法"、RFC 4448、2006年4月。
[RFC4553] Vainshtein, A., Ed., and YJ. Stein, Ed., "Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)", RFC 4553, June 2006.
[RFC4553] Vainshtein、A.編、及びYJ。スタイン、エド。、 "パケット（のSAToP）以上の構造に依存しない時分割多重（TDM）"、RFC 4553、2006年6月。
[RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal Cost Multipath Treatment in MPLS Networks", BCP 128, RFC 4928, June 2007.
[RFC4928]ツバメ、G.、ブライアント、S.、およびL.アンダーソン、 "MPLSネットワークにおけるイコールコストマルチパス治療の回避"、BCP 128、RFC 4928、2007年6月。
[RFC5085] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.
[RFC5085]ナドー、T.、エド、およびC. Pignataro、エド、 "Pseudowireの仮想回線接続性検証（VCCV）：スードワイヤ用制御チャネル"。。、RFC 5085、2007年12月。
[MPLS-ENTROPY] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", Work in Progress, October 2011.
[MPLS-エントロピー] Kompella、K.、ドレイク、J.、Amante、S.、Henderickx、W.、およびL.ヨンジュン、 "MPLSフォワーディングにおけるエントロピーラベルの使用"、進歩、2011年10月での作業。
[PWBONDING] Stein, Y(J)., Mendelsohn, I., and R. Insler, "PW Bonding", Work in Progress, November 2008.
[PWBONDING]スタイン、Y（J）。、メンデルゾーン、I.、およびR. Insler、 "PW絆"、進歩、2008年11月の作業。
[RFC3985] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985]ブライアント、S.、エド。、およびP.パテ、エド。、 "疑似ワイヤーエミュレーション端から端まで（PWE3）アーキテクチャ"、RFC 3985、2005年3月。
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090]パン、P.、エド。、ツバメ、G.、エド。、およびA.アトラス編、 "高速リルート機能拡張LSPトンネルのための-TEをRSVPする"、RFC 4090、2005年5月。
[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.バーガー、 "MPLSでのリンクバンドルトラフィックエンジニアリング（TE）"、RFC 4201、2005年10月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4378] Allan, D., Ed., and T. Nadeau, Ed., "A Framework for Multi-Protocol Label Switching (MPLS) Operations and Management (OAM)", RFC 4378, February 2006.
[RFC4378]アラン、D.、エド。、およびT.ナドー、エド。、 "（MPLS）操作と管理（OAM）をマルチプロトコルラベルスイッチングのためのフレームワーク"、RFC 4378、2006年2月。
[RFC5286] Atlas, A., Ed., and A. Zinin, Ed., "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, September 2008.
[RFC5286]アトラス、A.、エド、およびA.ジニン、エド、 "IP高速リルートのための基本仕様：ループフリーのAlternates"。。、RFC 5286、2008年9月。
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, February 2009.
[RFC5462]アンデション、L.およびR. Asatiは、 "マルチプロトコルラベルスイッチング（MPLS）ラベルスタックエントリ： "EXPトラフィッククラス "フィールド"、RFC 5462、2009年2月" フィールドに改名します"。
[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009.
[RFC5654]ニーヴン、ジェンキンス、B.、編。、Brungard、D.、編、ベッツ、M.編、Sprecher、N.、およびS.上野、 "MPLSトランスポートプロファイルの要件"、RFC 5654 2009年9月。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010.
[RFC5880]カッツ、D.およびD.区、 "双方向フォワーディング検出（BFD）"、RFC 5880、2010年6月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920]牙、L.、エド。、 "MPLSおよびGMPLSネットワークのセキュリティフレームワーク"、RFC 5920、2010年7月。
Authors' Addresses
著者のアドレス
Stewart Bryant (editor) Cisco Systems 250 Longwater Ave. Reading RG2 6GB United Kingdom
スチュワートブライアント（編集者）、シスコシステムズ250 Longwaterアベニュー。 RG2 6ギガバイトイギリスを読みます
Phone: +44-208-824-8828 EMail: stbryant@cisco.com
電話：+ 44-208-824-8828電子メール：stbryant@cisco.com
Clarence Filsfils Cisco Systems Brussels Belgium
クラレンスFilsfilsシスコシステムズブリュッセルベルギー
EMail: cfilsfil@cisco.com
メールアドレス：cfilsfil@cisco.com
Ulrich Drafz Deutsche Telekom Muenster Germany
ウルリッヒDrafzドイツテレコムミュンスタードイツ
EMail: Ulrich.Drafz@telekom.de
メールアドレス：Ulrich.Drafz@telekom.de
Vach Kompella Alcatel-Lucent
VACH Kompellaアルカテル・ルーセント
EMail: vach.kompella@alcatel-lucent.com
メールアドレス：vach.kompella@alcatel-lucent.com
Joe Regan Alcatel-Lucent
ジョー・リーガンアルカテル・ルーセント
EMail: joe.regan@alcatel-lucent.com
メールアドレス：joe.regan@alcatel-lucent.com
Shane Amante Level 3 Communications, LLC 1025 Eldorado Blvd. Broomfield, CO 80021 USA
シェーンAmanteレベル3コミュニケーションズ、LLC 1025エルドラドブールバード。ブルームフィールド、CO 80021 USA
EMail: shane@level3.net
メールアドレス：shane@level3.net