RFC 8372 - MPLS Flow Identification Considerations 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc8372
タイトル : RFC 8372 - MPLSフロー識別の考慮事項
翻訳編集 : 自動生成

[要約] 要約：RFC 8372は、MPLSネットワークでのフロー識別に関する考慮事項を提供しています。目的：このRFCの目的は、MPLSネットワークでのフロー識別の重要性を強調し、実装者に適切な方法を提供することです。

Internet Engineering Task Force (IETF)                         S. Bryant
Request for Comments: 8372                                        Huawei
Category: Informational                                     C. Pignataro
ISSN: 2070-1721                                                    Cisco
                                                                 M. Chen
                                                                   Z. Li
                                                                  Huawei
                                                               G. Mirsky
                                                               ZTE Corp.
                                                                May 2018

MPLS Flow Identification Considerations

MPLSフロー識別の考慮事項

Abstract

概要

This document discusses aspects to consider when developing a solution for MPLS flow identification. The key application that needs this solution is in-band performance monitoring of MPLS flows when MPLS is used to encapsulate user data packets.

このドキュメントでは、MPLSフロー識別のソリューションを開発する際に考慮すべき側面について説明します。このソリューションを必要とする主要なアプリケーションは、MPLSを使用してユーザーデータパケットをカプセル化する場合のMPLSフローの帯域内パフォーマンス監視です。

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 candidates for any level of Internet Standard; see Section 2 of RFC 7841.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補であるとは限りません。 RFC 7841のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8372.

このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8372で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Loss Measurement Considerations . . . . . . . . . . . . . . .   3
   3.  Delay Measurement Considerations  . . . . . . . . . . . . . .   4
   4.  Units of Identification . . . . . . . . . . . . . . . . . . .   4
   5.  Types of LSP  . . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  Network Scope . . . . . . . . . . . . . . . . . . . . . . . .   7
   7.  Backwards Compatibility . . . . . . . . . . . . . . . . . . .   7
   8.  Data Plane  . . . . . . . . . . . . . . . . . . . . . . . . .   7
   9.  Control Plane . . . . . . . . . . . . . . . . . . . . . . . .   9
   10. Privacy Considerations  . . . . . . . . . . . . . . . . . . .   9
   11. Security Considerations . . . . . . . . . . . . . . . . . . .   9
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   13. Informative References  . . . . . . . . . . . . . . . . . . .  10
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1. Introduction

1. はじめに

This document discusses the aspects that need to be considered when developing a solution for MPLS flow identification. The key application that needs this is in-band performance monitoring of MPLS flows when MPLS is used to encapsulate user data packets.

このドキュメントでは、MPLSフロー識別のソリューションを開発するときに考慮する必要がある側面について説明します。これを必要とする主要なアプリケーションは、MPLSを使用してユーザーデータパケットをカプセル化する場合のMPLSフローのインバンドパフォーマンスモニタリングです。

There is a need to identify flows in MPLS networks for various applications such as determining packet loss and packet delay measurement. A method of loss and delay measurement in MPLS networks was defined in [RFC6374]. When used to measure packet loss, [RFC6374] depends on the use of injected Operations, Administration, and Maintenance (OAM) packets to designate the beginning and the end of the packet group over which packet loss is being measured. If the misordering of packets from one group relative to the following group or the misordering of any of the packets being counted relative to the Loss Measurement packet [RFC6374] occurs, then an error will occur in the packet loss measurement.

パケット損失やパケット遅延測定の決定など、さまざまなアプリケーションのためにMPLSネットワークのフローを識別する必要があります。 MPLSネットワークにおける損失と遅延の測定方法は、[RFC6374]で定義されています。パケット損失の測定に使用する場合、[RFC6374]は、挿入された運用、管理、および保守（OAM）パケットの使用に依存して、パケット損失が測定されるパケットグループの開始と終了を指定します。次のグループに対する1つのグループからのパケットの順序の乱れ、または損失測定パケット[RFC6374]に関連してカウントされているパケットの順序の誤りが発生すると、パケット損失測定でエラーが発生します。

In addition, [RFC6374] did not support different granularities of flow or address a number of multipoint cases in which two or more ingress Label Switching Routers (LSRs) could send packets to one or more destinations.

さらに、[RFC6374]は、フローのさまざまな粒度をサポートしておらず、2つ以上の入力ラベルスイッチングルータ（LSR）が1つ以上の宛先にパケットを送信できる複数のマルチポイントのケースに対処していませんでした。

Due to the very low loss rate in normal operation, improvements in link and transmission technologies have made it more difficult to assess packet loss using active performance measurement methods with synthetic traffic. That, together with more demanding service-level requirements, means that network operators now need to be able to measure the loss of the actual user data traffic using passive performance measurement methods. Any technique deployed needs to be transparent to the end user, and it needs to be assumed that they will not take any active part in the measurement process. Indeed, it is important that any flow identification technique be invisible to them and that no remnant of the measurement process leaks into their network.

