[要約] RFC 7424は、ネットワークでのリンク集約グループ（LAG）と等価コストマルチパス（ECMP）コンポーネントリンクの利用を最適化するためのメカニズムについての要約です。このRFCの目的は、ネットワークのリンク利用率を最大化し、トラフィックの負荷分散を改善することです。
Internet Engineering Task Force (IETF) R. Krishnan
Request for Comments: 7424 Brocade Communications
Category: Informational L. Yong
ISSN: 2070-1721 Huawei USA
A. Ghanwani
Dell
N. So
Vinci Systems
B. Khasnabish
ZTE Corporation
January 2015
Mechanisms for Optimizing Link Aggregation Group (LAG) and Equal-Cost Multipath (ECMP) Component Link Utilization in Networks
ネットワークでのリンク集約グループ（LAG）と等コストマルチパス（ECMP）コンポーネントのリンク使用率を最適化するメカニズム
Abstract
概要
Demands on networking infrastructure are growing exponentially due to bandwidth-hungry applications such as rich media applications and inter-data-center communications. In this context, it is important to optimally use the bandwidth in wired networks that extensively use link aggregation groups and equal-cost multipaths as techniques for bandwidth scaling. This document explores some of the mechanisms useful for achieving this.
リッチメディアアプリケーションやデータセンター間通信など、帯域幅を大量に消費するアプリケーションにより、ネットワークインフラストラクチャへの需要は飛躍的に高まっています。このコンテキストでは、リンク集約グループと等コストマルチパスを帯域幅スケーリングの手法として広く使用する有線ネットワークで帯域幅を最適に使用することが重要です。このドキュメントでは、これを達成するために役立つメカニズムのいくつかを探ります。
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/rfc7424.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7424で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 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 ....................................................4
1.1. Acronyms ...................................................4
1.2. Terminology ................................................5
2. Flow Categorization .............................................6
3. Hash-Based Load Distribution in LAG/ECMP ........................6
4. Mechanisms for Optimizing LAG/ECMP Component Link Utilization ...8
4.1. Differences in LAG vs. ECMP ................................9
4.2. Operational Overview ......................................10
4.3. Large Flow Recognition ....................................11
4.3.1. Flow Identification ................................11
4.3.2. Criteria and Techniques for Large Flow
Recognition ........................................12
4.3.3. Sampling Techniques ................................12
4.3.4. Inline Data Path Measurement .......................14
4.3.5. Use of Multiple Methods for Large Flow
Recognition ........................................15
4.4. Options for Load Rebalancing ..............................15
4.4.1. Alternative Placement of Large Flows ...............15
4.4.2. Redistributing Small Flows .........................16
4.4.3. Component Link Protection Considerations ...........16
4.4.4. Algorithms for Load Rebalancing ....................17
4.4.5. Example of Load Rebalancing ........................17
5. Information Model for Flow Rebalancing .........................18
5.1. Configuration Parameters for Flow Rebalancing .............18
5.2. System Configuration and Identification Parameters ........19
5.3. Information for Alternative Placement of Large Flows ......20
5.4. Information for Redistribution of Small Flows .............21
5.5. Export of Flow Information ................................21
5.6. Monitoring Information ....................................21
5.6.1. Interface (Link) Utilization .......................21
5.6.2. Other Monitoring Information .......................22
6. Operational Considerations .....................................23
6.1. Rebalancing Frequency .....................................23
6.2. Handling Route Changes ....................................23
6.3. Forwarding Resources ......................................23
7. Security Considerations ........................................23
8. References .....................................................24
8.1. Normative References ......................................24
8.2. Informative References ....................................25
Appendix A. Internet Traffic Analysis and Load-Balancing
Simulation ...........................................28
Acknowledgements ..................................................28
Contributors ......................................................28
Authors' Addresses ................................................29
Networks extensively use link aggregation groups (LAGs) [802.1AX] and equal-cost multipaths (ECMPs) [RFC2991] as techniques for capacity scaling. For the problems addressed by this document, network traffic can be predominantly categorized into two traffic types: long-lived large flows and other flows. These other flows, which include long-lived small flows, short-lived small flows, and short-lived large flows, are referred to as "small flows" in this document. Long-lived large flows are simply referred to as "large flows".
ネットワークでは、容量スケーリングの手法として、リンクアグリゲーショングループ（LAG）[802.1AX]と等コストマルチパス（ECMP）[RFC2991]を広く使用しています。このドキュメントで扱う問題の場合、ネットワークトラフィックは主に、長命の大規模フローとその他のフローの2つのトラフィックタイプに分類できます。このドキュメントでは、長命の小さなフロー、短命の小さなフロー、短命の大きなフローを含むこれらの他のフローを「小さなフロー」と呼びます。長命の大きな流れは、単に「大きな流れ」と呼ばれます。
Stateless hash-based techniques [ITCOM] [RFC2991] [RFC2992] [RFC6790] are often used to distribute both large flows and small flows over the component links in a LAG/ECMP. However, the traffic may not be evenly distributed over the component links due to the traffic pattern.
ステートレスハッシュベースの技法[ITCOM] [RFC2991] [RFC2992] [RFC6790]は、LAG / ECMPのコンポーネントリンク上に大きなフローと小さなフローの両方を分散するためによく使用されます。ただし、トラフィックパターンにより、トラフィックはコンポーネントリンクに均等に分散されない場合があります。
This document describes mechanisms for optimizing LAG/ECMP component link utilization when using hash-based techniques. The mechanisms comprise the following steps: 1) recognizing large flows in a router, and 2) assigning the large flows to specific LAG/ECMP component links or redistributing the small flows when a component link on the router is congested.
このドキュメントでは、ハッシュベースの手法を使用するときにLAG / ECMPコンポーネントのリンク使用率を最適化するメカニズムについて説明します。このメカニズムは次の手順で構成されます。1）ルーター内の大きなフローを認識し、2）特定のLAG / ECMPコンポーネントリンクに大きなフローを割り当てるか、ルーター上のコンポーネントリンクが混雑しているときに小さなフローを再配布します。
It is useful to keep in mind that in typical use cases for these mechanisms, the large flows consume a significant amount of bandwidth on a link, e.g., greater than 5% of link bandwidth. The number of such flows would necessarily be fairly small, e.g., on the order of 10s or 100s per LAG/ECMP. In other words, the number of large flows is NOT expected to be on the order of millions of flows. Examples of such large flows would be IPsec tunnels in service provider backbone networks or storage backup traffic in data center networks.
これらのメカニズムの一般的な使用例では、大きなフローがリンク上のかなりの量の帯域幅、たとえばリンク帯域幅の5％を超えることを覚えておくと便利です。そのようなフローの数は必然的にかなり少なくなり、たとえば、LAG / ECMPあたり10秒または100秒程度になります。言い換えれば、大きなフローの数は数百万のオーダーであるとは予想されていません。このような大きなフローの例としては、サービスプロバイダーのバックボーンネットワークのIPsecトンネルや、データセンターネットワークのストレージバックアップトラフィックなどがあります。
DoS: Denial of Service
DoS：サービス拒否
ECMP: Equal-Cost Multipath
ECMP：等コストマルチパス
GRE: Generic Routing Encapsulation
GRE：ジェネリックルーティングカプセル化
IPFIX: IP Flow Information Export
IPFIX：IPフロー情報のエクスポート
LAG: Link Aggregation Group
LAG：リンク集約グループ
MPLS: Multiprotocol Label Switching
MPLS：マルチプロトコルラベルスイッチング
NVGRE: Network Virtualization using Generic Routing Encapsulation PBR: Policy-Based Routing
NVGRE：Generic Routing Encapsulation PBRを使用したネットワーク仮想化：ポリシーベースのルーティング
QoS: Quality of Service
QoS：サービスの品質
STT: Stateless Transport Tunneling
STT：ステートレストランスポートトンネリング
VXLAN: Virtual eXtensible LAN
VXLAN：仮想拡張可能LAN
Central management entity: An entity that is capable of monitoring information about link utilization and flows in routers across the network and may be capable of making traffic-engineering decisions for placement of large flows. It may include the functions of a collector [RFC7011].
中央管理エンティティ：ネットワーク全体のルーターでのリンク使用率とフローに関する情報を監視でき、大規模なフローの配置に関するトラフィックエンジニアリングの決定を行うことができるエンティティ。コレクターの機能[RFC7011]を含んでもよい。
ECMP component link: An individual next hop within an ECMP group. An ECMP component link may itself comprise a LAG.
ECMPコンポーネントリンク：ECMPグループ内の個々のネクストホップ。 ECMPコンポーネントリンク自体がLAGを構成する場合があります。
ECMP table: A table that is used as the next hop of an ECMP route that comprises the set of ECMP component links and the weights associated with each of those ECMP component links. The input for looking up the table is the hash value for the packet, and the weights are used to determine which values of the hash function map to a given ECMP component link.
ECMPテーブル：ECMPコンポーネントリンクのセットとそれらの各ECMPコンポーネントリンクに関連付けられた重みで構成されるECMPルートのネクストホップとして使用されるテーブル。テーブルを検索するための入力は、パケットのハッシュ値であり、重みは、ハッシュ関数のどの値が特定のECMPコンポーネントリンクにマッピングされるかを決定するために使用されます。
Flow (large or small): A sequence of packets for which ordered delivery should be maintained, e.g., packets belonging to the same TCP connection.
フロー（大または小）：順序付けされた配信を維持する必要がある一連のパケット（同じTCP接続に属するパケットなど）。
LAG component link: An individual link within a LAG. A LAG component link is typically a physical link.
LAGコンポーネントリンク：LAG内の個々のリンク。 LAGコンポーネントリンクは通常、物理リンクです。
LAG table: A table that is used as the output port, which is a LAG, that comprises the set of LAG component links and the weights associated with each of those component links. The input for looking up the table is the hash value for the packet, and the weights are used to determine which values of the hash function map to a given LAG component link.
LAGテーブル：出力ポートとして使用されるテーブル、つまりLAGは、LAGコンポーネントリンクのセットと、各コンポーネントリンクに関連付けられた重みで構成されます。テーブルを検索するための入力は、パケットのハッシュ値であり、重みは、ハッシュ関数のどの値が特定のLAGコンポーネントリンクにマッピングされるかを決定するために使用されます。
Large flow(s): Refers to long-lived large flow(s).
大流量：長寿命の大流量を指します。
Small flow(s): Refers to any of, or a combination of, long-lived small flow(s), short-lived small flows, and short-lived large flow(s).
小フロー：長命の小フロー、短命の小フロー、短命の大フローのいずれか、またはそれらの組み合わせを指します。
In general, based on the size and duration, a flow can be categorized into any one of the following four types, as shown in Figure 1:
一般に、フローは、サイズと期間に基づいて、図1に示すように、次の4つのタイプのいずれかに分類できます。
o short-lived large flow (SLLF),
o 短命の大流量（SLLF）、
o short-lived small flow (SLSF),
o 短命の小流量（SLSF）、
o long-lived large flow (LLLF), and
o 長寿命大流量（LLLF）、および
o long-lived small flow (LLSF).
o 長寿命小フロー（LLSF）。
Flow Bandwidth
^
|--------------------|--------------------|
| | |
Large | SLLF | LLLF |
Flow | | |
|--------------------|--------------------|
| | |
Small | SLSF | LLSF |
Flow | | |
+--------------------+--------------------+-->Flow Duration
Short-Lived Long-Lived
Flow Flow
Figure 1: Flow Categorization
図1：フローの分類
In this document, as mentioned earlier, we categorize long-lived large flows as "large flows", and all of the others (long-lived small flows, short-lived small flows, and short-lived large flows) as "small flows".
このドキュメントでは、前述のように、長命の大きなフローを「大フロー」として分類し、その他すべて（長命の小フロー、短命の小フロー、短命の大フロー）を「小フロー」として分類します」
Hash-based techniques are often used for load balancing of traffic to select among multiple available paths within a LAG/ECMP group. The advantages of hash-based techniques for load distribution are the preservation of the packet sequence in a flow and the real-time distribution without maintaining per-flow state in the router. Hash-based techniques use a combination of fields in the packet's headers to identify a flow, and the hash function computed using these fields is used to generate a unique number that identifies a link/path in a LAG/ECMP group. The result of the hashing procedure is a many-to-one mapping of flows to component links.
LAG / ECMPグループ内の複数の使用可能なパスから選択するトラフィックの負荷分散には、ハッシュベースのテクニックがよく使用されます。負荷分散のためのハッシュベースの技術の利点は、フローでのパケットシーケンスの保持と、ルーターでフローごとの状態を維持せずにリアルタイムで分散することです。ハッシュベースの技術は、パケットのヘッダーのフィールドの組み合わせを使用してフローを識別し、これらのフィールドを使用して計算されたハッシュ関数は、LAG / ECMPグループのリンク/パスを識別する一意の番号を生成するために使用されます。ハッシング手順の結果は、コンポーネントリンクへのフローの多対1マッピングです。
Hash-based techniques produce good results with respect to utilization of the individual component links if:
ハッシュベースの手法は、次の場合に個々のコンポーネントリンクの使用に関して良好な結果をもたらします。
o the traffic mix constitutes flows such that the result of the hash function across these flows is fairly uniform so that a similar number of flows is mapped to each component link,
o トラフィックミックスはフローを構成し、これらのフロー全体のハッシュ関数の結果はかなり均一になるため、同様の数のフローが各コンポーネントリンクにマッピングされます。
o the individual flow rates are much smaller as compared to the link capacity, and
o 個々の流量は、リンク容量と比較してはるかに小さいです。
o the differences in flow rates are not dramatic.
o 流量の違いは劇的ではありません。
However, if one or more of these conditions are not met, hash-based techniques may result in imbalance in the loads on individual component links.
ただし、これらの条件の1つ以上が満たされていない場合、ハッシュベースの手法では、個々のコンポーネントリンクの負荷が不均衡になる可能性があります。
An example is illustrated in Figure 2. As shown, there are two routers, R1 and R2, and there is a LAG between them that has three component links (1), (2), and (3). A total of ten flows need to be distributed across the links in this LAG. The result of applying the hash-based technique is as follows:
例を図2に示します。図のように、R1とR2の2つのルーターがあり、それらの間に3つのコンポーネントリンク（1）、（2）、（3）を持つLAGがあります。このLAGのリンク全体で合計10のフローを分散する必要があります。ハッシュベースの手法を適用した結果は次のとおりです。
o Component link (1) has three flows (two small flows and one large flow), and the link utilization is normal.
o コンポーネントリンク（1）には3つのフロー（2つの小さなフローと1つの大きなフロー）があり、リンクの使用率は正常です。
o Component link (2) has three flows (three small flows and no large flows), and the link utilization is light.
o コンポーネントリンク（2）には3つのフロー（3つの小さなフローがあり、大きなフローはない）があり、リンクの使用率はわずかです。
- The absence of any large flow causes the component link to be underutilized.
- 大きなフローがないと、コンポーネントのリンクが十分に活用されません。
o Component link (3) has four flows (two small flows and two large flows), and the link capacity is exceeded resulting in congestion.
o コンポーネントリンク（3）には4つのフロー（2つの小さなフローと2つの大きなフロー）があり、リンク容量を超えているため、輻輳が発生しています。
- The presence of two large flows causes congestion on this component link.
- 2つの大きなフローが存在すると、このコンポーネントリンクで輻輳が発生します。
+-----------+ -> +-----------+
| | -> | |
| | ===> | |
| (1)|--------|(1) |
| | -> | |
| | -> | |
| (R1) | -> | (R2) |
| (2)|--------|(2) |
| | -> | |
| | -> | |
| | ===> | |
| | ===> | |
| (3)|--------|(3) |
| | | |
+-----------+ +-----------+
Where: -> small flow
===> large flow
Figure 2: Unevenly Utilized Component Links
図2：不均等に利用されているコンポーネントリンク
This document presents mechanisms for addressing the imbalance in load distribution resulting from commonly used hash-based techniques for LAG/ECMP that are shown in the above example. The mechanisms use large flow awareness to compensate for the imbalance in load distribution.
このドキュメントでは、上記の例で示した、LAG / ECMPで一般的に使用されているハッシュベースの技術から生じる負荷分散の不均衡に対処するためのメカニズムを紹介します。メカニズムは、大きなフロー認識を使用して、負荷分散の不均衡を補正します。
The suggested mechanisms in this document are local optimization solutions; they are local in the sense that both the identification of large flows and rebalancing of the load can be accomplished completely within individual routers in the network without the need for interaction with other routers.
このドキュメントで提案されているメカニズムは、ローカル最適化ソリューションです。大規模なフローの識別と負荷の再調整の両方を、他のルーターとの相互作用を必要とせずにネットワーク内の個々のルーター内で完全に実行できるという意味で、ローカルです。
This approach may not yield a global optimization of the placement of large flows across multiple routers in a network, which may be desirable in some networks. On the other hand, a local approach may be adequate for some environments for the following reasons:
このアプローチでは、ネットワーク内の複数のルーターにまたがる大きなフローの配置のグローバルな最適化が得られない場合があり、これは一部のネットワークでは望ましい場合があります。一方、一部の環境では、次の理由により、ローカルアプローチが適切な場合があります。
1) Different links within a network experience different levels of utilization; thus, a "targeted" solution is needed for those hot spots in the network. An example is the utilization of a LAG between two routers that needs to be optimized.
1）ネットワーク内の異なるリンクは、異なるレベルの使用率を経験します。したがって、ネットワーク内のホットスポットには「ターゲット」ソリューションが必要です。例としては、最適化が必要な2つのルーター間のLAGの利用があります。
2) Some networks may lack end-to-end visibility, e.g., when a certain network, under the control of a given operator, is a transit network for traffic from other networks that are not under the control of the same operator.
2）一部のネットワークは、エンドツーエンドの可視性を欠いている可能性があります。たとえば、特定のオペレーターの制御下にある特定のネットワークが、同じオペレーターの制御下にない他のネットワークからのトラフィックのトランジットネットワークである場合です。
While the mechanisms explained herein are applicable to both LAGs and ECMP groups, it is useful to note that there are some key differences between the two that may impact how effective the mechanisms are. This relates, in part, to the localized information with which the mechanisms are intended to operate.
ここで説明するメカニズムはLAGとECMPグループの両方に適用できますが、メカニズムの効果に影響を与える可能性がある2つのキーの違いがいくつかあることに注意してください。これは、一部には、メカニズムが動作することを目的としたローカライズされた情報に関連しています。
A LAG is usually established across links that are between two adjacent routers. As a result, the scope of the problem of optimizing the bandwidth utilization on the component links is fairly narrow. It simply involves rebalancing the load across the component links between these two routers, and there is no impact whatsoever to other parts of the network. The scheme works equally well for unicast and multicast flows.
LAGは通常、2つの隣接するルーター間のリンク全体に確立されます。その結果、コンポーネントリンクの帯域幅使用率を最適化する問題の範囲はかなり狭くなります。単純に、これら2つのルーター間のコンポーネントリンク全体の負荷を再調整するだけで、ネットワークの他の部分に影響を与えることはありません。このスキームは、ユニキャストフローとマルチキャストフローのどちらでも同じように機能します。
On the other hand, with ECMP, redistributing the load across component links that are part of the ECMP group may impact traffic patterns at all of the routers that are downstream of the given router between itself and the destination. The local optimization may result in congestion at a downstream node. (In its simplest form, an ECMP group may be used to distribute traffic on component links that are between two adjacent routers, and in that case, the ECMP group is no different than a LAG for the purpose of this discussion. It should be noted that an ECMP component link may itself comprise a LAG, in which case the scheme may be further applied to the component links within the LAG.)
一方、ECMPでは、ECMPグループの一部であるコンポーネントリンク間で負荷を再分散すると、ルーターと宛先の間の特定のルーターの下流にあるすべてのルーターのトラフィックパターンに影響を与える可能性があります。ローカル最適化により、ダウンストリームノードで輻輳が発生する可能性があります。 （最も単純な形式では、ECMPグループを使用して、2つの隣接するルーター間のコンポーネントリンクにトラフィックを分散できます。その場合、ECMPグループは、この説明の目的でLAGと同じです。注意してください。 ECMPコンポーネントリンク自体がLAGを含む場合があることを示します。この場合、スキームはさらにLAG内のコンポーネントリンクに適用できます。）
To demonstrate the limitations of local optimization, consider a two-level Clos network topology as shown in Figure 3 with three leaf routers (L1, L2, and L3) and two spine routers (S1 and S2). Assume all of the links are 10 Gbps.
ローカル最適化の制限を示すために、3つのリーフルーター（L1、L2、およびL3）と2つのスパインルーター（S1とS2）を備えた、図3に示す2レベルのClosネットワークトポロジを考えます。すべてのリンクが10 Gbpsであると想定します。
Let L1 have two flows of 4 Gbps each towards L3, and let L2 have one flow of 7 Gbps also towards L3. If L1 balances the load optimally between S1 and S2, and L2 sends the flow via S1, then the downlink from S1 to L3 would get congested, resulting in packet discards. On the other hand, if L1 had sent both its flows towards S1 and L2 had sent its flow towards S2, there would have been no congestion at either S1 or S2.
L1にそれぞれL3に向かう4 Gbpsの2つのフローがあり、L2にもL3に向かう7 Gbpsの1つのフローがあるとします。 L1がS1とS2の間で負荷を最適に分散し、L2がS1を介してフローを送信する場合、S1からL3へのダウンリンクは輻輳し、パケット破棄が発生します。一方、L1が両方のフローをS1に向けて送信し、L2がS2に向けてフローを送信した場合、S1とS2のどちらにも輻輳はありません。
+-----+ +-----+
| S1 | | S2 |
+-----+ +-----+
/ \ \ / /\
/ +---------+ / \
/ / \ \ / \
/ / \ +------+ \
/ / \ / \ \
+-----+ +-----+ +-----+
| L1 | | L2 | | L3 |
+-----+ +-----+ +-----+
Figure 3: Two-Level Clos Network
図3：2レベルのClosネットワーク
The other issue with applying this scheme to ECMP groups is that it may not apply equally to unicast and multicast traffic because of the way multicast trees are constructed.
このスキームをECMPグループに適用する際のもう1つの問題は、マルチキャストツリーの構築方法が原因で、ユニキャストトラフィックとマルチキャストトラフィックに等しく適用されない可能性があることです。
Finally, it is possible for a single physical link to participate as a component link in multiple ECMP groups, whereas with LAGs, a link can participate as a component link of only one LAG.
最後に、単一の物理リンクが複数のECMPグループのコンポーネントリンクとして参加することは可能ですが、LAGの場合、リンクは1つのLAGのコンポーネントリンクとしてのみ参加できます。
The various steps in optimizing LAG/ECMP component link utilization in networks are detailed below:
ネットワークでのLAG / ECMPコンポーネントリンク使用率を最適化するためのさまざまな手順の詳細を以下に示します。
Step 1: This step involves recognizing large flows in routers and maintaining the mapping for each large flow to the component link that it uses. Recognition of large flows is explained in Section 4.3.
ステップ1：このステップには、ルーター内の大きなフローを認識し、使用するコンポーネントリンクへの各大きなフローのマッピングを維持することが含まれます。大きなフローの認識については、セクション4.3で説明します。
Step 2: The egress component links are periodically scanned for link utilization, and the imbalance for the LAG/ECMP group is monitored. If the imbalance exceeds a certain threshold, then rebalancing is triggered. Measurement of the imbalance is discussed further in Section 5.1. In addition to the imbalance, further criteria (such as the maximum utilization of any of the component links) may also be used to determine whether or not to trigger rebalancing. The use of sampling techniques for the measurement of egress component link utilization, including the issues of depending on ingress sampling for these measurements, are discussed in Section 4.3.3.
ステップ2：出力コンポーネントリンクのリンク使用率が定期的にスキャンされ、LAG / ECMPグループの不均衡が監視されます。インバランスが特定のしきい値を超えると、リバランスがトリガーされます。インバランスの測定については、セクション5.1で詳しく説明します。不均衡に加えて、追加の基準（コンポーネントリンクの最大使用率など）を使用して、リバランスをトリガーするかどうかを決定することもできます。これらの測定の入力サンプリングに依存する問題を含む、出力コンポーネントリンク使用率の測定のためのサンプリング技術の使用については、セクション4.3.3で説明します。
Step 3: As a part of rebalancing, the operator can choose to rebalance the large flows by placing them on lightly loaded component links of the LAG/ECMP group, redistribute the small flows on the congested link to other component links of the group, or a combination of both.
ステップ3：リバランスの一部として、オペレーターは、LAG / ECMPグループの負荷の軽いコンポーネントリンクにフローを配置することで大規模なフローをリバランスするか、グループの他のコンポーネントリンクに輻輳したリンク上の小さなフローを再分配するか、または両方の組み合わせ。
All of the steps identified above can be done locally within the router itself or could involve the use of a central management entity.
上記のすべての手順は、ルーター内でローカルに実行することも、中央管理エンティティを使用することもできます。
Providing large flow information to a central management entity provides the capability to globally optimize flow distribution as described in Section 4.1. Consider the following example. A router may have three ECMP next hops that lead down paths P1, P2, and P3. A couple of hops downstream on path P1, there may be a congested link, while paths P2 and P3 may be underutilized. This is something that the local router does not have visibility into. With the help of a central management entity, the operator could redistribute some of the flows from P1 to P2 and/or P3, resulting in a more optimized flow of traffic.
大規模なフロー情報を中央管理エンティティに提供すると、セクション4.1で説明されているように、フロー分散をグローバルに最適化する機能が提供されます。次の例を考えてみましょう。ルータには、パスP1、P2、およびP3につながる3つのECMPネクストホップがある場合があります。パスP1のダウンストリームホップは2つあり、リンクが混雑している可能性がありますが、パスP2およびP3は十分に活用されていません。これは、ローカルルーターが認識できないものです。中央管理エンティティの助けを借りて、事業者はP1からP2やP3へのフローの一部を再分配でき、トラフィックのより最適化されたフローをもたらします。
The steps described above are especially useful when bundling links of different bandwidths, e.g., 10 Gbps and 100 Gbps as described in [RFC7226].
上記の手順は、[RFC7226]で説明されているように、たとえば10 Gbpsと100 Gbpsなどの異なる帯域幅のリンクをバンドルする場合に特に役立ちます。
Flows are typically identified using one or more fields from the packet header, for example:
フローは通常、パケットヘッダーの1つ以上のフィールドを使用して識別されます。次に例を示します。
o Layer 2: Source Media Access Control (MAC) address, destination MAC address, VLAN ID.
o レイヤ2：ソースメディアアクセス制御（MAC）アドレス、宛先MACアドレス、VLAN ID。
o IP header: IP protocol, IP source address, IP destination address, flow label (IPv6 only).
o IPヘッダー：IPプロトコル、IP送信元アドレス、IP宛先アドレス、フローラベル（IPv6のみ）。
o Transport protocol header: Source port number, destination port number. These apply to protocols such as TCP, UDP, and the Stream Control Transmission Protocol (SCTP).
o トランスポートプロトコルヘッダー：送信元ポート番号、宛先ポート番号。これらは、TCP、UDP、Stream Control Transmission Protocol（SCTP）などのプロトコルに適用されます。
o MPLS labels.
o MPLSラベル。
For tunneling protocols like Generic Routing Encapsulation (GRE) [RFC2784], Virtual eXtensible LAN (VXLAN) [RFC7348], Network Virtualization using Generic Routing Encapsulation (NVGRE) [NVGRE],
Generic Routing Encapsulation（GRE）[RFC2784]、Virtual eXtensible LAN（VXLAN）[RFC7348]、Generic Routing Encapsulation（NVGRE）[NVGRE]を使用したネットワーク仮想化などのトンネリングプロトコルの場合
Stateless Transport Tunneling (STT) [STT], Layer 2 Tunneling Protocol (L2TP) [RFC3931], etc., flow identification is possible based on inner and/or outer headers as well as fields introduced by the tunnel header, as any or all such fields may be used for load balancing decisions [RFC5640].
ステートレストランスポートトンネリング（STT）[STT]、レイヤー2トンネリングプロトコル（L2TP）[RFC3931]など。内部ヘッダーまたは外部ヘッダー、あるいはトンネルヘッダーによって導入されたフィールドに基づいて、フローの識別が可能です。このようなフィールドは、ロードバランシングの決定に使用できます[RFC5640]。
The above list is not exhaustive.
上記のリストは完全なものではありません。
The mechanisms described in this document are agnostic to the fields that are used for flow identification.
このドキュメントで説明するメカニズムは、フローの識別に使用されるフィールドに依存しません。
This method of flow identification is consistent with that of IPFIX [RFC7011].
このフロー識別方法は、IPFIX [RFC7011]の方法と一致しています。
From the perspective of bandwidth and time duration, in order to recognize large flows, we define an observation interval and measure the bandwidth of the flow over that interval. A flow that exceeds a certain minimum bandwidth threshold over that observation interval would be considered a large flow.
帯域幅と継続時間の観点から、大きなフローを認識するために、観測間隔を定義し、その間隔でのフローの帯域幅を測定します。その観測間隔で特定の最小帯域幅しきい値を超えるフローは、大きなフローと見なされます。
The two parameters -- the observation interval and the minimum bandwidth threshold over that observation interval -- should be programmable to facilitate handling of different use cases and traffic characteristics. For example, a flow that is at or above 10% of link bandwidth for a time period of at least one second could be declared a large flow [DEVOFLOW].
2つのパラメーター（観測間隔とその観測間隔での最小帯域幅しきい値）は、さまざまなユースケースとトラフィック特性の処理を容易にするためにプログラム可能である必要があります。たとえば、少なくとも1秒間リンクバンド幅の10％以上のフローは、大規模なフロー[DEVOFLOW]と宣言できます。
In order to avoid excessive churn in the rebalancing, once a flow has been recognized as a large flow, it should continue to be recognized as a large flow for as long as the traffic received during an observation interval exceeds some fraction of the bandwidth threshold, for example, 80% of the bandwidth threshold.
リバランシングでの過剰なチャーンを回避するために、フローが大きなフローとして認識されると、観測間隔中に受信されたトラフィックが帯域幅しきい値の一部を超える限り、フローは大きなフローとして認識され続けるはずです。たとえば、帯域幅のしきい値の80％。
Various techniques to recognize a large flow are described in Sections 4.3.3, 4.3.4, and 4.3.5.
大きなフローを認識するためのさまざまな手法については、セクション4.3.3、4.3.4、および4.3.5で説明します。
A number of routers support sampling techniques such as sFlow [sFlow-v5] [sFlow-LAG], Packet Sampling (PSAMP) [RFC5475], and NetFlow Sampling [RFC3954]. For the purpose of large flow recognition, sampling needs to be enabled on all of the egress ports in the router where such measurements are desired.
多くのルーターは、sFlow [sFlow-v5] [sFlow-LAG]、Packet Sampling（PSAMP）[RFC5475]、NetFlow Sampling [RFC3954]などのサンプリング手法をサポートしています。大規模なフロー認識のために、このような測定が必要なルーターのすべての出力ポートでサンプリングを有効にする必要があります。
Using sFlow as an example, processing in an sFlow collector can provide an approximate indication of the mapping of large flows to each of the component links in each LAG/ECMP group. Assuming sufficient control plane resources are available, it is possible to implement this part of the collector function in the control plane of the router to reduce dependence on a central management entity.
例としてsFlowを使用すると、sFlowコレクターでの処理は、各LAG / ECMPグループの各コンポーネントリンクへの大規模なフローのマッピングのおおよその指標を提供できます。十分なコントロールプレーンリソースが利用可能であると仮定すると、コレクター機能のこの部分をルーターのコントロールプレーンに実装して、中央管理エンティティへの依存を減らすことができます。
If egress sampling is not available, ingress sampling can suffice since the central management entity used by the sampling technique typically has visibility across multiple routers in a network and can use the samples from an immediately downstream router to make measurements for egress traffic at the local router.
出力サンプリングが利用できない場合、サンプリング手法で使用される中央管理エンティティは、通常、ネットワーク内の複数のルーターにわたって可視性を持ち、すぐ下流のルーターからのサンプルを使用して、ローカルルーターで出力トラフィックを測定できるため、入力サンプリングで十分です。 。
The option of using ingress sampling for this purpose may not be available if the downstream router is under the control of a different operator or if the downstream device does not support sampling.
この目的で上りサンプリングを使用するオプションは、ダウンストリームルータが別のオペレータの制御下にある場合、またはダウンストリームデバイスがサンプリングをサポートしていない場合は使用できない場合があります。
Alternatively, since sampling techniques require that the sample be annotated with the packet's egress port information, ingress sampling may suffice. However, this means that sampling would have to be enabled on all ports, rather than only on those ports where such monitoring is desired. There is one situation in which this approach may not work. If there are tunnels that originate from the given router and if the resulting tunnel comprises the large flow, then this cannot be deduced from ingress sampling at the given router. Instead, for this scenario, if egress sampling is unavailable, then ingress sampling from the downstream router must be used.
または、サンプリング手法では、サンプルにパケットの出力ポート情報を注釈として付ける必要があるため、入力サンプリングで十分な場合があります。ただし、これは、そのような監視が必要なポートだけでなく、すべてのポートでサンプリングを有効にする必要があることを意味します。このアプローチが機能しない状況が1つあります。特定のルーターから発信されたトンネルがあり、結果のトンネルが大きなフローを構成している場合、これは特定のルーターでの入力サンプリングから推定できません。代わりに、このシナリオでは、出力サンプリングが利用できない場合、ダウンストリームルータからの入力サンプリングを使用する必要があります。
To illustrate the use of ingress versus egress sampling, we refer to Figure 2. Since we are looking at rebalancing flows at R1, we would need to enable egress sampling on ports (1), (2), and (3) on R1. If egress sampling is not available and if R2 is also under the control of the same administrator, enabling ingress sampling on R2's ports (1), (2), and (3) would also work, but it would necessitate the involvement of a central management entity in order for R1 to obtain large flow information for each of its links. Finally, R1 can only enable ingress sampling on all of its ports (not just the ports that are part of the LAG/ECMP group being monitored), and that would suffice if the sampling technique annotates the samples with the egress port information.
入力と出力のサンプリングの使用を説明するために、図2を参照してください。R1でフローのリバランスを検討しているため、R1のポート（1）、（2）、および（3）で出力サンプリングを有効にする必要があります。出力サンプリングが利用できず、R2も同じ管理者の制御下にある場合、R2のポート（1）、（2）、および（3）で入力サンプリングを有効にすることも機能しますが、セントラルの関与が必要になります。 R1が各リンクの大きなフロー情報を取得するための管理エンティティ。最後に、R1はそのポートすべて（監視されているLAG / ECMPグループの一部であるポートだけでなく）でのみ入力サンプリングを有効にすることができ、サンプリング手法がサンプルに出力ポート情報で注釈を付ける場合はこれで十分です。
The advantages and disadvantages of sampling techniques are as follows.
サンプリング手法の長所と短所は次のとおりです。
Advantages:
利点：
o Supported in most existing routers.
o 既存のほとんどのルーターでサポートされています。
o Requires minimal router resources.
o 最小限のルーターリソースが必要です。
Disadvantage:
不利益：
o In order to minimize the error inherent in sampling, there is a minimum delay for the recognition time of large flows, and in the time that it takes to react to this information.
o サンプリングに固有のエラーを最小限に抑えるために、大きなフローの認識時間と、この情報に反応するのにかかる時間には、最小限の遅延があります。
With sampling, the detection of large flows can be done on the order of one second [DEVOFLOW]. A discussion on determining the appropriate sampling frequency is available in [SAMP-BASIC].
サンプリングを使用すると、1秒程度の大きなフローの検出を行うことができます[DEVOFLOW]。適切なサンプリング周波数の決定に関する議論は、[SAMP-BASIC]で利用できます。
Implementations may perform recognition of large flows by performing measurements on traffic in the data path of a router. Such an approach would be expected to operate at the interface speed on every interface, accounting for all packets processed by the data path of the router. An example of such an approach is described in IPFIX [RFC5470].
実装では、ルーターのデータパスのトラフィックの測定を実行することにより、大きなフローの認識を実行できます。このようなアプローチは、ルータのデータパスによって処理されるすべてのパケットを考慮して、すべてのインターフェイスのインターフェイス速度で動作することが期待されます。このようなアプローチの例は、IPFIX [RFC5470]で説明されています。
Using inline data path measurement, a faster and more accurate indication of large flows mapped to each of the component links in a LAG/ECMP group may be possible (as compared to the sampling-based approach).
インラインデータパス測定を使用すると、LAG / ECMPグループの各コンポーネントリンクにマッピングされた大規模なフローのより高速かつ正確な表示が可能になります（サンプリングベースのアプローチと比較して）。
The advantages and disadvantages of inline data path measurement are as follows:
インラインデータパス測定の利点と欠点は次のとおりです。
Advantages:
利点：
o As link speeds get higher, sampling rates are typically reduced to keep the number of samples manageable, which places a lower bound on the detection time. With inline data path measurement, large flows can be recognized in shorter windows on higher link speeds since every packet is accounted for [NDTM].
o リンク速度が速くなると、サンプリングレートは通常、サンプル数を管理可能な状態に保つために下げられ、検出時間の下限が設定されます。インラインデータパス測定を使用すると、すべてのパケットが[NDTM]に対応するため、リンク速度が高く、短いウィンドウで大きなフローを認識できます。
o Inline data path measurement eliminates the potential dependence on a central management entity for large flow recognition.
o インラインデータパス測定は、大規模なフロー認識のために中央管理エンティティへの潜在的な依存を排除します。
Disadvantage:
不利益：
o Inline data path measurement is more resource intensive in terms of the table sizes required for monitoring all flows.
o インラインデータパス測定は、すべてのフローの監視に必要なテーブルサイズの点で、より多くのリソースを必要とします。
As mentioned earlier, the observation interval for determining a large flow and the bandwidth threshold for classifying a flow as a large flow should be programmable parameters in a router.
前述のように、大きなフローを決定するための観測間隔と、フローを大きなフローとして分類するための帯域幅しきい値は、ルーターでプログラム可能なパラメーターにする必要があります。
The implementation details of inline data path measurement of large flows is vendor dependent and beyond the scope of this document.
大規模なフローのインラインデータパス測定の実装の詳細はベンダーによって異なり、このドキュメントの範囲を超えています。
It is possible that a router may have line cards that support a sampling technique while other line cards support inline data path measurement. As long as there is a way for the router to reliably determine the mapping of large flows to component links of a LAG/ECMP group, it is acceptable for the router to use more than one method for large flow recognition.
他のラインカードがインラインデータパス測定をサポートしている間に、ルータがサンプリング技術をサポートするラインカードを備えている可能性があります。ルーターがLAG / ECMPグループのコンポーネントリンクへの大きなフローのマッピングを確実に決定する方法がある限り、ルーターが大規模なフローの認識に複数の方法を使用することは許容されます。
If both methods are supported, inline data path measurement may be preferable because of its speed of detection [FLOW-ACC].
両方の方法がサポートされている場合は、検出速度[FLOW-ACC]のため、インラインデータパス測定が推奨されます。
The following subsections describe suggested techniques for load balancing. Equipment vendors may implement more than one technique, including those not described in this document, and allow the operator to choose between them.
次のサブセクションでは、負荷分散の推奨手法について説明します。機器ベンダーは、このドキュメントに記載されていないものを含む複数の技術を実装し、オペレーターがそれらの中から選択できるようにする場合があります。
Note that regardless of the method used, perfect rebalancing of large flows may not be possible since flows arrive and depart at different times. Also, any flows that are moved from one component link to another may experience momentary packet reordering.
使用される方法に関係なく、フローの到着時刻と出発時刻が異なるため、大きなフローの完全なリバランスができない場合があることに注意してください。また、あるコンポーネントリンクから別のコンポーネントリンクに移動したフローでは、一時的なパケットの並べ替えが発生する可能性があります。
Within a LAG/ECMP group, member component links with the least average link utilization are identified. Some large flow(s) from the heavily loaded component links are then moved to those lightly loaded member component links using a PBR rule in the ingress processing element(s) in the routers.
LAG / ECMPグループ内で、平均リンク使用率が最小のメンバーコンポーネントリンクが識別されます。負荷の高いコンポーネントリンクからのいくつかの大きなフローは、ルーターの入力処理要素のPBRルールを使用して、負荷の軽いメンバーコンポーネントリンクに移動されます。
With this approach, only certain large flows are subjected to momentary flow reordering.
このアプローチでは、特定の大きなフローのみが一時的なフローの並べ替えの対象となります。
Moving a large flow will increase the utilization of the link that it is moved to, potentially once again creating an imbalance in the utilization across the component links. Therefore, when moving a large flow, care must be taken to account for the existing load and the future load after the large flow has been moved. Further, the appearance of new large flows may require a rearrangement of the placement of existing flows.
大きなフローを移動すると、移動先のリンクの使用率が増加し、コンポーネントリンク全体の使用率に不均衡が生じる可能性があります。したがって、大きなフローを移動するときは、大きなフローを移動した後の既存の負荷と将来の負荷を考慮する必要があります。さらに、新しい大きなフローの出現により、既存のフローの配置の再配置が必要になる場合があります。
Consider a case where there is a LAG compromising four 10 Gbps component links and there are four large flows, each of 1 Gbps. These flows are each placed on one of the component links. Subsequently, a fifth large flow of 2 Gbps is recognized, and to maintain equitable load distribution, it may require placement of one of the existing 1 Gbps flow to a different component link. This would still result in some imbalance in the utilization across the component links.
4つの10 Gbpsコンポーネントリンクを危うくするLAGがあり、それぞれが1 Gbpsの4つの大きなフローがある場合を考えます。これらのフローはそれぞれ、コンポーネントリンクの1つに配置されます。その後、2 Gbpsの5番目の大きなフローが認識され、負荷を均等に分散させるには、既存の1 Gbpsフローの1つを別のコンポーネントリンクに配置する必要がある場合があります。これでも、コンポーネントリンク全体の使用率にある程度の不均衡が生じます。
Some large flows may consume the entire bandwidth of the component link(s). In this case, it would be desirable for the small flows to not use the congested component link(s).
一部の大きなフローは、コンポーネントリンクの帯域幅全体を消費する場合があります。この場合、小さなフローが輻輳したコンポーネントリンクを使用しないことが望ましいでしょう。
o The LAG/ECMP table is modified to include only non-congested component link(s). Small flows hash into this table to be mapped to a destination component link. Alternatively, if certain component links are heavily loaded but not congested, the output of the hash function can be adjusted to account for large flow loading on each of the component links.
o LAG / ECMPテーブルは、輻輳していないコンポーネントリンクのみを含むように変更されています。小さなフローはこのテーブルにハッシュされ、宛先コンポーネントリンクにマッピングされます。または、特定のコンポーネントリンクの負荷が高くても混雑していない場合は、ハッシュ関数の出力を調整して、各コンポーネントリンクの大きなフローの負荷を考慮することができます。
o The PBR rules for large flows (refer to Section 4.4.1) must have strict precedence over the LAG/ECMP table lookup result.
o 大きなフローのPBRルール（セクション4.4.1を参照）は、LAG / ECMPテーブルの検索結果よりも厳密に優先する必要があります。
This method works on some existing router hardware. The idea is to prevent, or reduce the probability, that a small flow hashes into the congested component link(s).
この方法は、既存のルーターハードウェアの一部で機能します。アイデアは、小さなフローが輻輳したコンポーネントリンクにハッシュするのを防ぐ、または確率を減らすことです。
With this approach, the small flows that are moved would be subject to reordering.
このアプローチでは、移動された小さなフローは並べ替えの対象になります。
If desired, certain component links may be reserved for link protection. These reserved component links are not used for any flows in the absence of any failures. When there is a failure of one or more component links, all the flows on the failed component link(s) are moved to the reserved component link(s). The mapping table of large flows to component links simply replaces the failed component link with the reserved component link. Likewise, the LAG/ECMP table replaces the failed component link with the reserved component link.
必要に応じて、特定のコンポーネントリンクをリンク保護用に予約できます。これらの予約済みコンポーネントリンクは、障害がない場合、フローには使用されません。 1つ以上のコンポーネントリンクで障害が発生すると、障害が発生したコンポーネントリンク上のすべてのフローが予約済みコンポーネントリンクに移動されます。コンポーネントリンクへの大きなフローのマッピングテーブルは、失敗したコンポーネントリンクを予約済みコンポーネントリンクに置き換えるだけです。同様に、LAG / ECMPテーブルは、障害が発生したコンポーネントリンクを予約済みコンポーネントリンクに置き換えます。
Specific algorithms for placement of large flows are out of the scope of this document. One possibility is to formulate the problem for large flow placement as the well-known bin-packing problem and make use of the various heuristics that are available for that problem [BIN-PACK].
大きなフローを配置するための特定のアルゴリズムは、このドキュメントの範囲外です。 1つの可能性は、大規模なフロー配置の問題をよく知られているビンパッキング問題として定式化し、その問題に利用できるさまざまなヒューリスティックを利用することです[BIN-PACK]。
Optimizing LAG/ECMP component utilization for the use case in Figure 2 is depicted below in Figure 4. The large flow rebalancing explained in Section 4.4.1 is used. The improved link utilization is as follows:
図2のユースケースのLAG / ECMPコンポーネント使用率の最適化を図4に示します。セクション4.4.1で説明した大規模なフローの再調整が使用されます。改善されたリンク使用率は次のとおりです。
o Component link (1) has three flows (two small flows and one large flow), and the link utilization is normal.
o コンポーネントリンク（1）には3つのフロー（2つの小さなフローと1つの大きなフロー）があり、リンクの使用率は正常です。
o Component link (2) has four flows (three small flows and one large flow), and the link utilization is normal now.
o コンポーネントリンク（2）には4つのフロー（3つの小さなフローと1つの大きなフロー）があり、リンクの使用率は現在正常です。
o Component link (3) has three flows (two small flows and one large flow), and the link utilization is normal now.
o コンポーネントリンク（3）には3つのフロー（2つの小さなフローと1つの大きなフロー）があり、リンクの使用率は現在正常です。
+-----------+ -> +-----------+
| | -> | |
| | ===> | |
| (1)|--------|(1) |
| | | |
| | ===> | |
| | -> | |
| | -> | |
| (R1) | -> | (R2) |
| (2)|--------|(2) |
| | | |
| | -> | |
| | -> | |
| | ===> | |
| (3)|--------|(3) |
| | | |
+-----------+ +-----------+
Where: -> small flow
===> large flow
Figure 4: Evenly Utilized Composite Links
図4：均等に利用された複合リンク
Basically, the use of the mechanisms described in Section 4.4.1 resulted in a rebalancing of flows where one of the large flows on component link (3), which was previously congested, was moved to component link (2), which was previously underutilized.
基本的に、セクション4.4.1で説明されているメカニズムを使用すると、以前は輻輳していたコンポーネントリンク（3）の大きなフローの1つが、以前は十分に活用されていなかったコンポーネントリンク（2）に移動されて、フローのリバランスが行われました。 。
In order to support flow rebalancing in a router from an external system, the exchange of some information is necessary between the router and the external system. This section provides an exemplary information model covering the various components needed for this purpose. The model is intended to be informational and may be used as a guide for the development of a data model.
ルーターで外部システムからのフローの再調整をサポートするには、ルーターと外部システムの間で情報の交換が必要です。このセクションでは、この目的に必要なさまざまなコンポーネントをカバーする例示的な情報モデルを提供します。モデルは情報提供を目的としており、データモデル開発のガイドとして使用できます。
The following parameters are required for configuration of this feature:
この機能の構成には、次のパラメーターが必要です。
o Large flow recognition parameters:
o 大きなフロー認識パラメーター：
- Observation interval: The observation interval is the time period in seconds over which packet arrivals are observed for the purpose of large flow recognition.
- 監視間隔：監視間隔は、大規模なフロー認識の目的でパケットの到着が監視される時間（秒単位）です。
- Minimum bandwidth threshold: The minimum bandwidth threshold would be configured as a percentage of link speed and translated into a number of bytes over the observation interval. A flow for which the number of bytes received over a given observation interval exceeds this number would be recognized as a large flow.
- 最小帯域幅のしきい値：最小帯域幅のしきい値は、リンク速度のパーセンテージとして構成され、監視間隔にわたってバイト数に変換されます。特定の監視間隔で受信されたバイト数がこの数を超えるフローは、大きなフローとして認識されます。
- Minimum bandwidth threshold for large flow maintenance: The minimum bandwidth threshold for large flow maintenance is used to provide hysteresis for large flow recognition. Once a flow is recognized as a large flow, it continues to be recognized as a large flow until it falls below this threshold. This is also configured as a percentage of link speed and is typically lower than the minimum bandwidth threshold defined above.
- 大規模フローメンテナンスの最小帯域幅しきい値：大規模フローメンテナンスの最小帯域幅しきい値は、大規模フローの認識にヒステリシスを提供するために使用されます。フローが大きなフローとして認識されると、このしきい値を下回るまで、大きなフローとして認識され続けます。これはリンク速度のパーセンテージとしても構成され、通常は上記で定義された最小帯域幅しきい値よりも低くなります。
o Imbalance threshold: A measure of the deviation of the component link utilizations from the utilization of the overall LAG/ECMP group. Since component links can be different speeds, the imbalance can be computed as follows. Let the utilization of each component link in a LAG/ECMP group with n links of speed b_1, b_2 .. b_n be u_1, u_2 .. u_n. The mean utilization is computed as
o 不均衡のしきい値：LAG / ECMPグループ全体の使用率からのコンポーネントリンク使用率の偏差の測定。コンポーネントリンクは異なる速度になる可能性があるため、不均衡は次のように計算できます。速度b_1、b_2 .. b_nのn個のリンクを持つLAG / ECMPグループ内の各コンポーネントリンクの使用率をu_1、u_2 .. u_nとします。平均利用率は次のように計算されます
u_ave = [ (u_1 * b_1) + (u_2 * b_2) + .. + (u_n * b_n) ] /
[b_1 + b_2 + .. + b_n].
The imbalance is then computed as
次に、不均衡は次のように計算されます
max_{i=1..n} | u_i - u_ave |.
max_ {i = 1..n} | u_i-u_ave |。
o Rebalancing interval: The minimum amount of time between rebalancing events. This parameter ensures that rebalancing is not invoked too frequently as it impacts packet ordering.
o リバランス間隔：リバランスイベント間の最小時間。このパラメーターは、パケットの順序に影響を与えるため、リバランスが頻繁に呼び出されないようにします。
These parameters may be configured on a system-wide basis or may apply to an individual LAG/ECMP group. They may be applied to an ECMP group, provided that the component links are not shared with any other ECMP group.
これらのパラメーターは、システム全体で構成することも、個々のLAG / ECMPグループに適用することもできます。コンポーネントリンクが他のECMPグループと共有されていない場合は、ECMPグループに適用できます。
The following parameters are useful for router configuration and operation when using the mechanisms in this document.
次のパラメータは、このドキュメントのメカニズムを使用する場合のルータの設定と操作に役立ちます。
o IP address: The IP address of a specific router that the feature is being configured on or that the large flow placement is being applied to.
o IPアドレス：機能が構成されている、または大規模なフロー配置が適用されている特定のルーターのIPアドレス。
o LAG ID: Identifies the LAG on a given router. The LAG ID may be required when configuring this feature (to apply a specific set of large flow identification parameters to the LAG) and will be required when specifying flow placement to achieve the desired rebalancing.
o LAG ID：特定のルーターのLAGを識別します。 LAG IDは、（LAGに特定の一連の大規模なフロー識別パラメーターを適用するために）この機能を構成するときに必要になる場合があり、目的のリバランスを実現するためにフロー配置を指定するときに必要になります。
o Component Link ID: Identifies the component link within a LAG or ECMP group. This is required when specifying flow placement to achieve the desired rebalancing.
o コンポーネントリンクID：LAGまたはECMPグループ内のコンポーネントリンクを識別します。これは、フロー配置を指定して目的のリバランスを実現するときに必要です。
o Component Link Weight: The relative weight to be applied to traffic for a given component link when using hash-based techniques for load distribution.
o コンポーネントリンクの重み：負荷分散にハッシュベースの手法を使用する場合に、特定のコンポーネントリンクのトラフィックに適用される相対的な重み。
o ECMP group: Identifies a particular ECMP group. The ECMP group may be required when configuring this feature (to apply a specific set of large flow identification parameters to the ECMP group) and will be required when specifying flow placement to achieve the desired rebalancing. We note that multiple ECMP groups can share an overlapping set (or non-overlapping subset) of component links. This document does not deal with the complexity of addressing such configurations.
o ECMPグループ：特定のECMPグループを識別します。この機能を構成する場合（ECMPグループに特定の大規模なフロー識別パラメーターのセットを適用する場合）にECMPグループが必要になる場合があり、必要なリバランスを実現するためにフロー配置を指定するときに必要になります。複数のECMPグループが、コンポーネントリンクの重複するセット（または重複しないサブセット）を共有できることに注意してください。このドキュメントでは、このような構成への対処の複雑さについては扱いません。
The feature may be configured globally for all LAGs and/or for all ECMP groups, or it may be configured specifically for a given LAG or ECMP group.
この機能は、すべてのLAGおよび/またはすべてのECMPグループに対してグローバルに構成することも、特定のLAGまたはECMPグループに対して特別に構成することもできます。
In cases where large flow recognition is handled by a central management entity (see Section 4.3.3), an information model for flows is required to allow the import of large flow information to the router.
大規模なフロー認識が中央管理エンティティ（セクション4.3.3を参照）によって処理される場合、大規模なフロー情報をルーターにインポートするには、フローの情報モデルが必要です。
Typical fields used for identifying large flows were discussed in Section 4.3.1. The IPFIX information model [RFC7012] can be leveraged for large flow identification.
大きなフローを特定するために使用される一般的なフィールドについては、セクション4.3.1で説明しました。 IPFIX情報モデル[RFC7012]は、大規模なフローの識別に活用できます。
Large flow placement is achieved by specifying the relevant flow information along with the following:
大規模なフロー配置は、関連するフロー情報を以下と共に指定することによって実現されます。
o For LAG: router's IP address, LAG ID, LAG component link ID.
o LAGの場合：ルーターのIPアドレス、LAG ID、LAGコンポーネントリンクID。
o For ECMP: router's IP address, ECMP group, ECMP component link ID.
o ECMPの場合：ルーターのIPアドレス、ECMPグループ、ECMPコンポーネントリンクID。
In the case where the ECMP component link itself comprises a LAG, we would have to specify the parameters for both the ECMP group as well as the LAG to which the large flow is being directed.
ECMPコンポーネントリンク自体がLAGを構成する場合、ECMPグループと、大きなフローが向けられているLAGの両方のパラメーターを指定する必要があります。
Redistribution of small flows is done using the following:
小さなフローの再配布は、次を使用して行われます。
o For LAG: The LAG ID and the component link IDs along with the relative weight of traffic to be assigned to each component link ID are required.
o LAGの場合：LAG IDとコンポーネントリンクID、および各コンポーネントリンクIDに割り当てるトラフィックの相対的な重みが必要です。
o For ECMP: The ECMP group and the ECMP next hop along with the relative weight of traffic to be assigned to each ECMP next hop are required.
o ECMPの場合：ECMPグループとECMPネクストホップ、および各ECMPネクストホップに割り当てられるトラフィックの相対的な重みが必要です。
It is possible to have an ECMP next hop that itself comprises a LAG. In that case, we would have to specify the new weights for both the ECMP component links and the LAG component links.
それ自体がLAGを構成するECMPネクストホップを持つことが可能です。その場合、ECMPコンポーネントリンクとLAGコンポーネントリンクの両方に新しい重みを指定する必要があります。
In the case where an ECMP component link itself comprises a LAG, we would have to specify new weights for both the component links within the ECMP group as well as the component links within the LAG.
ECMPコンポーネントリンク自体がLAGを構成する場合、ECMPグループ内のコンポーネントリンクとLAG内のコンポーネントリンクの両方に新しい重みを指定する必要があります。
Exporting large flow information is required when large flow recognition is being done on a router but the decision to rebalance is being made in a central management entity. Large flow information includes flow identification and the component link ID that the flow is currently assigned to. Other information such as flow QoS and bandwidth may be exported too.
ルーターで大規模フローの認識が行われているが、リバランスの決定が中央管理エンティティで行われている場合、大規模フロー情報のエクスポートが必要です。大きなフロー情報には、フローIDと、フローが現在割り当てられているコンポーネントリンクIDが含まれます。フローQoSや帯域幅などの他の情報もエクスポートされる場合があります。
The IPFIX information model [RFC7012] can be leveraged for large flow identification.
IPFIX情報モデル[RFC7012]は、大規模なフローの識別に活用できます。
The incoming bytes (ifInOctets), outgoing bytes (ifOutOctets), and interface speed (ifSpeed) can be obtained, for example, from the Interfaces table (ifTable) in the MIB module defined in [RFC1213].
着信バイト（ifInOctets）、発信バイト（ifOutOctets）、およびインターフェース速度（ifSpeed）は、たとえば、[RFC1213]で定義されているMIBモジュールのインターフェーステーブル（ifTable）から取得できます。
The link utilization can then be computed as follows:
次に、リンク使用率を次のように計算できます。
Incoming link utilization = (delta_ifInOctets * 8) / (ifSpeed * T)
Outgoing link utilization = (delta_ifOutOctets * 8) / (ifSpeed * T)
Where T is the interval over which the utilization is being measured,
delta_ifInOctets is the change in ifInOctets over that interval, and
delta_ifOutOctets is the change in ifOutOctets over that interval.
For high-speed Ethernet links, the etherStatsHighCapacityTable in the MIB module defined in [RFC3273] can be used.
高速イーサネットリンクの場合、[RFC3273]で定義されているMIBモジュールのetherStatsHighCapacityTableを使用できます。
Similar results may be achieved using the corresponding objects of other interface management data models such as YANG [RFC7223] if those are used instead of MIBs.
MIBの代わりに使用すると、YANG [RFC7223]などの他のインターフェース管理データモデルの対応するオブジェクトを使用して、同様の結果を得ることができます。
For scalability, it is recommended to use the counter push mechanism in [sFlow-v5] for the interface counters. Doing so would help avoid counter polling through the MIB interface.
スケーラビリティのために、インターフェイスカウンターには[sFlow-v5]のカウンタープッシュメカニズムを使用することをお勧めします。そうすることで、MIBインターフェイスを介したカウンターポーリングを回避できます。
The outgoing link utilization of the component links within a LAG/ECMP group can be used to compute the imbalance (see Section 5.1) for the LAG/ECMP group.
LAG / ECMPグループ内のコンポーネントリンクの発信リンク使用率を使用して、LAG / ECMPグループの不均衡（セクション5.1を参照）を計算できます。
Additional monitoring information that is useful includes:
役立つ追加の監視情報は次のとおりです。
o Number of times rebalancing was done.
o リバランスが行われた回数。
o Time since the last rebalancing event.
o 最後のリバランスイベントからの時間。
o The number of large flows currently rebalanced by the scheme.
o スキームによって現在再調整されている大規模なフローの数。
o A list of the large flows that have been rebalanced including
o 再調整された大規模なフローのリスト
- the rate of each large flow at the time of the last rebalancing for that flow,
- そのフローの最後のリバランス時の各大きなフローのレート、
- the time that rebalancing was last performed for the given large flow, and
- 指定された大きなフローに対して最後にリバランスが実行された時間、および
- the interfaces that the large flows was (re)directed to.
- 大きなフローが（再）リダイレクトされたインターフェース。
o The settings for the weights of the interfaces within a LAG/ECMP group used by the small flows that depend on hashing.
o ハッシュに依存する小さなフローで使用されるLAG / ECMPグループ内のインターフェースの重みの設定。
Flows should be rebalanced only when the imbalance in the utilization across component links exceeds a certain threshold. Frequent rebalancing to achieve precise equitable utilization across component links could be counterproductive as it may result in moving flows back and forth between the component links, impacting packet ordering and system stability. This applies regardless of whether large flows or small flows are redistributed. It should be noted that reordering is a concern for TCP flows with even a few packets because three out-of-order packets would trigger sufficient duplicate ACKs to the sender, resulting in a retransmission [RFC5681].
コンポーネントリンク全体の使用率の不均衡が特定のしきい値を超えた場合にのみ、フローのバランスを再調整する必要があります。コンポーネントリンク間で正確な公平な利用を実現するための頻繁なリバランスは、コンポーネントリンク間でフローを前後に移動させ、パケットの順序とシステムの安定性に影響を与える可能性があるため、逆効果になる可能性があります。これは、大きなフローが再配布されるか小さなフローが再配布されるかに関係なく適用されます。順序が乱れている3つのパケットが送信者への十分な重複ACKをトリガーし、結果として再送信が発生するため、数が少ない場合でも、TCPフローでは並べ替えが問題になることに注意してください[RFC5681]。
The operator would have to experiment with various values of the large flow recognition parameters (minimum bandwidth threshold, minimum bandwidth threshold for large flow maintenance, and observation interval) and the imbalance threshold across component links to tune the solution for their environment.
オペレーターは、大規模なフロー認識パラメーター（最小帯域幅しきい値、大規模なフローメンテナンスの最小帯域幅しきい値、観測間隔）のさまざまな値と、コンポーネントリンク全体の不均衡しきい値を実験して、ソリューションを環境に合わせて調整する必要があります。
Large flow rebalancing must be aware of any changes to the Forwarding Information Base (FIB). In cases where the next hop of a route no longer to points to the LAG or to an ECMP group, any PBR entries added as described in Sections 4.4.1 and 4.4.2 must be withdrawn in order to avoid the creation of forwarding loops.
大規模なフローの再調整では、転送情報ベース（FIB）への変更を認識する必要があります。ルートのネクストホップがLAGまたはECMPグループをポイントしない場合、転送ループの作成を回避するために、セクション4.4.1および4.4.2で説明されているように追加されたPBRエントリを撤回する必要があります。
Hash-based techniques used for load balancing with LAG/ECMP are usually stateless. The mechanisms described in this document require additional resources in the forwarding plane of routers for creating PBR rules that are capable of overriding the forwarding decision from the hash-based approach. These resources may limit the number of flows that can be rebalanced and may also impact the latency experienced by packets due to the additional lookups that are required.
LAG / ECMPを使用したロードバランシングに使用されるハッシュベースのテクニックは、通常ステートレスです。このドキュメントで説明されているメカニズムでは、ハッシュベースのアプローチからの転送の決定を上書きできるPBRルールを作成するために、ルーターの転送プレーンに追加のリソースが必要です。これらのリソースは、リバランスできるフローの数を制限する可能性があり、必要な追加のルックアップが原因でパケットが経験する遅延にも影響を与える可能性があります。
This document does not directly impact the security of the Internet infrastructure or its applications. In fact, it could help if there is a DoS attack pattern that causes a hash imbalance resulting in heavy overloading of large flows to certain LAG/ECMP component links.
このドキュメントは、インターネットインフラストラクチャまたはそのアプリケーションのセキュリティには直接影響しません。実際、ハッシュの不均衡を引き起こし、特定のLAG / ECMPコンポーネントリンクへの大きなフローの過負荷を引き起こすDoS攻撃パターンがある場合に役立ちます。
An attacker with knowledge of the large flow recognition algorithm and any stateless distribution method can generate flows that are distributed in a way that overloads a specific path. This could be used to cause the creation of PBR rules that exhaust the available PBR rule capacity on routers in the network. If PBR rules are consequently discarded, this could result in congestion on the attacker-selected path. Alternatively, tracking large numbers of PBR rules could result in performance degradation.
大規模なフロー認識アルゴリズムと任意のステートレス分散方法の知識を持つ攻撃者は、特定のパスを過負荷にする方法で分散されるフローを生成できます。これは、ネットワーク内のルーターで利用可能なPBRルールの容量を使い果たすPBRルールの作成を引き起こすために使用できます。その結果、PBRルールが破棄されると、攻撃者が選択したパスで輻輳が発生する可能性があります。または、多数のPBRルールを追跡すると、パフォーマンスが低下する可能性があります。
[802.1AX] IEEE, "IEEE Standard for Local and metropolitan area networks - Link Aggregation", IEEE Std 802.1AX-2008, 2008.
[802.1AX] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Link Aggregation」、IEEE Std 802.1AX-2008、2008。
[RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and Multicast Next-Hop Selection", RFC 2991, November 2000, <http://www.rfc-editor.org/info/rfc2991>.
[RFC2991] Thaler、D。およびC. Hopps、「Multipath Issues in Unicast and Multicast Next-Hop Selection」、RFC 2991、2000年11月、<http://www.rfc-editor.org/info/rfc2991>。
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, September 2013, <http://www.rfc-editor.org/info/rfc7011>.
[RFC7011] Claise、B。、編、Trammell、B。、編、およびP. Aitken、「フロー情報の交換のためのIPフロー情報エクスポート（IPFIX）プロトコルの仕様」、STD 77、RFC 7011、 2013年9月、<http://www.rfc-editor.org/info/rfc7011>。
[RFC7012] Claise, B., Ed., and B. Trammell, Ed., "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, September 2013, <http://www.rfc-editor.org/info/rfc7012>.
[RFC7012] Claise、B。、編、およびB. Trammell、編、「IPフロー情報エクスポート（IPFIX）の情報モデル」、RFC 7012、2013年9月、<http://www.rfc-editor.org / info / rfc7012>。
[BIN-PACK] Coffman, Jr., E., Garey, M., and D. Johnson. "Approximation Algorithms for Bin-Packing -- An Updated Survey" (in "Algorithm Design for Computer System Design"), Springer, 1984.
[BIN-PACK]コフマンJr.、E。、ギャレイM.、D。ジョンソン。 「ビンパッキングの近似アルゴリズム-更新された調査」（「コンピュータシステム設計のアルゴリズム設計」）、Springer、1984年。
[CAIDA] "Caida Traffic Analysis Research", <http://www.caida.org/research/traffic-analysis/>.
[CAIDA]「Caida Traffic Analysis Research」、<http://www.caida.org/research/traffic-analysis/>。
[DEVOFLOW] Mogul, J., Tourrilhes, J., Yalagandula, P., Sharma, P., Curtis, R., and S. Banerjee, "DevoFlow: Cost-Effective Flow Management for High Performance Enterprise Networks", Proceedings of the ACM SIGCOMM, 2010.
[DEVOFLOW] Mogul、J.、Tourrilhes、J.、Yalagandula、P.、Sharma、P.、Curtis、R。、およびS. Banerjee、「DevoFlow：High-Effective Flow Management for High Performance Enterprise Networks」、Proceedings of ACM SIGCOMM、2010。
[FLOW-ACC] Zseby, T., Hirsch, T., and B. Claise, "Packet Sampling for Flow Accounting: Challenges and Limitations", Proceedings of the 9th international Passive and Active Measurement Conference, 2008.
[FLOW-ACC] Zseby、T.、Hirsch、T。、およびB. Claise、「フローアカウンティングのためのパケットサンプリング：課題と制限」、第9回国際パッシブおよびアクティブ測定会議の議事録、2008年。
[ITCOM] Jo, J., Kim, Y., Chao, H., and F. Merat, "Internet traffic load balancing using dynamic hashing with flow volume", SPIE ITCOM, 2002.
[ITCOM] Jo、J.、Kim、Y.、Chao、H.、F。Merat、「フローボリュームを使用した動的ハッシュを使用したインターネットトラフィックの負荷分散」、SPIE ITCOM、2002年。
[NDTM] Estan, C. and G. Varghese, "New Directions in Traffic Measurement and Accounting", Proceedings of ACM SIGCOMM, August 2002.
[NDTM] Estan、C.およびG. Varghese、「Traffic Measurement and Accountingの新しい方向」、ACM SIGCOMMの議事録、2002年8月。
[NVGRE] Garg, P. and Y. Wang, "NVGRE: Network Virtualization using Generic Routing Encapsulation", Work in Progress, draft-sridharan-virtualization-nvgre-07, November 2014.
[NVGRE] Garg、P。およびY. Wang、「NVGRE：Generic Routing Encapsulationを使用したネットワーク仮想化」、作業中、draft-sridharan-virtualization-nvgre-07、2014年11月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000, <http://www.rfc-editor.org/info/rfc2784>.
[RFC2784] Farinacci、D.、Li、T.、Hanks、S.、Meyer、D。、およびP. Traina、「Generic Routing Encapsulation（GRE）」、RFC 2784、2000年3月、<http：// www。 rfc-editor.org/info/rfc2784>。
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, November 2012, <http://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、November 2012、<http：// www.rfc-editor.org/info/rfc6790>。
[RFC1213] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, March 1991, <http://www.rfc-editor.org/info/rfc1213>.
[RFC1213] McCloghrie、K。およびM. Rose、「TCP / IPベースのインターネットのネットワーク管理のための管理情報ベース：MIB-II」、STD 17、RFC 1213、1991年3月、<http：//www.rfc- editor.org/info/rfc1213>。
[RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path Algorithm", RFC 2992, November 2000, <http://www.rfc-editor.org/info/rfc2992>.
[RFC2992] Hopps、C。、「Analysis of an Equal-Cost Multi-Path Algorithm」、RFC 2992、2000年11月、<http://www.rfc-editor.org/info/rfc2992>。
[RFC3273] Waldbusser, S., "Remote Network Monitoring Management Information Base for High Capacity Networks", RFC 3273, July 2002, <http://www.rfc-editor.org/info/rfc3273>.
[RFC3273] Waldbusser、S。、「大容量ネットワーク用のリモートネットワーク監視管理情報ベース」、RFC 3273、2002年7月、<http://www.rfc-editor.org/info/rfc3273>。
[RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005, <http://www.rfc-editor.org/info/rfc3931>.
[RFC3931] Lau、J。、編、Townsley、M。、編、I。Goyret、編、「Layer Two Tunneling Protocol-Version 3（L2TPv3）」、RFC 3931、2005年3月、<http：/ /www.rfc-editor.org/info/rfc3931>。
[RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export Version 9", RFC 3954, October 2004, <http://www.rfc-editor.org/info/rfc3954>.
[RFC3954] Claise、B。、編、「Cisco Systems NetFlow Services Export Version 9」、RFC 3954、2004年10月、<http://www.rfc-editor.org/info/rfc3954>。
[RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture for IP Flow Information Export", RFC 5470, March 2009, <http://www.rfc-editor.org/info/rfc5470>.
[RFC5470] Sadasivan、G.、Brownlee、N.、Claise、B。、およびJ. Quittek、「Architecture for IP Flow Information Export」、RFC 5470、2009年3月、<http://www.rfc-editor.org / info / rfc5470>。
[RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. Raspall, "Sampling and Filtering Techniques for IP Packet Selection", RFC 5475, March 2009, <http://www.rfc-editor.org/info/rfc5475>.
[RFC5475] Zseby、T.、Molina、M.、Duffield、N.、Niccolini、S。、およびF. Raspall、「IPパケット選択のためのサンプリングおよびフィルタリング技術」、RFC 5475、2009年3月、<http：// www.rfc-editor.org/info/rfc5475>。
[RFC5640] Filsfils, C., Mohapatra, P., and C. Pignataro, "Load-Balancing for Mesh Softwires", RFC 5640, August 2009, <http://www.rfc-editor.org/info/rfc5640>.
[RFC5640] Filsfils、C.、Mohapatra、P。、およびC. Pignataro、「メッシュソフトワイヤーのロードバランシング」、RFC 5640、2009年8月、<http://www.rfc-editor.org/info/rfc5640> 。
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, September 2009, <http://www.rfc-editor.org/info/rfc5681>.
[RFC5681] Allman、M.、Paxson、V。、およびE. Blanton、「TCP Congestion Control」、RFC 5681、2009年9月、<http://www.rfc-editor.org/info/rfc5681>。
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 7223, May 2014, <http://www.rfc-editor.org/info/rfc7223>.
[RFC7223] Bjorklund、M。、「A YANG Data Model for Interface Management」、RFC 7223、2014年5月、<http://www.rfc-editor.org/info/rfc7223>。
[RFC7226] Villamizar, C., Ed., McDysan, D., Ed., Ning, S., Malis, A., and L. Yong, "Requirements for Advanced Multipath in MPLS Networks", RFC 7226, May 2014, <http://www.rfc-editor.org/info/rfc7226>.
[RFC7226] Villamizar、C.、Ed。、McDysan、D.、Ed。、Ning、S.、Malis、A.、and L. Yong、 "Requirements for Advanced Multipath in MPLS Networks"、RFC 7226、May 2014、 <http://www.rfc-editor.org/info/rfc7226>。
[SAMP-BASIC] Phaal, P. and S. Panchen, "Packet Sampling Basics", <http://www.sflow.org/packetSamplingBasics/>.
[Sump-basic]秋、p。そしてs。 Panchem、「Packet Sampling Basics」、<http://www.sflou.org/packetSamplingBasics/>。
[sFlow-v5] Phaal, P. and M. Lavine, "sFlow version 5", July 2004, <http://www.sflow.org/sflow_version_5.txt>.
[Sflou-v౫]秋、p。 M. Livin、「Sflow Version 1」、2009年7月、<http://www.sflow.org/sflow_version_3.trust>。
[sFlow-LAG] Phaal, P. and A. Ghanwani, "sFlow LAG Counters Structure", September 2012, <http://www.sflow.org/sflow_lag.txt>.
[Sphawl-lag]秋、p。そしてそれ。 Ghanwani、「Sflau Lug Counters Structure」、2010年9月、http：//www.sflau.org/sflau_lug.trust>。
[STT] Davie, B., Ed., and J. Gross, "A Stateless Transport Tunneling Protocol for Network Virtualization (STT)", Work in Progress, draft-davie-stt-06, April 2014.
[STT] Davie、B.、Ed。、およびJ. Gross、「A Stateless Transport Tunneling Protocol for Network Virtualization（STT）」、Work in Progress、draft-davie-stt-06、2014年4月。
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, August 2014, <http://www.rfc-editor.org/info/rfc7348>.
[RFC7348] Mahalingam、M.、Dutt、D.、Duda、K.、Agarwal、P.、Kreeger、L.、Sridhar、T.、Bursell、M。、およびC. Wright、「Virtual eXtensible Local Area Network（ VXLAN）：A Layer over Overlayed Virtualized Layer 2 Networks over Layer 3 Networks」、RFC 7348、2014年8月、<http://www.rfc-editor.org/info/rfc7348>。
[YONG] Yong, L. and P. Yang, "Enhanced ECMP and Large Flow Aware Transport", Work in Progress, draft-yong-pwe3-enhance-ecmp-lfat-01, March 2010.
[YONG] Yong、L.、P。Yang、「Enhanced ECMP and Large Flow Aware Transport」、Work in Progress、draft-yong-pwe3-enhance-ecmp-lfat-01、2010年3月。
Internet traffic [CAIDA] has been analyzed to obtain flow statistics such as the number of packets in a flow and the flow duration. The 5-tuple in the packet header (IP source address, IP destination address, transport protocol source port number, transport protocol destination port number, and IP protocol) is used for flow identification. The analysis indicates that < ~2% of the flows take ~30% of total traffic volume while the rest of the flows (> ~98%) contributes ~70% [YONG].
インターネットトラフィック[CAIDA]は、フロー内のパケット数やフロー期間などのフロー統計を取得するために分析されています。パケットヘッダーの5タプル（IP送信元アドレス、IP宛先アドレス、トランスポートプロトコル送信元ポート番号、トランスポートプロトコル宛先ポート番号、およびIPプロトコル）は、フローの識別に使用されます。分析によると、フローの<〜2％は総トラフィック量の〜30％を占め、残りのフロー（>〜98％）は〜70％[YONG]を占めています。
The simulation has shown that, given Internet traffic patterns, the hash-based technique does not evenly distribute flows over ECMP paths. Some paths may be > 90% loaded while others are < 40% loaded. The greater the number of ECMP paths, the more severe is the imbalance in the load distribution. This implies that hash-based distribution can cause some paths to become congested while other paths are underutilized [YONG].
シミュレーションでは、インターネットトラフィックパターンが与えられた場合、ハッシュベースの手法ではフローがECMPパスに均等に分散されないことがわかりました。一部のパスが90％を超えてロードされている場合と、40％未満がロードされている場合があります。 ECMPパスの数が多いほど、負荷分散の不均衡が深刻になります。これは、ハッシュベースの配布により、一部のパスが混雑する一方で、他のパスが十分に活用されないことを意味します[YONG]。
The simulation also shows substantial improvement by using the large flow-aware, hash-based distribution technique described in this document. In using the same simulated traffic, the improved rebalancing can achieve < 10% load differences among the paths. It proves how large flow-aware, hash-based distribution can effectively compensate the uneven load balancing caused by hashing and the traffic characteristics [YONG].
シミュレーションはまた、このドキュメントで説明されている大規模なフロー対応のハッシュベースの分散手法を使用することにより、大幅な改善を示しています。同じシミュレートされたトラフィックを使用する場合、改善されたリバランスにより、パス間で10％未満の負荷差を達成できます。大規模なフロー対応のハッシュベースの分散が、ハッシュとトラフィック特性によって引き起こされる不均一なロードバランシングを効果的に補償できることを証明します[YONG]。
Acknowledgements
謝辞
The authors would like to thank the following individuals for their review and valuable feedback on earlier versions of this document: Shane Amante, Fred Baker, Michael Bugenhagen, Zhen Cao, Brian Carpenter, Benoit Claise, Michael Fargano, Wes George, Sriganesh Kini, Roman Krzanowski, Andrew Malis, Dave McDysan, Pete Moyer, Peter Phaal, Dan Romascanu, Curtis Villamizar, Jianrong Wong, George Yum, and Weifeng Zhang. As a part of the IETF Last Call process, valuable comments were received from Martin Thomson and Carlos Pignataro.
著者は、このドキュメントの以前のバージョンに対するレビューと貴重なフィードバックを提供してくれた次の個人に感謝します。 Krzanowski、Andrew Malis、Dave McDysan、Pete Moyer、Peter Phaal、Dan Romascanu、Curtis Villamizar、Jianrong Wong、George Yum、Weifeng Zhang。 IETF Last Callプロセスの一環として、Martin ThomsonとCarlos Pignataroから貴重なコメントが寄せられました。
Contributors
貢献者
Sanjay Khanna Cisco Systems EMail: sanjakha@gmail.com
Sanjay Khanna Cisco Systems EMail：sanjakha@gmail.com
Authors' Addresses
著者のアドレス
Ram Krishnan Brocade Communications San Jose, CA 95134 United States Phone: +1-408-406-7890 EMail: ramkri123@gmail.com
Ram Krishnan Brocade Communications San Jose、CA 95134 United States電話：+ 1-408-406-7890メール：ramkri123@gmail.com
Lucy Yong Huawei USA 5340 Legacy Drive Plano, TX 75025 United States Phone: +1-469-277-5837 EMail: lucy.yong@huawei.com
Lucy Yong Huawei USA 5340 Legacy Drive Plano、TX 75025 United States電話：+ 1-469-277-5837メール：lucy.yong@huawei.com
Anoop Ghanwani Dell 5450 Great America Pkwy Santa Clara, CA 95054 United States Phone: +1-408-571-3228 EMail: anoop@alumni.duke.edu
Anoop Ghanwani Dell 5450 Great America Pkwy Santa Clara、CA 95054 United States電話：+ 1-408-571-3228メール：anoop@alumni.duke.edu
Ning So Vinci Systems 2613 Fairbourne Cir Plano, TX 75093 United States EMail: ningso@yahoo.com
Ning So Vinci Systems 2613 Fairbourne Cir Plano、TX 75093アメリカ合衆国Eメール：ningso@yahoo.com
Bhumip Khasnabish ZTE Corporation New Jersey 07960 United States Phone: +1-781-752-8003 EMail: vumip1@gmail.com
Bhumip Khasnabish ZTE Corporationニュージャージー07960米国電話：+ 1-781-752-8003 Eメール：vumip1@gmail.com