JP2008530858A - ネットワーク・ルーティングを改良するためのイーサネット系のシステムおよび方法 - Google Patents

Abstract

インターネット・プロトコル（ＩＰ）・トラフィックを送信元サイトと宛先サイトとの間においてルーティングするイーサネット系のネットワーク。一実施例においては、送信元サイトと宛先サイトとの間に、データ伝送のための複数の離散的なバックボーンが設けられる。送信元サイトには、その送信元サイトにおけるＩＰトラフィックを宛先サイトに伝送するために、前記ＩＰトラフィックを前記複数のバックボーンに分散させるコントロール手段が設けられる。
【選択図】

Description

関連出願の参照

本出願は、「ネットワーク・ルーティングを改良するためのシステムおよび方法」を発明の名称として２００５年２月４日に出願された米国仮出願第６０／６５０，３１２号の利益を主張する出願であり、その仮出願はすべて本明細書に組み込まれる。

本発明は、概略的には、ネットワーク・ルーティングに関し、より具体的には、ＩＰ（インターネット・プロトコル）ネットワークのエッジおよびコア・バックボーン内においてＩＰトラフィックをルーティングするためのイーサネット（登録商標）系のシステムおよび方法に関する。

高速インターネットの価格は低下を続けているが、そのネットワークを保守するとともに動作させるための基本的なコストは比較的高いままである。ユニットのコストを高く維持する主な要因の１つに、テラビットＭＰＬＳバックボーン・ルータのコスト高がある。よって、帯域要求が増えるにつれて、コストも同様に増える可能性がある。したがって、ネットワーク・アーキテクチャをより費用効果的に拡張する（すなわち、帯域キャパシティを増加させる）手法が必要である。

それらネットワークをより低コストで拡張する手法の一つに、高価なルータが現在果たしている機能を果たすために、イーサネット・スイッチのネットワークすなわちマトリクスを利用する手法がある。イーサネット・スイッチ・マトリクスは、ネットワーク・バックボーンのエッジにおけるギガビット・アクセス・ルータに代えて使うのみならず、テラビットＭＰＬＳバックボーン・ルータに代えて使うことが可能である。イーサネット・スイッチ・マトリクスを使用することにより、ユニットのコストを低下させることが可能である。

新しいシステムをデザインしてインプリメントする場合にはコストが懸念されるが、スケーラビリティ（すなわち、帯域要求に合わせて増強する能力）も懸念される。実際に、要求が著しく増加することを予測している者が存在する。したがって、ネットワークを合理的なコストで拡張する能力は非常に重要となる。

それらの問題を解決するため、これまでに３つのシステムが開発されてきた。それらシステムは、費用効果的であり、かつ、スケーラブルであるコア・バックボーン・ネットワークおよび／またはエッジ・ネットワークを形成するため、個別にまたは一緒に利用することが可能である。それらシステムは、マルチシャーシ・イーサネット・ルータ（「ＭＥＲ」）と、複数のパラレル・バックボーン構成（「Ｎ×ＢＢ」）と、中央ＬＡＮ（ＬＡＮインザミドル「ＬＩＭ」）構成とを含む。

マルチシャーシ・イーサネット・ルータ（ＭＥＲ）

一実施例においては、ＭＥＲが、複数個のイーサネット・スイッチからなるマルチステージＣＬＯＳマトリクス（例えば、３ステージ）・ルータを含む。そのＭＥＲは、トラフィック負荷を複数のスイッチ・ステージにわたって分散させるために複数のＩＰプロトコルを利用する。このデザインは、既存の技術を増強するが、別のイーサネット・スイッチ、別のステージ、それらの併用、または新規で安価なＭＥＲを追加することにより、スケーラビリティを可能にする。

図１は、本発明の一実施例に従う３ステージＭＥＲの一実施例を示す線図である。本実施例においては、ＭＥＲが、３ステージの各々において、４個のイーサネット・スイッチを使用する。また、別のスイッチまたはステージを付加することが可能である。