通常の運用では損失率が非常に低いため、リンクおよび伝送技術の改善により、合成トラフィックでアクティブなパフォーマンス測定方法を使用してパケット損失を評価することがより困難になっています。つまり、より厳しいサービスレベル要件と合わせて、ネットワークオペレーターは、パッシブパフォーマンス測定方法を使用して、実際のユーザーデータトラフィックの損失を測定できる必要があります。導入された技術はエンドユーザーに対して透過的である必要があり、測定プロセスで積極的な役割を果たすことはないと想定する必要があります。実際、フロー識別技術がそれらに見えないこと、および測定プロセスの残りがネットワークに漏れないことが重要です。

Additionally, when there are multiple traffic sources, such as in multipoint-to-point and multipoint-to-multipoint network environments, there needs to be a method whereby the sink can distinguish between packets from the various sources; that is to say, a multipoint measurement model needs to be developed.

さらに、マルチポイントツーポイントおよびマルチポイントツーマルチポイントネットワーク環境など、複数のトラフィックソースがある場合、シンクがさまざまなソースからのパケットを区別できる方法が必要です。つまり、多点測定モデルを開発する必要があります。

2. Loss Measurement Considerations

2. 損失測定に関する考慮事項

Modern networks, if not oversubscribed, generally drop relatively few packets; thus, packet loss measurement is highly sensitive to the common demarcation of the exact set of packets to be measured for loss. Without some form of coloring or batch marking such as that proposed in [RFC8321], it may not be possible to achieve the required accuracy in the loss measurement of customer data traffic. Thus, when accurate measurement of packet loss is required, it may be economically advantageous, or even be a technical requirement, to include some form of marking in the packets to assign each packet to a particular counter for loss measurement purposes.

現代のネットワークは、オーバーサブスクライブされていなければ、一般的に比較的少ないパケットをドロップします。したがって、パケット損失測定は、損失について測定される正確なパケットのセットの一般的な境界に非常に敏感です。 [RFC8321]で提案されているような、何らかの形のカラーリングまたはバッチマーキングがないと、顧客データトラフィックの損失測定で必要な精度を達成できない場合があります。したがって、パケット損失の正確な測定が必要な場合、損失測定の目的で各パケットを特定のカウンタに割り当てるためにパケットに何らかの形のマーキングを含めることは、経済的に有利であるか、技術的要件でさえあるかもしれません。

When this level of accuracy is required and the traffic between a source-destination pair is subject to Equal-Cost Multipath (ECMP), a demarcation mechanism is needed to group the packets into batches. Once a batch is correlated at both ingress and egress, the packet accounting mechanism is then able to operate on the batch of packets that can be accounted for at both the packet ingress and the packet egress. Errors in the accounting are particularly acute in Label Switched Paths (LSPs) subjected to ECMP because the network transit time will be different for the various ECMP paths since:

このレベルの精度が必要で、送信元と宛先のペア間のトラフィックが等コストマルチパス（ECMP）の影響を受ける場合、パケットをバッチにグループ化するための境界メカニズムが必要です。バッチが入力と出力の両方で相互に関連付けられると、パケットアカウンティングメカニズムは、パケットの入力と出力の両方で説明できるパケットのバッチを操作できます。アカウンティングのエラーは、ECMPの対象となるラベルスイッチドパス（LSP）で特に深刻です。これは、ネットワーク通過時間がさまざまなECMPパスで異なるためです。

1. the packets may traverse different sets of LSRs;

1. パケットは、LSRの異なるセットを通過する場合があります。

2. the packets may depart from different interfaces on different line cards on LSRs; and

2. パケットは、LSR上の異なるラインカード上の異なるインターフェイスから出発する場合があります。そして

3. the packets may arrive at different interfaces on different line cards on LSRs.

3. パケットは、LSR上の異なるラインカード上の異なるインターフェイスに到着する場合があります。

A consideration with this solution on modifying the identity label (the MPLS label ordinarily used to identify the LSP, Virtual Private Network, Pseudowire, etc.) to indicate the batch is the impact that this has on the path chosen by the ECMP mechanism. When the member of the ECMP path set is chosen by deep packet inspection, a change of batch represented by a change of identity label will have no impact on the ECMP path. If the path member is chosen by reference to an entropy label [RFC6790], then changing the batch identifier will not result in a change to the chosen ECMP path. ECMP is so pervasive in multipoint-to-(multi)point networks that some method of avoiding accounting errors introduced by ECMP needs to be supported.

