(57)【特許請求の範囲】
【請求項１】
複数のホスト（１００、１０２，１０４、１０６）と、
複数の物理ルータ（１１０、１１６）と、
該ホストと該物理ルータを相互接続するＬＡＮ媒体とを備え、
該ホストの第１ホストが、第１冗長ルータプロトコルタイプのパケットを該ＬＡＮ媒体に加えるように構成されたローカルエリアネットワークＬＡＮであって、
該ホストの第２ホストが、第２冗長ルータプロトコルタイプのパケットを該ＬＡＮ媒体に加えるように構成され、第１冗長ルータプロトコルおよび第２冗長ルータプロトコルが相互使用可能でなく、
各々の該物理ルータ（１１０、１１６）が、第１冗長ルータプロトコルタイプおよび第２冗長ルータプロトコルタイプのパケットを同時に経路指定することができ、
該物理ルータ（１１０、１１６）は、着信パケットが第１冗長ルータプロトコルタイプであるかどうかを判定するために、着信パケットの行先アドレスプレフィクスと事前定義された第１の値とを比較するように構成され、
該物理ルータ（１１０、１１６）は、着信パケットが第２冗長ルータプロトコルタイプであるかどうかを判定するために、着信パケットの行先アドレスプレフィクスと事前定義された第２の値とを比較するように構成され、
該物理ルータ（１１０、１１６）が、パケットの判定された冗長ルータプロトコルタイプに応じて、ＬＡＮ媒体上で受信されたパケットを転送する責任を判定するように構成される、ローカルエリアネットワークＬＡＮ。
【請求項２】
第１冗長ルータプロトコルタイプが、仮想ルータ冗長プロトコルＶＲＲＰであり、第２冗長ルータプロトコルタイプが、ホットスタンバイルータプロトコルＨＳＲＰである、請求項１に記載のＬＡＮ。
【請求項３】
該複数のホストが、ホストの１つまたは複数のグループを含み、第１の冗長ルータプロトコルタイプの仮想ルータアドレスが構成されている、ホストの第１グループに第１ホストが属する、請求項１に記載のＬＡＮ。
【請求項４】
第２の冗長ルータプロトコルタイプの仮想ルータアドレスが構成されている、ホストの第２グループに第２ホストが属する、請求項３に記載のＬＡＮ。
【請求項５】
ホストのグループが、第１の冗長ルータプロトコルタイプの他の仮想ルータアドレスが構成されている、ホストの第３グループを含む、請求項３に記載のＬＡＮ。
【請求項６】
ホストのグループが、第２の冗長ルータプロトコルタイプの他の仮想ルータアドレスが構成されている、ホストの第４グループを含む、請求項４に記載ＬＡＮ。
【請求項７】
該物理ルータ（１１０、１１６）の少なくとも１つが、少なくとも１つのパケットのプレフィクスＭＡＣアドレスビットと、第１および第２の冗長ルータプロトコルタイプの少なくとも１つの事前定義されたプレフィクスビットとのマッチングを実行するように構成される、請求項１に記載のＬＡＮ。
【請求項８】
該物理ルータ（１１０、１１６）の少なくとも１つは、パケットのプレフィクスＭＡＣアドレスビットが、第１の冗長ルータプロトコルタイプの事前定義されたプレフィクスビットと一致する場合、第１の冗長ルータプロトコルタイプの仮想ルータアドレスを使用して、パケットを経路指定するように構成される、請求項７に記載のＬＡＮ。
【請求項９】
該物理ルータ（１１０、１１６）の少なくとも１つは、パケットのプレフィクスＭＡＣアドレスビットが、第２の冗長ルータプロトコルタイプの事前定義されたプレフィクスビットと一致する場合、第２の冗長ルータプロトコルタイプの仮想ルータアドレスを使用して、パケットを経路指定するように構成される、請求項８に記載のＬＡＮ。
【請求項１０】
複数の相互使用可能でない冗長経路指定プロトコルタイプをルータにおいて使用して、複数のパケットを同時に経路指定する方法であって、該方法は、
パケットアドレスを有するパケットをルータ（１１０、１１６）内へ受信するステップと、
パケットが、第１冗長経路指定プロトコルタイプまたは第２冗長経路指定プロトコルタイプであるかを判定するために、受信されたパケットの行先アドレスのプレフィクスと事前定義された第１の値とを比較することによって、および受信されたパケットの行先アドレスのプレフィクスと事前定義された第２の値とを比較することによって、受信されたパケットが、第１冗長経路指定プロトコルタイプまたは第２冗長経路指定プロトコルタイプであるかを判定するステップと、
判定された冗長ルータプロトコルタイプに応じて、受信されたパケットを転送する責任を判定するステップとを含む、複数のパケットを経路指定する方法。
【請求項１１】
パケットアドレスが、媒体アクセス制御ＭＡＣアドレスを含む、請求項１０に記載の経路指定の方法。
【請求項１２】
ＭＡＣアドレスが、４８ビットを含み、プレフィクスが、４０ビットを含み、第１および第２の事前定義された値が、それぞれ４０ビットを含む、請求項１１に記載の経路指定の方法。
【請求項１３】
さらに、パケットが第１または第２の冗長経路指定プロトコルタイプである場合、該ルータが該パケットを転送する責任があるかを判定するために、データベーステーブル（２５２）を探索するキーを策定するステップ（３０８）を含む、請求項１０に記載の経路指定の方法。
【請求項１４】
キーが、パケットの冗長経路指定プロトコルタイプを示すプロトコルＩＤを含む、請求項１３に記載の経路指定の方法。
【請求項１５】
キーが、ＶＬＡＮアドレスを含む、請求項１３に記載の経路指定の方法。
【請求項１６】
キーが、パケットに関連付けられている冗長経路指定プロトコルグループＩＤを示すグループＩＤを含む、請求項１３に記載の経路指定の方法。
【請求項１７】
パケットが、仮想ルータアドレスを使用して経路指定される（３１６）、請求項１３に記載の経路指定の方法。
【請求項１８】
複数のホスト（１００、１０２，１０４、１０６）と、複数の物理ルータ（１１０、１１６）と、該ホストと該物理ルータとを相互接続するＬＡＮ媒体とを備え、ルータ（１１０、１１６）が、第１冗長ルータプロトコルタイプのパケットを受信するように構成される、ローカルエリアネットワークＬＡＮのルータであって、
ルータ（１１０、１１６）が、第２冗長ルータプロトコルタイプのパケットも受信するように構成され、第１冗長ルータプロトコルおよび第２冗長ルータプロトコルが相互使用可能でなく、
ルータ（１１０、１１６）が、第１冗長ルータプロトコルおよび第２冗長ルータプロトコルのパケットを同時に経路指定するように構成され、
ルータ（１１０、１１６）が、パケットが、第１の冗長ルータプロトコルタイプであるかを判定するために、受信されたパケットの行先アドレスプレフィクスと事前定義された第１の値とを比較する第１の比較手段（２５０）を備え、
ルータ（１１０、１１６）が、パケットが、第２の冗長ルータプロトコルタイプであるかを判定するために、受信されたパケットの行先アドレスプレフィクスと事前定義された第２の値とを比較する第２の比較手段（２５０）を備え、
ルータ（１１０、１１６）が、判定された冗長ルータプロトコルタイプに応じて、ＬＡＮ媒体上で受信されたパケットを転送する責任を判定するように構成される、ルータ。
【請求項１９】
ルータはさらに、該ルータがパケットを転送する責任があるかを判定するための手段を備える、請求項１８に記載のルータ（１１０、１１６）。
【請求項２０】
ルータが、仮想ルータアドレスを使用してパケットを転送するように構成され、仮想ルータアドレスが、ＭＡＣアドレスおよびＶＬＡＮ  ＩＤを含む、請求項１９に記載のルータ（１１０、１１６）。
【請求項２１】
第１の比較手段（２５０）および第２の比較手段（２５０）が、プログラム可能パケット交換コントローラ（２００）で実現される、請求項１８に記載のルータ（１１０、１１６）。
【請求項２２】
第１の比較手段および第２の比較手段が、ハードワイヤードのパケット交換コントローラ（１５２）で実現される、請求項１８に記載のルータ（１１０、１１６）。
【請求項２３】
パケットが冗長ルータプロトコルタイプであるかを判定するためのプレフィクス一致手段（２５０）をさらに備える、請求項１８に記載のルータ（１１０、１１６）。
【請求項２４】
ＶＬＡＮ  ＩＤと冗長ルータプロトコルグループＩＤの少なくとも１つが、所定の範囲内にあるかを判定するための範囲チェック手段（２５０）をさらに備える、請求項１８に記載のルータ（１１０、１１６）。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
関連出願の相互参照
本出願は、２０００年５月２４日に出願された「Ｓｙｓｔｅｍ  ａｎｄ  Ｍｅｔｈｏｄ  ｆｏｒ  Ｅｎｈａｎｃｅｄ  Ｌｉｎｅ  Ｃａｒｄｓ」という名称の米国仮出願第６０／２０６，６１７号、２０００年５月２４日に出願された「Ｆｌｏｗ  Ｒｅｓｏｌｕｔｉｏｎ  Ｌｏｇｉｃ  Ｓｙｓｔｅｍ  ａｎｄ  Ｍｅｔｈｏｄ」という名称の米国仮出願第６０／２０６，９９６号、２０００年７月２４日に出願された「Ｐｒｏｇｒａｍｍａｂｌｅ  Ｐａｃｋｅｔ  Ｐｒｏｃｅｓｓｏｒ」という名称の米国仮出願第６０／２２０，３３５号、および２０００年９月１３日に出願された「Ｈｏｔ  Ｓｔａｎｄｂｙ  Ｒｏｕｔｉｎｇ」という名称の米国仮出願第６０／２３２，４７９号の優先権を請求する。これらの内容は全て、参照によって本明細書に完全に組み込まれている。本出願は、２０００年１２月２８日に出願された「Ｐｒｏｇｒａｍｍａｂｌｅ  Ｐａｃｋｅｔ  Ｐｒｏｃｅｓｓｏｒ  ｗｉｔｈ  Ｆｌｏｗ  Ｒｅｓｏｌｕｔｉｏｎ  Ｌｏｇｉｃ」という名称の米国特許出願第０９／７５１，１９４号に開示されている主題に関係する主題を含んでおり、この特許出願の内容は、参照によって本明細書に完全に組み込まれている。
【０００２】
本発明は、冗長経路指定に関し、詳細には、マルチプロトコル冗長ルータプロトコルサポートを提供する方法および装置に関する。
【０００３】
【従来の技術】
冗長経路指定プロトコルを開発し、静的ルートで構成されたホストにルータの故障に対する保護策を提供してきた。冗長経路指定では、ホストは、ＬＡＮをホストと共有する２つ以上の物理ルータによってサポートされている仮想ルータＭＡＣアドレスに送信するように構成されている。詳細には、動作サイクルの任意の時間に、物理ルータの１つである仮想マスタは、ホストから受信されたパケットを転送しかつ仮想ルータＭＡＣアドレスを有する責任があり、他のバックアップルータは、仮想マスタが故障した場合に転送する責任を担うために待機している。各バックアップルータは、移行によって仮想マスタとなるが、この移行は、ホストにとってトランスペアレントである。
【０００４】
【発明が解決しようとする課題】
故障回復の特性の他に、冗長経路指定プロトコルを２つ以上のホストを有するＬＡＮで使用して、ロード共有を達成することができることが有利である。ロード共有の構成では、物理ルータの異なるものは、ホストの異なるものに対する当初の仮想マスタとなるように、少なくとも２つのホストが仮想ルータＭＡＣアドレスの異なるものを割り当てられている。
【０００５】
冗長ルータプロトコルは明らかな利点を有するが、冗長ルータプロトコルのハードウェアサポートをルータに追加することは、通常費用がかかる。通常、追加のキャッシュ設備が、稼動仮想ルータの４８ビットＭＡＣアドレスを格納するために関与している物理ルータ上に要求される。この実施コストは、２つ競合する（そして、相互使用可能でない）冗長プロトコル：Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ（ＩＥＴＥ）のＲｅｑｕｅｓｔ  ｆｏｒＣｏｍｍｅｎｔ  （ＲＦＣ）２２８１で指定されているＨｏｔ  Ｓｔａｎｄｂｙ  Ｒｏｕｔｅｒ  Ｐｒｏｔｏｃｏｌ（ＨＳＲＰ）とＩＥＴＦのＲＦＣ２３３８で指定されているＶｉｒｔｕａｌ  Ｒｏｕｔｅｒ  Ｒｅｄｕｎｄａｎｃｙ  Ｐｒｏｔｏｃｏｌ（ＶＲＲＰ）の存在によって、高くなる一方であった。
【０００６】
したがって、一般的には効率的な冗長ルータプロトコルサポート、詳細にはマルチプロトコル冗長ルータプロトコルサポートを提供することが望ましい。
【０００７】
【課題を解決するための手段】
本発明の一実施形態では、ローカルエリアネットワーク（ＬＡＮ）が提供される。ＬＡＮは、複数のホスト、複数の物理ルータ、およびホストと物理ルータを相互接続するＬＡＮ媒体を含む。ホストの第１ホストは、第１冗長ルータプロトコルタイプのパケットをＬＡＮ媒体に加え、ホストの第２ホストは、第２冗長ルータプロトコルタイプのパケットをＬＡＮ媒体に加える。物理ルータは、パケットの冗長ルータプロトコルタイプに応じて、ＬＡＮ媒体上で受信されたパケットを転送する責任を決定する。
【０００８】
本発明の他の実施形態では、複数の冗長経路指定プロトコルを使用して複数のパケットを経路指定する方法が提供される。ルータは、パケットアドレスを有するパケットを受信する。パケットアドレスのプレフィクスを、事前定義された第１の値と比較して、パケットが第１冗長経路指定プロトコルタイプであるかを判定する。パケットアドレスのプレフィクスを事前定義された第２の値と比較して、パケットが第２冗長経路指定プロトコルタイプであるかを判定する。
【０００９】
本発明の他の実施形態では、１つまたは複数のパケットを受信および転送するルータが提供される。ルータは、パケットアドレスのプレフィクスと事前定義された第１の値を比較して、パケットが第１冗長ルータプロトコルタイプであるかを判定する、第１コンパレータを含む。また、ルータは、パケットアドレスのプレフィクスと事前定義された第２の値を比較して、パケットが第２冗長ルータプロトコルタイプであるかを判定する、第２コンパレータを含む。
【００１０】
本発明のこれらおよび他の特徴は、添付の図面に関連して取り入れた、以下の詳細な説明を参照することによって理解することが可能である。
【００１１】
【発明の実施の形態】
図１は、本発明の一実施形態による、ＨＳＲＰとＶＲＲＰの両方をサポートする装置のシステム図である。図１では、ローカルエリアネットワーク（ＬＡＮ）は、複数のホスト１００、１０２、１０４、１０６と、（仮想の反対である）物理ルータである複数のルータ１１０、１１６を含む。ルータ１１０と１１６は、コンピュータネットワーク１２０に結合されている。ルータ１１０、１１６は、ＬＡＮに結合され、コンピュータネットワーク１２０へのゲートウェイを提供していると見なすことが可能である。他の実施形態では、ルータ１１０、１１６は、図１のＬＡＮ以外の１つまたは複数のＬＡＮに結合することが可能である。
【００１２】
コンピュータネットワーク１２０は、例えば、インターネットまたは他のグローバルあるいはローカルコンピュータネットワークを含むことが可能である。また、ルータ１１０および１１６は、１つまたは複数の他のＬＡＮ（図示せず）に結合することが可能である。この実施形態および他の実施形態のＬＡＮは、イーサネット（ＩＥＥＥ８０２．３）、トークンリング（ＩＥＥＥ８０２．５）、およびＦＤＤＩ（ＡＮＳＩ  Ｘ３Ｔ９．５）を含む１つまたは複数の異なる構成を有することが可能であるが、これに限定されるものではない。
【００１３】
ホスト１００と１０４は、それぞれ、冗長ルータのＨＳＲＰグループ１とＨＳＲＰグループ２のグループに関連付けられていることが好ましい。ホスト１０２と１０６は、それぞれ、冗長ルータのＶＲＲＰグループ１とＶＲＲＰグループ２のグループに関連付けられている。図１のホストとルータは、単に例示の目的で示していることに留意されたい。実際には、ＬＡＮは、ＨＳＲＰグループ１および／または２、ＶＲＲＰグループ１および／または２、および／または他のＨＳＲＰおよび／またはＶＲＲＰグループに属する１つまたは複数の追加のホストおよびルータを含むことが可能である。各グループの冗長ルータは、共通の仮想ルータアドレスを共有し、これは、冗長ルータのグループに関連付けられている１つまたは複数のホストに割り当てられる。
【００１４】
仮想ルータアドレスは、媒体アクセス制御（ＭＡＣ）アドレス、ネットワークアドレス（ＩＰなど）、またはその両方を含むことが可能である。仮想ルータアドレスに割り当てられているホストが、経路指定される１つまたは複数のデータユニット（イーサネットフレーム、ＩＰパケット、またはＡＴＭセルなど）を送信するとき、データユニットは、特定のグループの仮想マスタとして作用しているグループの冗長ルータの１つに向けられる。
【００１５】
例えば、ホスト１００からのデータユニットは、ＨＳＲＰグループ１の仮想ルータ１０８によって経路指定することが好ましく、ホスト１０２からのデータユニットは、ＶＲＲＰグループ１の仮想ルータ１１８によって経路指定することが好ましく、ホスト１０４からのデータユニットは、ＨＳＲＰグループ２の仮想ルータ１１４によって経路指定することが好ましく、ホスト１０６からのデータユニットは、ＶＲＲＰグループ２の仮想ルータ１１２によって経路指定することが好ましい。
【００１６】
ＨＳＲＰおよびＶＲＲＰの仮想ルータ１０８、１１２、１１４、および１１８は、物理ルータではないので、それらの仮想ルータのアドレスは、ルータ１１０と１１６にマップすることが好ましい。例えば、本発明による実施形態では、ルータ１１０は、ＨＳＲＰグループ１仮想マスタおよびＶＲＲＰグループ２仮想マスタとして構成されることが好ましい。他の例としては、ルータ１１６は、ＶＲＲＰグループ１仮想マスタおよびＨＳＲＰグループ２仮想マスタとして構成される。また、仮想ルータは、稼動ルータ、仮想ルータマスタ、またはマスタと呼ぶことが可能である。
【００１７】
図１では、仮想ルータの４つのグループ（すなわち、ＨＳＲＰグループ１仮想ルータ、ＶＲＲＰグループ２仮想ルータ、ＨＳＲＰグループ２仮想ルータ、およびＶＲＲＰグループ１仮想ルータ）をサポートしているルータ１１０および１１６が示されている。したがって、例えば、ルータ１１０がＨＳＲＰグループ１仮想マスタおよびＶＲＲＰグループ２仮想マスタとして動作するとき、ルータ１１６は、ＨＳＲＰグループ１待機ルータおよびＶＲＲＰグループ２待機ルータとして動作することが可能である。他の例として、ルータ１１６がＨＳＲＰグループ２仮想マスタおよびＶＲＲＰグループ１仮想マスタとして動作するとき、ルータ１１０は、ＨＳＲＰグループ２待機ルータおよびＶＲＲＰグループ１待機ルータとして動作することが可能である。また、待機ルータは、バックアップルータと呼ぶことも可能である。他の実施形態では、各物理ルータは、冗長ルータの１つのＨＳＲＰグループおよび冗長ルータの１つのＶＲＲＰグループにマップすることが可能である。
【００１８】
実際には、例えば、各ルータ１１０および１１６は、最高で５１２の異なるＬＡＮ上で、最高で４つのＨＳＲＰ仮想ルータグループと、最高で４つのＶＲＲＰ仮想ルータグループを同時にサポートすることが可能である。他の実施形態では、各ルータ１１０および１１６は、５１２以上の異なるＬＡＮ上で、５つ以上のＨＳＲＰ仮想ルータグループと５つ以上のＶＲＲＰ仮想ルータグループを同時にサポートすることが可能である。
【００１９】
図２には、パケット交換ノード１２０を含むネットワーク環境が示されている。パケット交換ノード１２０は、例えば、ルータ１１０および１１６の一方または両方として使用することが可能である。パケット交換ノード１２０は、いくつかの交換インタフェース１２４、１２６、１２８を含む。これらは、ＬＡＮ１３０、１３２、１３４のそれぞれのグループに相互接続されていることが好ましく、交換バックプレーン１２２を介してデータ経路１３８、１４０、１４２により、および制御経路１４４、１４６により、相互接続されていることが好ましい、。
【００２０】
交換インタフェース１２４、１２６、１２８は、例えば、媒体アクセス制御（ＭＡＣ）ブリッジングおよびインターネットプロトコル（ＩＰ）経路指定など、１つまたは複数の操作可能通信プロトコルに従って、ＬＡＮ１３０、１３２、１３４のそれぞれのグループへ、およびグループからパケットを転送することが好ましい。交換インタフェース１２４、１２６、および１２８は、インターネットおよび／または他のグローバルあるいはローカルコンピュータネットワークを含むことが可能であるコンピュータネットワーク１３６を介して、他のパケット交換ノードと通信することが好ましい。
【００２１】
図３は、交換インタフェース１５０のブロック図であり、これは、１つまたは複数の交換インタフェース１２４、１２６、および１２８と同様であることが可能である。交換インタフェース１５０は、ＬＡＮとパケット交換コントローラ１５２との間で結合されているアクセスコントローラ１５４を含む。アクセスコントローラ１５４は、ＬＡＮから離れるインバウンドパケットを受信し、インバウンドパケットに対して、フローに依存しない物理層操作およびＭＡＣ層操作を実施して、フローに依存する処理のために、インバウンドパケットをパケット交換コントローラ１５２に送信することが好ましい。また、アクセスコントローラ１５４は、パケット交換コントローラ１５２からアウトバウンドパケットを受信することが好ましく、アウトバウンドパケットに対して、物理層操作およびＭＡＣ層操作を実施して、アウトバウンドパケットを、ＬＡＮ上で、または例えば、図２のコンピュータネットワーク１３６などコンピュータネットワークへ送信することが好ましい。
【００２２】
パケット交換コントローラ１５２は、インバウンドパケットを受信し、パケットを分類し、インバウンドパケットのアプリケーションデータを生成し、アプリケーションデータに従ってインバウンドパケットを変更して、変更したインバウンドパケットを、例えば、図２の交換バックプレーン１２２など交換バックプレーン上で送信することが好ましい。また、パケット交換コントローラ１５２は、バックプレーンを介して、他の交換コントローラからのアウトバウンドパケットを受信して、アクセスコントローラ１５４に送信し、ＬＡＮ上で、または、例えば、図２のコンピュータネットワーク１３６などコンピュータネットワークに転送することが好ましい。他の実施形態では、パケット交換コントローラ１５２は、また、１つまたは複数のアウトバウンドパケットに出口処理を受けさせ、その後アクセスコントローラ１５４に転送することも可能である。パケット交換コントローラ１５２は、プログラム固定式論理、プログラム可能論理、またはプログラム固定式論理とプログラム可能論理の任意の組合せで実現することが可能である。
【００２３】
図４は、本発明の実施形態による、プログラム可能パケット交換コントローラ２００のブロック図である。プログラム可能パケット交換コントローラ２００は、例えば、図３のパケット交換コントローラ１５２と同様とすることが可能である。プログラム可能パケット交換コントローラ２００は、着信パケットのフローを分類および経路指定するフロー解決論理を有することが好ましい。他の実施形態のパケット交換コントローラは、より多くのまたはより少ない数の構成要素を含むことが可能である。例えば、他の実施形態のパケット交換コントローラは、パケットの一部と所定のパターンを比較して、一致性を調べるパターン一致モジュールを含むことが可能である。他の実施形態のパケット交換コントローラは、インバウンドパケットを編集してアウトバウンドパケットを生成する、編集モジュールを含むことが可能である。さらに、他の実施形態のパケット交換コントローラは、プログラム可能パケット交換コントローラ２００に含まれている構成要素の他に、またはその代わりに、例えば、規制エンジンなど他の構成要素を含むことが可能である。
【００２４】
プログラム可能な性質により、プログラム可能交換コントローラ２００は、多くの異なるプロトコルおよび／またはフィールドのアップグレード性に対処する柔軟性を提供することが好ましい。また、プログラム可能交換コントローラ２００は、パケット交換コントローラ、交換コントローラ、プログラム可能パケットプロセッサ、ネットワークプロセッサ、通信プロセッサと呼ぶこと、または当業者によって一般に使用されている他の名称で呼ぶことが可能である。
【００２５】
プログラム可能パケット交換コントローラ２００は、パケットバッファ２０２、パケット分類エンジン２０４、およびアプリケーションエンジン２０６を含む。プログラム可能パケット交換コントローラ２００は、インバウンドパケット２０８を受信することが好ましい。パケット（またはデータユニット）は、イーサネットフレーム、ＡＴＭセル、ＴＣＰ／ＩＰおよび／またはＵＤＰ／ＩＰパケットを含むことが可能であるが、これに限定されるものでない。また、他の層２（データリンク／ＭＡＣ層）、層３（ネットワーク層）、または層４（トランスポート層）のデータユニットを含むことが可能である。例えば、パケットバッファ２０２は、イーサネットを介して、１つまたは複数の媒体アクセス制御（ＭＡＣ）層インタフェースからインバウンドパケットを受信することが可能である。
【００２６】
受信したパケットは、パケットバッファ２０２に格納されることが好ましい。
パケットバッファ２０２は、パケットを受信し、一時的に格納するパケットＦＩＦＯを含むことが可能である。パケットバッファ２０２は、格納されたパケットまたはその一部を、パケット分類エンジン２０４とアプリケーションエンジン２０６に提供して処理することが好ましい。
【００２７】
また、パケットバッファ２０２は、パケットを編集して、その後アウトバウンドパケット２１８として交換コントローラから外に進める編集モジュールを含むことが可能である。編集モジュールは、実時間で編集プログラムを作成する編集プログラム構築エンジン、および／またはパケットを変更する編集エンジンを含むことが可能である。アプリケーションエンジン２０６は、パケットの配置決定を含むことが可能である、アプリケーションデータ２１６を、パケットバッファ２０２に提供することが好ましい。編集プログラム構築エンジンは、アプリケーションデータを使用して、編集エンジンを創出することが好ましい。アウトバウンドパケット２１８は、交換ファブリックインタフェースを介して、例えばイーサネットなど、通信ネットワークに送信することが可能である。
【００２８】
また、パケットバッファ２０２は、ヘッダデータ抽出器とヘッダデータキャッシュのどちらかまたは両方を含むことが可能である。ヘッダデータ抽出器を使用して、パケットから１つまたは複数のフィールドを抽出し、抽出したフィールドを、抽出ヘッダデータとしてヘッダデータキャッシュに格納することが好ましい。抽出ヘッダデータは、パケットヘッダの一部または全てを含むことが可能であるが、これに限定されるものではない。例えば、イーサネットシステムでは、ヘッダデータキャッシュは、各フレームの初めのＮバイトを格納することも可能である。
【００２９】
抽出ヘッダデータは、出力信号２１０としてパケット分類エンジン２０４に提供し、処理することが好ましい。また、アプリケーションエンジンは、インタフェース２１４を介して、抽出ヘッダデータを要求および受信することが可能である。抽出ヘッダデータは、層２のＭＡＣアドレス、８０２．１Ｐ／Ｑタグステータス、層２の密閉タイプ、層３のプロトコルタイプ、層３のアドレス、ＴｏＳ（サービスのタイプ）値、および層４のポート番号の１つまたは複数を含むことが可能であるが、これに限定されるものではない。他の実施形態では、出力信号２１０は、抽出したヘッダデータの代わりに、またはそれの他に、インバウンドパケット全体を含むことが可能である。他の実施形態では、パケット分類エンジン２０４を使用して、抽出ヘッダデータを、アプリケーションエンジンの使用に適したフォーマットにし、および／またはデータをヘッダデータキャッシュにロードすることが可能である。
【００３０】
パケット分類エンジン２０４は、プログラム可能マイクロコード駆動埋込み型処理エンジンを含むことが好ましい。パケット分類エンジン２０４は、命令ＲＡＭ（ＩＲＡＭ）（図示せず）に結合されていることが好ましい。パケット分類エンジンは、ＩＲＡＭに格納されている命令を読み取り、実行することが好ましい。一実施形態では、パケット分類エンジンが実行する命令の多くは、条件付きジャンプである。この実施形態では、分類論理は、異なるタイプのパケット分類を示すことが好ましい端部分の葉を有する決定ツリーを含む。さらに、決定ツリーのブランチは、命令の条件と、ヘッダデータキャッシュに格納されているヘッダフィールドとの比較に基づいて選択されることが好ましい。他の実施形態では、分類論理は、決定ツリーに基づいていないことが可能である。
【００３１】
本発明の一実施形態では、アプリケーションエンジン２０６は、複数のプログラム可能サブエンジンが直線的にパイプライン化されている、パイプラインアーキテクチャを有することが好ましい。各プログラム可能サブエンジンは、パケットに対する作用を実施することが好ましく、また、「バケツリレー」方式で、パケットを次のプログラム可能サブエンジンに進めることが好ましい。パケット分類エンジンは、開始信号２１２を使用して、アプリケーションエンジンの第１プログラム可能サブエンジンを開始することによって、パイプラインのパケット処理を開始することが好ましい。開始信号２１２は、アプリケーションエンジン２０６で実行する１つまたは複数のプログラムの識別を含むことが可能である。また、開始信号２１２は、パケット分類情報を含むことが可能である。アプリケーションエンジンのプログラム可能サブエンジンは、インタフェース２１４を介して、ヘッダデータと、ヘッダデータキャッシュに格納されている抽出フィールドへの直接アクセスを有することが好ましい。
【００３２】
アプリケーションエンジンは、プログラム可能サブエンジンが実行しない他の処理段階を含むことが可能であるが、意思決定段階は、プログラム可能サブエンジンによって実行し、柔軟性を増大することが好ましい。他の実施形態では、アプリケーションエンジンは、他の処理アーキテクチャを含むことが可能である。
【００３３】
図５は、本発明の実施形態による、着信データユニットがＨＳＲＰまたはＶＲＲＰのどちらのタイプであるかを判定するプロセスを示す概略図である。図５の概略図は、プレフィクス一致ブロック２５０とデータベーステーブル２５２を含む。プレフィクス一致ブロック２５０は、例えば、図４のパケット分類エンジンなど、パケット分類エンジンに含むことが可能である。他の実施形態では、プレフィクス一致ブロック２５０は、例えば、図４のアプリケーションエンジン２０６など、アプリケーションエンジンに含むことが可能である。
【００３４】
データベーステーブル２５４は、ビットテーブルを含むことが好ましく、これは、プロトコル選択（ＨＳＲＰまたはＶＲＲＰ）、ＶＬＡＮ番号（またはＶＬＡＮ  ＩＤ／アドレス）、およびグループ番号（またはグループＩＤ）によって索引付けされて単一ビットの結果を生ずる。他の実施形態では、データベーステーブル２５４は、他のテーブルフォーマットとすることが可能であり、他のパラメータを使用して、テーブルを索引付けすることが可能である。データベーステーブル２５４がもたらす結果は、他の実施形態では、複数のビットを含むことが可能である。データベーステーブル２５４は、他のアプリケーションエンジンに含むことが可能であるか、または、アプリケーションエンジンの外部のメモリで実現することが可能である。
【００３５】
図５は、図６を参照して説明することが可能である。図６は、本発明の実施形態による、着信データユニットが、ＨＳＲＰまたはＶＲＲＰのどちらのタイプであるかを判定するプロセスを示す流れ図である。ステップ３０２で、プロセスはデータユニットを受信する。データユニットは、行先アドレスを含み、これは、行先媒体アクセス制御（ＤＭＡＣ）アドレスおよび／または仮想ローカルエリアネットワーク（ＶＬＡＮ）ＩＤを含むことが可能である。図５に示す例示的なＤＭＡＣアドレスおよびＶＬＡＭ  ＩＤは、それぞれ、４８ビットと１２ビットを含む。
【００３６】
ステップ３０３で、プレフィクス一致ブロック２５０を使用して、受信されたデータユニットが、ＨＳＲＰまたはＶＲＲＰのどちらのタイプであるかを判定することが好ましい。ＨＳＲＰおよびＶＲＲＰのルータＭＡＣアドレスのそれぞれは、ＩＥＥＥ８０２ＭＡＣアドレスを含み、８ビットのグループ接尾部を備える事前に定義した４０ビットのプレフィクスを有する。例えば、ＨＳＲＰグループの仮想ＭＡＣアドレスは、００−００−０Ｃ−０７−ＡＣ−ＸＸとすることが可能であり、００、０Ｃ、０７、およびＡＣは、それぞれ８ビットの１６進数であり、ＸＸは、ＨＳＲＰグループの８ビットのグループＩＤである。他の例として、ＶＲＲＰグループの仮想ＭＡＣアドレスは、００−００−５Ｅ−００−０１−ＸＸとすることが可能であり、００、５Ｅ、および０１は、それぞれ８ビットの１６進数であり、ＸＸは、ＶＲＲＰグループの８ビットのグループＩＤである。受信されたＤＭＡＣの初めの４０ビットのプレフィクスが、ＨＳＲＰとＶＲＲＰのどちらの４０ビットのプレフィクスとも一致しない場合、プロセスは、判断３０４で、プレフィクスの一致がないことを示す。プレフィクスの一致が存在しない場合、データユニットは、仮想ルータのいずれにも向けられなかった可能性がある。
【００３７】
ステップ３０５で、プレフィクス一致ブロック２５０は、また、受信されたデータユニットのＶＬＡＮ  ＩＤとＶＲＲＰ／ＨＳＲＰグループＩＤをチェックして、それらが所定の値の範囲内にあるかを判定することが好ましい。例えば、ルータが最高で５１２の異なるＬＡＮを同時にサポートすることが可能である実施形態では、ＶＬＡＮ  ＩＤの値は、０と５１１を含むその間にあるべきである。他の例として、ルータが最高で４つのＨＳＲＰグループおよび／または４つのＶＲＲＰグループを同時にサポートすることが可能で一実施形態では、ＶＲＲＰ／ＨＳＲＰグループＩＤの値は、０と３を含むその間にあるべきである。ＶＬＡＮＩＤまたはＶＲＲＰ／ＨＳＲＰグループＩＤのどちらかがそれぞれの値の範囲内にない場合、プロセスは、判断３０６で、範囲外にあることを示す。ＶＬＡＮＩＤまたはＶＲＲＰ／ＨＳＲＰグループＩＤのどちらかが範囲外にある場合、データユニットは、ソフトウェアを使用して経路指定することが可能であるが、通常より遅い速度で行われる。
【００３８】
他の実施形態では、さらなる異なるＬＡＮの数および／またはさらなるＶＲＲＰ／ＨＳＲＰグループの数をサポートすることが可能である。例えば、最高で４０９６の異なるＬＡＮを、１２ビットのＶＡＬＮ  ＩＤの１２ビットを全て使用してサポートすることが可能であり、最高で２５６のＶＲＲＰ／ＨＳＲＰグループを、８ビットのグループＩＤの８ビットを全て使用してサポートすることが可能である。
【００３９】
ステップ３０８で、プレフィクス一致ブロック２５０は、データベーステーブル２５２での一致用キーを構築することが好ましい。図５に示した例示的な実施形態では、キーは１２ビットを含む。他の実施形態では、キーは、１２より多いまたは少ないビット数を含むことが可能である。キーは、プロトコルＩＤ２５４、ＶＬＡＮアドレス２５６、およびグループＩＤ２５８を含むことが好ましい。プロトコルＩＤ２５４は、ＨＳＲＰまたはＶＲＲＰの単一ビット識別であることが好ましい。ＶＬＡＮアドレス２５６は、受信データユニットに対して、１２ビットＶＬＡＮ  ＩＤの９つの最下位ビット（ＬＳＢ）を含むことが好ましい。グループＩＤは、ＶＲＲＰまたはＨＳＲＰのグループＩＤを表すように、２ビットを含むことが好ましい。
【００４０】
１２ビットのキーを使用して、プレフィクス一致ブロックを含む記載実施形態のルータは、最高で５１２のＶＬＡＮ上で、最高で各タイプの４つのグループを有するＨＳＲＰおよびＶＲＲＰパケットを同時に処理することができる。他の実施形態では、プロトコルＩＤ２５４、ＶＬＡＮアドレス２５６、および／またはグループＩＤ２５８のビット数は、異なることが可能であり、異なるＨＳＲＰおよび／またはＶＲＲＰのパケット処理能力をもたらす可能性がある。他の実施形態では、プロトコルＩＤ、ＶＡＬＮアドレスおよび／またはグループＩＤのビット数は、冗長ルータプロトコル（例えば、ＨＳＲＰおよびＶＲＲＰ以外のプロトコルが、将来定義される可能性がある）および／または仮想ルータアドレスの異なる数をサポートするように、プログラム可能であることが可能である。
【００４１】
ステップ３１０で、キーを、データベーステーブル２５２の１つまたは複数のエントリと比較することが好ましい。データベーステーブルは、ＶＲＲＰ／ＨＳＲＰデータベースを含むことが可能であり、これはまた、ＶＲＲＰ／ＨＳＲＰ仮想マスタデータベースと呼ぶことが可能である。キーが、データベーステーブル２５２のいずれのエントリとも一致しない場合、データベーステーブルを含むルータは、データユニットを送信したホストの仮想マスタとして動作していない（３１４）。キーが、データベースのエントリと一致する場合、一致ビットを生成して、ルータが仮想マスタとして動作していることを示す。データユニットは、ステップ３１６で示すように、キーが一致しているとき、該仮想ルータアドレスを使用して、経路指定する（または交換する）ことが好ましい。
【００４２】
当業者なら、本発明は、その精神または本質的な特徴から逸脱せずに、他の特有の形態で実現することができることを理解するであろう。したがって、本記述は、あらゆる点で例示的であり、限定的ではないと見なされる。本発明の範囲は、添付の請求項によって示されており、その同等物の意味と範囲内にある全ての変更は、請求項に包含されていることを意図している。
【００４３】
例えば、記述した本発明の実施形態は、プログラム可能パケット交換コントローラで、マルチプロトコル冗長ルータプロトコルサポートを使用することに関して記述されている。しかし、本発明のマルチプロトコル冗長ルータプロトコルサポートを、ハードワイヤードなど、プログラム固定式パケット交換コントローラに適用することも可能である。
【図面の簡単な説明】
【図１】本発明の実施形態による、ＨＳＲＰとＶＲＲＰのプロトコルを両方サポートする装置のシステム図である。
【図２】本発明の実施形態による、ルータなど、パケット交換ノードを含むネットワーク環境の図である。
【図３】本発明の実施形態による、交換インタフェースのブロック図である。
【図４】本発明の実施形態による、パケット交換コントローラの図である。
【図５】本発明の実施形態による、着信データユニットが、ＨＳＲＰまたはＶＲＲＰのどちらのタイプであるかを判定するプロセスを示す概略図である。
【図６】本発明の実施形態による、着信データユニットが、ＨＳＲＰまたはＶＲＲＰのどちらのタイプであるかを判定するプロセスを示す流れ図である。
【符号の説明】
１００、１０２、１０４、１０６  ホスト
１０８  ＨＳＲＰグループ１仮想ルータ
１１０  物理ルータ１
１１２  ＶＲＲＰグループ２仮想ルータ
１１４  ＨＳＲＰグループ２仮想ルータ
１１６  物理ルータ２
１１８  ＶＲＲＰグループ１仮想ルータ
１２０  コンピュータネットワーク、パケット交換ノード
１２２  交換バックプレーン
１２４、１２６、１２８、１５０  交換インタフェース
１３０、１３２、１３４  ＬＡＮ
１３６  コンピュータネットワーク
１３８、１４０、１４２  データ経路
１４４、１４６  制御経路
１５２  パケット交換コントローラ
１５４  アクセスコントローラ
２００  プログラム可能パケット交換コントローラ
２０２  パケットバッファ
２０４  分類エンジン
２０６  アプリケーションエンジン
２０８  インバウンドパケット
２１０  出力信号
２１２  開始信号
２１４  インタフェース
２１６  アプリケーションデータ
２１８  アウトバウンドパケット
２５０  プレフィクス一致ブロック
２５２  データベーステーブル
２５４  プロトコルＩＤ
２５６  ＶＬＡＮアドレス
２５８  グループＩＤ
３０４、３０６  判断
【図１】
0004744723.tif 000002
【図２】
0004744723.tif 000003
【図３】
0004744723.tif 000004
【図４】
0004744723.tif 000005
【図５】
0004744723.tif 000006
【図６】
0004744723.tif 000007