本実施例においては、図１に矢印で示すように、Ｌ３４からの出力が予定されるトラフィックは、Ｌ１１に到達する。Ｌ１１は、１または複数の負荷均等化（load balancing）方法すなわち負荷分散（load distribution）方法を用いて、そのトラフィックを、Ｌ２１−Ｌ２４に等しく分散させる。Ｌ２１−Ｌ２４は、トラフィックをＬ３４に伝送し、Ｌ３４はそのフローを結合して必要なリンクへ送出する。

このデザインは、スケールを大幅に増大させる。例えば、図示された実施例においては、４×ＭＥＲが、ノードサイズを４倍に増加させる。３ステージのファブリック（fabric）である場合の増加の限度は、ｎ^２／２であり、ここに、ｎは各ステージにおいて使用されるスイッチの数を表す。５ステージ・マトリクスおよび７ステージ・マトリクスによれば、スケーラビリティがさらに向上する。

ＣＬＯＳマトリクスは既知であるが、ＣＬＯＳマトリクスは、これまで、イーサネット・スイッチのネットワークにおいてインプリメントされてきておらず、これを実現するのが本実施例である。さらに、非常に高価なＭＰＬＳルータにおいて一般的にインプリメントされるＣＬＯＳマトリクスは、プロプリエタリ（独自）なソフトウエアを用いてインプリメントされるとともに、１つのボックス内に収容される。本実施例においては、複数個の安価なイーサネット・スイッチがマトリクスを形成し、また、プロプリエタリ（独自）なソフトウエアではなく、複数のＩＰプロトコルを利用してＣＬＯＳディストリビューションがインプリメントされる。

さらに、本実施例においては、ＣＬＯＳマトリクスが、１つの装置内にインプリメントされるのではなく、前記複数個のスイッチの各ホップにおいてインプリメントされる。別の実施例においては、他のいくつかのプロトコルを利用することが可能である。

それら複数個のイーサネット・スイッチを相互に接続した後、フロー重視型（flow based)負荷均等化により、パケットおよび／またはパケット・セルを、前記マトリクスにおいて互いに異なる複数のステージに分散させることが可能である。その負荷均等化技術をインプリメントするため、内部ゲートウェイ・プロトコル（「ＩＧＰ」）を利用することが可能である。

いくつかの実施例においては、ＭＥＲが、宛先に関連付けられた第３ステージのボックス（すなわち、Ｌ３１、Ｌ３２、Ｌ３３およびＬ３４）の各々が、同量のトラフィックを受信するように、等コスト（equal cost）負荷均等化を利用することが可能である。例えば、Ｌ１、Ｌ２およびＬ３のすべてのボックスがニューヨークに通じている場合には、各ボックスは、同量のトラフィックを受信することになる。この技術は、複数の新規のＭＥＲをインプリメントする場合において、インプリメントが比較的容易であるとともに、うまく拡張することができる。

別の実施例においては、最もビジーではないスイッチにパケットを送信するトラフィック・エンジニアリング技術（例えば、ＭＰＬＳトラフィック・エンジニアリング）等の帯域対応型（bandwidth aware）負荷均等化技術を利用してＭＥＲにおけるトラフィックを分散させることが可能である。ある実施例においては、中間層が、トラフィック・エンジニアリング機能を果たし、これにより、インテリジェントなルーティング決定を行うことが可能である。

さらに別の実施例においては、何がダウンストリーム・トラフィック要求である可能性があるかを判断するため、中間層（すなわち、Ｌ２１、Ｌ２２、Ｌ２３およびＬ２４）においてトラフィック対応型（traffic awareness）技術を利用することが可能である。すなわち、その中間層は、第３層すなわち最終層にある要求を判断した後、キャパシティ要求に応じてルーティングを決定することが可能である。この実施例においては、その中間層が、トラフィック・エンジニアリング・トンネル（例えば、ＭＰＬＳトンネル）または第２層のＶＬＡＮＳを経由して、最終層（例えば、第３層）からの要求すなわちキャパシティ情報を受信することが可能である。