アイデンティティラベル（通常、LSP、仮想プライベートネットワーク、疑似配線などを識別するために使用されるMPLSラベル）を変更してこのバッチがECMPメカニズムによって選択されたパスに与える影響を示すためのこのソリューションに関する考慮事項。ディープパケットインスペクションによってECMPパスセットのメンバーが選択されている場合、IDラベルの変更によって表されるバッチの変更は、ECMPパスに影響を与えません。パスメンバーがエントロピーラベル[RFC6790]を参照して選択された場合、バッチ識別子を変更しても、選択されたECMPパスは変更されません。 ECMPはマルチポイントツー（マルチ）ポイントネットワークで非常に普及しているため、ECMPによって発生するアカウンティングエラーを回避するいくつかの方法をサポートする必要があります。

3. Delay Measurement Considerations

3. 遅延測定に関する考慮事項

Most of the existing delay measurement methods are active methods that depend on the extra injected test packet to evaluate the delay of a path. With the active measurement method, the rate, numbers, and interval between the injected packets may affect the accuracy of the results. Due to ECMP (or link aggregation techniques), injected test packets may traverse different links from the ones used by the data traffic. Thus, measuring the delay of the real traffic is required.

既存の遅延測定方法のほとんどはアクティブな方法であり、追加の挿入されたテストパケットに依存してパスの遅延を評価します。アクティブ測定方法では、挿入されたパケット間のレート、数、および間隔が結果の精度に影響を与える可能性があります。 ECMP（またはリンク集約技術）により、挿入されたテストパケットは、データトラフィックで使用されるリンクとは異なるリンクを通過する場合があります。したがって、実際のトラフィックの遅延を測定する必要があります。

For combined loss and delay measurements, both the loss and the delay considerations apply.

損失と遅延を組み合わせた測定では、損失と遅延の両方の考慮事項が適用されます。

4. Units of Identification

4. 識別の単位

The most basic unit of identification is the identity of the node that processed the packet on its entry to the MPLS network. However, the required unit of identification may vary depending on the use case for accounting, performance measurement, or other types of packet observations. In particular, note that there may be a need to impose identity at several different layers of the MPLS label stack.

最も基本的な識別単位は、MPLSネットワークへのエントリでパケットを処理したノードのIDです。ただし、必要な識別単位は、アカウンティング、パフォーマンス測定、またはその他のタイプのパケット監視のユースケースによって異なる場合があります。特に、MPLSラベルスタックのいくつかの異なる層でアイデンティティを課す必要がある場合があることに注意してください。

This document considers the identification of the following traffic components:

このドキュメントでは、次のトラフィックコンポーネントの識別について検討します。

o Per source LSR: everything from one source is aggregated

o ソースごとのLSR：1つのソースからのすべてが集約されます

o Per group of LSPs chosen by an ingress LSR: an ingress LSP aggregates a group of LSPs (e.g., all the LSPs of a tunnel)

o 入力LSRによって選択されたLSPのグループごと：入力LSPは、LSPのグループ（たとえば、トンネルのすべてのLSP）を集約します。

o Per LSP: the basic form

o LSPごと：基本形式

o Per flow [RFC6790] within an LSP: a fine-grained method

o LSP内のフローごと[RFC6790]：きめの細かい方法

Note that a fine-grained identity resolution is needed when there is a need to perform these operations on a flow not readily identified by some other element in the label stack. Such a fine-grained resolution may be possible by deep packet inspection. However, this may not always be possible, or it may be desired to minimize processing costs by doing this only on entry to the network. Adding a suitable identifier to the packet for reference by other network elements minimizes the processing needed by other network elements. An example of such a fine-grained case might be traffic belonging to a certain service or from a specific source, particularly if matters related to service level agreement or application performance were being investigated.

ラベルスタック内の他の要素によって容易に識別されないフローに対してこれらの操作を実行する必要がある場合は、詳細なID解決が必要であることに注意してください。このようなきめ細かい解決は、詳細なパケット検査によって可能になる場合があります。ただし、これが常に可能であるとは限りません。または、ネットワークへのエントリ時にのみこれを実行することにより、処理コストを最小限に抑えることが望ましい場合があります。他のネットワーク要素による参照のために適切な識別子をパケットに追加すると、他のネットワーク要素が必要とする処理が最小限に抑えられます。このようなきめ細かいケースの例としては、特定のサービスに属するトラフィックや特定のソースからのトラフィックが挙げられます。特に、サービスレベルアグリーメントやアプリケーションのパフォーマンスに関する問題が調査されている場合はそうです。

We can thus characterize the identification requirement in the following broad terms:

したがって、以下の大まかな用語で識別要件を特徴付けることができます。

