(57)【特許請求の範囲】
【請求項１】
ネットワーク装置であって、
クライアントにネットワーク・アドレスおよびデフォルト・ゲートウェイ・アドレスを設定することができる構成サーバに接続された第１のポートと、
IPアドレスおよびデフォルト・ゲートウェイ・アドレスを設定されることを求めているクライアントに接続された第２のポートと、
前記第１のポートおよび第２のポートの間に接続され、前記第１および第２のポートの間でパケットを送出する送出ユニット(100)と、を有し、
前記送出ユニット(100)は、前記構成サーバから前記設定されることを求めているクライアントに送られる構成設定のためのメッセージを含む構成パケットをインターセプトする構成エージェント(102)を含んでおり、該構成パケットは前記クライアントによって使用されるネットワーク・アドレスおよびデフォルト・ゲートウェイ・アドレスを含んでおり、前記構成エージェントは、前記デフォルト・ゲートウェイ・アドレスに前記設定されることを求めているクライアントの前記ネットワーク・アドレスをコピーし、コピーした前記ネットワーク・アドレスで前記デフォルト・ゲートウェイ・アドレスを変更し、変更された前記デフォルト・ゲートウェイ・アドレスを含む前記構成パケットを前記第２のポートを介して前記設定されることを求めているクライアントに送出し、前記設定されることを求めているクライアントが、送出された前記構成パケットを受信することによって、前記設定されることを求めているクライアントが自身のデフォルト・ゲートウェイになるようにする、ネットワーク装置。
【請求項２】
前記構成エージェントが、前記第１のポートで前記構成サーバからの前記構成パケットを受け取ることによって前記構成パケットをインターセプトし、前記第２のポートで前記構成パケットを前記クライアントに伝送することによって前記構成パケットを伝送する、請求項１に記載のネットワーク装置。
【請求項３】
前記クライアントのネットワーク・アドレスとして現在使用されているまたは将来使用される候補ネットワーク・アドレスを前記構成パケットのクライアント・ネットワーク・アドレス・フィールドから、前記構成パケットのデフォルト・ゲートウェイ・アドレス・フィールドにコピーして該候補アドレスを記憶することによって、前記構成エージェントが、前記クライアントによって使用されるべきデフォルト・ゲートウェイ・アドレスを変更する、請求項１に記載のネットワーク装置。
【請求項４】
前記構成エージェントが、前記構成パケットを伝送する前に、前記構成パケットに関連するチェックサムを再計算する、請求項１に記載のネットワーク装置。
【請求項５】
前記構成エージェントが、
前記構成サーバおよび前記クライアントの間の構成設定のための発見メッセージまたは要求メッセージを含むパケットをインターセプトし、
前記発見メッセージまたは前記要求メッセージを含む前記パケットを検査して該パケットのブロードキャスト・フラグが設定されているかどうかを判定し、
前記ブロードキャスト・フラグが設定されていない場合には前記ブロードキャスト・フラグを設定し、
前記発見メッセージまたは前記要求メッセージを含む前記パケットに関連するチェックサムを再計算し、
前記発見メッセージまたは前記要求メッセージを含む前記パケットを伝送する、請求項１に記載のネットワーク装置。
【請求項６】
前記構成エージェントが、前記構成パケットの構成サーバ・アドレス・フィールドに構成エージェントのネットワーク・アドレスを記憶する、請求項１に記載のネットワーク装置。
【請求項７】
前記構成エージェントが、前記構成パケットが肯定応答メッセージを含むか否かを判断し、前記構成パケットが肯定応答メッセージを含む場合には、サーバ割り当てテーブルに前記クライアントと前記構成サーバとを関連付けるエントリを記憶する、請求項１に記載のネットワーク装置。
【請求項８】
前記構成エージェントが、クライアントがリースを更新することを求めるネットワーク・アドレスを含む要求メッセージを含むパケットをインターセプトし、前記要求メッセージを含む前記パケットの宛先を前記構成サーバのアドレスに再アドレス指定し、前記要求メッセージを含む前記パケットを前記構成サーバに伝送する、請求項１に記載のネットワーク装置。
【請求項９】
前記構成エージェントが、前記構成エージェントおよび前記構成サーバが同じサブネット上にあるか否かを判断し、
前記構成エージェントおよび前記構成サーバが同じサブネット上にある場合には、前記要求メッセージを含む前記パケットのブロードキャスト・フラグが設定されてなければ該ブロードキャスト・フラグを設定し、前記要求メッセージを含む前記パケットに関連するチェックサムを再計算し、前記パケットの宛先を前記構成サーバのハードウェア・アドレスに再アドレス指定し、
前記構成エージェントおよび前記構成サーバが同じサブネット上にない場合には、前記要求メッセージを含む前記パケットのブロードキャスト・フラグが解除されてなければ該ブロードキャスト・フラグを解除し、前記要求メッセージを含む前記パケットの中継エージェント・フィールドに前記構成エージェントのネットワーク・アドレスを記憶し、前記要求メッセージを含む前記パケットに関連するチェックサムを再計算し、前記パケットの宛先を前記構成サーバのネットワーク・アドレスに再アドレス指定する、請求項８に記載のネットワーク装置。
【請求項１０】
前記構成エージェントが、構成サーバ割り当てテーブルにアクセスして、クライアントと既に関連付けられている構成サーバのアドレスを取り出し、前記要求メッセージの宛先を前記クライアントと既に関連付けられている構成サーバのアドレスに含む前記パケットを再アドレス指定することによって、前記パケットの宛先を構成サーバのアドレスに再アドレス指定する、請求項８に記載のネットワーク装置。
【請求項１１】
前記構成エージェントが、構成サーバおよびクライアントの間の構成対話の一部である発見メッセージまたは要求メッセージを含むパケットをインターセプトして、構成エージェントおよび構成サーバが同じサブネット上にあるか否か判断し、
構成エージェントおよび構成サーバが同じサブネット上にある場合には、発見メッセージまたは要求メッセージを含むパケットのブロードキャスト・フラグが設定されていなければ該ブロードキャスト・フラグを設定し、前記パケットに関連するチェックサムを再計算し、前記パケットを伝送し、
構成エージェントおよび構成サーバが同じサブネット上にない場合には、発見メッセージまたは要求メッセージを含むパケットのブロードキャスト・フラグが解除されていなければ該ブロードキャスト・フラグを解除し、前記発見メッセージまたは要求メッセージを含む前記パケットの中継エージェント・フィールドに構成エージェントのネットワーク・アドレスを記憶し、前記パケットに関連するチェックサムを再計算し、前記パケットを伝送する、請求項１に記載のネットワーク装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ネットワーク・ノードの間の通信に関するもので、特に、ネットワーク・ノードがそれ自身のデフォルト・ゲートウェイであるように自動的に構成されることを可能にする方法および装置に関するものである。
【０００２】
【従来の技術】
コンピュータ・ネットワークの技術分野においては、同軸ケーブルまたはツイスト・ペア配線のようなネットワーク媒体によって連結されるネットワーク・ノードの間でデータを伝送するためプロトコル・スタックが一般に使用されている。ネットワーク・ノードは、コンピュータ・ワークステーション、サーバ、ネットワーク・プリンタ、ネットワーク・スキャナなどのような装置を含む。プロトコル・スタックの開発および実施の調和を図るため、国際標準機構(すなわちＩＳＯ）は、ネットワーク・プトトコルの７つの層を定めたオープン・システム相互接続(Open System Interconnectionの頭文字を取ってＯＳＩと呼ばれる)の基準モデルを発布した。
【０００３】
図１は、ＯＳＩ基準モデル１０のブロック図である。モデルは、ハードウェア層１２、データ・リンク層１４、ネットワーク層１６、トランスポート層１８、セッション層２０、プレゼンテーション層２２およびアプリケーション層２４を含む。各層は特定の作業を実行することに対して責任を持つ。ハードウェア層１２は、ビット・ストリームの物理的伝送の機械的および電気的細部を取り扱うことに対して責任がある。データ・リンク層１４は、ハードウェア・プロトコルによって使用されるアドレスの生成ならびに解読、および、物理層で発生したエラー検出ならびに訂正を含むパケット処理に対して責任がある。例えば、イーサネット・ネットワークのデータ・リンク層１４は、媒体アクセス制御アドレスの生成および解読に対して責任がある。ネットワーク層１６は、上位プロトコルによって使用されるアドレスの生成ならびに解読、および、負荷の変化に適切に応答するための経路指定情報の維持を含めて、接続を行い、通信ネットワークにおけるパケットの経路指定を行うことに対して責任がある、例えば、ＴＣＰ／ＩＰプロトコルにおいて、ネットワーク層１６はＩＰアドレスを生成および解読することに対して責任がある。
【０００４】
トランスポート層１８は、メッセージのパケットへの細分化、パケット順序ならびに送達の維持、フロー制御および物理アドレス生成を含めて、ネットワークにおけるノード間のエンド対エンドの接続およびユーザの間でのメッセージ伝送に対して責任がある。セッション層２０は、プロセス対プロセスのプロトコルを実施することに対して責任がある。プレゼンテーション層２２は、文字変換および多重化(エコー化)を含めて、ネットワークにおけるいろいろなサイトの間での形式の相違を解決することに対して責任がある。最後に、アプリケーション層２４は直接ユーザと対話することに対して責任がある。層２４は、例えば、電子メールのようなアプリケーション、分散データベース、ウェブ・ブラウザなどを含む。
【０００５】
ＩＳＯがＯＳＩ基準モデルを発布する前に、米国国防総省高等研究計画局(ＤＡＰＲＡ)がＡＲＰＮＥＴ基準モデルを発布した。ＡＲＰＮＥＴ基準モデルは、ネットワーク・ハードウェア層、ネットワーク・インタフェース層、ホスト対ホスト層およびプロセス/アプリケーション層という４つの層を含む。
【０００６】
その名前が示唆するように、ＯＳＩおよびＡＲＰＮＥＴ基準モデルは、ネットワーク通信プロトコルの設計者がそれに従うこともあれば従わないこともあるガイドラインを提供する。しかしながら、大部分のネットワーク・プロトコルは、１つの基準モデルにすくなくともゆるやかに対応する諸層を定義している。コンピュータの分野においては、ネットワーク・ノードの間でデータを伝送するために使用される多数の有名なプロトコルがある。例えば、ＴＣＰ／ＩＰ、アップルＴａｌｋＲ(ＮｅｔＢＥＵＩ）およびＩＰＸXはすべて、コンピュータ・ネットワークに接続されるサーバ、ワークステーション、プリンタおよび他の装置の間でデータを送るために使用される有名なプロトコルである。
【０００７】
たとえネットワーク・ノードが単一のネットワーク・インタフェースを持つとしても、単一ネットワーク・ノードの範囲内でいくつかのプロトコルが同時に動作することは普通である。例えば、典型的なコンピュータ・ワークステーションは、インターネットを経由して通信を行うためＴＣＰ／ＩＰ、および、ネットワーク・サーバと通信するＩＰＸを使用する場合がある。同様に、プリンタが、ＡｐｐｌｅＴａｌｋＲプロトコルまたはＮｅｔＢＥＵＩプロトコルのいずれかを使用して印刷ジョブを受け取るように構成される場合がある。典型的には、これらのプロトコルは、一層低位の層のハードウェア・プロトコルと通信し対話する。例えば、イーサネット・ネットワークを経由して接続された２つのコンピュータ・システムがＴＣＰ／ＩＰプロトコルを使用して通信することは一般的である。一般に、データ・リンク層１４またはネットワーク層１６に存在しているソフトウェア・ルーチンは、ネットワーク・アダプタおよび適切なプロトコル・スタックの間でデータ・パケットを伝送する。
【０００８】
ここで、イーサネット・ネットワーク経由で伝送されるＴＣＰ／ＩＰパケットを考察する。各パケットは、イーサネット・ネットワーク上の別のノードを識別する４８ビットの媒体アクセス制御(media access controlを略してＭＡＣと呼ばれる)アドレスを含む。ＭＡＣアドレスは、一般的には、ハードウェア・アドレスとして知られている。イーサネット・パケット全体は、送信元のネットワーク・アダプタによって計算されイーサネット・パケットに詰め込まれる周期的冗長検査コード(すなわちＣＲＣコード)によって保護されている。受け取りネットワーク・アダプタは、イーサネット・パケットの完全性を検証するためＣＲＣを復号する。
【０００９】
パケットの完全性が検証されない場合、すなわち、エラーが検出される場合、パケットは破棄される。ＴＣＰ／ＩＰプロトコルのＩＰ部分は、"データグラム"として知られるもので、イーサネット・パケットの範囲内にカプセル化されている。データグラムは、３２ビットのＩＰアドレスおよびＩＰヘッダを保護する１６ビットのチェックサム・コードを含む。ＩＰは、より一般的にはネットワーク・アドレスとして知られているものである。ＩＰヘッダの完全性が検証されないと、データグラムは破棄される。ＴＣＰ／ＩＰプロトコルのＴＣＰ部分は、データグラムの範囲内にカプセル化され、ＴＣＰヘッダおよびデータグラムのＴＣＰ部分のコンテントを保護する１６ビットのチェックサム・コードを持つ。ＴＣＰヘッダまたはＴＣＰ部分のコンテントの完全性が検証されない場合、データグラムは破棄され、送信元は、意図された受け取り人から肯定応答データグラムを受け取らなかったならその後パケットを再送信する。このパケットは、ハードウェア(イーサネット)アドレスおよびネットワーク(ＩＰ)アドレスという２つのアドレスを含む点に注意する必要がある。これら２つのアドレスの関係を以下詳細に記述する。
【００１０】
図２は、従来技術のネットワーク２６を示している。ネットワーク２６は、ネットワーク・ノード２８、３０、３２、３４、３６、３８、４０、４２および４４を相互に接続させる。上述のように、ネットワーク・ノードは、例えば、コンピュータ・ワークステーション、サーバ、ネットワーク・プリンタ、ネットワーク・スキャナなどのような装置である。以下の記述において、ネットワーク・ノードは、イーサネット・ネットワーク・アダプタを備えていて、ＴＣＰ／ＩＰプロトコルを使用してデータを伝送すると仮定する。多くのネットワークは、ＩＥＥＥによって発布された一連の規格に従う。この一連の規格は、当業界においてＩＥＥＥ８０２ファミリ規格として知られている。本明細書はＩＥＥＥ８０２ファミリ規格を参照する。
【００１１】
いくつかのネットワーク・ノードがハブを介して１つのＬＡＮセグメントにまとめられる。１つのＬＡＮセグメントにおける各ノードは別のノードがパケットを送信することを試みる時信号を受け取り、また、１つのＬＡＮセグメントにおける２つのノードが同時にパケットの伝送を試みるとき衝突が発生するので、１つのＬＡＮセグメントにおけるすべてのノードは共通の衝突ドメインの中にある。イーサネット・プロトコルは、２つのノードがそれぞれのパケットを再送信しようとする時更にもう１つの衝突が発生する可能性を最小にする転送アルゴリズムを含む。図２において、ネットワーク・ノード２８、３０および３２はハブ４６を介してＬＡＮセグメント４８として結合され、同様に、ネットワーク・ノード４、３６および３８は、ハブ５０を介してＬＡＮセグメント５０として結合され、ネットワーク・ノード４０、４２および４４は、ハブ５４を介してＬＡＮセグメント５６として結合されている。
【００１２】
ローカルまたは遠隔のＬＡＮセグメントを相互接続させるためスイッチおよびブリッジが使用される。スイッチおよびブリッジは、(しばしばサブネットと呼ばれる)単一の論理ネットワークを形成し、ＯＳＩ参照モデル１０のデータ・リンク層１４およびハードウェア層１２での動作を実行する。図２において、スイッチ５８はＬＡＮセグメント４８および５２を接続している。イーサネット・プロトコルにおいては、パケットは、媒体アクセス制御(すなわちＭＡＣ)アドレスによってアドレス指定される。スイッチおよびブリッジは、接続する各ＬＡＮセグメント上のネットワーク・ノードのＭＡＣアドレスのリストを維持する。ＭＡＣアドレスによってアドレス指定されるノードを含むＬＡＮセグメントに各パケットを経路指定するスイッチまたはブリッジの範囲内の適切なポートへ個々のパケットが伝送される。
【００１３】
スイッチおよびブリッジがサブネットを形成するようにＬＡＮセグメントを結合する一方、インターネットまたはワイド・エリア・ネットワーク(ＷＡＮ)のような別のネットワークを経由してサブネット同志を結合するため、ルータ(経路指定機構)が使用される。ルータは、また、共通のサブネットの範囲内でパケットの経路指定を行うためにも使用される場合がある(詳細は後述)。ルータは、(ＩＰアドレスのような)より高位のプロトコル・アドレスをルータのポートと関連付けるテーブルを維持する。スイッチおよびブリッジと対照的に、ルータは、階層的トポロジーとしてネットワークを見ることができる。この場合、大きいブロックおよび範囲のアドレスが、更なる経路指定のため他のルータへ送付される。この理由のため、インターネットのような非常に大きいネットワークにおいて、複数パケットを経路指定するため、ルータがしばしば使用される。
【００１４】
デフォルト・ゲートウェイは、送出パケットを同じサブネット上のノードへアドレス指定することをノードが決定することができない時、そのノードがパケットを送付する先のルータである。デフォルト・ゲートウェイに送付されたパケットは、宛先ノードへ到着するまでにいくつかの他のルータによって処理される可能性がある。
【００１５】
ＴＣＰ／ＩＰプロトコルがイーサネット・プロトコルのような低位のハードウェア・プロトコルで動作することを可能にするいくつかのプロトコルが定義されている。例えば、ＴＣＰ／ＩＰを使用するように構成されたイーサネット・ノードは、サブネット・マスクおよびデフォルト・ゲートウェイ・アドレスをＩＰアドレスに割り当てられる。サブネット・マスクは、同じサブネットの上にあるＩＰアドレスを識別し、デフォルト・ゲートウェイ・アドレスは、同じサブネット上にないパケットを処理するルータを識別する。同じサブネット上のパケットに関しては、アドレス・レゾリューション・プロトコル(ＡＲＰ)を使用して、宛先ノードのＩＰアドレスが見つけ出される。
【００１６】
ノード２８が192.44.133.13というＩＰアドレスを持ち、ノード３０が192.44.133.25というＩＰアドレスを持つと仮定する。更に、ノード２８のサブネット・マスクが255.255.255.0に設定されると仮定する。ノード２８は、パケットをノード３０に送るため、先ずノード３０のＩＰアドレスとサブネット・マスクのビット単位ＡＮＤ演算を行い、その結果をノード２８のＩＰアドレスとサブネット・マスクのビット単位ＡＮＤ演算と比較する。２つのＡＮＤ演算が一致すれば、ノード３０はノード２８と同じサブネット上にあり、ノード３０のＭＡＣアドレスはＡＲＰを使用して判明できる。次に、ノード２８は、ＡＲＰに従ってそれ自身のＭＡＣアドレスおよびノード３０のＩＰアドレスを用いてブロードキャスト・イーサネット・パケットを送出する。イーサネット・プロトコルは、ユニキャストおよびブロードキャスト・パケットをサポートする。ブロードキャスト・パケットは、１つのサブネット上のすべてのノードへアドレス指定され、すべてのノードによって受け取られるものであり、一方、ユニキャスト・パケットは、特定のノードへアドレス指定され、特定のノードによって受け取られるものである。
【００１７】
ノード３０は、ノード３０のＭＡＣアドレスを含むユニキャスト・パケットをノード２８に送り戻すことによってこのメッセージに応答する。次に、ノード２８は、ノード３０から受け取ったＭＡＣアドレスを使用してＴＣＰ／ＩＰパケットをノード３０に伝送する。更に、ノードは将来の伝送のためこの情報をキャッシュ記憶して、同じサブネット上のノードのＭＡＣアドレスの検出を反復するする必要性を最小限にとどめる。
【００１８】
更に、上述のように構成されたノード２８が、168.45.198.2というＩＰアドレスを持つノード４０にパケットを送信することを試みると仮定する。ノード２８は、上述のビット単位ＡＮＤ演算を使用するサブネット・マスクに基づいて、ノード４０が同じサブネット上にないと判断する。このような場合、ノード２８が同じサブネットにあることを検証することができないノードにアドレス指定されているパケットを伝送するためにノード２８によって使用されるデフォルト・ゲートウェイであるルータ６２にノード２８はそのパケットを中継する。ルータ６２は、ルータ６８へ、ルータ６８はルータ６９へ、ルータ６９はルータ６０へそのパケットを順に中継する。ルータ６０は(宛先ノードである)ノード４０と同じサブネット上にあるので、ルータ６０は、ＡＲＰを使用してノード４０のＭＡＣアドレスを検出し、ノード４０のＭＡＣアドレスでそのパケットのアドレスを再指定し、その結果、ＬＡＮセグメント５６へそのパケットを伝送して、そのパケットがノード４０によって受け取られる。
【００１９】
ＩＰアドレス、サブネット・マスク、デフォルト・ゲートウェイのアドレスおよびその他のパラメータでノードが構成されることを許容する種々のプロトコルが定義されている。以下の記述において、"クライアント"、"クライアント・ノード"および"構成されるべきノード"という用語は、それ自身のための構成パラメータを取得することを求めるネットワーク・ノードを意味する。また、「サーバ」という用語は、構成パラメータを提供するネットワーク・ノードを意味する。１つの単純なプロトコルは、イーサネット・ネットワーク上で実行され、イーサネット・アドレスをＩＰアドレスに変換する逆アドレス変換プロトコル(Reverse Address Resolution Protocolの頭文字を取ってＲＡＲＰと略称される)である。クライアントが、そのＭＡＣアドレスを用いてイーサネット・パケットをブロードキャストすると、サーバが、クライアントのＩＰアドレスを含むユニキャスト・パケットをクライアントに伝送することによって応答する。ＲＡＲＰは、主にディスクのないネットワーク・ノードによって使用される。
【００２０】
ディスクのないノードで構成されるネットワークにおいて一般に使用されるもう１つの標準プロトコルは、ブートストラップ・プロトコル(略してＢＯＯＴＰ)である。ＢＯＯＴＰは、ユーザ・データグラム・プロトコル(略してＵＤＰ)を使用する。ＢＯＯＴＰは、ノードが、それ自身のＩＰアドレス、サブネット・マスク、デフォルト・ゲートウェイ・アドレス、ＢＯＯＴＰサーバのアドレス、および、ノードが起動する時ＢＯＯＴＰサーバからロードされるブート・ファイルをポイントするパス名を決定することを可能にする。ＢＯＯＴＰは、また、構成パラメータを捜し求めているノードが別のサブネット上のＢＯＯＴＰサーバによってサービスを提供されることを可能にするＢＯＯＴＰ中継エージェントを定義している。ＢＯＯＴＰは、ＲＦＣ(意見を求める案)９５１に定義されている。
【００２１】
また、ネットワーク情報プロトコル(略してＮＩＰ)は、ネットワーク・ノードがそれ自身のＩＰアドレスを決定し、ＩＰアドレスが使用中であるか否かを判断するためネットワーク・ノードがポーリングされる"ポーリング／防御"メカニズムを使用することによって使用可能なＩＰアドレスを識別することを可能にする。クライアントは、ポーリングしているメッセージに応答することによって使用中のＩＰアドレスを防御する。クライアントがＩＰアドレスを捜し求めているメッセージを送出する時、ＮＩＰサーバは、ネットワーク上で利用できるＩＰアドレス・セットを返す。クライアントは、ＩＰアドレスの１つを選択し、ＡＲＰを使用して、そのＩＰアドレスが利用できることを確認する２重検証を行う。クライアントは、次に、ＮＩＰサーバに応答することによって自身のＩＰアドレスを確保し、ＮＩＰサーバは割り当てられたＩＰアドレスを記録する。
【００２２】
最後に、動的ホスト構成プロトコル(Dynamic Host Configuration Protocolを略してＤＨＣＰと呼ばれる)は、ＲＦＣ１５４１およびＲＦＣ１５３３に記述されているＢＯＯＴＰの拡張である。ＢＯＯＴＰの拡張であるから、ＤＨＣＰはＢＯＯＴＰによって提供されるすべてのサービスを提供する。ＤＨＣＰは、有限のリースを持つ(従って一定時間経過後満期になる)ＩＰアドレスの自動割り当て、無限リースを持つ(従って決して満期にならない)ＩＰアドレスの自動割り当て、および、ネットワーク管理者によって選択されるＩＰアドレスの静的割り当てを提供することができる。
【００２３】
下記表１は、クライアント／サーバ対話の記述とともにＤＨＣＰプロトコルに従って交換される主要メッセージである。
【００２４】
【表１】
0004519214.tif 000002
【００２５】
クライアントとサーバの間の構成対話は、そのローカル・サブネット上にDHCPDISCOVERメッセージをブロードキャストするクライアントから始まる。そのサブネット上のＢＯＯＴＰ中継ソフトウェア・エージェントが、同じサブネット上にないＤＨＣＰサーバにそのメッセージを伝える。次に、各サーバは、利用できるネットワークＩＰアドレスおよびその他の構成パラメータを含むDHCPOFFERメッセージで応答する。サーバは可能であればそのクライアントにDHCPOFFERメッセージをユニキャストし、また必要に応じてＢＯＯＴＰ中継エージェントを使用する。代替的に、サーバは、ブロードキャスト・アドレスを使用して、そのクライアントのサブネットにメッセージをブロードキャストすることもできる。
【００２６】
クライアントは、次に、１つまたは複数のサーバから１つまたは複数のDHCPOFFERメッセージを受け取る。クライアントは、複数の応答を待って待機することを選択することができる。DHCPOFFERメッセージで申し出を受けた構成パラメータに基づいた構成パラメータを要求するため１つのサーバを選択する。クライアントは、どのサーバを選択したかを標示するサーバ識別子オプションを必ず含むDHCPREQUESTメッセージをブロードキャストする。このメッセージは、所望の構成値を指定するその他のオプションを含むこともできる。
【００２７】
すべてのサーバはクライアントからDHCPREQUESTブロードキャストを受け取り、DHCPREQUESTメッセージによって選択されなかったサーバ(複数)は、クライアントがそのサーバの申し出を辞退したことの通知としてそのメッセージを使用する。DHCPREQUESTメッセージによって選択されたサーバは、クライアントとの連結をコミットして、構成パラメータを含むDHCPACKメッセージで応答する。選択されたサーバがDHCPREQUESTメッセージを満たすことができないならば、サーバは、クライアントの要求を拒否するDHCPNAKメッセージで応答する。
【００２８】
クライアントはDHCPNAKメッセージを受け取ると、やり直しする。クライアントが構成パラメータを含むDHCPACKメッセージを受け取ると、クライアントは、パラメータに関する最終的検証を実行し、ＩＰアドレスが有効な(リースの持続)時間の長さおよびDHCPACKメッセージに指定されるリース識別情報を確認する。この時点で、クライアントは、クライアントＩＰアドレス、サブネット・マスクおよびデフォルト・ゲートウェイ・アドレスで構成される。クライアントがDHCPACKメッセージの中のパラメータに関して問題を検出する場合、クライアントは、DHCPDECLINEメッセージをサーバに送り返して、構成プロセスをやり直す。クライアントは、サーバにDHCPRELEASEメッセージを送ることによってＩＰアドレスに関するリースを放棄することができる。ＢＯＯＴＰプロトコルにおけるメッセージの対話も同様である。
【００２９】
【発明が解決しようとする課題】
上記従来技術のノードは、宛先ノードが同じサブネット上にあるか否か判断するためサブネット・マスクを使用する。サブネット・マスク・メカニズムは、２の累乗のノード・アドレスがサブネットに加えられなければならず、これは必ずしも常に実用的または可能ではないので、柔軟性に欠けている。それ自身のゲートウェイであるようにノードを構成することが望ましいにも関わらず、ＤＨＣＰのような従来技術構成プロトコールは、ネットワーク・ノードがそれ自身のゲートウェイとして構成されることを許容しない。従って、このな問題の解決が求められている。
【００３０】
【課題を解決するための手段】
本発明は、ネットワーク・ノードが、それ自身のゲートウェイ・アドレスとして構成されることができるように、ＩＰアドレスおよびデフォルト・ゲートウェイ・アドレスで自動的に構成されることを可能にする構成エージェントを提供する。それ自身のデフォルト・ゲートウェイであるようにノードを構成することによって、ノードは、サブネット内およびサブネット外パケットを処理する共通のデフォルト・ゲートウェイ・ルーチンを実行することができる。本発明に従った構成エージェントは、構成されるべきノードを含む１つのネットワーク・セグメントおよび構成パラメータを自動的に提供することができる機能を有するサーバを含む別の１つのネットワーク・セグメントという２つのネットワーク・セグメントに接続される(スイッチまたはブリッジのような)ネットワーク装置の上に配置される。
【００３１】
本発明の第１の側面において、構成エージェントは詮索型エージェントの役を果たす。構成サーバから構成されるべきノードへのメッセージが、ＩＰアドレスおよびデフォルト・ゲートウェイ・アドレスを含むメッセージを発見するため詮索される。そのようなメッセージは、構成を求めているノードに申し出されているＩＰアドレスをデフォルト・ゲートウェイ・アドレスにコピーするように変更され、そのメッセージがその意図されている宛先に送られることによって、構成されることを求めているノードがそれ自身のデフォルト・ゲートウェイであるように構成されることが可能にされる。場合によっては、構成されることを求めているノードへの構成サーバからのメッセージがブロードキャスト・メッセージであることを保証するため、構成されるべきノードから構成サーバへのメッセージが変更される。
【００３２】
本発明の第２の側面において、構成エージェントは代理エージェントの役を果たす。構成されようとしているノードから見れば、代理エージェントは構成エージェントであるように見える。構成サーバから見れば、構成サーバおよび構成されることを求めているノードが異なるサブネット上に存在するとすれば、代理エージェントは中継エージェントであるように見える。それらが同じサブネット上にあれば、代理エージェントは、詮索エージェントの場合と同様に、構成サーバから構成されることを求めているノードへのメッセージを処理する。
【００３３】
構成されることを求めているノードが、ＩＰアドレスおよびデフォルト・ゲートウェイで構成されることを求めていることを標示するメッセージを送る時、代理エージェントがそのメッセージを受け取る。代理エージェントは、サーバからユニキャストまたはブロードキャスト応答を要求するようにメッセージを変更する。加えて、構成されるべきノードおよび構成エージェントが同じサブネット上にないならば、構成サーバが代理エージェントを中継エージェントとしてみなすようにメッセージが変更される。
【００３４】
構成サーバが(おそらく代理エージェントを中継エージェントとしてみなして)構成されるべきノードにメッセージを送る時、代理エージェントは、メッセージをインターセプトして、メッセージで提供されたＩＰアドレスをデフォルト・ゲートウェイ・アドレスにコピーする。これによって、構成されることを求めているノードがそれ自身のデフォルト・ゲートウェイとして構成されることが可能とされる。代理エージェントは、また、実際の構成サーバのＩＰアドレスを代理エージェントのＩＰアドレスと置き換えて、構成されることを求めているノードが代理エージェントを構成エージェントとして見なすことを可能にする。
【００３５】
【発明の実施の形態】
本発明は、スイッチのようなネットワーク装置上に位置する構成エージェントである。構成エージェントは、たとえサブネット・マスクがノードが異なるサブネット上にあることを標示しても、同じサブネット上にあるノードと直接通信するため、構成パラメータを捜し求めているネットワーク・ノードがそれ自身のデフォルト・ゲートウェイとして構成されることを可能にする。本発明の詳細な記述の前に、コンピュータ・ネットワークの技術分野における最近の傾向を考察する。
【００３６】
伝統的に、大規模ＴＣＰ／ＩＰネットワークは、ネットワーク・ノードの間でパケットを伝送するためしばしばルータを使用してきた。しかしながら、スイッチと比較して、ルータは比較的遅く、プロセッサ集約的である。加えて、ルータはスイッチよりかなり高価である。
【００３７】
上述のように、イーサネット・ネットワークを通して接続される２つのＴＣＰ／ＩＰノードは、宛先ＩＰアドレスが同じイーサネット・ネットワーク上にあることを送信元ノードのサブネット・マスクが標示することを前提とすれば、ルータなしに直接通信することができる。送信元ノードは、サブネット・マスクおよびそのＩＰアドレスに関するビット単位ＡＮＤ演算を実行して、その結果をサブネット・マスクおよび宛先ＩＰアドレスに関するビット単位ＡＮＤ演算と比較する。結果が一致すれば、送信元ノードは、アドレス・レゾリューション・プロトコル(すなわちＡＲＰ)を使用してＴＣＰ／ＩＰパケットを送信する前にＩＰアドレスをイーサネット・アドレスに変換する。以下の記述において、"ハードウェア・アドレス"という用語は、イーサネットＭＡＣアドレスのようなネットワーク・ハードウェアによって使用される低位アドレスを意味し、"ネットワーク・アドレス"という用語は、ＩＰアドレスのような高位プロトコル・スタックで使用されるアドレスを意味する。
【００３８】
サブネット・マスクは、比較的未完成のメカニズムである。ＩＰアドレスは、２の累乗の単位でネットワークに加えられる。従って、サブネット・マスクが255.255.255.0に設定される場合、１０２４のユニークなＩＰアドレスがネットワーク上で利用することが可能であり、これらのアドレスを割り当てられるノードは、ルータを必要とすることなく直接相互に通信することができる。しかしながら、ネットワーク管理者がそれより多いＩＰアドレスを加えることを望むとすれば、サブネット・マスクの中のビットの１つを消去することによって２０４８のユニークなアドレスが提供される。多くの状況において、これらのアドレスのすべてが利用できるというわけではない。従って、ネットワーク管理者は、宛先パケットによってアドレス指定されるノードがたとえ同じサブネット上にあったとしても、デフォルト・ゲートウェイ・アドレスによって識別されるルータへパケットを送信するようにＴＣＰ／ＩＰを構成することを強制される。実際、構成問題を最小にするため、多くのネットワーク・ノードは、すべてのＴＣＰ／ｌＰパケットをデフォルト・ゲートウェイに送信するように単純に構成される。
【００３９】
この問題の１つの解決策は、そのノード自身のＩＰアドレスに各ノードのデフォルト・ゲートウェイ・アドレスを構成することである。このようにすると、ネットワーク・ノードがＴＣＰ／ＩＰパケットを送信しようとする時、ネットワーク・ノード上のゲートウェイ・サブルーチンがパケットの経路指定を行う。ゲートウェイ・サブルーチンは、ＡＲＰを使用して、パケットを送付すべきＭＡＣアドレスを検出する。ルータおよびスイッチがＡＲＰ代理サーバを含むように構成されることができる点に注意する必要がある。スイッチに関して、ＡＲＰ代理サーバは、サブネット上のすべてのノードのＭＡＣ対ＩＰアドレス対応関係をキャッシュ記憶することによってネットワーク・トラフィックを減少させる。従って、ノードが同じサブネット上の遠隔ノードのＩＰアドレスを検出を試みてＡＲＰ要求パケットをブロードキャストする時、パケットは単にそのＬＡＮセグメントの範囲内で送信されるだけである。ＬＡＮセグメントがスイッチを介してサブネットに統合されていれば、ＡＲＰ代理サーバは必要とされない。しかしながら、スイッチ上にＡＲＰ代理サーバがないと、ＡＲＰブロードキャストはサブネット上のすべてのノードに伝送されるので、ネットワーク・トラフィックは増加する。スイッチがＡＲＰ代理サーバを持つとして、ゲートウェイ・サブルーチンがＡＲＰを使用して、別のＬＡＮセグメント上の遠隔ノードのＭＡＣアドレスを検出する時、ＡＲＰ代理サーバが遠隔ノードのＭＡＣアドレスを提供する。
【００４０】
対照的に、異なるサブネット上のノードがＡＲＰを使用して通信するとすれば、ルータ上のＡＲＰ代理サーバが必要とされる。ルータのＡＲＰ代理サーバは、ＭＡＣアドレスおよびＩＰアドレスの対応関係を維持する。しかしながら、サブネット外ノードの場合、ルータのＡＲＰ代理サーバによって提供されるＭＡＣアドレスは、そのルータ自身のＭＡＣアドレスである。ゲートウェイ・サブルーチンが別のサブネット上の遠隔ノードのＭＡＣアドレスを見つけるためＡＲＰを使用する時、ルータのＡＲＰ代理サーバは、ルータのＭＡＣアドレスを応答するので、更に経路指定を行うためパケットがルータに送信される。
【００４１】
ＡＲＰはすべてのＩＰアドレスを検出するために使用されるので、同じサブネット上のすべてのパケットはスイッチによって経路指定され、ルータは、そのイーサネット・ネットワークから実際に離れているパケットを伝送するためにだけ使用される。スイッチはルータより速いので、ネットワークの範囲内で送られるＴＣＰ／ＩＰパケットは比較的速く伝送される。サブネット・マスク・メカニズムと比較すると、ゲートウェイ・サブルーチンは、２の累乗でＩＰアドレスを加えることに限定されていない。また、加えられる範囲は連続的である必要はない。従って、ネットワーク管理者は、イーサネット・ネットワークにＩＰアドレスを一層柔軟に割り当てることができる。
【００４２】
この手法を追求する際、ネットワーク管理者が直面する１つの問題は、各ネットワーク・ノードをそれ自身のゲートウェイであるように構成することである。当然のことであるがこれは手操作で実施することはできるが、それは初歩のユーザにとって適切な解決策ではない。加えて、多くのノードを持つネットワークにとってこれは受け入れることのできる解決策ではない。
【００４３】
ネットワーク管理を単純化するため、多くのネットワーク管理者は、既に、ＢＯＯＴＰまたはＤＨＣＰのような自動ホスト構成プロトコルへ移行している。あいにく、これらのプロトコルは、ネットワーク・ノードをそれ自身のゲートウェイであるように構成することをサポートしていない。ネットワーク管理者が、自動ホスト構成プロトコル・サーバを確立する作業に着手し、そのサーバから構成パラメータを受け取るようにすべてのネットワーク・ノードを構成した後管理者が手動構成に戻る可能性はほとんどない。
【００４４】
本発明はこのジレンマを解く。１つの実施形態において、スイッチ(または同様のネットワーク装)はＤＨＣＰ詮索エージェントを含む。詮索エージェントは、スイッチを通して伝送されるパケットを詮索して、ＤＨＣＰ構成メッセージを監視する。ネットワーク・ノード方向の、構成パラメータを含むメッセージを検出する時、詮索エージェントは、候補ＩＰアドレスを含むフィールドをデフォルト・ゲートウェイを含むフィールドにコピーする。次に、詮索エージェントは、そのパケットを意図されたノードへ送信する。これによって、ネットワーク・ノードに記憶されたデフォルト・ゲートウェイのＩＰアドレスがノード自身のＩＰアドレスに設定されることが可能にされる。
【００４５】
第２の、一層洗練された実施形態において、スイッチ(または同様の装置)はＤＨＣＰ代理エージェントを含む。構成情報を捜し求めているネットワーク・ノードから見れば、代理エージェントは、ＤＨＣＰサーバであるように見える。ＤＨＣＰサーバから見れば、代理エージェントは、構成されるべきクライアント、および、ＤＨＣＰサーバが異なるサブネット上にあるとすれば、ＤＨＣＰ／ＢＯＯＴＰ中継エージェントであるように見える。クライアントおよびサーバが同じサブネット上にあれば、代理エージェントは、サーバからクライアントへのメッセージを、詮索エージェントと同じように、処理する。ＤＨＣＰ／ＢＯＯＴＰ中継エージェントは、当業界においては既知であり、ネットワークの間で構成パラメータを中継するために使用される。代理エージェントは、構成パラメータを求めるネットワーク・ノードとＤＨＣＰサーバの間に位置するので、代理エージェントが、候補ＩＰアドレスを含むフィールドをデフォルト・ゲートウェイを含むフィールドへコピーすることによってＤＨＣＰサーバとの間で伝送されているメッセージを変更することができる。上記２つの実施形態の詳細は以下に記述される。
【００４６】
本発明は、動的ホスト構成プロトコル(すなわちＤＨＣＰ)を引用して記述される。しかし、本発明はＤＨＣＰに限定されていない。本発明がＢＯＯＴＰのようなその他の類似したプロトコルにも適用できることは当業者に理解されるであろう。ＤＨＣＰメッセージの形式は、下記表２にリストされている。この形式はＲＦＣ１５４１からと取り出したものである。各フィールドの定義は、下記表３の通りである。
【００４７】
【表２】
0004519214.tif 000003
【００４８】
【表３】
0004519214.tif 000004
【００４９】
図３は、本発明に従った構成エージェントを有するスイッチ７６を含むネットワーク７４を示す。図３は、構成エージェントがＤＨＣＰ詮索エージェントである第１の実施形態、および、構成エージェントがＤＨＣＰ代理エージェントである第２の実施形態の両者に対して共通である。スイッチ７６は、ハブ８０およびハブ８４を経由してＬＡＮセグメント７８をＬＡＮセグメント８２に連結する。ＬＡＮセグメント７８は構成されることを求めるネットワーク・ノード８６を含み、ＬＡＮセグメント８２は構成パラメータを提供するＤＨＣＰサーバ８８を含む。本発明の両方の構成において、スイッチ上の構成エージェントは、ノード８６およびサーバ８８の間の対話を変更する。従って、スイッチ７６は、ノード８６およびサーバ８８の間の通信経路がスイッチ７６を通過するように、ノード８６およびサーバ８８の間に配置されることが好ましい。
【００５０】
図４は、本発明の第１の実施形態に従うＮポート・スイッチ９０を示す。各ポートは、送出装置１００への入力経路、および、出力バッファ９２、９４、９６および９８のような出力バッファを含む出力経路を持つ。更に、送出装置１００は、ＤＨＣＰ詮索エージェント１０２を含む。以下に記述される場合を除いて、送出装置１００は従来技術における既知の方法で、パケットを送出する。
【００５１】
図５は、ＤＨＣＰ詮索エージェント１０２がパケットを処理する方法を示す流れ図１０４である。ブロック１０６においてパケットが受け取られる。ブロック１０８は、そのパケットがそれ自身のゲートウェイとして構成されるべきネットワーク・ノードを指定しているHCPDISCOVER、DHCPREQUEST、DHCPOFFERまたはDHCPACKパケットであるか否か判断する。本発明の１つの構成において、"援助"されるべきノードのテーブルを維持することによって一定のＭＡＣアドレスを持つノードを単に"援助"するようにスイッチ９０が構成される場合があることに注意する必要がある。言い換えると、それ自身のゲートウェイとして構成されることが望ましいノードもあれば、従来技術に従って構成されるのが望ましいノードもある。パケットが上記のタイプの１つでなけば、あるいは、パケットが"援助"されるべきものではないノードからのパケットであれば、ブロック１０８は"NO"に分岐して、ブロック１１０においてパケットが伝送される。制御はブロック１０６に渡り、次のパケットを待機する。
【００５２】
パケットがDHCPDISCOVERまたはDHCPREQUESTパケットであれば、ブロック１０８は"YES"に分岐して、ブロック１１２へ進み、そこで、パケットのＢフラグがセットされているか否か検査される。Ｂフラグの機能はＲＦＣ１５４１において次のように定義されている。
【００５３】
「そのプロトコル・ソフトウェアがＩＰアドレスで構成されるまでユニキャストＩＰデータグラムを受け取ることができないクライアントは、そのクライアントが送るDHCPDISCOVERまたはDHCPREQUESTメッセージにおけるフラグ・フィールドのBROADCAST(ブロードキャスト)ビット(すなわちＢフラグ)を１に設定しなければならない。Ｂフラグは、ＤＨＣＰサーバおよびＢＯＯＴＰ中継エージェントがクライアントのサブネット上にクライアントに対するメッセージをブロードキャストするためのヒントを与える。そのプロトコル・ソフトウェアが構成される前にユニキャストＩＰデータグラムを受け取ることができるクライアントは、Ｂフラグ・ビットを０に設定しなければならない。('giaddr'フィールドに指定されている中継エージェントへではなく)ＤＨＣＰクライアントに直接ＤＨＣＰメッセージを送信または中継するサーバまたは中継エージェントは、Ｂフラグを検査しなければならない。Ｂフラグが１に設定されていれば、ＩＰ宛先アドレスとしてＩＰブロードキャスト・アドレス(好ましくは255.255.255.255)を、リンク層(イーサーネット)宛先アドレスとしてリンク層(イーサーネット)ブロードキャスト・アドレスを使用してＤＨＣＰはＩＰブロードキャストとして送信されなければならない。Ｂフラグが０に設定されていれば、メッセージは、ＩＰとしてユニキャストを送られなければならない"YIADDR"フィールドに指定されているＩＰアドレスおよび"CHADDR"フィールドに指定されているリンク層(イーサーネット)へのＩＰユニキャストとしてそのメッセージは送信されなければならない。ユニキャスト送信が可能でないならば、ＩＰ宛先アドレスとしてＩＰブロードキャスト・アドレス(好ましくは255.255.255.255)を、リンク層(イーサーネット)宛先アドレスとしてリンク層(イーサーネット)ブロードキャスト・アドレスを使用してＩＰブロードキャストとしてそのメッセージを送信してもよい。」
一部のスイッチは、ユニキャストおよびブロードキャスト・パケットをトラップおよび処理することができる。このタイプのスイッチは、ブロック１１２および１１４をスキップして、ブロック１１０においてパケットを送信し、Ｂフラグを解除する。しかしながら、その他のスイッチは、スイッチＭＡＣアドレスに直接アドレスされるパケットをトラップすることができるだけである。このタイプのスイッチにとって、構成対話に関係しているすべてのパケットがイーサネット・ブロードキャスト・パケットであって、スイッチのＣＰＵがパケットをインターセプトすることができることが重要である。
【００５４】
初期的DHCPDISCOVERおよびDHCPREQUESTパケットは、クライアントが通常ＤＨＣＰサーバにおけるＩＰアドレスを知らないので、典型的には、イーサネット・ブロードキャスト・パケットである。しかしながら、クライアントがＩＰアドレスで構成される前にユニキャストＩＰデータグラムを受け取ることができるならば、クライアントはＢフラグを設定し、ＤＨＣＰサーバがノードへ応答を送る方法を決定する時のヒントとしてＢフラグを使用することができる。フラグが解除されると、DHCPOFFER、DHCPACKおよびDHCPNAKパケットはノードへ戻されるユニキャストとなり、そのため、スイッチがユニキャスト・パケットをトラップすることができなければエージェント１０２がパケットをインターセプトすることができなくなる。多くのノードがＩＰアドレスで構成されるまでユニキャストＩＰデータグラムを受ける取ることができないのでＢフラグが既に設定されている可能性が高い。Ｂフラグが設定されていれば、ブロック１１０へ進み、パケットは送信され、制御は次のパケットを待つためブロック１０６へ戻る。フラグが解除されていれば、ブロック１１４へ進み、Ｂフラグが設定され、イーサネット・チェックサムが再計算される。制御はブロック１１０に移り、パケットが送信され、制御は次のパケットを待つためブロック１０６へ戻る。
【００５５】
ブロック１０８において、パケットがDHCPOFFERまたはDHCPACKパケットである場合、制御は下方分岐"YES"からブロック１１６へ進む。ブロック１１６は、オプション・フィールドにおけるデフォルト・ゲートウェイ・フィールドへYIADDRフィールドの候補ＩＰアドレスをコピーして、それ自身のゲートウェイあるようにネットワーク・ノードを構成させ、その後パケット・チェックサムを再計算する。制御はブロック１１０に移り、パケットが送信され、制御は次のパケットを待つためブロック１０６へ戻る。
【００５６】
本発明のこの実施形態の主な利点は、実施が容易で、オーバーヘッドをあまり必要としないことである。しかし、この実施形態には２、３のマイナーな制限がある。ユニキャスト・パケットをインターセプトすることができないスイッチに関して、構成されることを求めているノードがＤＨＣＰサーバのアドレスを知っている時、ノードはそのアドレスを使用して、DHCPDISCOVERおよびDHCPREQUESTパケットをユニキャストするかもしれない。初期的ＤＨＣＰパケットがブロードキャストでないので、ＤＨＣＰ詮索エージェントは、そのようなパケットを見逃し、Ｂフラグを設定することができない。しかしながら、ＤＨＣＰプロトコルの大部分の実施において、構成されることを求めているノードは、ＤＨＣＰサーバのアドレスを知らないので、初期的ＤＨＣＰパケットがブロードキャストでないことを確認する。
【００５７】
ネットワーク・ノードがそのＩＰアドレスのリース期間を更新しようとする時、同じような問題が発生する可能性がある。ノードはＤＨＣＰサーバのアドレスを知っているので、典型的にはノードはサーバにDHCPREQUESTパケットをユニキャストする。ＤＨＣＰ詮索エージェントは、ユニキャスト・パケットをインターセプトすることができないスイッチ上に所在するので、Ｂフラグを設定する機会のないままこのメッセージをサーバに直接送信する。クライアントはＩＰアドレスで構成され、従って、ユニキャストＩＰデータグラムを受け取ることができるので、クライアントはＢフラグを解除し、ＤＨＣＰサーバはユニキャスト・メッセージで応答する可能性が高い。ＤＨＣＰサーバは、修正されたデフォルト・ゲートウェイ・アドレスを認識しないので、パケットを破棄するか、正しいと信じているアドレスにデフォルト・ゲートウェイ・アドレスを戻すことを試みるかもしれない。
【００５８】
メッセージはクライアントへのユニキャストであるから、ＤＨＣＰ詮索エージェントがデフォルト・ゲートウェイ・アドレスを修正する機会はない。従って、ＤＨＣＰサーバを修正しない場合、この実施形態は、ユニキャスト・パケットをインターセプトすることができないスイッチに関する動的アドレス割り当ての問題を持つ可能性がある。一方、ＤＨＣＰサーバがクライアントによって提供されるデフォルト・ゲートウェイを使用するように修正されれば、本発明が従来技術のＤＨＣＰサーバを用いて動作するという大きな利点が得られる。当然、ユニキャスト・パケットをインターセプトすることができるスイッチは影響を受けない。
【００５９】
もう１つのマイナーな欠点は、Ｂフラグを設定することが、さもなければＢフラグを解除したままにしておくであろう構成において、ネットワーク・トラフィックを若干増加させることになる点である。このようなマイナーな欠点にもかかわらず、ＤＨＣＰまたはＢＯＯＴＰのような従来技術の自動構成プロトコルを使用してそれ自身のゲートウェイであるようにノードを構成することをネットワーク管理者が求める場合、ＤＨＣＰ詮索エージェントは、多くのネットワークに対して効果的で構成の容易な解決策を提供する。
【００６０】
本発明の第２の実施形態は、上記のようなマイナーな欠点に苦しまない。図６は、本発明の第２の実施形態に従ったＮポート・スイッチ１１８を示す。各ポートは、送出装置１２０への入力経路、および、出力バッファ１２２、１２４、１２６および１２８のような出力バッファを含む出力経路を有する。更に、送出装置１２０は、ＤＨＣＰ代理エージェント１３０を含む。ＤＨＣＰ代理エージェント１３０が、ＤＨＣＰサーバ１３２として構成されることを求めているノードに見えるように構成される。加えて、ＤＨＣＰ代理エージェント１３０のＤＨＣＰ／ＢＯＯＴＰ中継詮索エージェント１３４が、ＤＨＣＰサーバが同じサブネット上になければ、ＤＨＣＰ／ＢＯＯＴＰ中継エージェントとしてのサーバに見えるように構成される。構成されるべきクライアントとＤＨＣＰサーバが同じサブネットの上にあれば、ＤＨＣＰ／ＢＯＯＴＰ中継詮索エージェント１３４が、ＤＨＣＰサーバからクライアントへ伝送されるパケットに関して(第１の実施形態と同様な)詮索エージェントとして機能する。以下に記述される点を除いて、送出装置１２０は従来技術における既知の方法でパケットを送出する。
【００６１】
図７乃至図１０は、ＤＨＣＰ代理エージェント１３０がパケットを処理する方法を示す流れ図１３６である。ブロック１３８においてパケットが受け取られる。制御がブロック１４０に渡り、そこで、そのパケットがそれ自身のゲートウェイとして構成されるべきネットワーク・ノードを指定しているHCPDISCOVER、DHCPREQUEST、DHCPOFFER、DHCPACKまたはDHCPNAKパケットであるか否か判断する。上述のＤＨＣＰ詮索エージェント１０２の場合と同様に、ＤＨＣＰ代理エージェント１３０は、"援助"されるべきネットワーク・ノードを識別するＭＡＣアドレスのテーブルを維持するように構成されることができる。パケットが上記のタイプの１つでなけば、あるいは、ノードが、"援助"されるべきものではない場合、ブロック１４０は"NO"に分岐して、ブロック１４２においてパケットが伝送される。次に制御はブロック１３８に戻り、次のパケットを待機する。
【００６２】
ＤＨＣＰ代理エージェント１３０は構成対話において伝送されるすべてのブロードキャスト・パケットを受け取る点に注意する必要がある。加えて、パケットがクライアントからのユニキャストであれば、構成されることを求めているクライアントがＤＨＣＰ代理エージェント１３０がそのクライアントのＤＨＣＰサーバであると見なすので、ＤＨＣＰ代理エージェント１３０はそれらのパケットを受け取る。
【００６３】
パケットがDHCPDISCOVERまたはDHCPREQUESTパケットであれば、制御は、ブロック１４０の右側の"YES"からブロック１４４へ進む。ブロック１４４は、パケットがCIADDRフィールドにＩＰアドレスを含むDHCPREQUESTパケットであるか否か判断する。クライアント・ノードが以前に割り当てられた構成パラメータを検証することを求めている場合、上記表２および表３に示されるように、DHCPREQUESTパケットのCIADDRフィールドはクライアント・ノードによって記入されているはずである。このプロセスは当業界においてリース更新として知られているものである。パケットがCIADDRフィールドにＩＰアドレスを含むDHCPREQUESTパケットであれば、制御はブロック１４５へ進む。
【００６４】
ブロック１４５は、ＤＨＣＰサーバおよびスイッチが同じサブネット上にあるか否か判断する。これは、ＤＨＣＰ代理エージェント１３０をＤＨＣＰサーバによって構成させることによって判断されるか、あるいは、スイッチは、ＤＨＣＰ応答を受け取る時ＤＨＣＰサーバの存在を動的に知ることができる。ＤＨＣＰサーバおよびスイッチが同じサブネット上にあれば、制御はブロック１４６に移る。ブロック１４６は、先ずサーバ割り当てテーブルをアクセスする。サーバ割り当てテーブルは、以前に構成されたクライアントと構成情報を提供したＤＨＣＰサーバの間の対応関係を維持する。サーバ割り当てテーブルは、ＤＨＣＰサーバを１つだけ持つネットワークにおいては必ずしも必要でない点に注意する必要がある。DHCPACKおよびDHCPREQUESTパケットが処理される時テーブルに１つのエントリが記憶される(詳細は後述)。
【００６５】
ブロック１４６は、クライアントを構成したＤＨＣＰサーバのアドレスをサーバ割り当てテーブルから取り出す。サーバとクライアントが同じサブネット上にあるので、アドレスは、ＭＡＣアドレスまたは(ＡＲＰを使用してＭＡＣアドレスに変換される)ＩＰアドレスである。次に、ブロック１４６は、取り出したＤＨＣＰサーバのＭＡＣアドレスにパケットを再アドレス指定する。次に、ブロック１４６は、(すでに設定されてなければ)Ｂフラグを設定して、それによって、ＤＨＣＰサーバが、上記第１の実施形態と同様に、インターセプトされるブロードキャスト・メッセージを応答することが保証される。最後に、パケット・チェックサムが再計算され、制御はブロック１４２に渡る。
【００６６】
ブロック１４５において、ＤＨＣＰサーバとスイッチが同じサブネット上になければ、制御はブロック１４７に移る。ブロック１４７は、ブロック１４６の場合と同様に、サーバ割り当てテーブルにアクセスして、サーバによって提供されたデフォルト・ゲートウェイ・アドレスと共に、クライアントを構成したＤＨＣＰサーバのＩＰアドレスを取り出す。次に、ブロック１４７は、ＤＨＣＰサーバのＩＰアドレスへパケットを再アドレス指定して、ＤＨＣＰ代理エージェント１３０のＩＰアドレスをGIADDRフィールドに加え、(すでに解除されてなければ)Ｂフラグを解除し、チェックサムを再計算する。ＤＨＣＰ代理エージェント１３０のＩＰアドレスをGIADDRフィールドに加え、Ｂフラグを解除することによって、ＤＨＣＰ代理エージェント１３０がＤＨＣＰサーバに対するＤＨＣＰ／ＢＯＯＴＰ中継エージェントのように見えるので、応答されるユニキャスト・パケットはＤＨＣＰ代理エージェント１３０へ戻される。次に、制御はブロック１４２へ戻り、ＤＨＣＰ代理エージェント１３０のデフォルト・ゲートウェイを通してパケットがＤＨＣＰサーバに伝送される。制御は次のパケットを待機するためブロック１３８に移る。
【００６７】
ブロック１４４において、パケットがCIADDRフィールドにＩＰアドレスを含むDHCPREQUESTパケットでない場合、制御はブロック１４８へ進む。ブロック１４８は、パケットがDHCPREQUESTパケットであるかDHCPDISCOVERパケットであるか判断する。(ここでは、DHCPREQUESTパケットは、CIADDRフィールドにアドレスがあればブロック１４４において"YES"となっているので、当然、CIADDRフィールドにアドレスを持っていない)。パケットがDHCPREQUESTパケットであれば、パケットは、構成されることを求めているノードによって要求されたパラメータを含み、制御はブロック１５０へ進む。ブロッック１５０は、申し出されたネットワーク・ノード対ＤＨＣＰサーバの対応関係でサーバ割り当てテーブルを更新する。クライアントがDHCPREQUESTパケットによってＩＰアドレスに関するリース期間を更新することを求める時、このテーブルが使用される。制御は次にブロック１５２に移る。ブロック１４８において、パケットがDHCPDISCOVERパケットであれば、制御はブロック１５２に進む。
【００６８】
ブロック１５２は、ＤＨＣＰサーバとスイッチが同じサブネット上にあるか否か判断する。この判断は、上述のステップ１４５の場合と同様に行われる。スイッチおよびＤＨＣＰサーバが同じサブネット上になければ、制御はブロック１５４へ進む。ブロック１５４において、GIADDRフィールドにＤＨＣＰ代理エージェント１３０のＩＰアドレスが挿入され、これにより、ＤＨＣＰ代理エージェント１３０はＤＨＣＰサーバにとってＤＨＣＰ／ＢＯＯＴＰ中継エージェントのように見える。次に、ブロック１５４は、ユニキャスト伝送が要求されるように、Ｂフラグを解除する。これはネットワーク・バンド幅を節約する。次に、パケットはＤＨＣＰサーバのＩＰアドレスでアドレス指定される。ＤＨＣＰ代理エージェント１３０がサブネット外ＤＨＣＰサーバに関する限りＤＨＣＰ／ＢＯＯＴＰ中継エージェントの役を果たしているので、ＤＨＣＰ代理エージェント１３０は、応答パケットを調べることによって動的にＤＨＣＰサーバを発見するというＤＨＣＰサーバ・アドレス手操作構成のような従来技術を使用して、ＤＨＣＰサーバのリストを維持することもできる。最後に、パケット・チェックサムが再計算され、制御はブロック１４２に戻って、そこで、パケットはＤＨＣＰ代理エージェント１３０のデフォルト・ゲートウェイを経由して伝送される。次に、制御は次のパケットを待機するためブロック１３８に移る。
【００６９】
ブロック１５２において、ＤＨＣＰサーバおよびスイッチが同じサブネット上にあれば、ブロック１５６に進み、ＤＨＣＰサーバからのブロードキャスト伝送を要求するため、Ｂフラグが設定され、既にＢフラグが解除されていた場合はチェックサムが再計算される。次に、制御はブロック１４２に戻って、そこで、パケットが伝送される。制御は次のパケットを待機するためブロック１３８に移る。
【００７０】
一方、ブロック１４０において、パケットが、"援助"されるように構成されるネットワークのDHCPOFFER、DHCPACKまたはDHCPNAKパケットであれば、制御はブロック１５８に渡り、パケットがDHCPACパケットであるか否か判断される。DHCPACパケットであれば、パケットは構成情報を含むことを意味し、制御はブロック１６０へ進み、ステップ１５０の場合と同様に、ネットワーク・ノード対ＤＨＣＰサーバ対応関係でサーバ割り当てテーブルが更新される。次に、制御はブロック１６２に移る。ブロック１５８においてパケットがDHCPACパケットでない場合も、制御はブロック１６２に移る。
【００７１】
ブロック１６２において、ＤＨＣＰ代理エージェント１３２のＩＰアドレスがSIADDRフィールドにコピーされ、それによって、構成されることを求めているネットワーク・ノードがＤＨＣＰ代理エージェント１３２をそのＤＨＣＰサーバとみなすことが可能となる。ブロック１６２は、ＤＨＣＰ代理エージェント１３２がクライアント・ノードにとってＤＨＣＰ／ＢＯＯＴＰ中継エージェントであるように見えなくするように、GIADDRフィールドを消去する。次に、ノードをそれ自身のデフォルト・ゲートウェイであるように構成するため、候補Ｐアドレスがオプション・フィールドでYIADDRフィールドからデフォルト・ゲートウェイ・フィールドへコピーされる。最後に、パケット・チェックサムが再計算され、制御はブロック１４２に戻って、そこで、パケットが構成されるべきクライアントに送信される。次に、制御は次のパケットを待機するためブロック１３８に移る。
【００７２】
本発明の第２の実施形態は、従来技術のＤＨＣＰサーバを維持しながら、リース更新およびユニキャスト伝送を含めＤＨＣＰメッセージのすべての面をサポートすることを求めるネットワーク管理者に包括的な解決策を提供する。それに加えて、ブロードキャスト・パケットだけをインターセプトすることができるスイッチに関して使用される場合、本発明の第２の実施形態は充分に機能的である。
【００７３】
ネットワーク・ノードがそれ自身のゲートウェイとして自動的に構成されることを可能ににすることによって、本発明の上記２つの実施形態は、自動構成を維持しながら、かつ、ルータを経由するトラフィックを大幅に増加させることなく、スイッチおよびブリッジを追加することによって、ネットワーク管理者がネットワークを拡張することを可能にする。スイッチおよびブリッジはルータより非常に速く、廉価であるので、本発明は、ネットワークを拡張するコストを最小にし、ネットワークの速度を最大にし、自動構成を維持する機会をネットワーク管理者に提供する。
【００７４】
従来技術においては、スイッチまたはブリッジの追加によってネットワークを拡張する時、ネットワーク管理者には３つの選択があった。第１に、管理者は、サブネット・マスクを変更することが可能であった。この選択は、自動構成を許容するが、多くの場合実際的でない２の累乗の数でＩＰアドレスをサブネットに追加しなければならない。第２に、ネットワーク管理者は、それ自身のデフォルト・ゲートウェイであるように各クライアントを手操作で構成することができたが、この選択は、管理者がすでにＤＨＣＰのような自動構成プロトコルを確立する出費を支出していれば、魅力のある候補ではない。最後に、ネットワーク管理者は、ルータを使用することができたが、ルータは速度が遅く高価である。本発明は、第４の選択を提供する。本発明に従えば、構成エージェントは、手操作での構成の実施を必要とすることなく、また、ルータに頼ることもなく、いかなるＩＰアドレスの増加をもサブネットに加えることを可能にする。
【００７５】
以上、特定の実施形態を参照して本発明を記述したが、本発明の理念を逸脱することなく、上記実施形態に種々の変更を加えることが可能である点は当業者に認められることであろう。
【００７６】
本発明には、例として次のような実施様態が含まれる。
【００７７】
（１）クライアントをそれ自身のデフォルト・ゲートウェイであるように構成する方法であって、構成サーバおよびクライアントの間の構成対話の一部であり、該クライアントによって現在使用されているまたは将来使用されるデフォルト・ゲートウェイ・アドレスを含むメッセージをインターセプトするステップと、上記メッセージ中のデフォルト・ゲートウェイ・アドレスを該クライアントのアドレスであるように修正するステップと、上記メッセージを伝送するステップと、を含むクライアント構成方法。
【００７８】
（２）上記メッセージが申し出メッセージである、上記（１）に記載のクライアント構成方法。
【００７９】
（３）上記メッセージが肯定応答メッセージである、上記（１）に記載のクライアント構成方法。
【００８０】
（４）メッセージをインターセプトする上記ステップが、上記サーバからメッセージを受け取るステップを含み、メッセージを伝送する上記ステップが、上記メッセージを上記クライアントに伝送するステップを含む、上記（１）に記載のクライアント構成方法。
【００８１】
（５）上記メッセージ中のデフォルト・ゲートウェイ・アドレスを修正する上記ステップが、該クライアントのネットワーク・アドレスとして現在使用されているまたは将来使用される候補ネットワーク・アドレスを当該メッセージのクライアント・ネットワーク・アドレス・フィールドからコピーし、該メッセージのデフォルト・ゲートウェイ・アドレス・フィールドにその候補アドレスを記憶するステップを含む、上記（１）に記載のクライアント構成方法。
【００８２】
（６）上記メッセージに関連するチェックサムを再計算するステップを、更に含む上記（５）に記載のクライアント構成方法。
【００８３】
（７）構成サーバおよびクライアントの間の構成対話の一部分である発見メッセージまたは要求メッセージをインターセプトするステップと、その発見メッセージまたは要求メッセージを調べて、そのメッセージのブロードキャスト・フラグが設定されているか否かを判断するステップと、ブロードキャスト・フラグが設定されていなければ、ブロードキャスト・フラグを設定し、上記発見メッセージまたは要求メッセージに関連するチェックサムを再計算し、上記発見メッセージまたは要求メッセージを伝送するステップと、を更に含む、上記（１）に記載のクライアント構成方法。
【００８４】
（８）上記メッセージの構成サーバ・アドレス・フィールドに構成エージェントのネットワーク・アドレスを記憶するステップを更に含む、上記（１）に記載のクライアント構成方法。
【００８５】
（９）上記メッセージが肯定応答メッセージであるか否かを判断するステップと、メッセージが肯定応答メッセージであれば、サーバ割り当てテーブルに当該クライアントと上記構成サーバを関連付ける１つのエントリを記憶するステップを更に含む、上記（１）に記載のクライアント構成方法。
【００８６】
（１０）クライアントがそのリースを更新することを求めるネットワーク・アドレスを含む要求メッセージをインターセプトするステップと、構成サーバのアドレスに要求メッセージを再アドレス指定するステップと、要求メッセージを構成サーバに伝送するステップと、を更に含む、上記（１）に記載のクライアント構成方法。
【００８７】
（１１）構成エージェントおよび構成サーバが同じサブネット上にあるか否かを判断し、構成エージェントおよび構成サーバが同じサブネット上にあれば、上記要求メッセージのブロードキャスト・フラグが設定されてなければブロードキャスト・フラグを設定し、上記要求メッセージに関連するチェックサムを再計算するステップを含み、構成サーバのアドレスに要求メッセージを再アドレス指定する上記ステップが、構成サーバのハードウェア・アドレスに上記要求メッセージのハードウェア・アドレスを再アドレス指定するステップを含み、構成エージェントおよび構成サーバが同じサブネット上になければ、上記要求メッセージのブロードキャスト・フラグが解除されてなければブロードキャスト・フラグを解除し、上記要求メッセージの中継エージェント・フィールドに構成エージェントのネットワーク・アドレスを記憶し、上記要求メッセージに関連するチェックサムを再計算するステップを含み、構成サーバのアドレスに要求メッセージを再アドレス指定する上記ステップが、構成サーバのネットワーク・アドレスに上記要求メッセージのネットワーク・アドレスを再アドレス指定するステップを含む、上記（１０）に記載のクライアント構成方法。
【００８８】
（１２）構成サーバのアドレスに上記要求メッセージを再アドレス指定する上記ステップが、サーバ割り当てテーブルにアクセスして、クライアントと既に関連付けられている構成サーバのアドレスを取り出し、クライアントと既に関連付けられている構成サーバのアドレスに上記要求メッセージを再アドレス指定するステップを含む、上記（１０）に記載のクライアント構成方法。
【００８９】
（１３）構成サーバおよびクライアントの間の構成対話の一部である発見メッセージまたは要求メッセージをインターセプトするステップと、構成エージェントおよび構成サーバが同じサブネット上にあるか否か判断するステップと、構成エージェントおよび構成サーバが同じサブネット上にあれば、ブロードキャスト・フラグが設定されていなければ、発見メッセージまたは要求メッセージのブロードキャスト・フラグを設定し、上記発見メッセージまたは上記要求メッセージに関連するチェックサムを再計算し、上記発見メッセージまたは上記要求メッセージを伝送するステップと、構成エージェントおよび構成サーバが同じサブネット上になければ、ブロードキャスト・フラグが解除されていなければ発見メッセージまたは要求メッセージのブロードキャスト・フラグを解除し、発見メッセージまたは要求メッセージの中継エージェント・フィールドに構成エージェントのネットワーク・アドレスを記憶し、発見メッセージまたは要求メッセージに関連するチェックサムを再計算し、発見メッセージまたは要求メッセージを伝送するステップと、を更に含む、上記（１）に記載のクライアント構成方法。
【００９０】
（１４）デフォルト・ゲートウェイ・アドレスでクライアントを構成することができる構成サーバに接続された第１のポートと、デフォルト・ゲートウェイ・アドレスで構成されることを求めているクライアントに接続された第２のポートと、上記第１のポートおよび第２のポートの間に接続され、上記第１および第２のポートの間でパケットを送出する送出装置と、を備えるネットワーク装置であって、上記送出装置が、構成サーバおよびクライアントの間の構成対話の一部である構成パケットをインターセプトする構成エージェントを含み、上記構成パケットがクライアントによって使用されるデフォルト・ゲートウェイ・アドレスを含み、上記構成エージェントが、該クライアントのネットワーク・アドレスであるようにデフォルト・ゲートウェイ・アドレスを修正して、該構成パケットを伝送する、ネットワーク装置。
【００９１】
（１５）上記構成パケットが申し出パケットを含む、上記（１４）に記載のネットワーク装置。
【００９２】
（１６）上記構成パケットが肯定応答パケットを含む、上記（１４）に記載のネットワーク装置。
【００９３】
（１７）上記構成エージェントが、構成サーバからの構成パケットを上記第１のポートで受け取ることによって上記構成パケットをインターセプトし、該構成パケットを上記第２のポートで上記クライアントに伝送すことによって該構成パケットを伝送する、上記（１４）に記載のネットワーク装置。
【００９４】
（１８）該クライアントのネットワーク・アドレスとして現在使用されているまたは将来使用される候補ネットワーク・アドレスを上記構成パケットのクライアント・ネットワーク・アドレス・フィールドからコピーして、上記構成パケットのデフォルト・ゲートウェイ・アドレス・フィールドにその候補アドレスを記憶することによって、上記構成エージェントが、クライアントによって使用されるべきデフォルト・ゲートウェイ・アドレスを修正する、上記（１４）に記載のネットワーク装置。
【００９５】
（１９）上記構成エージェントが、構成パケットを伝送する前に上記構成パケットに関連するチェックサムを再計算する、上記（１４）に記載のネットワーク装置。
【００９６】
（２０）上記構成エージェントが、構成サーバおよびクライアントの間の構成対話の一部である発見メッセージまたは要求メッセージを含むパケットをインターセプトして、該発見メッセージまたは要求メッセージを検査して、ブロードキャスト・フラグが設定されていなければ、発見メッセージまたは要求メッセージのブロードキャスト・フラグを設定し、該パケットに関連するチェックサムを再計算し、上記要求パケットを伝送する、上記（１４）に記載のネットワーク装置。
【００９７】
（２１）上記構成エージェントが、構成パケットの構成サーバ・アドレス・フィールドに構成エージェントのネットワーク・アドレスを記憶する、上記（１４）に記載のネットワーク装置。
【００９８】
（２２）上記構成エージェントが、上記構成パケットが肯定応答メッセージを含むか否かを判断し、構成パケットが肯定応答メッセージを含めば、サーバ割り当てテーブルに当該クライアントと上記構成サーバを関連付ける１つのエントリを記憶する、上記（１４）に記載のネットワーク装置。
【００９９】
（２３）上記構成エージェントが、クライアントがそのリースを更新することを求めるネットワーク・アドレスを含む要求メッセージを含むパケットをインターセプトし、構成サーバのアドレスにそのパケットを再アドレス指定して、そのパケットを構成サーバに伝送する、上記（１４）に記載のネットワーク装置。
【０１００】
（２４）上記構成エージェントが、構成エージェントおよび構成サーバが同じサブネット上にあるか否かを判断し、構成エージェントおよび構成サーバが同じサブネット上にあれば、上記要求メッセージのブロードキャスト・フラグが設定されてなければブロードキャスト・フラグを設定し、上記パケットに関連するチェックサムを再計算し、構成サーバのネットワーク・アドレスに上記パケットを再アドレス指定し、構成エージェントおよび構成サーバが同じサブネット上になければ、上記要求メッセージのブロードキャスト・フラグが解除されてなければブロードキャスト・フラグを解除し、上記要求メッセージの中継エージェント・フィールドに構成エージェントのネットワーク・アドレスを記憶し、上記要求メッセージに関連するチェックサムを再計算し、構成サーバのネットワーク・アドレスに上記パケットを再アドレス指定する、上記（２３）に記載のネットワーク装置。
【０１０１】
（２５）上記構成エージェントが、構成サーバ割り当てテーブルにアクセスして、クライアントと既に関連付けられている構成サーバのアドレスを取り出し、クライアントと既に関連付けられている構成サーバのアドレスに上記パケットを再アドレス指定することによって、上記パケットを構成サーバのアドレスに再アドレス指定する、上記（２３）に記載のネットワーク装置。
【０１０２】
（２６）上記構成エージェントが、構成サーバおよびクライアントの間の構成対話の一部である発見メッセージまたは要求メッセージを含むパケットをインターセプトして、構成エージェントおよび構成サーバが同じサブネット上にあるか否か判断し、構成エージェントおよび構成サーバが同じサブネット上にあれば、ブロードキャスト・フラグが設定されていなければ、発見メッセージまたは要求メッセージのブロードキャスト・フラグを設定し、上記パケットに関連するチェックサムを再計算し、上記パケットを伝送し、構成エージェントおよび構成サーバが同じサブネット上になければ、ブロードキャスト・フラグが解除されていなければ発見メッセージまたは要求メッセージのブロードキャスト・フラグを解除し、上記発見メッセージまたは要求メッセージの中継エージェント・フィールドに構成エージェントのネットワーク・アドレスを記憶し、上記パケットに関連するチェックサムを再計算し、そのパケットを伝送する、上記（１４）に記載のネットワーク装置。
【０１０３】
【発明の効果】
ネットワーク・ノードがそれ自身のゲートウェイとして自動的に構成されることを可能ににすることによって、本発明は、自動構成を維持しながら、かつ、ルータを経由するトラフィックを大幅に増加させることなく、スイッチおよびブリッジを追加することによって、ネットワーク管理者がネットワークを拡張することを可能にする。スイッチおよびブリッジは、ルータより非常に速く、廉価であるので、本発明は、ネットワークを拡張するコストを最小にし、ネットワークの速度を最大にしつつ、ノードの自動構成を維持する機会をネットワーク管理者に提供する。
【図面の簡単な説明】
【図１】ＯＳＩ基準モデルのブロック図である。
【図２】従来技術のネットワークを示すブロック図である。
【図３】本発明に従った構成エージェントを有するスイッチを含むネットワークを示すブロック図である。
【図４】構成エージェントがＤＨＣＰ詮索エージェントである本発明の第１の実施形態に従ったＮポート・スイッチを示すブロック図である。
【図５】図４に示されたＤＨＣＰ詮索エージェントがパケットを処理する方法を示す流れ図である。
【図６】構成エージェントがＤＨＣＰ代理エージェントである本発明の第２の実施形態に従ったＮポート・スイッチを示すブロック図である。
【図７】図８乃至図１０と共に、図６のＤＨＣＰ代理エージェントがパケットを処理する方法を示す流れ図である。
【図８】図７、図９および図１０と共に、図６のＤＨＣＰ代理エージェントがパケットを処理する方法を示す流れ図である。
【図９】図７、図８および図１０と共に、図６のＤＨＣＰ代理エージェントがパケットを処理する方法を示す流れ図である。
【図１０】図７乃至図９と共に、図６のＤＨＣＰ代理エージェントがパケットを処理する方法を示す流れ図である。
【符号の説明】
７４      ネットワーク
７６      構成エージェントを含むスイッチ
８６      構成されるべきネットワーク・ノード(クライアント)
８８、１３２      ＤＨＣＰサーバ
１００、１２０    送出装置
１０２    ＤＨＣＰ詮索エージェント
１３０    ＤＨＣＰ代理エージェント
１３４    ＤＨＣＰ／ＢＯＯＴＰ中継詮索エージェント
【図１】
0004519214.tif 000005
【図２】
0004519214.tif 000006
【図３】
0004519214.tif 000007
【図４】
0004519214.tif 000008
【図５】
0004519214.tif 000009
【図６】
0004519214.tif 000010
【図７】
0004519214.tif 000011
【図８】
0004519214.tif 000012
【図９】
0004519214.tif 000013
【図１０】
0004519214.tif 000014