これに代えて、帯域幅情報を中間層に伝えるように、ＩＧＰへの変更を増強することが可能である。例えば、スイッチＬ３１は、３０Ｇｂのトラフィックでニューヨークと接続されていることを中間層に伝える（例えば、ＩＧＰまたは他のプロトコルにより）ことが可能である。中間層は、ＭＥＲを負荷に関して均等化するため、このプロトコル情報を他の複数個のスイッチからの情報に加えて利用することが可能である。

別の実施例においては、ＭＥＲのインプリメンテーションが、コントロール・ボックスまたはルート・リフレクタを用いてＭＥＲを管理することが可能である。いくつかの実施例においては、そのルート・リフレクタまたはコントロール・ボックスが、ルーティング・プロトコルへの参加またはコントロール、ルーティング統計の保存、ＭＥＲに関する問題の原因究明、ルーティング・プロトコルのスケーリング等を実施することが可能である。

一実施例においては、ルート・リフレクタがルーティング・プロトコルをインプリメントすることが可能である。よって、あるＭＥＲにおける第３ステージが他のＭＥＲにおける第３ステージと交信する代わりに、あるＭＥＲに関連付けられたルート・リフレクタが、他のＭＥＲに関連付けられたルート・リフレクタと交信することが、ルーティング要求およびプロトコルを決定するために、可能である。ルート・リフレクタが、ボーダ・ゲートウェイ・プロトコル（「ＢＧＰ」）を利用するか、またはＩＧＰルート・リフレクション・プロトコルを利用することが可能である（例えば、ルート・リフレクタがエリア・ボーダ・ルータとして動作することが可能である）。

複数のパラレル・バックボーン（Ｎ×ＢＢ）

コア・バックボーン・ネットワークを拡張するために利用可能な別のインプリメンテーションは、複数のパラレル・バックボーンを形成することである。この種のインプリメンテーションの一実施例が、図２に示されている。Ｎ×ＢＢ構成により、スケール増大のためにトラフィックを複数のバックボーンにわたって分散させることが可能である。

図２に示すように、あるインプリメンテーションの一実施例においては、コア・サイト間において一連の複数のパラレル・バックボーンが利用される。それらバックボーンは、複数台の大規模なＭＰＬＳルータ、複数個のイーサネット・スイッチ、前述の複数のＭＥＲ、または他の適切なルーティング技術を利用することが可能である。

さらに、図示された実施例においては、複数のピアを、各バックボーンに接続された共通のピアリング・インフラストラクチャすなわちエッジを経由して、複数のバックボーンに接続することが可能であり、また、複数のカスタマを複数の特定のバックボーン・エッジに接続することが可能である。

すなわち、複数のピアは、１つのピアリング・エッジを経由して、複数のパラレル・バックボーン（ＢＢ、ＢＢ１、ＢＢ２、ＢＢ３およびＢＢ４）に接続され、また、複数のカスタマは、互いに分離された複数のエッジ・ネットワークを経由して、複数のバックボーンに接続される。

図２においては、各バックボーンが、それ自身のカスタマ・エッジ・ネットワークを有する。しかしながら、別の実施例においては、１つのみまたは少数のみのエッジ・ネットワークが利用されるかもしれない（１のピアリング・エッジと同様に）。そのエッジ・ネットワークは、前記ＭＥＲを含み、別のルーティング技術を利用することが可能である。ＭＥＲを利用することにより、ピアリング・エッジのスケーリングが可能となる。

図２における矢印は、パラレル・バックボーン・ネットワークにおけるトラフィックのフローの一例を示している。この例においては、カスタマＡ−Ｚが宛先であるトラフィックが、ピア＃２から到着する。ピアリング・エッジは、トラフィックの最終的な宛先に応じて、トラフィックを複数のバックボーンに分散させる（例えば、ピアリング・エッジは、ＩＰ宛先プレフィクスに応じて、トラフィックを分散させることが可能である）。その後、各バックボーンは、トラフィックを、そのトラフィックに関連するカスタマ・エッジを経由して、最終的なカスタマ宛先に伝送する。

複数のパラレル・バックボーンを用いるこのネットワークは、多くの利点を有することが可能である。例えば、パラレル・バックボーンにより、各バックボーンにおけるスイッチング要求が少なくなるため、イーサネット・スイッチおよび／またはＭＥＲの使用が可能である。