o There needs to be some way for an egress LSR to identify the ingress LSR with an appropriate degree of scope. This concept is discussed further in Section 6.

o 出力LSRが適切な範囲の範囲で入力LSRを識別するための何らかの方法が必要です。この概念については、セクション6で詳しく説明します。

o There needs to be a way to identify a specific LSP at the egress node. This allows for the case of instrumenting multiple LSPs operating between the same pair of nodes. In such cases, the identity of the ingress LSR is insufficient.

o 出力ノードで特定のLSPを識別する方法が必要です。これにより、同じノードのペア間で動作する複数のLSPを計測する場合が可能になります。このような場合、入力LSRのIDは不十分です。

o In order to conserve resources such as labels, counters, and/or compute cycles, it may be desirable to identify an LSP group so that an operation can be performed on the group as an aggregate.

o ラベル、カウンタ、計算サイクルなどのリソースを節約するために、LSPグループを識別して、グループとして操作を集約として実行できることが望ましい場合があります。

o There needs to be a way to identify a flow within an LSP. This is necessary when investigating a specific flow that has been aggregated into an LSP.

o LSP内のフローを識別する方法が必要です。これは、LSPに集約された特定のフローを調査するときに必要です。

The unit of identification and the method of determining which packets constitute a flow will be specific to the application or use case and are out of scope of this document.

識別の単位およびフローを構成するパケットを決定する方法は、アプリケーションまたはユースケースに固有であり、このドキュメントの範囲外です。

5. Types of LSP

5. LSPのタイプ

We need to consider a number of types of LSP. The two simplest types to monitor are point-to-point LSPs and point-to-multipoint LSPs. The ingress LSR for a point-to-point LSP, such as those created using the Resource Reservation Protocol - Traffic Engineering (RSVP-TE) [RFC5420] signaling protocol or those that conform to the MPLS Transport Profile (MPLS-TP) [RFC5654], may be identified by inspection of the top label in the stack because, at any provider-edge (PE) or provider (P) router on the path, the top label is unique to the ingress-egress pair at every hop at a given layer in the LSP hierarchy. Provided that Penultimate Hop Popping (PHP) is disabled, the identity of the ingress LSR of a point-to-point LSP is available at the egress LSR; thus, determining the identity of the ingress LSR must be regarded as a solved problem. Note, however, that the identity of a flow cannot to be determined without further information being carried in the packet or gleaned from some aspect of the packet payload.

いくつかのタイプのLSPを考慮する必要があります。監視する最も単純な2つのタイプは、ポイントツーポイントLSPとポイントツーマルチポイントLSPです。リソース予約プロトコル-トラフィックエンジニアリング（RSVP-TE）[RFC5420]シグナリングプロトコルを使用して作成されたものや、MPLSトランスポートプロファイル（MPLS-TP）[RFC5654]に準拠したものなど、ポイントツーポイントLSPの入力LSR ]、パス上のプロバイダーエッジ（PE）またはプロバイダー（P）のルーターでは、トップラベルがすべてのホップの入出力ペアに固有であるため、スタックのトップラベルを検査することで識別できます。 LSP階層の特定のレイヤー。 Penultimate Hop Popping（PHP）が無効になっている場合、ポイントツーポイントLSPの入力LSRのIDは出力LSRで利用できます。したがって、入力LSRのIDを決定することは、解決済みの問題と見なす必要があります。ただし、パケット内で運ばれたり、パケットペイロードのいくつかの側面から収集した情報がないと、フローのIDを特定できないことに注意してください。

In the case of a point-to-multipoint LSP, and in the absence of PHP, the identity of the ingress LSR may also be inferred from the top label. However, it may not possible to adequately identify the flow from the top label alone; thus, further information may need to be carried in the packet or gleaned from some aspect of the packet payload. In designing any solution, it is desirable that a common flow identification solution be used for both point-to-point and point-to-multipoint LSP types. Similarly, it is desirable that a common method of LSP group identification be used. In the above cases, a context label [RFC5331] needs to be used to provide the required identity information. This is a widely supported MPLS feature.

ポイントツーマルチポイントLSPの場合、およびPHPがない場合、入力LSRのIDもトップラベルから推測できます。ただし、トップラベルのみからのフローを適切に特定できない場合があります。したがって、さらなる情報は、パケットで運ばれるか、またはパケットのペイロードのいくつかの側面から収集する必要があるかもしれません。ソリューションの設計では、ポイントツーポイントとポイントツーマルチポイントの両方のLSPタイプに共通のフロー識別ソリューションを使用することが望ましいです。同様に、LSPグループ識別の一般的な方法を使用することが望ましいです。上記の場合、必要な識別情報を提供するには、コンテキストラベル[RFC5331]を使用する必要があります。これは、広くサポートされているMPLS機能です。

