[要約] RFC 7190は、MPLSとMPLS Transport Profile（MPLS-TP）のマルチパスの使用に関するガイドラインです。このRFCの目的は、MPLS-TPネットワークでのマルチパスの効果的な利用方法を提供することです。
Internet Engineering Task Force (IETF) C. Villamizar
Request for Comments: 7190 Outer Cape Cod Network Consulting
Category: Informational March 2014
ISSN: 2070-1721
Use of Multipath with MPLS and MPLS Transport Profile (MPLS-TP)
MPLSおよびMPLSトランスポートプロファイル（MPLS-TP）でのマルチパスの使用
Abstract
概要
Many MPLS implementations have supported multipath techniques, and many MPLS deployments have used multipath techniques, particularly in very high-bandwidth applications, such as provider IP/MPLS core networks. MPLS Transport Profile (MPLS-TP) has strongly discouraged the use of multipath techniques. Some degradation of MPLS-TP Operations, Administration, and Maintenance (OAM) performance cannot be avoided when operating over many types of multipath implementations.
多くのMPLS実装はマルチパス技術をサポートしており、多くのMPLS展開は、特にプロバイダーIP / MPLSコアネットワークなどの非常に高帯域幅のアプリケーションでマルチパス技術を使用しています。 MPLSトランスポートプロファイル（MPLS-TP）は、マルチパス技術の使用を強く推奨していません。多くのタイプのマルチパス実装で動作している場合、MPLS-TP運用、管理、および保守（OAM）のパフォーマンスの低下は避けられません。
Using MPLS Entropy Labels (RFC 6790), MPLS Label Switched Paths (LSPs) can be carried over multipath links while also providing a fully MPLS-TP-compliant server layer for MPLS-TP LSPs. This document describes the means of supporting MPLS as a server layer for MPLS-TP. The use of MPLS-TP LSPs as a server layer for MPLS LSPs is also discussed.
MPLSエントロピーラベル（RFC 6790）を使用すると、MPLSラベルスイッチドパス（LSP）をマルチパスリンク上で伝送すると同時に、MPLS-TP LSPに完全にMPLS-TP準拠のサーバーレイヤーを提供できます。このドキュメントでは、MPLS-TPのサーバー層としてMPLSをサポートする方法について説明します。 MPLS LTPのサーバー層としてのMPLS-TP LSPの使用についても説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7190.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7190で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. MPLS as a Server Layer for MPLS-TP . . . . . . . . . . . . . 5
3.1. MPLS-TP Forwarding and Server-Layer Requirements . . . . 5
3.2. Methods of Supporting MPLS-TP Client LSPs over MPLS . . . 7
4. MPLS-TP as a Server Layer for MPLS . . . . . . . . . . . . . 11
5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 13
Today the requirement to handle large aggregations of traffic can be met by a number of techniques that we will collectively call "multipath". Multipath applied to parallel links between the same set of nodes includes Ethernet Link Aggregation [IEEE-802.1AX], link bundling [RFC4201], or other aggregation techniques, some of which could be vendor specific. Multipath applied to diverse paths rather than parallel links includes Equal-Cost Multipath (ECMP) as applied to OSPF, IS-IS, or BGP, and equal-cost Label Switched Paths (LSPs). Some vendors support load splitting across equal-cost MPLS LSPs where the load is split proportionally to the reserved bandwidth of the set of LSPs.
今日、大量のトラフィックを処理する要件は、「マルチパス」と総称されるいくつかの手法で満たすことができます。同じノードセット間のパラレルリンクに適用されるマルチパスには、イーサネットリンク集約[IEEE-802.1AX]、リンクバンドリング[RFC4201]、またはその他の集約技術が含まれ、その一部はベンダー固有である可能性があります。パラレルリンクではなく多様なパスに適用されるマルチパスには、OSPF、IS-IS、またはBGPに適用される等コストマルチパス（ECMP）、および等コストラベルスイッチドパス（LSP）が含まれます。一部のベンダーは、負荷がLSPセットの予約済み帯域幅に比例して分割される等コストMPLS LSP間での負荷分割をサポートしています。
RFC 5654 requirement 33 requires the capability to carry a client MPLS Transport Profile (MPLS-TP) or MPLS layer over a server MPLS-TP or MPLS layer [RFC5654]. This is possible in all cases with one exception. When an MPLS LSP exceeds the capacity of any single component link, it MAY be carried by a network using multipath techniques, but it SHOULD NOT be carried by a single MPLS-TP LSP due to the inherent MPLS-TP capacity limitation imposed by MPLS-TP Operations, Administration, and Maintenance (OAM) fate-sharing constraints and MPLS-TP Loss Measurement OAM packet-ordering constraints (see Section 3.1). Instead, multiple MPLS-TP LSPs SHOULD be used to carry a large MPLS LSP (see Section 4).
RFC 5654要件33では、サーバーMPLS-TPまたはMPLSレイヤー[RFC5654]を介してクライアントMPLSトランスポートプロファイル（MPLS-TP）またはMPLSレイヤーを伝送する機能が必要です。これは、1つの例外を除き、すべての場合に可能です。 MPLS LSPが単一のコンポーネントリンクの容量を超える場合、マルチパステクニックを使用してネットワークによって運ばれる場合がありますが、MPLS-によって課される固有のMPLS-TP容量制限のため、単一のMPLS-TP LSPによって運ばれるべきではありません。 TP運用、管理、および保守（OAM）運命共有制約とMPLS-TP損失測定OAMパケット順序制約（セクション3.1を参照）。代わりに、複数のMPLS-TP LSPを使用して、大きなMPLS LSPを伝送する必要があります（セクション4を参照）。
The term "composite link" is more general than terms such as "link aggregation" (which is specific to Ethernet) or "ECMP" (which implies equal-cost paths within a routing protocol). The use of the term "composite link" here is consistent with the broad definition in [ITU-T.G.800]. Multipath is very similar to composite link as defined by ITU-T but specifically excludes inverse multiplexing.
「複合リンク」という用語は、「イーサネットに固有の」「リンク集約」や「ルーティングプロトコル内の等コストパスを意味する」「ECMP」などの用語よりも一般的です。ここで「複合リンク」という用語を使用することは、[ITU-T.G.800]の広範な定義と一致しています。マルチパスは、ITU-Tで定義されている複合リンクと非常に似ていますが、逆多重化は特に除外されています。
MPLS LSPs today are able to function as a server layer and carry client MPLS LSPs. When control-plane signaling is used, forwarding adjacency (FA) advertisements are used to inform the set of Label Switching Routers (LSRs) of Packet Switching Capable (PSC) LSPs within the MPLS topology [RFC4206]. Client MPLS LSP at a higher layer (lower PSC number) may signal their intention to use PSC LSPs as hops in the RSVP-TE Explicit Route Object (ERO). LSRs with no explicit support for RFC 4206 see the PSC LSPs as ordinary links and therefore use them.
今日のMPLS LSPは、サーバーレイヤーとして機能し、クライアントMPLS LSPを伝送できます。コントロールプレーンシグナリングを使用する場合、転送隣接（FA）アドバタイズメントを使用して、MPLSトポロジー内のパケットスイッチング機能（PSC）LSPのラベルスイッチングルーター（LSR）のセットに通知します[RFC4206]。上位層（下位のPSC番号）のクライアントMPLS LSPは、RSC-TE明示的ルートオブジェクト（ERO）のホップとしてPSC LSPを使用する意思を示す場合があります。 RFC 4206を明示的にサポートしていないLSRは、PSC LSPを通常のリンクと見なして使用します。
An MPLS LSP that has been set up using RSVP-TE appears to its ingress LSR as a viable IP next hop to a distant LSR. If LDP is used and bidirectional RSVP-TE LSP connectivity is available, then LDP signaling can be set up among the RSVP-TE LSP endpoints, and LDP can make use of the RSVP-TE LSP as an LDP hop. This is another form of existing MPLS-in-MPLS use. MPLS LSPs may also make use of hierarchy that is configured through the management plane rather than signaled using RSVP-TE.
RSVP-TEを使用してセットアップされたMPLS LSPは、その入力LSRからは、遠いLSRへの実行可能なIPネクストホップとして表示されます。 LDPが使用され、双方向のRSVP-TE LSP接続が利用可能な場合、LVPシグナリングをRSVP-TE LSPエンドポイント間で設定でき、LDPはRSVP-TE LSPをLDPホップとして利用できます。これは、既存のMPLS-in-MPLS使用の別の形式です。 MPLS LSPは、RSVP-TEを使用してシグナリングされるのではなく、管理プレーンを介して構成された階層を利用することもできます。
These existing forms of MPLS-in-MPLS may traverse multipath hops such as Ethernet Link Aggregation Group (LAG) [IEEE-802.1AX] or MPLS Link Bundling [RFC4201]. MPLS-TP brings with it a new set of requirements not considered in past deployments of the various forms of MPLS-in-MPLS where multipath was in use. This document merely discusses use of existing forwarding and protocol mechanisms that can support the case where either the client-layer LSPs or the server-layer LSPs are MPLS-TP and where multipath is used.
MPLS-in-MPLSのこれらの既存の形式は、Ethernet Link Aggregation Group（LAG）[IEEE-802.1AX]またはMPLS Link Bundling [RFC4201]などのマルチパスホップを通過する場合があります。 MPLS-TPは、マルチパスが使用されていたMPLS-in-MPLSのさまざまな形式の過去の展開では考慮されなかった新しい要件セットをもたらします。このドキュメントでは、クライアント層のLSPまたはサーバー層のLSPがMPLS-TPであり、マルチパスが使用されている場合をサポートできる既存の転送およびプロトコルメカニズムの使用についてのみ説明します。
Please refer to the terminology related to multipath introduced in [ADV-MULTIPATH-REQ]. The following additional terms are used in this document; related terms are grouped together.
[ADV-MULTIPATH-REQ]で導入されたマルチパスに関連する用語を参照してください。このドキュメントでは、次の追加の用語が使用されています。関連する用語はグループ化されています。
Link Bundle Link bundling is a multipath technique specific to MPLS [RFC4201]. Link bundling supports two modes of operations. Either an LSP can be placed on one component link of a link bundle, or an LSP can be load-split across all members of the bundle. There is no signaling defined that allows a per-LSP preference regarding load split, therefore whether to load split is generally configured per bundle and applied to all LSPs across the bundle.
リンクバンドルリンクバンドルは、MPLS [RFC4201]に固有のマルチパス技術です。リンクバンドリングは、2つの動作モードをサポートしています。 LSPをリンクバンドルの1つのコンポーネントリンクに配置するか、LSPをバンドルのすべてのメンバーにロードスプリットできます。ロードスプリットに関するLSPごとのプリファレンスを許可するシグナリングは定義されていないため、ロードスプリットするかどうかは、通常、バンドルごとに設定され、バンドル全体のすべてのLSPに適用されます。
All-Ones Component Within the context of link bundling, [RFC4201] defines a special case where the same label is to be valid across all component links. This case is indicated in signaling by a bit value of "all ones" when identifying a component link. Following the publication of RFC 4201, for brevity this special case has been referred to as the "all-ones component".
すべて1のコンポーネントリンクバンドリングのコンテキスト内で、[RFC4201]は、同じラベルがすべてのコンポーネントリンクにわたって有効である特別なケースを定義します。このケースは、コンポーネントリンクを識別するときに、「すべて1」のビット値によってシグナリングで示されます。 RFC 4201の公開後、簡潔にするために、この特殊なケースは「すべて1のコンポーネント」と呼ばれています。
Equal-Cost Multipath (ECMP) Equal-Cost Multipath (ECMP) is a specific form of multipath in which the costs of the links or paths must be equal in a given routing protocol. The load may be split equally across all available links (or available paths), or the load may be split proportionally to the capacity of each link (or path).
等コストマルチパス（ECMP）等コストマルチパス（ECMP）は、特定のルーティングプロトコルでリンクまたはパスのコストが等しい必要があるマルチパスの特定の形式です。負荷は、使用可能なすべてのリンク（または使用可能なパス）に均等に分割される場合と、各リンク（またはパス）の容量に比例して分割される場合があります。
Loop-Free Alternate Paths (LFA) "Loop-free alternate paths" (LFA) are defined in Section 5.2 of RFC 5714 [RFC5714] as follows: "Such a path exists when a direct neighbor of the router adjacent to the failure has a path to the destination that can be guaranteed not to traverse the failure." Further detail can be found in [RFC5286]. LFA as defined for IP Fast Reroute (IPFRR) can be used to load balance by relaxing the equal-cost criteria of ECMP, though IPFRR defined LFA for use in selecting protection paths. When used with IP, proportional split is generally not used. LFA use in load balancing is implemented by some vendors, though it may be rare or non-existent in deployments.
ループフリー代替パス（LFA）「ループフリー代替パス」（LFA）は、RFC 5714 [RFC5714]のセクション5.2で次のように定義されています。「このようなパスは、障害に隣接するルーターの直接のネイバーに障害を通過しないことが保証できる宛先へのパス。」詳細は[RFC5286]にあります。 IP高速リルート（IPFRR）に定義されたLFAを使用して、ECMPの等価コスト基準を緩和することでロードバランスを行うことができますが、IPFRRは保護パスの選択に使用するLFAを定義しました。 IPで使用する場合、通常、比例分割は使用されません。負荷分散でのLFAの使用は一部のベンダーによって実装されていますが、展開ではまれであるか、存在しない場合があります。
Link Aggregation The term "link aggregation" generally refers to Ethernet Link Aggregation as defined by [IEEE-802.1AX]. Ethernet Link Aggregation defines a Link Aggregation Control Protocol (LACP) which coordinates inclusion of Link Aggregation Group (LAG) members in the LAG.
リンク集約「リンク集約」という用語は一般に、[IEEE-802.1AX]で定義されているイーサネットリンク集約を指します。イーサネットリンク集約は、リンク集約グループ（LAG）メンバーをLAGに含めることを調整するリンク集約制御プロトコル（LACP）を定義します。
Link Aggregation Group (LAG) A group of physical Ethernet interfaces that are treated as a logical link when using Ethernet Link Aggregation is referred to as a Link Aggregation Group (LAG).
リンク集約グループ（LAG）イーサネットリンク集約を使用するときに論理リンクとして扱われる物理イーサネットインターフェイスのグループは、リンク集約グループ（LAG）と呼ばれます。
LAG Member Ethernet Link Aggregation as defined in [IEEE-802.1AX] refers to an individual link in a LAG as a LAG member. A LAG member is a component link. An Ethernet LAG is a composite link. IEEE does not use the terms "composite link" or "component link".
[IEEE-802.1AX]で定義されているLAGメンバーのイーサネットリンク集約は、LAG内の個々のリンクをLAGメンバーとして指します。 LAGメンバーはコンポーネントリンクです。イーサネットLAGは複合リンクです。 IEEEでは、「複合リンク」または「コンポーネントリンク」という用語を使用していません。
A small set of requirements are discussed. These requirements make use of keywords such as MUST and SHOULD as described in [RFC2119].
少数の要件について説明します。これらの要件は、[RFC2119]で説明されているように、MUSTやSHOULDなどのキーワードを使用します。
An MPLS LSP may be used as a server layer for MPLS-TP LSPs as long as all MPLS-TP requirements are met. Section 3.1 reviews the basis for requirements of a server layer that supports MPLS-TP as a client layer. Key requirements include OAM "fate-sharing" and that packets within an MPLS-TP LSP (including both payload and OAM packets) not be reordered. Section 3.2 discusses implied requirements where MPLS is the server layer for MPLS-TP client LSPs and describes a set of solutions that use existing MPLS mechanisms.
MPLS-TP要件がすべて満たされている限り、MPLS LSPをMPLS-TP LSPのサーバー層として使用できます。セクション3.1では、MPLS-TPをクライアントレイヤーとしてサポートするサーバーレイヤーの要件の基礎をレビューします。重要な要件には、OAMの「運命共有」と、MPLS-TP LSP内のパケット（ペイロードとOAMパケットの両方を含む）の順序が変更されないことが含まれます。セクション3.2では、MPLSがMPLS-TPクライアントLSPのサーバー層である場合の暗黙の要件について説明し、既存のMPLSメカニズムを使用する一連のソリューションについて説明します。
[RFC5960] defines the data-plane requirements for MPLS-TP. Two very relevant paragraphs in Section 3.1.1 ("LSP Packet Encapsulation and Forwarding") are the following:
[RFC5960]は、MPLS-TPのデータプレーン要件を定義しています。セクション3.1.1の2つの関連性の高い段落（「LSPパケットのカプセル化と転送」）は次のとおりです。
RFC 5960, Section 3.1.1, Paragraph 3 Except for transient packet reordering that may occur, for example, during fault conditions, packets are delivered in order on L-LSPs, and on E-LSPs within a specific ordered aggregate.
RFC 5960、セクション3.1.1、段落3たとえば、障害状態の間に発生する可能性のある一時的なパケットの並べ替えを除き、パケットは、L-LSPで、および特定の順序付けられた集約内のE-LSPで順番に配信されます。
RFC 5960, Section 3.1.1, Paragraph 6 Equal-Cost Multi-Path (ECMP) load-balancing MUST NOT be performed on an MPLS-TP LSP. MPLS-TP LSPs as defined in this document MAY operate over a server layer that supports load-balancing, but this load-balancing MUST operate in such a manner that it is transparent to MPLS-TP. This does not preclude the future definition of new MPLS-TP LSP types that have different requirements regarding the use of ECMP in the server layer.
RFC 5960、セクション3.1.1、パラグラフ6等コストマルチパス（ECMP）ロードバランシングは、MPLS-TP LSPで実行してはなりません。このドキュメントで定義されているMPLS-TP LSPは、負荷分散をサポートするサーバーレイヤー上で動作する場合がありますが、この負荷分散はMPLS-TPに対して透過的な方法で動作する必要があります。これは、サーバー層でのECMPの使用に関して異なる要件を持つ新しいMPLS-TP LSPタイプの将来の定義を排除するものではありません。
[RFC5960], Section 3.1.1, Paragraph 3 requires that packets within a specific ordered aggregate be delivered in order. This same requirement is already specified by Differentiated Services [RFC2475]. [RFC5960], Section 3.1.1, Paragraph 6 explicitly allows a server layer to use ECMP, provided that it is transparent to the MPLS-TP client layer.
[RFC5960]、セクション3.1.1、パラグラフ3では、特定の順序付けられた集合体内のパケットを順番に配信する必要があります。この同じ要件は、Differentiated Services [RFC2475]によってすでに指定されています。 [RFC5960]、セクション3.1.1、パラグラフ6では、MPLS-TPクライアントレイヤーに対して透過的であれば、サーバーレイヤーがECMPを使用することを明示的に許可しています。
[RFC6371] adds a requirement for data traffic and OAM traffic "fate-sharing". The following paragraph in Section 1 ("Introduction") summarizes this requirement.
[RFC6371]は、データトラフィックとOAMトラフィックの「運命共有」の要件を追加します。セクション1の次の段落（「はじめに」）では、この要件を要約しています。
RFC 6371, Section 1, Paragraph 7 OAM packets that instrument a particular direction of a transport path are subject to the same forwarding treatment (i.e., fate-share) as the user data packets and in some cases, where Explicitly TC-encoded-PSC LSPs (E-LSPs) are employed, may be required to have common per-hop behavior (PHB) Scheduling Class (PSC) End-to-End (E2E) with the class of traffic monitored. In case of Label-Only-Inferred-PSC LSP (L-LSP), only one class of traffic needs to be monitored, and therefore the OAM packets have common PSC with the monitored traffic class.
RFC 6371、セクション1、段落7、トランスポートパスの特定の方向を計測するOAMパケットは、ユーザーデータパケットと同じ転送処理（つまり、運命共有）の対象となり、場合によっては、明示的にTCエンコードされたPSC LSP（E-LSP）が採用されており、トラフィックのクラスを監視しながら、共通のホップごとの動作（PHB）スケジューリングクラス（PSC）エンドツーエンド（E2E）が必要になる場合があります。 Label-Only-Inferred-PSC LSP（L-LSP）の場合、1つのクラスのトラフィックのみを監視する必要があるため、OAMパケットには監視対象のトラフィッククラスと共通のPSCがあります。
[RFC6371] does not prohibit multilink techniques in Section 4.6 ("Fate-Sharing Considerations for Multilink"), where multilink is defined as Ethernet Link Aggregation and the use of Link Bundling for MPLS, but it does declare that such a network would be only partially MPLS-TP compliant. The characteristic that is to be avoided is contained in the following sentence in that section.
[RFC6371]は、マルチリンクがイーサネットリンクアグリゲーションおよびMPLSのリンクバンドリングの使用として定義されているセクション4.6（「マルチリンクの運命共有の考慮事項」）のマルチリンクテクニックを禁止していませんが、このようなネットワークは一部MPLS-TP準拠。回避すべき特性は、そのセクションの次の文に含まれています。
RFC 6371, Section 4.6, Paragraph 1, last sentence These techniques frequently share the characteristic that an LSP may be spread over a set of component links and therefore be reordered, but no flow within the LSP is reordered (except when very infrequent and minimally disruptive load rebalancing occurs).
RFC 6371、セクション4.6、パラグラフ1、最後の文これらの手法は、LSPが一連のコンポーネントリンクに分散しているために並べ替えられる可能性があるという特徴を頻繁に共有しますが、LSP内のフローは並べ替えられません（ごくまれで最小限の中断を除く負荷の再調整が行われます）。
A declaration that implies that Link Bundling for MPLS yields a partially MPLS-TP-compliant network is perhaps overstated since only the Link Bundling all-ones component link has this characteristic.
リンクバンドリングオールワンコンポーネントリンクのみがこの特性を持っているため、MPLSのリンクバンドリングが部分的にMPLS-TP準拠のネットワークを生成することを暗示する宣言は、おそらく過大評価されています。
[RFC6374] defines a direct Loss Measurement (LM) where LM OAM packets cannot be reordered with respect to payload packets. This will require that payload packets themselves not be reordered. The following paragraph in Section 2.9.4 ("Equal Cost Multipath") gives the reason for this restriction.
[RFC6374]は、LM OAMパケットをペイロードパケットに関して並べ替えることができない直接損失測定（LM）を定義しています。これには、ペイロードパケット自体を並べ替えないことが必要です。セクション2.9.4の次の段落（「等コストマルチパス」）は、この制限の理由を示しています。
RFC 6374, Section 2.9.4, Paragraph 2 The effects of ECMP on loss measurement will depend on the LM mode. In the case of direct LM, the measurement will account for any packets lost between the sender and the receiver, regardless of how many paths exist between them. However, the presence of ECMP increases the likelihood of misordering both of LM messages relative to data packets and of the LM messages themselves. Such misorderings tend to create unmeasurable intervals and thus degrade the accuracy of loss measurement. The effects of ECMP are similar for inferred LM, with the additional caveat that, unless the test packets are specially constructed so as to probe all available paths, the loss characteristics of one or more of the alternate paths cannot be accounted for.
RFC 6374、セクション2.9.4、パラグラフ2損失測定に対するECMPの影響は、LMモードによって異なります。直接LMの場合、測定値は、それらの間に存在するパスの数に関係なく、送信側と受信側の間で失われたパケットを考慮します。ただし、ECMPが存在すると、データパケットに関連するLMメッセージとLMメッセージ自体の両方の順序が誤っている可能性が高くなります。このような誤った順序は、測定不能な間隔を作成する傾向があり、したがって損失測定の精度を低下させます。 ECMPの影響は推論されたLMと同様ですが、使用可能なすべてのパスをプローブするようにテストパケットが特別に構築されていない限り、1つまたは複数の代替パスの損失特性を考慮できないという追加の警告があります。
Supporting MPLS-TP LSPs over a fully MPLS-TP conformant MPLS LSP server layer where the MPLS LSPs are making use of multipath requires special treatment of the MPLS-TP LSPs such that those LSPs meet MPLS-TP forwarding requirements (see Section 3.1). This implies the following brief set of requirements.
MPLS LTPがマルチパスを利用しているMPLS-TPに完全に準拠したMPLS LSPサーバー層でMPLS-TP LSPをサポートするには、これらのLSPがMPLS-TP転送要件を満たすようにMPLS-TP LSPを特別に処理する必要があります（セクション3.1を参照）。これは、次の簡単な要件のセットを意味します。
MP#1 It MUST be possible for a midpoint MPLS-TP Label Switching Router (LSR) that is serving as ingress to a server-layer MPLS LSP to identify MPLS-TP LSPs, so that MPLS-TP forwarding requirements can be applied, or to otherwise accommodate the MPLS-TP forwarding requirements.
MP＃1 MPLS-TP LSPを識別するために、サーバー層MPLS LSPへの入口として機能しているミッドポイントMPLS-TPラベルスイッチングルーター（LSR）がMPLS-TP LSPを識別できるようにする必要があります。それ以外の場合は、MPLS-TP転送要件に対応します。
MP#2 The ability to completely exclude MPLS-TP LSPs from the multipath hash and load split SHOULD be supported. If the selected component link no longer meets requirements, an LSP is considered down, which may trigger protection and/or may require that the ingress LSR select a new path and signal a new LSP.
MP＃2マルチパスハッシュからMPLS-TP LSPを完全に除外する機能とロードスプリットがサポートされるべきです（SHOULD）。選択したコンポーネントリンクが要件を満たさなくなった場合、LSPはダウンしていると見なされます。これにより、保護がトリガーされるか、入力LSRが新しいパスを選択して新しいLSPに信号を送る必要があります。
MP#3 It SHOULD be possible to ensure that MPLS-TP LSPs will not be moved to another component link as a result of a load-rebalancing operation for multipath. If the selected component link no longer meets requirements, another component link may be selected; however, a change in path SHOULD NOT occur solely for load balancing.
MP＃3マルチパスの負荷再バランス操作の結果として、MPLS-TP LSPが別のコンポーネントリンクに移動されないようにすることが可能である必要があります（SHOULD）。選択したコンポーネントリンクが要件を満たさなくなった場合は、別のコンポーネントリンクを選択できます。ただし、パスの変更は、ロードバランシングのためだけに行うべきではありません。
MP#4 Where a Resource Reservation Protocol - Traffic Engineering (RSVP-TE) control plane is used, it MUST be possible for an ingress LSR that is setting up an MPLS-TP or an MPLS LSP to determine at path selection time whether a link or Forwarding Adjacency (FA; see [RFC4206]) within the topology can support the MPLS-TP requirements of the LSP.
MP＃4リソース予約プロトコル-トラフィックエンジニアリング（RSVP-TE）コントロールプレーンが使用されている場合、MPLS-TPまたはMPLS LSPを設定している入力LSRがパス選択時にリンクかどうかを判断できる必要がありますまたはトポロジー内の転送隣接（FA、[RFC4206]を参照）は、LSPのMPLS-TP要件をサポートできます。
The reason for requirement MP#1 may not be obvious. An MPLS-TP LSP may be aggregated along with other client LSPs by a midpoint LSR into a very large MPLS server-layer LSP, as would be the case in a core-node-to-core-node MPLS LSP between major cities. In this case, the ingress of the MPLS LSP, being a midpoint LSR for a set of client LSPs, has no signaling mechanism that can be used to determine whether one of its specific client LSPs is using MPLS or MPLS-TP. Multipath load splitting can be avoided for MPLS-TP LSPs if at the MPLS server-layer LSP ingress LSR an Entropy Label Indicator (ELI) and Entropy Label (EL) are added to the label stack by the midpoint LSR for the client MPLS-TP LSP, at the ingress of the MPLS LSP [RFC6790]. For those client LSPs that are MPLS-TP LSPs, a single per-LSP EL value must be chosen. For those client LSPs that are MPLS LSPs, per-packet entropy below the top label must, for practical reasons, be used to determine the entropy label value. The resulting label stack contains the server MPLS LSP label, ELI, EL and the client LSP label. Requirement MP#1 simply states that there must be a means to make this decision.
MP＃1が必要な理由は明らかではないかもしれません。 MPLS-TP LSPは、主要都市間のコアノード間コアMPLS LSPの場合と同様に、ミッドポイントLSRによって他のクライアントLSPとともに非常に大きなMPLSサーバー層LSPに集約される場合があります。この場合、一連のクライアントLSPのミッドポイントLSRであるMPLS LSPの入力には、特定のクライアントLSPの1つがMPLSまたはMPLS-TPのどちらを使用しているかを判断するために使用できるシグナリングメカニズムがありません。 MPLSサーバー層LSP入力LSRでエントロピーラベルインジケーター（ELI）とエントロピーラベル（EL）がクライアントMPLS-TPのミッドポイントLSRによってラベルスタックに追加されている場合、MPLS-TP LSPのマルチパス負荷分割を回避できます。 LSP、MPLS LSP [RFC6790]の入口。 MPLS-TP LSPであるクライアントLSPの場合、LSPごとの単一のEL値を選択する必要があります。 MPLS LSPであるこれらのクライアントLSPの場合、エントロピーラベル値を決定するには、実際の理由により、トップラベルより下のパケットごとのエントロピーを使用する必要があります。結果のラベルスタックには、サーバーMPLS LSPラベル、ELI、EL、およびクライアントLSPラベルが含まれます。要件MP＃1は、この決定を行う手段が必要であると単に述べています。
There is currently no signaling mechanism defined to support requirement MP#1, though that does not preclude a new extension being defined later. In the absence of a signaling extension, MPLS-TP can be identified through some form of configuration, such as configuration that provides an MPLS-TP-compatible server layer to all LSPs arriving on a specific interface or originating from a specific set of ingress LSRs.
要件MP＃1をサポートするために現在定義されているシグナリングメカニズムはありませんが、それによって後で定義される新しい拡張機能が除外されることはありません。シグナリング拡張がない場合、MPLS-TPは、特定のインターフェイスに到着する、または特定の入力LSRのセットから発生するすべてのLSPにMPLS-TP互換のサーバー層を提供する構成など、なんらかの構成を通じて識別できます。 。
Alternatively, the need for requirement MP#1 can be eliminated if every MPLS-TP LSP created by an MPLS-TP ingress makes use of an Entropy Label Indicator (ELI) and Entropy Label (EL) below the MPLS-TP label [RFC6790]. This would require that all MPLS-TP LSRs in a deployment support Entropy Label, which may render it impractical in many deployments.
または、MPLS-TP入力によって作成されたすべてのMPLS-TP LSPがMPLS-TPラベルの下のエントロピーラベルインジケーター（ELI）とエントロピーラベル（EL）を使用する場合、要件MP＃1の必要性を排除できます[RFC6790] 。これには、展開内のすべてのMPLS-TP LSRがエントロピーラベルをサポートする必要があるため、多くの展開では実用的ではない可能性があります。
Some hardware that exists today can support requirement MP#2. Signaling in the absence of MPLS Entropy Labels can make use of link bundling with the path pinned to a specific component for MPLS-TP LSPs and link bundling using the all-ones component for MPLS LSPs. This prevents MPLS-TP LSPs from being carried within MPLS LSPs but does allow the coexistence of MPLS-TP and very large MPLS LSPs.
現在存在する一部のハードウェアは、要件MP＃2をサポートできます。 MPLSエントロピーラベルがない場合のシグナリングは、MPLS-TP LSPの特定のコンポーネントにピン留めされたパスを使用したリンクバンドリングと、MPLS LSPのオールワンコンポーネントを使用したリンクバンドリングを利用できます。これにより、MPLS-TP LSPがMPLS LSP内で伝送されるのを防ぎますが、MPLS-TPと非常に大きなMPLS LSPを共存させることができます。
When Entropy Label Indicators (ELIs) and Entropy Labels (ELs) are not applied by MPLS-TP ingresses, MPLS-TP LSPs can be carried as client LSPs within an MPLS server LSP if the ingress of the MPLS server-layer LSP pushes an Entropy Label Indicator (ELI) and Entropy Label (EL) below the server-layer LSP label(s) in the label stack, just above the MPLS-TP LSP label entry [RFC6790]. The value of EL can be randomly selected at the client MPLS-TP LSP setup time, and the same EL value can be used for all packets of that MPLS-TP LSP. This allows MPLS-TP LSPs to be carried as client LSPs within MPLS LSPs and satisfies MPLS-TP forwarding requirements but requires that MPLS LSRs be able to identify MPLS-TP LSPs (requirement MP#1).
エントロピーラベルインジケーター（ELI）とエントロピーラベル（EL）がMPLS-TP入力によって適用されない場合、MPLSサーバーレイヤーLSPの入力がエントロピーをプッシュすると、MPLS-TP LSPはMPLSサーバーLSP内のクライアントLSPとして伝送されます。ラベルスタック内のサーバー層LSPラベルの下、MPLS-TP LSPラベルエントリ[RFC6790]のすぐ上にあるラベルインジケーター（ELI）およびエントロピーラベル（EL）。 ELの値は、クライアントMPLS-TP LSPセットアップ時にランダムに選択でき、そのMPLS-TP LSPのすべてのパケットに同じEL値を使用できます。これにより、MPLS-TP LSPをMPLS LSP内のクライアントLSPとして伝送でき、MPLS-TP転送要件を満たしますが、MPLS LSRがMPLS-TP LSPを識別できる必要があります（要件MP＃1）。
MPLS-TP traffic can be protected from degraded performance due to an imperfect load split if the MPLS-TP traffic is given queuing priority. For example, using (1) strict priority and policing, shaping at ingress, or per-LSP shaping locally, or (2) per-LSP weighted queuing locally. This can be accomplished using the Traffic Class (TC) field and Diffserv treatment of traffic [RFC5462] [RFC2475]. In the event of congestion due to load imbalance, only non-prioritized traffic will suffer as long as there is a low percentage of prioritized traffic.
MPLS-TPトラフィックにキューイング優先順位が与えられている場合、不完全なロードスプリットによるパフォーマンスの低下からMPLS-TPトラフィックを保護できます。たとえば、（1）厳密な優先度とポリシング、入口でのシェーピング、またはローカルでのLSPごとのシェーピング、または（2）ローカルでのLSPごとの重み付きキューイングを使用します。これは、トラフィッククラス（TC）フィールドとトラフィックのDiffserv処理[RFC5462] [RFC2475]を使用して実現できます。負荷の不均衡が原因で輻輳が発生した場合、優先順位付けされたトラフィックの割合が低い限り、優先順位付けされていないトラフィックのみが影響を受けます。
If MPLS-TP LSPs are carried within MPLS LSPs and ELI and EL are used, requirement MP#3 is satisfied (1) for uncongested links where load balancing is not required, or (2) for MPLS-TP LSPs using Traffic Class (TC) and Diffserv, where the load rebalancing implementation rebalances only the less preferred traffic. Load rebalance is generally needed only when congestion occurs; therefore, restricting MPLS-TP to be carried over MPLS LSPs that are known to traverse only links that are expected to be uncongested can satisfy requirement MP#3.
MPLS-TP LSPがMPLS LSP内で伝送され、ELIおよびELが使用される場合、要件MP＃3は、（1）ロードバランシングが不要な非輻輳リンクに対して、または（2）トラフィッククラス（TC）を使用するMPLS-TP LSPに対して満たされます。 ）およびDiffserv。ここで、負荷リバランシングの実装は、優先度の低いトラフィックのみをリバランスします。負荷の再バランスは通常、輻輳が発生した場合にのみ必要です。したがって、輻輳していないと予想されるリンクのみを通過することがわかっているMPLS LSPを介してMPLS-TPが伝送されるように制限すると、要件MP＃3を満たすことができます。
An MPLS-TP LSP can be pinned to a Link Bundle component link if the behavior of requirement MP#2 is preferred. An MPLS-TP LSP can be assigned to a Link Bundle but not pinned if the behavior of requirement MP#3 is preferred. In both of these cases, the MPLS-TP LSP must be the top-level LSP, except as noted above.
要件MP＃2の動作が優先される場合、MPLS-TP LSPをリンクバンドルコンポーネントリンクに固定できます。 MPLS-TP LSPはリンクバンドルに割り当てることができますが、要件MP＃3の動作が優先される場合は固定できません。これらのどちらの場合でも、上記の場合を除いて、MPLS-TP LSPは最上位のLSPでなければなりません。
If MPLS-TP LSPs can be moved among component links, then the Link Bundle all-ones component link can be used or server-layer MPLS LSPs can be used with no restrictions on the server-layer MPLS use of multipath, except that Entropy Labels must be supported along the entire path. An Entropy Label must be used to ensure that all of the MPLS-TP payload and OAM traffic are carried on the same component, except during very infrequent transitions due to load balancing. Since the Entropy Label Indicator and Entropy Label are always placed above the Generic Associated Channel Label (GAL) in the stack, the presence of a GAL will not affect the selection of a component link as long as the LSR does not hash on the label stack entries below the Entropy Label.
MPLS-TP LSPをコンポーネントリンク間で移動できる場合は、リンクバンドルのすべて1のコンポーネントリンクを使用するか、サーバー層MPLS LSPを使用できます。ただし、エントロピーラベルを除き、サーバー層MPLSでのマルチパスの使用に制限はありません。パス全体でサポートされている必要があります。エントロピーラベルを使用して、すべてのMPLS-TPペイロードとOAMトラフィックが同じコンポーネントで確実に伝送されるようにする必要があります。ただし、負荷分散による非常にまれな移行中は例外です。エントロピーラベルインジケーターとエントロピーラベルは常にスタック内のGeneric Associated Channel Label（GAL）の上に配置されるため、LSRがラベルスタックでハッシュしない限り、GALの存在はコンポーネントリンクの選択に影響しません。エントロピーラベルの下のエントリ。
An MPLS-TP LSP may not traverse multipath links on the path where MPLS-TP forwarding requirements cannot be met. Such links include any using pre-[RFC6790] Ethernet Link Aggregation, pre-[RFC6790] Link Bundling using the all-ones component link, or any other form of multipath that does not support termination of the entropy search at the EL as called for in [RFC6790]. An MPLS-TP LSP MUST NOT traverse a server-layer MPLS LSP that traverses any form of multipath that does not support termination of the entropy search at the EL. For this to occur, the MPLS-TP ingress LSR MUST be aware of these links. This is the reason for requirement MP#4.
MPLS-TP LSPは、MPLS-TP転送の要件が満たされないパス上のマルチパスリンクを通過しない場合があります。そのようなリンクには、[RFC6790]以前のイーサネットリンク集約を使用するもの、[RFC6790]以前のすべて1のコンポーネントリンクを使用するリンクバンドリング、またはELでのエントロピー検索の終了をサポートしていない他の形式のマルチパスが含まれます。 [RFC6790]。 MPLS-TP LSPは、ELでのエントロピー検索の終了をサポートしない任意の形式のマルチパスを通過するサーバー層MPLS LSPを通過してはなりません（MUST NOT）。これが発生するには、MPLS-TP入力LSRがこれらのリンクを認識している必要があります。これがMP＃4要件の理由です。
Requirement MP#4 can be supported using administrative attributes. Administrative attributes are defined in [RFC3209]. Some configuration is required to support this.
要件MP＃4は、管理属性を使用してサポートできます。管理属性は[RFC3209]で定義されています。これをサポートするには、いくつかの構成が必要です。
In MPLS Link Bundling the requirement for bidirectional co-routing can be interpreted as meaning that the same set of LSRs must be traversed or can be interpreted to mean that the same set of component links must be traversed [RFC4201] [RFC3473]. Following the procedures of Section 3 of RFC 3473 where Link Bundling is used only ensures that the same set of LSRs are traversed and that acceptable labels are created in each direction.
MPLSリンクバンドリングでは、双方向コルーティングの要件は、同じLSRのセットをトラバースする必要がある、または同じコンポーネントリンクのセットをトラバースする必要があることを意味すると解釈できる[RFC4201] [RFC3473]。リンクバンドリングが使用されるRFC 3473のセクション3の手順に従うと、LSRの同じセットがトラバースされ、受け入れ可能なラベルが各方向で作成されることが保証されます。
When an MPLS-TP LSP is set up over a MPLS LSP, if the MPLS-TP LSP is a bidirectional LSP, then providers who want to only set these MPLS-TP LSPs over bidirectional co-routed MPLS LSPs can make use of administrative attributes [RFC3209] to ensure that this occurs. If MPLS-TP LSPs are carried by unidirectional MPLS LSPs, the MPLS-TP OAM will be unaffected, as only the MPLS LSP endpoints will appear as MPLS-TP OAM Maintenance Entity Group Intermediate Points (MIPs).
MPLS-TP LSPがMPLS LSPを介して設定されている場合、MPLS-TP LSPが双方向LSPである場合、これらのMPLS-TP LSPを双方向コルーテッドMPLS LSPのみに設定するプロバイダーは、管理属性を利用できます。 [RFC3209]これが確実に行われるようにします。 MPLS-TP LSPが単方向MPLS LSPによって運ばれる場合、MPLS-TP OAMはMPLS-TP OAMメンテナンスエンティティグループ中間ポイント（MIP）として表示されるため、MPLS-TP OAMは影響を受けません。
Two methods of adding an Entropy Label are described above. The MPLS-TP ingress must have a means to determine which links can support MPLS-TP in selecting a path (MP#4). Administrative attributes can satisfy that requirement. If the MPLS-TP LSR is capable of adding ELI/EL to the label stack, this method is preferred. However, equipment furthest from a provider's network core is the least likely to support RFC 6790 in the near term. For portions of the topology where an MPLS-TP is carried within a server-layer MPLS LSP, the ingress of the server-layer MPLS LSP can add ELI/ EL using a fixed EL value per client LSP, except those known not to require MPLS-TP treatment. There are numerous ways to determine which client LSPs are MPLS-TP LSPs and which are not. While this determination is out of scope and will vary among deployments, configuration or the presence of specific attribute affinities in RSVP-TE signaling are among the likely means to do so.
エントロピーラベルを追加する2つの方法については、上記で説明しています。 MPLS-TP入力には、パスを選択する際にMPLS-TPをサポートできるリンクを決定する手段が必要です（MP＃4）。管理属性はその要件を満たすことができます。 MPLS-TP LSRがELI / ELをラベルスタックに追加できる場合、この方法が推奨されます。ただし、プロバイダーのネットワークコアから最も遠い機器は、RFC 6790を短期的にサポートする可能性が最も低くなります。 MPLS-TPがサーバー層MPLS LSP内で伝送されるトポロジの一部では、サーバー層MPLS LSPの入口は、MPLSを必要としないことがわかっているものを除いて、クライアントLSPごとに固定EL値を使用してELI / ELを追加できます。 -TP処理。 MPLS-TP LSPであるクライアントLSPとそうでないクライアントLSPを判別する方法は多数あります。この決定は範囲外であり、展開によって異なりますが、RSVP-TEシグナリングでの特定の属性アフィニティの構成または存在は、そうする可能性が高い手段の1つです。
Carrying MPLS LSPs that are larger than a component link over an MPLS-TP server layer requires that the large MPLS client-layer LSP be accommodated by multiple MPLS-TP server-layer LSPs. MPLS multipath can be used in the client-layer MPLS.
MPLS-TPサーバーレイヤー上のコンポーネントリンクより大きいMPLS LSPを伝送するには、大きなMPLSクライアントレイヤーLSPが複数のMPLS-TPサーバーレイヤーLSPに対応している必要があります。 MPLSマルチパスは、クライアント層MPLSで使用できます。
Creating multiple MPLS-TP server-layer LSPs places a greater Incoming Label Map (ILM) scaling burden on the LSR. High-bandwidth MPLS cores with a smaller amount of nodes have the greatest tendency to require LSPs in excess of component links; therefore, the reduction in the number of nodes offsets the impact of increasing the number of server-layer LSPs in parallel. Today, only in cases where deployed LSR ILMs are small would this be an issue.
複数のMPLS-TPサーバー層LSPを作成すると、LSRの受信ラベルマップ（ILM）スケーリングの負担が大きくなります。ノード数が少ない高帯域幅MPLSコアは、コンポーネントリンクを超えるLSPを必要とする傾向が最も高くなります。したがって、ノード数の削減は、サーバーレイヤーLSPの数を並行して増やす影響を相殺します。今日、これが問題になるのは、展開されたLSR ILMが小さい場合のみです。
The most significant disadvantage of MPLS-TP as a server layer for MPLS is that the use of MPLS-TP server-layer LSPs reduces the efficiency of carrying the MPLS client layer. The service that provides by far the largest offered load in provider networks is the Internet, for which the LSP capacity reservations are predictions of expected load. Many of these MPLS LSPs may be smaller than component link capacity. Using MPLS-TP as a server layer results in bin-packing problems for these smaller LSPs. For those LSPs that are larger than component link capacity, the LSP capacities need not be (and often are not) integer multiples of convenient capacity increments such as 10 Gbit/s. Using MPLS-TP as an underlying server layer greatly reduces the ability of the client-layer MPLS LSPs to share capacity. For example, when one MPLS LSP is underutilizing its predicted capacity, the fixed allocation of MPLS-TP to component links may not allow another LSP to exceed its predicted capacity. Using MPLS-TP as a server layer may result in less efficient use of resources and may result in a less cost-effective network.
MPLSのサーバー層としてのMPLS-TPの最も大きな欠点は、MPLS-TPサーバー層LSPを使用すると、MPLSクライアント層の伝送効率が低下することです。プロバイダーネットワークで提供される最大の負荷を提供するサービスはインターネットであり、LSPの容量予約は予想される負荷の予測です。これらのMPLS LSPの多くは、コンポーネントのリンク容量よりも小さい場合があります。 MPLS-TPをサーバー層として使用すると、これらの小さなLSPでビンパッキングの問題が発生します。コンポーネントのリンク容量よりも大きいLSPの場合、LSP容量は、10 Gbit / sなどの便利な容量増分の整数倍である必要はありません（多くの場合はそうではありません）。基盤となるサーバー層としてMPLS-TPを使用すると、クライアント層のMPLS LSPが容量を共有する能力が大幅に低下します。たとえば、1つのMPLS LSPが予測容量を十分に活用していない場合、コンポーネントリンクへのMPLS-TPの固定割り当てでは、別のLSPが予測容量を超えることができない場合があります。サーバー層としてMPLS-TPを使用すると、リソースの使用効率が低下し、ネットワークのコスト効率が低下する可能性があります。
No additional requirements beyond MPLS-TP as it is now currently defined are required to support MPLS-TP as a server layer for MPLS. It is therefore viable but has some undesirable characteristics discussed above.
MPLS-TPをMPLSのサーバー層としてサポートするために、MPLS-TPが現在定義されているため、MPLS-TP以外の追加要件は必要ありません。したがって、それは実行可能ですが、上記のいくつかの望ましくない特性があります。
MPLS equipment deployed in the core currently supports multipath. For large service providers, core LSR must support some form of multipath to be deployable. Deployed MPLS access and edge equipment is often oblivious to the use of multipath in the core. It is expected that at least first-generation MPLS-TP equipment will be oblivious to the use of multipath in the core. This first-generation MPLS-TP equipment is deployable in a core using multipath, with no adverse impact to RSVP-TE signaling, if:
コアに導入されたMPLS機器は現在マルチパスをサポートしています。大規模なサービスプロバイダーの場合、コアLSRは、展開可能な何らかの形式のマルチパスをサポートする必要があります。展開されたMPLSアクセスおよびエッジ機器は、コアでのマルチパスの使用に気づかないことがよくあります。少なくとも第1世代のMPLS-TP機器は、コアでのマルチパスの使用に気づかないことが予想されます。この第1世代MPLS-TP機器は、マルチパスを使用してコアに展開可能であり、次の場合、RSVP-TEシグナリングに悪影響を与えません。
1. the edge equipment can support administrative attributes (RFC 3209),
1. エッジ機器は管理属性（RFC 3209）をサポートできます。
2. the core equipment can support ELI/EL, and
2. コア機器はELI / ELをサポートできます。
3. the core equipment can put a per-LSP fixed EL value on any LSP that indicates a particular attribute affinity or can identify a client MPLS-TP LSP through some other means.
3. コア機器は、特定の属性アフィニティを示す任意のLSPにLSPごとの固定EL値を配置したり、他の方法でクライアントMPLS-TP LSPを識別したりできます。
There are no issues carrying MPLS over MPLS-TP, except when the MPLS LSP is too big to be carried by a single MPLS-TP LSP. Most MPLS core equipment and some edge equipment can configure an MPLS Link Bundle [RFC4201] over multiple component links where the component links are themselves MPLS LSP. This existing capability can be used to carry large MPLS LSPs and overcome the limited capacity of any single server-layer MPLS-TP LSP.
MPLS LTPがMPLS-TP LSPで運ぶには大きすぎる場合を除いて、MPLS-TP over MPLS-TPを運ぶ問題はありません。ほとんどのMPLSコア機器と一部のエッジ機器は、コンポーネントリンク自体がMPLS LSPである複数のコンポーネントリンク上でMPLSリンクバンドル[RFC4201]を構成できます。この既存の機能を使用して、大きなMPLS LSPを伝送し、単一のサーバー層MPLS-TP LSPの制限された容量を克服できます。
MPLS OAM and MPLS-TP OAM are unaffected in the following cases proposed in this document:
このドキュメントで提案されている次のケースでは、MPLS OAMおよびMPLS-TP OAMは影響を受けません。
1. Where MPLS is carried over a single MPLS-TP, all traffic flows on one link, MPLS OAM is unaffected and need not use multipath support in LSP Ping [RFC4379].
1. MPLSが単一のMPLS-TPで伝送される場合、1つのリンク上のすべてのトラフィックフロー、MPLS OAMは影響を受けず、LSP Ping [RFC4379]でマルチパスサポートを使用する必要はありません。
2. Where MPLS-TP is carried over MPLS, all traffic for that MPLS-TP LSP is carried over one link thanks to the fixed EL value. In this case, MPLS-TP OAM is unaffected.
2. MPLS-TPがMPLSを介して伝送される場合、そのMPLS-TP LSPのすべてのトラフィックは、固定されたEL値のおかげで1つのリンクを介して伝送されます。この場合、MPLS-TP OAMは影響を受けません。
3. Where MPLS LSPs are carried over MPLS LSPs (an existing case) or over multiple MPLS-TP LSPs, the multipath support in LSP Ping is used and LSP Ping operation is unaffected [RFC4379] [RFC6425].
3. MPLS LSPがMPLS LSP（既存のケース）または複数のMPLS-TP LSPを介して伝送される場合、LSP Pingのマルチパスサポートが使用され、LSP Ping操作は影響を受けません[RFC4379] [RFC6425]。
Carlos Pignataro, Dave Allan, and Mach Chen provided valuable comments and suggestions. Carlos suggested that MPLS-TP requirements in RFC 5960 be explicitly referenced or quoted. An email conversation with Dave led to the inclusion of references and quotes from RFCs 6371 and 6374. Mach made suggestions to improve the clarity of the document.
Carlos Pignataro、Dave Allan、Mach Chenは、貴重なコメントと提案を行いました。 Carlosは、RFC 5960のMPLS-TP要件を明示的に参照または引用することを提案しました。 Daveとの電子メールによる会話により、RFC 6371および6374からの参照と引用が含まれました。Machは、ドキュメントの明確さを改善するための提案を行いました。
This document specifies use of existing MPLS and MPLS-TP mechanisms to support MPLS and MPLS-TP as client and server layers for each other. This use of existing mechanisms supports coexistence of MPLS/ GMPLS (without MPLS-TP) when used over a packet network, MPLS-TP, and multipath. The combination of MPLS, MPLS-TP, and multipath does not introduce any new security threats. The security considerations for MPLS/GMPLS and for MPLS-TP are documented in [RFC5920] and [RFC6941].
このドキュメントでは、既存のMPLSメカニズムとMPLS-TPメカニズムを使用して、MPLSとMPLS-TPを相互のクライアントレイヤーとサーバーレイヤーとしてサポートすることを規定しています。既存のメカニズムのこの使用は、パケットネットワーク、MPLS-TP、およびマルチパスを介して使用される場合、MPLS / GMPLS（MPLS-TPなし）の共存をサポートします。 MPLS、MPLS-TP、およびマルチパスの組み合わせは、新しいセキュリティの脅威をもたらしません。 MPLS / GMPLSおよびMPLS-TPのセキュリティに関する考慮事項は、[RFC5920]および[RFC6941]で文書化されています。
[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月。
[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009.
[RFC5654] Niven-Jenkins、B.、Brungard、D.、Betts、M.、Sprecher、N。、およびS. Ueno、「要件、MPLSトランスポートプロファイル」、RFC 5654、2009年9月。
[RFC5960] Frost, D., Bryant, S., and M. Bocci, "MPLS Transport Profile Data Plane Architecture", RFC 5960, August 2010.
[RFC5960] Frost、D.、Bryant、S。、およびM. Bocci、「MPLS Transport Profile Data Plane Architecture」、RFC 5960、2010年8月。
[RFC6371] Busi, I. and D. Allan, "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, September 2011.
[RFC6371] Busi、I。およびD. Allan、「Operations、Administration、and Maintenance Framework for MPLS-Based Transport Networks」、RFC 6371、2011年9月。
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, September 2011.
[RFC6374] Frost、D。およびS. Bryant、「MPLSネットワークのパケット損失と遅延測定」、RFC 6374、2011年9月。
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, November 2012.
[RFC6790] Kompella、K.、Drake、J.、Amante、S.、Henderickx、W。、およびL. Yong、「The Use of Entropy Labels in MPLS Forwarding」、RFC 6790、2012年11月。
[ADV-MULTIPATH-REQ] Villamizar, C., McDysan, D., Ning, S., Malis, A., and L. Yong, "Requirements for Advanced Multipath in MPLS Networks", Work in Progress, February 2014.
[ADV-MULTIPATH-REQ] Villamizar、C.、McDysan、D.、Ning、S.、Malis、A。、およびL. Yong、「MPLSネットワークにおける高度なマルチパスの要件」、進行中の作業、2014年2月。
[IEEE-802.1AX] IEEE, "IEEE Standard for Local and Metropolitan Area Networks - Link Aggregation", IEEE Std 802.1AX-2008, 2006, <http://standards.ieee.org/getieee802/download/ 802.1AX-2008.pdf>.
[IEEE-802.1AX] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Link Aggregation」、IEEE Std 802.1AX-2008、2006、<http://standards.ieee.org/getieee802/download/ 802.1AX-2008 .pdf>。
[ITU-T.G.800] ITU-T, "Unified functional architecture of transport networks", ITU-T G.800, 2007, <http://www.itu.int/rec/ T-REC-G/recommendation.asp?parent=T-REC-G.800>.
[ITU-TG800] ITU-T、「トランスポートネットワークの統合機能アーキテクチャ」、ITU-T G.800、2007、<http://www.itu.int/rec/ T-REC-G / recommendation.asp ？parent = T-REC-G.800>。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z。、およびW. Weiss、「An Architecture for Differentiated Services」、RFC 2475、1998年12月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：Extensions for RSVP for LSP Tunnels」、RFC 3209、12月2001年。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473] Berger、L。、「Generalized Multi-Protocol Label Switching（GMPLS）Signaling Resource ReserVation Protocol-Traffic Engineering（RSVP-TE）Extensions」、RFC 3473、2003年1月。
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4201] Kompella、K.、Rekhter、Y。、およびL. Berger、「MPLSトラフィックエンジニアリング（TE）におけるリンクバンドリング」、RFC 4201、2005年10月。
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC4206] Kompella、K。、およびY. Rekhter、「Label Switched Paths（LSP）Hierarchy with Generalized Multi-Protocol Label Switching（GMPLS）Traffic Engineering（TE）」、RFC 4206、2005年10月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379] Kompella、K。およびG. Swallow、「Detecting Multi-Protocol Label Switched（MPLS）Data Plane Failures」、RFC 4379、2006年2月。
[RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, September 2008.
[RFC5286] Atlas、A。およびA. Zinin、「IP Fast Rerouteの基本仕様：ループフリー代替」、RFC 5286、2008年9月。
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, February 2009.
[RFC5462] Andersson、L。およびR. Asati、「Multiprotocol Label Switching（MPLS）Label Stack Entry： "EXP" Renamed to "Traffic Class" Field」、RFC 5462、2009年2月。
[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 5714, January 2010.
[RFC5714] Shand、M。、およびS. Bryant、「IP Fast Reroute Framework」、RFC 5714、2010年1月。
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920] Fang、L。、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、2010年7月。
[RFC6425] Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa, S., and T. Nadeau, "Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 6425, November 2011.
[RFC6425] Saxena、S.、Swallow、G.、Ali、Z.、Farrel、A。、安川S、およびT. Nadeau、「ポイントツーマルチポイントMPLSでのデータプレーン障害の検出-LSPの拡張Ping」、RFC 6425、2011年11月。
[RFC6941] Fang, L., Niven-Jenkins, B., Mansfield, S., and R. Graveman, "MPLS Transport Profile (MPLS-TP) Security Framework", RFC 6941, April 2013.
[RFC6941] Fang、L.、Niven-Jenkins、B.、Mansfield、S。、およびR. Graveman、「MPLS Transport Profile（MPLS-TP）Security Framework」、RFC 6941、2013年4月。
Author's Address
著者のアドレス
Curtis Villamizar Outer Cape Cod Network Consulting
Curtis Villamizar Outer Cape Codネットワークコンサルティング
EMail: curtis@occnc.com