さらに、このパラレル・バックボーン構成は、トラフィック・エンジニアリング、コンフェデレーション、ＭＢＧＰ等のＢＧＰツールのような既存のルーティング・プロトコルおよびコントロール・プロトコルを増強させることが可能である。トラフィック・エンジニアリング・プロトコルの利用により、トラフィックが適切な１または複数のバックボーンに導かれることが支援され得る。

さらに、複数のバックボーンの存在により、ミッション・クリティカル・アプリケーションについて、フォールト・トレラント・バックアップ・システムを形成することが可能である。すなわち、１または複数のバックボーンを災害復旧および／またはバックアップのために使用することが可能である。

さらに、別の実施例においては、互いに異なる複数のファクタに基づき、複数のパラレル・バックボーンを構成するとともに利用することが可能である。例えば、ピアが、そのピアに専ら使用される１または複数のバックボーンを有することができる。同様に、カスタマは、そのカスタマに専ら使用される１または複数のバックボーンを有することが可能である。

さらに別の実施例においては、トラフィックおよび／またはサービスに基づき、複数のカスタマを複数のバックボーンにわたって割り当てることが可能である。例えば、ボイス・オーバー・アイピー（ＶｏＩＰ）が１または複数のバックボーンを利用し、一方、他のＩＰサービスが他のバックボーンを利用するかもしれない。このように、バックボーンは、ピア、カスタマ、サービス、トラフィック量または他の適切なプロビジョニング・パラメータによってプロビジョン(provision)することが可能である。

さらに、図３に示すように、より大きなスケーリングのために、複数のマルチシャーシ・イーサネット・ルータ（ＭＥＲ）と複数のパラレル・バックボーン（Ｎ×ＢＢ）との組合せを利用することが可能である。例えば、図３の例に示すように、ＭＥＲとパラレル・バックボーンとの組合せを用いることにより、３００Ｇであるイーサネット・スイッチのキャパシティを６４倍して１９，２００Ｇにすることが可能である。この例においては、８×ＭＥＲと８×パラレル・バックボーンとが、６４倍のスケーラビリティを実現するために結合される。より大規模なＭＥＲ（例えば、１６×ＭＥＲまたは３２×ＭＥＲ）および／またはより多くのパラレル・バックボーンを利用すると、スケーラビリティをさらに増加させることが可能である。このように、それらの技術を別々にまたは一緒に利用することは、キャパシティの大幅な拡張に有用であり得る。

さらに、図４に示すように、イーサネット系のコア（例えば、ＭＥＲｓをベースにしたコア）をパラレル・コアとして既存のＭＰＬＳコアに追加することが可能であり、これにより、既存のコアの交換を要することなく、簡単なスケーラビリティを合理的な価格で付加することが可能である。本実施例においては、新規のカスタマに加えて、既存のカスタマを、その新規のイーサネット・コア・バックボーンにルーティングすることが可能である。これに代えて、ＶｏＩＰのような特別なサービスをその新規のバックボーンに割り当て、一方、他のサービスをＭＰＬＳに割り当てることが可能である。それら２つのコアの利用については、互いに異なる多くのシナリオを検討して採用することが可能である。

図５は、既存のＭＰＬＳコアに対して並列であるイーサネット系のパラレル・コアを示す別の図である。利用すべきバックボーンを宛先ごとに選択するため、ＢＧＰ技術を利用することが可能である。候補ルートに、宛先アドレスに向かうべきすべてのトラフィックを２番目のバックボーンに向かわせるＢＧＰコミュニティ・ストリング（およびＩＰネクスト・ホップ）というマークが付される。この選択は、ルートごとに行うことが可能であり、送信元に基づいて変更することが可能である。これに代えて、複数のカスタマ・パートから成る特定の組から送出されるすべてのトラフィックが同一のバックボーンを利用するように、カスタマ系のグローバル・ポリシィを利用することが可能である。ルート・セレクションおよびルート・マップは、キャパシティ・プランニング・ツールによって自動的に作成することが可能である。

中央ＬＡＮ（ＬＡＮインザミドル：ＬＩＭ）