A more interesting case is the case of a multipoint-to-point LSP. In this case, the same label is normally used by multiple ingress or upstream LSRs; hence, source identification is not possible by inspection of the top label by the egress LSRs. It is therefore necessary for a packet to be able to explicitly convey any of the identity types described in Section 4.

より興味深いケースは、マルチポイントツーポイントLSPのケースです。この場合、通常、同じラベルが複数の入力または上流LSRで使用されます。したがって、出力LSRによるトップラベルの検査では、送信元の識別は不可能です。したがって、セクション4で説明されているIDタイプのいずれかをパケットが明示的に伝達できる必要があります。

Similarly, in the case of a multipoint-to-multipoint LSP, the same label is normally used by multiple ingress or upstream LSRs; hence, source identification is not possible by inspection of the top label by egress LSRs. The various identity types described in Section 4 are again needed. Note, however, that the scope of the identity may be constrained to be unique within the set of multipoint-to-multipoint LSPs terminating on any common node.

同様に、マルチポイントツーマルチポイントLSPの場合、通常は同じラベルが複数の入力LSRまたはアップストリームLSRで使用されます。したがって、出力LSRによるトップラベルの検査では、送信元の識別は不可能です。セクション4で説明したさまざまなIDタイプが再び必要になります。ただし、IDのスコープは、任意の共通ノードで終了するマルチポイントツーマルチポイントLSPのセット内で一意になるように制限される場合があることに注意してください。

6. Network Scope

6. ネットワークの範囲

The scope of identification can be constrained to the set of flows that are uniquely identifiable at an ingress LSR or some aggregation thereof. There is no need for an ingress LSR to seek assistance from outside the MPLS protocol domain.

識別の範囲は、入力LSRまたはその一部の集約で一意に識別可能なフローのセットに制限できます。入力LSRがMPLSプロトコルドメインの外部から支援を求める必要はありません。

In any solution that constrains itself to carrying the required identity in the MPLS label stack rather than in some different associated data structure, constraints on the choice of label and label stack size imply that the scope of identity resides within that MPLS domain. For similar reasons, the identity scope of a component of an LSP is constrained to the scope of that LSP.

いくつかの異なる関連データ構造ではなく、MPLSラベルスタックで必要なIDを運ぶように制約するソリューションでは、ラベルとラベルスタックサイズの選択に対する制約は、IDのスコープがそのMPLSドメイン内にあることを意味します。同様の理由で、LSPのコンポーネントのIDスコープは、そのLSPのスコープに制限されます。

7. Backwards Compatibility

7. 下位互換性

In any network, it is unlikely that all LSRs will have the same capability to support the methods of identification discussed in this document. It is therefore an important constraint on any flow identity solution that it is backwards compatible with deployed MPLS equipment to the extent that deploying the new feature will not disable anything that currently works on the legacy equipment.

どのネットワークでも、すべてのLSRがこのドキュメントで説明されている識別方法をサポートする同じ機能を備えているとは考えられません。したがって、新しい機能を導入してもレガシー機器で現在機能しているものは何も無効にならない範囲で、導入されたMPLS機器と下位互換性があることは、フローIDソリューションに対する重要な制約です。

This is particularly the case when the deployment is incremental or the feature is not required for all LSRs or all LSPs. Thus, the flow identification design must support the coexistence of LSRs that can identify the traffic components described in Section 4 and those that cannot. In addition, the identification of the traffic components described in Section 4 must be an optional feature that is disabled by default. As a design simplification, a solution may require that all egress LSRs of a point-to-multipoint or a multipoint-to-multipoint LSP support the identification type in use so that a single packet can be correctly processed by all egress devices. The corollary of this last point is that either all egress LSRs are enabled to support the required identity type or none of them are.

これは、展開が増分的である場合、またはすべてのLSRまたはすべてのLSPに機能が必要ではない場合に特に当てはまります。したがって、フロー識別設計は、セクション4で説明したトラフィックコンポーネントを識別できるLSRと識別できないLSRの共存をサポートする必要があります。さらに、セクション4で説明されているトラフィックコンポーネントの識別は、デフォルトで無効になっているオプション機能である必要があります。設計を簡素化するために、ソリューションでは、ポイントツーマルチポイントまたはマルチポイントツーマルチポイントLSPのすべての出力LSRが使用中の識別タイプをサポートし、すべての出力デバイスで単一のパケットを正しく処理できるようにする必要がある場合があります。この最後のポイントの当然の結果は、すべての出力LSRが必要なIDタイプをサポートするように有効にされているか、どれも有効になっていないかのどちらかです。

8. Data Plane

8. データプレーン

