トラフィックのバランスをとるさまざまなアプローチ

今日のMPLSテクノロジーは、通信事業者のネットワークを構築するための事実上の標準となっています。 初期開発の一部の参加者は、作業がルーティング決定を行うプロセスを簡素化するために固定長ヘッダーを持つプロトコルを取得することを目的としていたと主張しますが、この意味で革命的な変更はなく、スイッチングチップのハードウェア実装の出現後、パフォーマンスの問題はバックグラウンドに後退しました。 しかし、標準が筋肉で大きくなりすぎたため、後にスタックと呼ばれるいくつかのラベルを使用すると、サービスを提供および提供するための統一された方法を備えたテクノロジーとしてMPLSを見ることができることが明らかになりました。 そのため、スタック上のラベルは条件付きでサービスとトランスポートに分割されます。 大規模なネットワークの場合、これでは十分ではなく、すぐに独自のトランスポートラベルの階層が現れました。 一般に、中継ルーターは、送信しているサービスの種類を理解する義務はありません。最も一般的な意味でのタスクは、階層の最上位ラベルでの作業に限定され、スタック内にあるものはまったく関係ありません。 このアプローチにより、中継ルーターは数十万、さらには数百万もの異なるサービスのフローのトラフィックを送信できます。



「分割統治」ルールは完璧に機能しますが、分割して通信することはあまり効果的ではありませんでした。つまり、限られた数の通信チャネル内で、ゆとりのある力でできるだけ均等にトラフィックのバランスを取りたいという意味で、変更、ハードウェアソリューション。 この記事では、この問題を解決するためのさまざまな方法のいくつかの側面を見つけます。



LDPは 、一見すると、ホップバイホップの宛先ベースのルーティングパラダイムとともに、IGPのECMP機能を継承しますが、同時に、IPの世界に固有のバランシング機能の一部が継承されます。 IPルーターは、パケット内で使い慣れているもの（ネットワークおよびトランスポート層の潜在的に高いエントロピーヘッダー）を確認します。 それらは簡単に分解でき、多数のフローがあるため、分布は非常に均一に見えます。 MPLSの世界でこの規則を適用する複雑さは、スタック内を見る中継LSRが常にそこにIPパケットを見つけるとは限らないことです。多くの場合、トランスポートラベルの下に、VPNv4、Labeled Unicast、VPWS、VPLSまたはEVPNなどのエントロピーの低いサービスパケットがあります、したがって、ラベルスタック全体、さらにはスタックに詰め込まれたパケット/フレームの中継ルーターによる検査など、このような奇妙なアイデアが必要になりました。 スイッチングチップが必要な深さのスタックでこれを行うことができる場合-まあ、バランスが取れていない場合は、一方が他方の機能に対応していないため、スタックの充填（ネットワーク設計）またはスイッチングチップのいずれかを変更する必要があります



スタック全体を検査する必要性に関連する問題は、別の方法で解決できます。 これを行うには、サービス提供の時点で、エントロピーを増加させるラベルがスタックに追加されます。 Flow Aware TransportおよびEntropy Labelの標準はほぼその通りですが、エネルギー保存の法則により、中継ルーターの要件を下げることで、標準は境界ルーターの要件を増やします。 どのスイッチングチップでも、プッシュ操作を有限回数実行できます。 トランスポートおよびサービスタグに加えて、1パスで1〜2個のエントロピーラベルをスタックに配置する必要があります。これはすべてのチップで取得されるわけではなく、すべてのケースで取得されるわけではないため、LDPドメインでのMPLSトラフィックのバランスの効率は、スイッチングチップのハードウェア実装、スタックの長さ、およびサイズに依存しますエントロピー。