バックボーン・コアを拡張するために利用可能な別のネットワーク・インプリメンテーションは、ＬＩＭである。ＬＩＭの一実施例が図６に示されている。この図示された実施例においては、複数台のコア・ルータが複数個のイーサネット・スイッチを経由して複数台のエッジ・ルータに接続されている。この構成は、すべてのステージがイーサネット・スイッチを利用する代わりにステージ１および３が既存のコア・ルータおよびエッジ・ルータを利用することを除いて、前述のＭＥＲの構成と類似している。この構成の利点は、既存のルータのイーサネット・スイッチへの交換を要することなく、既存のルータを拡張することが可能である点にある。前述のように、中間層でのイーサネット・スイッチの利用およびＣＬＯＳマトリクスの利用により、既存のコア・ルータおよびエッジ・ルータのキャパシティが拡張される。一実施例においては、それらコア・ルータおよびエッジ・ルータが、前記マトリクスを利用してトラフィックをプロビジョン(provision)する役目を果たす。

図７は、別のＬＩＭを示す線図である。カスタマ指向(customer facing) プロバイダ・エッジ（ＰＥ）は、例えば、ＬＩＭに対して４×１０Ｇを有する。１＋１プロテクションにより、２０Ｇのカスタマ指向ワーキング・トラフィックが許容される。ＷＡＮ側においては、各プロバイダすなわちコア・ルータ（Ｐ）が、ＬＩＭに対して４×１０Ｇを有する。１＋１プロテクションにより、少なくとも２０ＧのＷＡＮトラフィックが許容される。

以上、本発明を好ましいいくつかの実施形態を参照して説明したが、当業者であれば、本発明の主旨および範囲から逸脱することなく、形式および細部を変更することが可能であることを認識する。

図１は、本発明の一実施例に従う３ステージ・マルチシャーシ・イーサネット・ルータ（ＭＥＲ）を示す線図である。 図２は、ピア・ネットワークおよびエッジ・ネットワークに接続された複数のパラレル・バックボーン（Ｎ×ＢＢ）であって本発明の別の実施例に従うものを示す線図である。 図３は、図１に示すマルチシャーシ・イーサネット・ルータと図２に示す複数のパラレル・バックボーンとの組合せであって、サイト間に接続され、かつ、本発明の別の実施例に従うものを示す線図である。 図４は、サイト間における複数の既存のＭＰＬＳコアに対して並列であるマルチシャーシ・イーサネット・ルータ系のコアであって本発明の別の実施例に従うものを示す線図である。 図５は、図４に示す発明の別の態様を示す線図である。 図６は、コア・ルータとエッジ・ルータとの間に接続された複数のコア・ローカル・エリア・ネットワークであって本発明の別の実施例に従うものを示す線図である。 図７は、別のＬＩＭを示す線図である。

Claims (16)

1. インターネット・プロトコル（ＩＰ）・トラフィックを送信元バックボーンと宛先バックボーンとの間においてルーティングするルータであって、
   ＩＰに対応可能な、複数個のイーサネット・スイッチを用いるＮ×Ｍ型のＣＬＯＳマトリクスであって、Ｎは、１より大きく、かつ、前記マトリクス内のステージの数を表し、Ｍは、１より大きく、かつ、各ステージにおけるスイッチの数を表すものと、
   前記複数個のスイッチ間にＩＰトラフィックを分散させるルーティング・プロトコル・コントロール手段と
   を含むルータ。