There is a huge installed base of MPLS equipment; typically, this type of equipment remains in service for an extended period of time, and in many cases, hardware constraints mean that it is not possible to upgrade its data-plane functionality. Changes to the MPLS data plane are therefore expensive to implement, add complexity to the network, and may significantly impact the deployability of a solution that requires such changes. For these reasons, MPLS users have set a very high bar to changes to the MPLS data plane, and only a very small number have been adopted. Hence, it is important that the method of identification must minimize changes to the MPLS data plane. Ideally, method(s) of identification that require no changes to the MPLS data plane should be given preferential consideration. If a method of identification that makes a change to the data plane is chosen, it will need to have a significant advantage over any method that makes no change, and the advantage of the approach will need to be carefully evaluated and documented. If a change to the MPLS data plane proves necessary, it should be (a) as small a change as possible and (b) a general-purpose method, so as to maximize its use for future applications. It is imperative that, as far as can be foreseen, any necessary change made to the MPLS data plane does not impose any foreseeable future limitation on the MPLS data plane.

MPLS機器の巨大な設置ベースがあります。通常、このタイプの機器は長期間使用されます。多くの場合、ハードウェアの制約により、データプレーンの機能をアップグレードすることはできません。したがって、MPLSデータプレーンへの変更は、実装にコストがかかり、ネットワークが複雑になり、そのような変更を必要とするソリューションの展開可能性に大きな影響を与える可能性があります。これらの理由により、MPLSユーザーはMPLSデータプレーンの変更に非常に高い基準を設定しており、採用されている数はごくわずかです。したがって、識別方法がMPLSデータプレーンへの変更を最小限に抑える必要があることが重要です。理想的には、MPLSデータプレーンへの変更を必要としない識別方法は、優先的に検討する必要があります。データプレーンを変更する識別方法を選択する場合、変更を行わない方法よりも大きな利点があり、アプローチの利点を慎重に評価して文書化する必要があります。 MPLSデータプレーンへの変更が必要であることが判明した場合、将来のアプリケーションでの使用を最大化するために、（a）変更をできるだけ小さくし、（b）汎用的な方法にする必要があります。予測できる限り、MPLSデータプレーンに必要な変更を加えても、MPLSデータプレーンに予測可能な将来の制限が課せられないことが不可欠です。

Stack size is an issue with many MPLS implementations both as a result of hardware limitations and due to the impact on networks and applications in which a large number of small payloads need to be transported. In particular, one MPLS payload may be carried inside another. For example, one LSP may be carried over another LSP, or a Pseudowire (PW) or similar multiplexing construct may be carried over an LSP, and identification may be required at both layers. Of particular concern is the implementation of low-cost edge LSRs that, for cost reasons, have a significant limit on the number of Label Stack Entries (LSEs) that they can impose or dispose. Therefore, any method of identity must not consume an excessive number of unique labels and must not result in an excessive increase in the size of the label stack.

スタックサイズは、ハードウェアの制限の結果として、および多数の小さなペイロードを転送する必要のあるネットワークとアプリケーションへの影響による、多くのMPLS実装での問題です。特に、1つのMPLSペイロードが別のMPLSペイロード内で伝送される場合があります。たとえば、あるLSPが別のLSPで伝送されたり、疑似配線（PW）または同様の多重化構成がLSPで伝送されたり、両方の層で識別が必要になる場合があります。特に懸念されるのは、コスト上の理由から、強制または破棄できるラベルスタックエントリ（LSE）の数に大きな制限がある低コストのエッジLSRの実装です。したがって、どのような識別方法でも、一意のラベルを過度に消費してはならず、ラベルスタックのサイズが過度に増加してはなりません。

The design of the MPLS data plane provides two types of special-purpose labels: the original 16 reserved labels and the much larger set of special-purpose labels defined in [RFC7274]. The original reserved labels need one LSE, and the newer special-purpose labels [RFC7274] need two LSEs. Given the tiny number of original reserved labels, it is core to the MPLS design philosophy that this scarce resource is only used when it is absolutely necessary. Using a special-purpose label to encode flow identity requires two label stack entries, one for the reserved label and one for the flow identity. Use of extended special-purpose labels [RFC7274] requires a total of three label stack entries to encode the flow identity. The larger set of [RFC7274] labels requires two label stack entries for the special-purpose label itself; hence, a total of three label stack entries is needed to encode the flow identity.

