[要約] RFC 6391は、MPLSパケットスイッチングネットワーク上での擬似ワイヤのフローアウェアトランスポートに関する規格です。その目的は、擬似ワイヤのトラフィックフローを効率的に制御し、ネットワークのパフォーマンスを最適化することです。
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.
擬似ワイヤのペイロードが多数の異なるフローを含む場合、パケットスイッチネットワークに存在する等しいコストの複数のパス（ECMP）でそれらのフローを運ぶことが望ましい場合があります。ほとんどの転送エンジンは、MPLSラベルスタックのハッシュを生成し、このメカニズムを使用してMPLSフローのバランスをとることができます。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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]は、通常、1つのネットワークパスで輸送されます。これは、エミュレートサービスの特性を保存するために必要です（たとえば、パケット（SATOP）PWパケット[RFC4553]を介した構造に依存しない時刻分割多重化を避けたり、パケットを使用できない攻撃時間にさらしたりするため）。順序を維持するための単一のパスの使用は、PWの操作のデフォルトモードのままです。このドキュメントで提案されている新しい機能は、ECMPの使用がPWの動作に有益である（有害ではない）ことが知られている場合に使用される可能性のあるオプションモードです。
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.
一部のPWは、ルーター間で大量のIPトラフィックを輸送するために使用されます。この一例は、イーサネットPWを使用して、ルーターのペア間の仮想直接リンクを作成することです。このようなPWは、数百のMBPからGBPSのトラフィックに運ばれる場合があります。これらのPWは、個々の輸送された各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.
複数のECMPの可用性を活用するようにこのような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の場合、ラベルスタックをハッシュすることによって得られる粒度は、満足のいく負荷分散には不十分です。ただし、Ingressノードは、利用可能なECMPまたはループフリーの代替品[RFC5286]の間でフローの拡散を支援するために、カプセル化されていないパケットヘッダーを理解できるという特別な位置にあります[RFC5286]。このドキュメントでは、Ingressノードによって選択され、ラベルスタックの下部に配置された追加のラベルを導入することにより、PWS上で実行されるトラフィックのハッシュに関する粒度を導入する方法を定義します。
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.1AX-2008（元々はIEEE 802.3AD-2000として指定）リンクを介して分布のためのフローを選択するために使用することもできます。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）は、一般に、ラベルスタックまたはラベルスタックのいくつかの要素のハッシュを生成し、フローを識別し、これを使用してネットワークに存在する利用可能なECMPを介してそれらを分散する方法として生成します。スタックの下部にあるラベルは通常、フローに最も密接に関連するラベルであるため、通常は最大のエントロピーを提供するため、通常はハッシュに含まれます。このドキュメントでは、利用可能なECMP上の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:
多数のPWSを作成し、それらの間のフローを分配することにより、負荷分散の代替方法は考慮されましたが、以下のために拒否されました。
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 セットアップおよび維持するには、追加のPWSが必要でした。
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内の不可分なフローは、Ingress PEによって同じフローラベルにマッピングする必要があります。フローラベルは、パケットスイッチネットワーク（PSN）で正しいECMP負荷バランスの動作を刺激します。出口PE（フローLSEが存在することを知っている）で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）の価値の選択を考慮することは有用です[RFC3032]。フローLSEは、ラベルスタックの下部にあります。したがって、最後から2番目のホップポップが採用されている場合でも、PEに到着すると常にPWラベルが先行します。エラー条件により、フローLSEがスタックの上部になると、通常のLSEであるかのように調べられ、パケットが転送される可能性があります。これは、フローLSE TTLを1に設定することで防止でき、それによりパケットをフォワーダーによって破棄することを強制します。ペイロードに関係なくTTLを1に設定することは、一般的な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.
このドキュメントは、流れラベルのトラフィッククラス（TC）フィールド[RFC5462]（以前は実験用途（EXP）ビット[RFC3032]）として知られている使用を定義していません。将来の文書は、これらのビットの使用を定義する場合があります。したがって、この仕様に準拠する実装は、イングレスで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]は、エミュレートサービスの構造に関する知識を持つPEのコンポーネントであり、PWの範囲外のサービスに対してアクションを実行できます。この場合、イングレス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で。Ingress PEのフォワーダーは、PWコントロールワード（該当する場合）を準備し、Flowラベルをプッシュし、続いて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.
Egress PEのフォワーダーは、Pseudowireラベルを使用してPseudowireを識別します。Pseudowireラベルに関連付けられたコンテキストから、出力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.
フローLSEを含むように変更されたPWE3プロトコルスタック参照モデルを図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：pseudowire flow 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]でシグナル伝達手順を使用する場合、新しいPseudowire InterfaceパラメーターSub-TLV、フローラベルSub-TLV（FL Sub-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 Sub-TLVがないことは、PEがフローラベルを処理できないことを示しています。PWシグナル伝達を使用しており、FL Sub-TLVを送信しないIngress PEは、PWパケットにフローラベルを含めてはなりません。PWシグナル伝達を使用しており、出力ピアからFL Sub-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 Sub-TLVを送信し、R = 1でFL Sub-TLVを受信するPEは、PWパケットにフローラベルを含める必要があります。FL Sub-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.
フローラベルSub-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.
o t = 1の場合、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）の変更を必要とせずにマルチセグメントPWSで機能します。これは、フロー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はPESでPWSが構成されていることを確認するための基本的なテストを実行するためにのみ使用されます。仮想回路接続検証（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]接続検証メッセージは、各ECMPパスに擬似術PEに送信する必要があります。このソリューションは達成が難しく、スケールが不十分です。これらの状況では、PSN内で障害が発生した場合、障害が通常PSNによって検出および修復されるため、荷物バランスの擬似ワイヤパスを使用してVCCVメッセージを送信するだけで十分かもしれません。つまり、PSNのインテリアゲートウェイプロトコル（IGP）リンク/ノード障害検出メカニズム（光の喪失、双方向転送検出[RFC5880]、またはIGPハロー検出）とIGP収束は、侵入間のネットワークパスのECMPセットセットを自然に変更します。と出口o。したがって、PWは通常のIGP収束時間中にのみ影響を受けます。高速な再ルーティングまたは高速収束技術がネットワークに展開されている場合、この期間は短縮される可能性があることに注意してください[RFC4090] [RFC5286]。
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テクノロジーは自己記述的ではないため、PSN内のノードはPWのディープパケット検査（DPI）を実行することはできません。PWペイロードの構造は、イングレスと出口のPEデバイスにのみ知られています。このドキュメントで提案されている方法は、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
この設計は、MPLS PWSに適用されます。ここでは、イングレスPEに提示されたパケットをフローに構築することが意味があります。このドキュメントで説明されているメカニズムは、異なるネットワークパス上のPW内のフローの分布を促進します。次に、これは、フロー内のパケットが順番に配信される一方であることを意味します
(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.
（トポロジーの変動による通常の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などの高層流量依存フィールドが含まれます。
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つの隣接するノード間のいくつかの物理回路を結合するため、単一の高帯域幅の「仮想」パイプとして高層プロトコルに表示されます。これらは、特定のネットワークのさまざまな部分に共存する場合があります。ラグの利点は、デバイス間のルーティングおよびシグナル伝達プロトコルの隣接の数を減らし、コントロールプレーンの処理オーバーヘッドを削減することです。ECMPと同様に、遅延に関連する重要な問題は、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セットの1人のメンバーを介してフローを必要とする同じ考慮事項は、ラグのメンバーに適用されます。
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].
一部のネットワークでは、ラベルエッジルーター（LER）が複数のリソース予約プロトコル - トラフィックエンジニアリング（RSVP-TE）トンネルにPWをロードできるようにすることが望ましいです。このドキュメントで説明されているフローラベルメカニズムは、必要なフロー情報とこのタイプの負荷分散を提供するために必要なエントロピーをLERに提供するために使用できます。そのようなケースの例は、すべてのコンポーネント[RFC4201]とのリンクバンドルを使用して、ネットワークでのフローラベルメカニズムの使用です。
Methods by which the LER is configured to apply this type of ECMP are outside the scope of this document.
このタイプのECMPを適用するようにLERが構成されている方法は、このドキュメントの範囲外です。
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. オペレーターは、これらのフローによって1つのパスのみが影響を受けるように、すべての高帯域幅フローに一定のフローラベルを割り当てるようにIngress 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. オペレーターは、ユーザーへのオーダーオーダートラフィックを犠牲にしてネットワークへの破壊を最小限に抑えるために、すべての高帯域幅フローにランダムフローラベルを割り当てるようにIngress 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.
o 第一に、PSNの非効率的な使用がジッターにつながり、最終的にPWのペイロードを損なうため、高帯域幅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輸送プロファイル（MPLS-TP）[RFC5654]要件44は、「MPLS-TPは、関連するサービスレベル契約（SLA）が必要とする輸送された顧客のサービストラフィックの整合性を確保するメカニズムをサポートする必要があると述べています。通常のネットワーク条件中のパケットの破損、並べ替え、または損失として定義されています」。さらに、MPLS-TPは、OAMとデータパケット間の運命共有を広範囲に使用しており、これはFlow LSEによって敗北しています。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が分類を実行できないが、ピアからフローラベルの付いたパケットを受信できる場合、非対称操作が予想されます。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エントロピー]で説明されています。この一般化は、aと見なすことができます
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値に適用される考慮事項について説明します。1つの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は、サブレジストリ「Pseudowire Interfaceパラメーターサブ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]に記載されているPWSに適用される混雑の考慮事項は、この設計に適用されます。
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.
複数のECMPの可用性を活用するように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.
著者は、メアリー・バーンズ、エリック・グレイ、キリエト・コンペラ、ジョーグ・クエチェマン、ウィルフリード・マース、ルカ・マティーニ、マーク・タウンズリー、ロルフ・ウィンター、ルーシー・ヨンにこの文書に関する貴重なコメントに感謝します。
[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] Rosen、E.、Tappan、D.、Fedorkow、G.、Rekhter、Y.、Farinacci、D.、Li、T。、およびA. conta、「Mpls Label Stack Encoding」、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. Swallow、「Multi-Protocol Label Switched（MPLS）データプレーン障害の検出」、RFC 4379、2006年2月。
[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] Bryant、S.、Swallow、G.、Martini、L。、およびD. McPherson、「Pseudowire Emulation Edge-to-Edge（PWE3）がMPLS PSNを介して使用するコントロールワード」、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] Martini、L.、Ed。、Ed。、Rosen、E.、El-Aawar、N.、Smith、T.、およびG. Heron、「ラベル分布プロトコル（LDP）を使用した擬似ワイヤーのセットアップとメンテナンス」、RFC 4447、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] Martini、L.、Ed。、Rosen、E.、El-Aawar、N。、およびG. Heron、「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.、ed。、およびYJ。Stein、ed。、「パケット（TDM）（TDM）（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] Swallow、G.、Bryant、S。、およびL. Andersson、「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] Nadeau、T.、ed。、およびC. Pignataro、ed。、「Pseudowire Virtual Curned Connectivity Verification（VCCV）：Pseudowiresの制御チャネル」、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 -Entropy] Kompella、K.、Drake、J.、Amante、S.、Henderickx、W。、およびL. Yong、「MPLS転送におけるエントロピーラベルの使用」、2011年10月の作業。
[PWBONDING] Stein, Y(J)., Mendelsohn, I., and R. Insler, "PW Bonding", Work in Progress, November 2008.
[PWBonding] Stein、Y（J）。、Mendelsohn、I。、およびR. Insler、「PW Bonding」、Progress、2008年11月。
[RFC3985] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985] Bryant、S.、ed。、およびP. Pate、ed。、「Pseudo Wire Emulation Edge-to-Edge（PWE3）Architecture」、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] Pan、P.、Ed。、Ed。、Swallow、G.、ed。、およびA. Atlas、ed。、「LSP TunnelsのRSVP-TEへの高速リルート拡張」、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. Berger、「MPLS Traffic Engineering（TE）のリンクバンドリング」、RFC 4201、2005年10月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、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] Allan、D.、ed。、およびT. Nadeau、ed。、「マルチプロトコルラベルスイッチング（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] Atlas、A.、ed。、およびA. Zinin、ed。、「IP Fast Reroute：Loop-Free 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] Andersson、L。and 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] Niven-Jenkins、B.、Ed。、Brungard、D.、Ed。、Betts、M.、Ed。、Sprecher、N.、およびS. Ueno、「MPLS輸送プロファイルの要件」、RFC 5654、2009年9月。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010.
[RFC5880] Katz、D。およびD. Ward、「双方向転送検出（BFD）」、RFC 5880、2010年6月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920] Fang、L.、ed。、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、2010年7月。
Authors' Addresses
著者のアドレス
Stewart Bryant (editor) Cisco Systems 250 Longwater Ave. Reading RG2 6GB United Kingdom
スチュワートブライアント（編集者）シスコシステム250ロングウォーターアベニュー。RG26GBイギリスを読む
Phone: +44-208-824-8828
EMail: stbryant@cisco.com
Clarence Filsfils Cisco Systems Brussels Belgium
Clarence Filsfils Cisco Systems Brussels Belgium
EMail: cfilsfil@cisco.com
Ulrich Drafz Deutsche Telekom Muenster Germany
Ulrich Drafz Deutsche Telekom Muensterドイツ
EMail: Ulrich.Drafz@telekom.de
Vach Kompella Alcatel-Lucent
Vach Kompella Alcatel-Lucent
EMail: vach.kompella@alcatel-lucent.com
Joe Regan Alcatel-Lucent
Joe Regan Alcatel-Lucent
EMail: joe.regan@alcatel-lucent.com
Shane Amante Level 3 Communications, LLC 1025 Eldorado Blvd. Broomfield, CO 80021 USA
Shane Amanteレベル3 Communications、LLC 1025 Eldorado Blvd.Broomfield、Co 80021 USA
EMail: shane@level3.net