分散RSVP-TEは、まったく異なる方法でバランシングの問題を解決します。 ここでの分布の均一性は、中継ルーターの能力に大きく依存するのではなく、境界ルーターによる最適化問題を解決する品質に依存します。それぞれの境界ルーターは、チャネルの現在の利用レベルとトラフィック特性を考慮して、隣接ルータへのパスを計算します。 計算が成功すると、ルーターは隣接ルータに通知して、対応するチャネルの帯域の一部を予約し、新しいパスの使用を開始します。 「if」という言葉は偶然に書かれたものではありません。実際、この問題の解決策は、入力データとシステムの動的状態に大きく依存します。 各ルーターが道を切り開き、それ自体の希望だけを考慮して、グローバルな最適化はほとんど達成できません。 ルーターは、セットアップとホールドの優先順位を使用してのみ、既に確立されたパスに影響を与えることができます。優先順位付けは簡単なタスクではなく、ソリューションへのいくつかのアプローチがあります（帯域ごとの優先順位、トラフィックのタイプごとの優先順位など）。 各アプローチには狭い目標があり、このプロセス用の自動化ツールがないため、従来のRSVP-TEは、普遍的な適用性を備えたシンプルなテクノロジーとはほとんど言えません。 ネットワークに多くのノードがなく、一部のパスのストリップがチャネル容量に近い場合、断片化された使用率のネットワークを簡単に取得できます。 したがって、実際には、複数の並列パスを計算するか、サービスの異なるタイプとインスタンスにルーター間の複数のパスが使用されている場合、サービストランスポートプレーンアプローチを使用することにより、パスの過度の肥大化が通常回避されます。 これにより、チャネルをより均等に埋めることができ、トラックを正常にインストールできる可能性が高くなりますが、かなりの量の手動作業が必要になります。 RSVP-TEの機能を過小評価していませんが、このアプローチには単純さが欠けていると思います。



集中型RSVP-TEはSDN道路に沿った明るい未来への一歩です。視界が限られている状況でのローカルパス計算ではなく、MPLSドメイン全体を完全に見るスマートコントローラーが表示されます。 コントローラーは、既存のパスのルートを変更する必要がある場合でも最適なパスを計算できます。たとえば、それらを再グループ化したり、ストリップの一部を解放したりします。 計算後、コントローラーはPCEPプロトコルを使用して結果をルーターに報告し、ルーターはネットワーク状態をシームレスに再構築します。 エリア間パスの問題は最終的にここで解決できます。コントローラは、BGPリンクステートNLRIを使用して、すべてのネットワークセグメントからTE情報を受信できます。 現時点では、PCEコントローラーの実装がいくつかあるテクノロジーの開発を観察するのは素晴らしいことですが、PCEをサポートするルーターモデルの選択により、事態はより複雑になりますが、メーカーはこの方法のサポートを急いで追加する必要はありません。



一元化されたSPRING-TEは 、リストされている最も機能的で、柔軟でスケーラブルなアプローチである可能性があります。このソリューションは、コントローラーをより厳密に使用します。 この場合のラベルスタックは、中継ルーターの指示として機能します。 何らかの方法でパスを受信すると、入力デバイスは異なるスタックコンテンツを使用してトラフィックフローを分割し、中継ルーターは単純なスワップ/ポップ操作のみを実行します。 スタックを長い命令セットで満たすと、スイッチングチップのハードウェア実装に疑問が生じる可能性があることを考えると、集中SPRING-TEのアイデアは、スタックへのラベルのロードがそれほど厳しく制限されていないmpls対応サーバーを備えたDC環境で非常に調和しているように見えます。 現時点では、帯域予約メカニズムに関する一般的な意見はまだ開発されていません。 これが近い将来に実装されるかどうかはまだ明確ではありません;この方向での開発は進行中です。



マルチパスLSP 少し前に、悪名高いKireeti KompellaはRSVP-TEとECMPバランシングを組み合わせようとしました。 それはかなり興味深いドラフトであることが判明しました[RSVP-TEを使用してシグナリングされるマルチパスラベルスイッチドパス]。 この方法の本質は、空気を抜いた風船を空のポットに入れる方法について、ロバ・エイヨーというフレーズで正確に説明されています。 1つの太い入力パスをシグナリングする代わりに、ルーターはレーン要求の少ないパス（サブLSP）を計算します。 このプロセスでは、チャネルとそのトポロジの現在の使用率によって、サブLSPの数とそれらに予約されている帯域が決まります。 サブLSPのタイプに応じて、トラフィックはすべてのパス間で、または予約帯域に従って均等に分散できます。 2番目の場合、パスを選択する決定は入力ルーターのみにあるため、中継ノードのスイッチングチップに重大な要件は課されません。 このアプローチは、エンジニアや大規模なコントローラーの特別な手動作業なしで比較的控えめなトランジットネットワークに実装できるため、非常に便利です。ドラフトとその実装の詳細については、次の記事で説明します。