MPLSデータプレーンの設計は、2種類の特殊用途ラベルを提供します。元の16個の予約済みラベルと、[RFC7274]で定義されたより大きな特殊用途ラベルのセットです。元の予約済みラベルには1つのLSEが必要であり、新しい専用ラベル[RFC7274]には2つのLSEが必要です。元の予約済みラベルの数が非常に少ないことを考えると、この希少なリソースは絶対に必要な場合にのみ使用されるというMPLS設計哲学の中核です。特殊用途のラベルを使用してフローIDをエンコードするには、2つのラベルスタックエントリが必要です。1つは予約済みラベル用、もう1つはフローID用です。拡張特殊用途ラベル[RFC7274]を使用するには、フローIDをエンコードするために合計3つのラベルスタックエントリが必要です。 [RFC7274]ラベルのより大きなセットでは、専用ラベル自体に2つのラベルスタックエントリが必要です。したがって、フローIDをエンコードするには、合計3つのラベルスタックエントリが必要です。

The use of special-purpose labels [RFC7274] as part of a method to encode the identity information therefore has a number of undesirable implications for the data plane. Thus, while a solution may use special-purpose labels, methods that do not require special-purpose labels need to be carefully considered.

したがって、アイデンティティ情報をエンコードする方法の一部として特殊用途のラベル[RFC7274]を使用すると、データプレーンに多くの望ましくない影響が生じます。したがって、ソリューションで専用ラベルを使用する場合がありますが、専用ラベルを必要としない方法は慎重に検討する必要があります。

9. Control Plane

9. コントロールプレーン

Any flow identity design should both seek to minimize the complexity of the control plane and minimize the amount of label coordination needed amongst LSRs.

フローIDの設計では、コントロールプレーンの複雑さを最小限に抑え、LSR間で必要なラベル調整の量を最小限に抑えることを目指す必要があります。

10. Privacy Considerations

10. プライバシーに関する考慮事項

The inclusion of originating and/or flow information in a packet provides more identity information and hence potentially degrades the privacy of the communication.

パケットに発信および/またはフロー情報を含めると、より多くの識別情報が提供され、通信のプライバシーが低下する可能性があります。

Recent IETF concerns on pervasive monitoring [RFC7258] have resulted in a preference for a solution that does not degrade the privacy of user traffic below that of an MPLS network not implementing the flow identification feature. The choice of using MPLS technology for this OAM solution has a privacy advantage, as the choice of the label identifying a flow is limited to the scope of the MPLS domain and does not have any dependency on the identification of the user data. This minimizes the observability of the flow characteristics.

普及モニタリングに関する最近のIETFの懸念[RFC7258]により、フロー識別機能を実装していないMPLSネットワークよりもユーザートラフィックのプライバシーを低下させないソリューションが好まれました。フローを識別するラベルの選択はMPLSドメインのスコープに限定され、ユーザーデータの識別に依存しないため、このOAMソリューションにMPLSテクノロジーを使用する選択にはプライバシー上の利点があります。これにより、流れ特性の観察可能性が最小化されます。

11. Security Considerations

11. セキュリティに関する考慮事項

Any flow identification solution must not degrade the security of the MPLS network below that of an equivalent network not deploying the specified identity solution. In order to preserve present assumptions about MPLS privacy properties, propagation of identification information outside the MPLS network imposing it must be disabled by default. Any solution should provide for the restriction of the identity information to those components of the network that need to know it. It is thus desirable to limit the knowledge of the identify of an endpoint to only those LSRs that need to participate in traffic flow. The choice of using MPLS technology for this OAM solution, with MPLS encapsulation of user traffic, provides for a key advantage over other data-plane solutions, as it provides for a controlled access and trusted domain within a service provider's network.

フロー識別ソリューションは、MPLSネットワークのセキュリティを、指定されたIDソリューションを展開していない同等のネットワークのセキュリティよりも低下させてはなりません。 MPLSプライバシープロパティに関する現在の想定を保持するために、MPLSネットワーク外への識別情報の伝達を強制することは、デフォルトで無効にする必要があります。どのようなソリューションでも、それを知る必要があるネットワークのコンポーネントへのID情報の制限を提供する必要があります。したがって、エンドポイントの識別に関する知識を、トラフィックフローに参加する必要があるLSRのみに制限することが望ましいです。このOAMソリューションにMPLSテクノロジーを使用することと、ユーザートラフィックのMPLSカプセル化を選択すると、サービスプロバイダーのネットワーク内でアクセスの制御と信頼できるドメインが提供されるため、他のデータプレーンソリューションに比べて重要な利点があります。

For a more comprehensive discussion of MPLS security and attack mitigation techniques, please see "Security Framework for MPLS and GMPLS Networks" [RFC5920].

MPLSセキュリティと攻撃軽減技術のより包括的な説明については、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」[RFC5920]を参照してください。

12. IANA Considerations

12. IANAに関する考慮事項

This document has no IANA considerations.

このドキュメントには、IANAに関する考慮事項はありません。

13. Informative References

13. 参考引用