2. 前記ルーティング・プロトコル・コントロール手段は、１以上のステージの各々における２個以上のスイッチ間においてトラフィックのフローを均等化する負荷均等化(load balancing)手段を含む請求項１に記載のルータ。
3. 前記ルーティング・プロトコル・コントロール手段は、トラフィックを均等化するフロー重視型(flow-based)負荷均等化手段を含む請求項２に記載のルータ。
4. 前記ルーティング・プロトコル・コントロール手段は、トラフィックを均等化する手段であって内部ゲートウェイ・プロトコル（ＩＧＰ）に対応可能であるものを含む請求項２に記載のルータ。
5. 前記ルーティング・プロトコル・コントロール手段は、共通の宛先に関連付けられた最終ステージの各スイッチにほぼ同量のトラフィックを受信させることにより、トラフィックを均等化する等コスト重視型(equal cost-based)負荷均等化手段を含む請求項２に記載のルータ。
6. 前記ルーティング・プロトコル・コントロール手段は、トラフィックを均等化する帯域対応型(bandwidth-aware)負荷均等化手段を含む請求項２に記載のルータ。
7. 前記ルーティング・プロトコル・コントロール手段は、トラフィックを均等化するトラフィック対応型(traffic-awareness)負荷均等化手段を含む請求項２に記載のルータ。
8. 前記ルーティング・プロトコル・コントロール手段は、前記複数個のスイッチを用いる前記マトリクスに接続されるコントローラまたはルート・リフレクタを含む請求項１に記載のルータ。
9. 前記ルーティング・プロトコル・コントロール手段は、前記複数個のイーサネット・スイッチに組み込まれるコントロール手段を含む請求項１に記載のルータ。
10. インターネット・プロトコル（ＩＰ）・トラフィックを送信元サイトと宛先サイトとの間においてルーティングするネットワーク・システムであって、
    前記送信元サイトと前記宛先サイトとの間における、データ伝送のための複数の離散的なバックボーンと、
    前記送信元サイトにおけるＩＰトラフィックを前記宛先サイトに伝送するために、前記ＩＰトラフィックを前記複数のバックボーンに分散させる送信元サイト・コントロール手段と
    を含むネットワーク・システム。
11. 前記複数のバックボーンにおいて受信されたＩＰトラフィックを、前記宛先サイトにルーティングする宛先サイト・コントロール手段をさらに含む請求項１０に記載のネットワーク・システム。
12. 前記複数のバックボーンのうちの１以上のものは、１以上のカスタマからのＩＰトラフィックに専ら用いられ、
    前記送信元サイト・コントロール手段は、ＩＰトラフィックを、そのトラフィックの送信元であるカスタマに応じて前記複数のバックボーンに分散させ、
    前記宛先サイト・コントロール手段は、前記複数のバックボーンのうちの１以上のものに専ら用いられるコントロール手段であって、ＩＰトラフィックを、そのトラフィックの送信元であるカスタマに応じてルーティングするものを含む請求項１１に記載のネットワーク・システム。
13. 前記送信元サイト・コントロール手段は、前記複数のバックボーンのすべてに共通のピアリング・エッジを含み、
    前記宛先サイト・コントロール手段は、前記複数のバックボーンのうちの１以上のものに接続される複数のピアリング・エッジであって、各々、ＩＰトラフィックを、そのトラフィックの送信元であるカスタマに応じてルーティングするものを含む請求項１１に記載のネットワーク・システム。
14. 前記送信元サイト・コントロール手段は、ＩＰトラフィックを、前記複数のバックボーンのトラフィック量に応じて分散させる手段を含む請求項１０に記載のネットワーク・システム。
15. 前記送信元サイト・コントロール手段は、ＩＰトラフィックを、そのＩＰトラフィックの性質または種類に応じて分散させる手段を含む請求項１０に記載のネットワーク・システム。
16. インターネット・プロトコル（ＩＰ）・トラフィックをコア・バックボーンとエッジとの間においてルーティングするシステムであって、
    ＩＰに対応可能な、複数個のスイッチを用いるＮ×Ｍ型のＣＬＯＳマトリクスと、
    前記複数個のスイッチ間にＩＰトラフィックを分散させるルーティング・プロトコル・コントロール手段と
    を含み、
    Ｎは、１より大きく、かつ、前記マトリクス内のステージの数を表し、
    Ｍは、１より大きく、かつ、各ステージにおけるスイッチの数を表し、
    第１ステージおよび最終ステージにおける前記Ｍ個のスイッチは、マルチ・プロトコル・ラベル・スイッチング（ＭＰＬＳ）・スイッチであり、
    前記第１ステージと前記最終ステージとの間における少なくとも１つのステージにおける前記Ｍ個のスイッチは、イーサネット・スイッチであるシステム。

Images