[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, DOI 10.17487/RFC5331, August 2008, <https://www.rfc-editor.org/info/rfc5331>.

[RFC5331] Aggarwal、R.、Rekhter、Y。、およびE. Rosen、「MPLSアップストリームラベル割り当ておよびコンテキスト固有のラベルスペース」、RFC 5331、DOI 10.17487 / RFC5331、2008年8月、<https：//www.rfc -editor.org/info/rfc5331>。

[RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. Ayyangarps, "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420, February 2009, <https://www.rfc-editor.org/info/rfc5420>.

[RFC5420] Farrel、A.、Ed。、Papadimitriou、D.、Vasseur、JP。、およびA. Ayyangarps、「Resource Reservation Protocol Traffic Engineering（RSVP-TE）を使用したMPLS LSP確立のための属性のエンコーディング」、RFC 5420、 DOI 10.17487 / RFC5420、2009年2月、<https://www.rfc-editor.org/info/rfc5420>。

[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, DOI 10.17487/RFC5654, September 2009, <https://www.rfc-editor.org/info/rfc5654>.

[RFC5654] Niven-Jenkins、B.、Ed。、Brungard、D.、Ed。、Betts、M.、Ed。、Sprecher、N.、and S. Ueno、 "Requirements of an MPLS Transport Profile"、RFC 5654 、DOI 10.17487 / RFC5654、2009年9月、<https://www.rfc-editor.org/info/rfc5654>。

[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <https://www.rfc-editor.org/info/rfc5920>.

[RFC5920] Fang、L。、編、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、DOI 10.17487 / RFC5920、2010年7月、<https://www.rfc-editor.org/info/rfc5920>。

[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, DOI 10.17487/RFC6374, September 2011, <https://www.rfc-editor.org/info/rfc6374>.

[RFC6374] Frost、D。およびS. Bryant、「MPLSネットワークのパケット損失と遅延測定」、RFC 6374、DOI 10.17487 / RFC6374、2011年9月、<https://www.rfc-editor.org/info/rfc6374 >。

[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, DOI 10.17487/RFC6790, November 2012, <https://www.rfc-editor.org/info/rfc6790>.

[RFC6790] Kompella、K.、Drake、J.、Amante、S.、Henderickx、W.、and L. Yong、 "The Use of Entropy Labels in MPLS Forwarding"、RFC 6790、DOI 10.17487 / RFC6790、November 2012、 <https://www.rfc-editor.org/info/rfc6790>。

[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <https://www.rfc-editor.org/info/rfc7258>.

[RFC7258] Farrell、S。およびH. Tschofenig、「Pervasive Monitoring Is a Attack」、BCP 188、RFC 7258、DOI 10.17487 / RFC7258、2014年5月、<https://www.rfc-editor.org/info/rfc7258 >。

[RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating and Retiring Special-Purpose MPLS Labels", RFC 7274, DOI 10.17487/RFC7274, June 2014, <https://www.rfc-editor.org/info/rfc7274>.

[RFC7274] Kompella、K.、Andersson、L。、およびA. Farrel、「特別な目的のMPLSラベルの割り当てと廃止」、RFC 7274、DOI 10.17487 / RFC7274、2014年6月、<https：//www.rfc-editor .org / info / rfc7274>。

[RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, "Alternate-Marking Method for Passive and Hybrid Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, January 2018, <https://www.rfc-editor.org/info/rfc8321>.

[RFC8321] Fioccola、G.、Ed。、Capello、A.、Cociglio、M.、Castaldelli、L.、Chen、M.、Zheng、L.、Mirsky、G.、and T. Mizrahi、 "Alternate-Marking Method for Passive and Hybrid Performance Monitoring」、RFC 8321、DOI 10.17487 / RFC8321、2018年1月、<https://www.rfc-editor.org/info/rfc8321>。

Acknowledgments

謝辞

The authors thank Nobo Akiya, Nagendra Kumar Nainar, George Swallow, and Deborah Brungard for their comments.

著者は、Nobo Akiya、Nagendra Kumar Nainar、George Swallow、Deborah Brungardのコメントに感謝します。

Authors' Addresses

著者のアドレス

Stewart Bryant Huawei

スチュワートブライアントファーウェイ

   Email: stewart.bryant@gmail.com

Carlos Pignataro Cisco Systems, Inc.

Carlos Pignataro Cisco Systems、Inc.

   Email: cpignata@cisco.com

Mach(Guoyi) Chen Huawei

マッハ（GUお一）陳湖Aは

   Email: mach.chen@huawei.com

Zhenbin Li Huawei

Zは非常にビンl IH UAは

   Email: lizhenbin@huawei.com

Gregory Mirsky ZTE Corp.

グレゴリー・ミルスキーZTE Corp.

   Email: gregimirsky@gmail.com