JP2021508212A - ネットワーク通信方法および装置 - Google Patents

Abstract

ネットワーク通信方法および装置。方法は、宛先ホストのインターネットプロトコルアドレスを取得するために、パケットを受信して解析すること、ネクストホップルートの物理アドレスおよびルートタイプを取得するために、宛先ホストのインターネットプロトコルアドレスに従ってルートネイバーテーブルに対して単一のクエリを実行すること、物理アドレスおよびルートタイプに従ってパケットを送信することを備える。本発明は、３層のカプセル化処理プロセスを簡素化し、リソースの占有を減少させる。

Description

本出願は、2017年12月29日に出願され、「ネットワーク通信方法および装置」と題する中国特許出願番号201711482414.2の優先権を主張し、その全体が参照によって組み込まれる、2018年12月24日に出願されたＰＣＴ特許出願番号PCT/CN2018/122996に対応する。

本発明は、ネットワーク通信の分野に関し、より詳細に言えば、ネットワーク通信方法および装置に関する。

現在、多くの場合で、ＴＣＰ／ＩＰネットワークプロトコルスタックがネットワーク通信を実装するために使用されている。図１に示すように、ＴＣＰ／ＩＰネットワークプロトコルスタックは、４つの層、すなわち、アプリケーション層（Ａｐｐｌｉｃａｔｉｏｎ）、トランスポート層（Ｔｒａｎｓｐｏｒｔ）、ネットワーク層（Ｎｅｔｗｏｒｋ）、およびリンク層（Ｌｉｎｋ）に分割される。図２は、ＴＣＰ／ＩＰプロトコルによって２つのコンピュータ間で実行される通信を示しており、送信時には、カプセル化を上位層から下位層のレイヤーで行う必要があり、宛先ホストに到着後、下位層から上位層へレイヤーごとに解析を行って、デバイス間の通信を実現する。

３層カプセル化は、ルーティングテーブル、ネイバーテーブルおよび様々なスコープのテーブルで主に構成される。ルーティングテーブルはさらにキャッシュを含み得る。統計によると、多くの場合、プログラムはこれらのテーブルを簡単な方法で使用し、ネットワークアーキテクチャが確立されると、対応するテーブルの構造は実質的に変更されない。しかしながら、これらのテーブルはストレージ領域を占有する必要があり、さらに、これらのテーブルで実行される追加、削除、変更およびチェックはそれぞれ異なるロジックに従うため、メンテナンスコストが高くなる。また、リンクの数が多いとランタイムメモリのオーバーヘッドが増加し、多くのサービスシナリオでは、プログラムがクエリ操作を複数回実行する必要があり、メモリオーバーフローのリスクが高くなる。さらに、セキュリティの観点から言えば、そのような設計はＡＲＰ攻撃に対してより脆弱であり、それによって伝送デバイスのパフォーマンスを低下させる。複雑なルーティングテーブルと複雑なネイバーテーブルは、セキュリティや分散環境では望ましくない。

本発明は、伝送装置の動作性能を改善するために、ネットワーク通信伝送方法を提供する。さらに、本発明は、ネットワーク通信装置を提供する。

実施形態では、本発明は、
宛先ホストのインターネットプロトコルアドレスを取得するために、パケットを受信して解析することと、
ネクストホップルートの物理アドレスおよびルートタイプを取得するために、宛先ホストのインターネットプロトコルアドレスに従ってルートネイバーテーブルに対して単一のクエリを実行することと、
物理アドレスおよびルートタイプに従ってパケットを送信することと
を備えるネットワーク通信方法を提供する。

実施形態では、本発明はさらに、
宛先ホストのインターネットプロトコルアドレスを取得するために、パケットを受信して解析することと、
ルートネイバーテーブルが有効かどうかを判定し、有効になっている場合は、ネクストホップルートの物理アドレスおよびルートタイプを取得するために、ルートネイバーテーブルで単一のクエリを実行することと、
物理アドレスおよびルートタイプに従ってパケットを送信することと
を備えるネットワーク通信方法を提供する。

実施形態では、本発明はさらに、
宛先ホストのインターネットプロトコルアドレスを取得するために、パケットを受信して解析することと、
ルートネイバーテーブルが有効かどうかを判定し、有効になっている場合は、ルートネイバーテーブルで単一のクエリを実行し、ネクストホップルートの物理アドレスが見つからない場合は、次のステップを実行することと、
ルートマッチングアルゴリズムにより、ネクストホップルートのインターネットプロトコルアドレスを取得することと、
ネクストホップルートのインターネットプロトコルアドレスに従ってネクストホップルートの物理アドレスを取得することと、
ネクストホップルートの物理アドレスをルートネイバーテーブルに更新し、その物理アドレスにパケットを送信することと
を備えるネットワーク通信方法を提供する。

実施形態では、本発明は、
宛先ホストのインターネットプロトコルアドレスを取得するために、パケットを受信して解析することと、
ルートネイバーテーブルが有効かどうかを判定し、有効でない場合は、ネクストホップルートのインターネットプロトコルアドレスを取得するために、宛先ホストのインターネットプロトコルアドレスに従ってルーティングテーブルにクエリを行うことと、
ネクストホップルートの物理アドレスを取得するために、ネクストホップルートのインターネットプロトコルアドレスに従ってネイバーテーブルにクエリを行うことと、
パケットを物理アドレスに送信することと
を備えるネットワーク通信方法を提供する。

実施形態では、本発明は、ネットワーク通信方法をさらに提供し、ネットワーク通信方法は、
宛先ホストのインターネットプロトコルアドレスがローカルアドレスかどうかを確認し、ローカルアドレスである場合、パケットを受信することと、
パケットのポート番号に従ってパケットをターゲットアプリケーションに送信することと、
ローカルアドレスでない場合、転送機能が有効になっているとき、ルータの物理アドレスを取得するために、ルートネイバーテーブルに対して単一のクエリを実行し、受信したパケットの物理アドレスをルータの物理アドレスに置き換え、受信したパケットをルータの物理アドレスに転送することと
を備える。

実施形態では、本発明は、
宛先ホストのインターネットプロトコルアドレスを取得するためにパケットを受信して解析するために使用される解析ユニットと、
ネクストホップルートの物理アドレスおよびルートタイプを取得するために、宛先ホストのインターネットプロトコルアドレスに従ってルートネイバーテーブルに対して単一のクエリを実行するために使用されるクエリユニットと、
物理アドレスおよびルートタイプに従ってパケットを送信するために使用されるパケット送信ユニットと
を備えるネットワーク通信装置を提供する。

実施形態では、本発明は、
宛先ホストのインターネットプロトコルアドレスを取得するためにパケットを受信して解析するために使用される解析ユニットと、
ルートネイバーテーブルが有効かどうかを判定するために使用される判定ユニットと、
ルートネイバーテーブルが有効な場合、ルートネイバーテーブルに対して単一のクエリを実行して、ネクストホップルートの物理アドレスおよびルートタイプを取得するために使用されるクエリユニットと、
物理アドレスおよびルートタイプに従ってパケットを送信するために使用されるパケット送信ユニットと
を備えるネットワーク通信装置を提供する。

従来技術と比較して、本発明の実施形態は以下の利点を有する：
３つのレイヤーの全てのテーブルが１つのテーブルに結合され、ＩＰアドレスに対応する物理アドレスおよびルート情報を１つのクエリで取得できるため、３つのレイヤーの全てのパケットカプセル化処理プロセスが大幅に簡素化され、リソースの占有率が減少し、余分なメモリオーバーヘッドが最小化され、特定のサービスシナリオでの複数のクエリによるメモリオーバーフロー問題が回避され、操作効率が向上し、メモリオーバーヘッドが減少し、操作パフォーマンスが向上する。
メンテナンスに関しては、メンテナンスする必要があるテーブルは１つだけなので、メンテナンスコストを大幅に削減できる。さらに、ルートネイバーテーブルに対して実行されるクエリ操作は単純であるため、ＡＲＰ攻撃に対する保護が容易になる。

ＴＣＰ／ＩＰネットワークプロトコルスタックのレイヤーの概略図である。 ＴＣＰ／ＩＰプロトコルによって２つのコンピュータ間で実行される通信プロセスの概略図である。 本発明の第１の実施形態によって提供されるネットワーク通信方法のフローチャートである。 本発明の第１の実施形態および第２の実施形態によって提供されるルートネイバーテーブルの概略図である。 本発明の第２の実施形態によって提供されるネットワーク通信方法のフローチャートである。 本発明の第３の実施形態によって提供されるネットワーク通信伝送方法のフローチャートである。 本発明の第４の実施形態によって提供されるネットワーク通信方法のフローチャートである。 本発明の第５の実施形態によって提供されるネットワーク通信方法のフローチャートである。

本発明の完全な理解を容易にするために、多くの特定の詳細が以下の説明に示される。しかしながら、本発明は、本明細書に記載されている以外の多くの方法で実装することができ、当業者は、本発明の本質から逸脱することなく、同様の派生の実施形態を行うことができる。したがって、本発明は、以下に説明する特定の実装によって限定されない。

前述のように、既存の３層データパケットのカプセル化では、ルーティングテーブルおよびネイバーテーブルを使用してデータが送受信される。ルーティングテーブルは、ルータまたはネットワークコンピュータに格納されているスプレッドシート（ファイル）または準データベースである。ルーティングテーブルは、ネットワーク境界のトポロジ情報を含んでいる。ルーティングテーブルを確立する主な目的は、ルーティングプロトコルを実装し、静的ルートを選択することである。宛先ホストおよび送信ホストが同じローカルエリアネットワーク内にない場合、パケットを宛先ホストに送信し得るための適切な伝送経路が選択される必要があり、伝送経路が通過する必要があるネクストホップルートのインターネットプロトコルアドレスが選択される必要がある。ルーティングテーブルは、特定のネットワークアドレスへの経路を格納する。ネイバーテーブルは、ＡＲＰキャッシュテーブルとも呼ばれる。このテーブルには、ＡＲＰプロトコルを使用してプロトコルスタックによって取得されたネットワーク内のネイバーホストのＩＰアドレスとＭＡＣアドレスの対応が、ネイバーとの次の通信用に格納される。また、ＡＲＰモジュールは、このネイバーテーブルを更新し、および維持するための対応するメカニズムも提供する。

本発明の一実施形態では、ルーティングテーブルおよびネイバーテーブルは１つのテーブルに組み合わせられ、２つのテーブルの情報が１つのデータ構造に格納されて、ルートネイバーテーブルを形成する。ルートネイバーテーブル（Route-neighbor Table）は、インターネットプロトコルアドレス（ＩＰアドレス）、物理アドレス、ルート情報、ルートタイプなどの情報を含むデータ構造である。このように、従来技術におけるルーティングテーブルおよびネイバーテーブルの情報は、同じデータ構造にある。ＩＰはハッシュクエリのキーとして使用できる。パケットが３層のプロトコルスタックを通過するとき、ＩＰアドレスに対応する物理アドレスおよびルート情報を取得するために、ＩＰアドレス情報は単一のクエリで直接使用される。本発明の解決策は、ルーティングテーブルおよびネイバーテーブルが別々にクエリされる必要がある従来技術の解決策とは異なる。つまり、従来技術では、上記の情報を取得するために少なくとも２つのクエリが必要である。

本発明の第１の実施形態は、ネットワーク通信方法を提供する。図３は、本発明の一実施形態によって提供されるネットワーク通信方法のフローチャートを示す。以下、図３を参照して詳細に説明する。

ステップ３０１では、宛先ホストのインターネットプロトコルアドレスを取得するために、パケットが受信および解析される。このステップは本実施形態の開始ステップである。つまり、宛先ホストのインターネットプロトコルアドレスを取得するため、３層プロトコルスタックがパケットを受信して解析し、このメソッドのプロセス全体が開始される。

パケット（メッセージ）は、ネットワークで交換されて送信されるデータ単位、すなわちサイトが一度に送信するデータブロックである。パケットには、送信される完全なデータ情報が含まれる。パケットの長さは同じではなく、制限もなく、可変である。インターネットプロトコルアドレスは、ネットワークでインターネットプロトコル（ＩＰ）を使用するデバイスに割り当てられた数値ラベルである。

ステップ３０２では、ネクストホップルートの物理アドレスおよびルートタイプを取得するために、宛先ホストのインターネットプロトコルアドレスに従ってルートネイバーテーブルに対して単一のクエリが実行される。

３層データパケットカプセル化の最も重要な機能は、上位層パケットの宛先ホストのインターネットプロトコルアドレスに従って、宛先ホストの物理アドレス（physical address）またはネクストホップルートを取得することである。宛先ホストと送信ホストが同じローカルエリアネットワークにない場合があるため、従来技術では、宛先ホストのインターネットプロトコルアドレスを使用して、宛先ホストと送信ホストが同じローカルエリアネットワークにあるかどうかを判定するために、ルーティングテーブルが使用される必要がある。宛先ホストと送信ホストが同じローカルエリアネットワークにある場合、宛先ホストのインターネットプロトコルアドレスが取得される。宛先ホストおよび送信ホストが同じローカルエリアネットワークにない場合、パケットを宛先ホストに送信し得るための適切な伝送経路が選択され、伝送経路が通過する必要があるネクストホップルートのインターネットプロトコルアドレスが取得される。インターネットプロトコルアドレスが取得された後、ルーティングテーブルは、インターネットプロトコルアドレスによって、インターネットプロトコルアドレスに対応する物理アドレスを取得するために使用される。物理アドレスは、パケットヘッダに埋め込まれ、パケットの送信を担当する物理メディア層に送信される。

本発明では、上記ステップのルーティングテーブルおよびネイバーテーブルを１つのテーブルに組み合わせ、ルーティングテーブルおよびネイバーテーブルの情報を１つのデータ構造に格納することにより、従来技術と同じ機能を実現する。

ルートネイバーテーブル（Route-neighbor Table）は、インターネットプロトコルアドレス、物理アドレス、ルート情報、ルートタイプなどの情報を含むデータ構造であり、各デバイスの上記情報を記録する。データ構造は、データをコンピュータに格納し、編成する方法である。データ構造は、インターフェースまたはカプセル化を示す。１つのデータ構造は、２つの関数間のインターフェースと考えることができ、または、データ型の共用体（data type union）によって形成された格納コンテンツにアクセスするためのメソッドのカプセル化である。

具体的には、ルートネイバーテーブルはハッシュテーブルの形式で編成でき、インターネットプロトコルアドレス、物理アドレス、ルート情報、およびルートタイプがフィールドとして使用され、各レコードは、図４に示すように、上記の４つのフィールドの情報を提供する。このように、従来技術におけるルーティングテーブルおよびネイバーテーブルの情報は、同じデータ構造にある。ＩＰはハッシュクエリのキーとして使用できる。パケットが３層プロトコルスタックを通過するとき、ＩＰ情報（つまり、宛先ホストのインターネットプロトコルアドレス）を直接使用して、対応する物理アドレスおよび対応するルート情報を取得する。図４の表において、フィールド「ＩＰ」は、宛先ホストのインターネットプロトコルアドレスを示し、フィールド「ＭＡＣ」は、宛先ホストの物理アドレスを示し、フィールド「ルート」は、宛先ホストのルート情報を示し、フィールド「タイプ」は、宛先ホストのルートタイプを示す。

物理アドレスは、媒体アクセス制御アドレスであり、イーサネットＩＤまたはイーサネット物理アドレスとも呼ばれ、ネットワークデバイスの位置を特定するために使用されるアドレスである。物理アドレスは、ネットワーク内のネットワークアダプタを一意に識別するために使用される。デバイスに１つまたは複数のネットワークアダプタがある場合、各ネットワークアダプタは、一意の物理アドレスを必要とし、有している。

ルート情報は、ネクストホップルートのインターネットプロトコルアドレスを記録し、情報は一般にクロスドメイン伝送で使用される。同じローカルエリアネットワーク内で送信が行われる場合、このパラメータは「０」である。他のタイプの文字を指定して、異なるルート情報を示すこともできる。

ルートタイプは、宛先ホストと送信側（sender）の間のネットワーク距離を指す。本実施形態では、ルートタイプは、それぞれ「０」、「１」、「２」の３つの数値など異なる値で示される。数字「０」はルータ自体を示し、数字「１」はルータが配置されているローカルエリアネットワークを示し、数字「２」は広域ネットワークを示す。他のタイプの文字を指定して、異なるルートタイプを示すこともできる。

ルータ自体は、ルータデバイス自体を指し、本実施形態では、このオプションは、階層的完全性および漸進的関係のためにのみ提供される。

ローカルエリアネットワークとは、ルータが配置されているローカルエリアネットワークを指し、つまり、受信側（宛先ホスト）と送信側は同じローカルエリアネットワークにあり、この場合、クロスドメイン伝送は必要ない。

広域ネットワークとは、受信側（宛先ホスト）と送信側が同じローカルエリアネットワーク内になく、クロスドメイン伝送が必要であることを指す。

パケットが３層プロトコルスタックを通過するとき、ルートタイプが最初に読み取られる。ルートタイプのパラメータが０の場合、宛先ホストがローカルエリアネットワークにあることが示されている。この場合、ルート情報を読み取る必要はなく、物理アドレスは直接読み取られ、パケットは読み取られた物理アドレス（つまり、宛先ホストの物理アドレス）に送信される。ルートタイプのパラメータが１の場合、宛先ホストが広域ネットワークにあることが示されている。この場合、ルート情報と物理アドレスが読み取られる必要があり、読み取った物理アドレス（つまり、ネクストホップルートの物理アドレス）にパケットが送信される。

例えば、宛先ホストのインターネットプロトコルアドレス１９２．１６８．０．３に対応する物理アドレスがａａ：ｂｂ：ｃｃ：ｄｄ：ｅｅ：ｆｆである場合、ルート情報は０、ルートタイプは１であり、宛先ホストはローカルエリアネットワークにあり、物理アドレスはａａ：ｂｂ：ｃｃ：ｄｄ：ｅｅ：ｆｆである。宛先ホストのインターネットプロトコルアドレス１９２．１６８．２４．３に対応する物理アドレスがａａ：ｃｃ：ｅｅ：ｄｄ：ｂｂ：ｆａであり、ルート情報が１９２．１６８．１．０であり、ルートタイプが２の場合、以下のことが示される。宛先ホストは広域ネットワークにあり、クロスドメイン伝送が必要であり、ネクストホップルートのインターネットプロトコルアドレスは１９２．１６８．１．０であり、ネクストホップルートの物理アドレスはａａ：ｃｃ：ｅｅ：ｄｄ：ｂｂ：ｆａである。

上記のルートネイバーテーブルのデータ構造は、このステップを実装するための１つの可能なデータ構造にすぎない。ルートネイバーテーブルが設計されている場合、他のタイプの文字を使用して、様々なルート情報またはルートタイプを示すことができる。さらに、ルートネイバーテーブルの情報は、要件に応じて増減でき得る。例えば、ポリシールートをフィールドとして追加したり、１つまたは複数の不要なフィールドを削除したりできる。別の可能な実装スキームを以下に示す。

インターネットプロトコルアドレス、物理アドレス、およびルート情報をフィールドとして使用でき、ルートタイプフィールドは削除される。パケットが３層プロトコルスタックを通過すると、ルート情報とＭＡＣ情報が直接読み取られ、読み取られた物理アドレスにパケットが送信される。

さらに、フィールドは要件に応じて調整および設計でき、ルートネイバーテーブルのデータ構造は、ハッシュテーブルとしてだけでなく、他のツリーベースのデータ構造としても実装できる。

ローカルエリアネットワークのレコードが特定の範囲内にある場合、つまりローカルエリアネットワーク内のデバイスの総数が制限されている場合、ローカルエリアネットワーク内の全てのデバイスのルートネイバーテーブル情報は、ルーティングデバイスに記録されることができる。

ステップＳ３０３では、物理アドレスとルートタイプに従ってパケットが送信される。このステップの物理アドレスは、宛先ホストのネットワークアダプタまたはネクストホップルートの物理アドレスを指す。

本発明の第２の実施形態は、３層データパケットカプセル化のための別のネットワーク伝送方法を提供する。図５は、本発明の第２の実施形態によって提供される３層データパケットカプセル化のためのネットワーク通信方法のフローチャートを示す。図５は、本発明の第２の実施形態によって提供される３層データパケットカプセル化のためのネットワーク通信方法のフローチャートを示す。

ステップ４０１では、宛先ホストのインターネットプロトコルアドレスを取得するために、パケットが受信および解析される。このステップは本実施形態の開始ステップである。つまり、宛先ホストのインターネットプロトコルアドレスを取得するため、３層プロトコルスタックがパケットを受信して解析し、このメソッドのプロセス全体が開始される。

パケット（メッセージ）は、ネットワークで交換されて送信されるデータ単位、すなわちサイトが一度に送信するデータブロックである。パケットは、送信される完全なデータ情報を含んでいる。パケットの長さは同じではなく、制限もなく、可変である。

インターネットプロトコルアドレスは、ネットワークでインターネットプロトコル（ＩＰ）を使用するデバイスに割り当てられた数値ラベルである。

ステップＳ４０２では、ルートネイバーテーブルが有効であるか否かを判定し、有効である場合、ルートネイバーテーブルに対して単一のクエリを実行して、ネクストホップルートの物理アドレスおよびルートタイプを取得する。

３層データパケットカプセル化の最も重要な機能は、上位層パケットの宛先ホストのインターネットプロトコルアドレスに従って、宛先ホストの物理アドレス（physical address）またはネクストホップルートを取得することである。宛先ホストと送信ホストが同じローカルエリアネットワークにない場合があるため、従来技術では、宛先ホストのインターネットプロトコルアドレスを使用して、宛先ホストと送信ホストが同じローカルエリアネットワークにあるかどうかを判定するために、ルーティングテーブルが使用される必要がある。宛先ホストと送信ホストが同じローカルエリアネットワークにある場合、宛先ホストのインターネットプロトコルアドレスが取得される。宛先ホストおよび送信ホストが同じローカルエリアネットワークにない場合、パケットを宛先ホストに送信し得るための適切な伝送経路が選択され、伝送経路が通過する必要があるネクストホップルートのインターネットプロトコルアドレスが取得される。インターネットプロトコルアドレスが取得された後、ルーティングテーブルは、インターネットプロトコルアドレスによって、インターネットプロトコルアドレスに対応する物理アドレスを取得するために使用される。物理アドレスは、パケットヘッダに埋め込まれ、パケットの送信を担当する物理メディア層に送信される。

本発明では、上記ステップのルーティングテーブルおよびネイバーテーブルを１つのテーブルに組み合わせ、ルーティングテーブルおよびネイバーテーブルの情報を１つのデータ構造に格納することにより、従来技術と同じ機能を実現する。

ルートネイバーテーブルは、インターネットプロトコルアドレス、物理アドレス、ルート情報、ルートタイプなどの情報を含むデータ構造であり、各デバイスの上記情報を記録する。

データ構造は、データをコンピュータに格納し、編成する方法である。データ構造は、インターフェースまたはカプセル化を示す。１つのデータ構造は、２つの関数間のインターフェースと考えることができ、または、データ型の共用体によって形成された格納コンテンツにアクセスするためのメソッドのカプセル化である。

具体的には、ルートネイバーテーブルはハッシュテーブルの形式で編成でき、インターネットプロトコルアドレス、物理アドレス、ルート情報、およびルートタイプがフィールドとして使用され、各レコードは、図４に示すように、上記の４つのフィールドの情報を提供する。このように、従来技術におけるルーティングテーブルおよびネイバーテーブルの情報は、同じデータ構造にある。ＩＰはハッシュクエリのキーとして使用できる。パケットが３層プロトコルスタックを通過するとき、対応する物理アドレスおよび対応するルート情報を取得するために、ＩＰ情報（つまり、宛先ホストのインターネットプロトコルアドレス）が直接使用される。図４の表において、フィールド「ＩＰ」は、宛先ホストのインターネットプロトコルアドレスを示し、フィールド「ＭＡＣ」は、宛先ホストの物理アドレスを示し、フィールド「ルート」は、宛先ホストのルート情報を示し、フィールド「タイプ」は、宛先ホストのルートタイプを示す。

物理アドレスは、媒体アクセス制御アドレスであり、イーサネットＩＤまたはイーサネット物理アドレスとも呼ばれ、ネットワークデバイスの位置を判定するために使用されるアドレスである。物理アドレスは、ネットワーク内のネットワークアダプタを一意に識別するために使用される。デバイスに１つまたは複数のネットワークアダプタがある場合、各ネットワークアダプタは、一意の物理アドレスを必要とし、有している。

ルート情報は、ネクストホップルートのインターネットプロトコルアドレスを記録し、情報は一般にクロスドメイン伝送で使用される。同じローカルエリアネットワーク内で送信が行われる場合、このパラメータは「０」である。他のタイプの文字を指定して、異なるルート情報を示すこともできる。

ルートタイプは、宛先ホストと送信側の間のネットワーク距離を指す。本実施形態では、ルートタイプは、３つの数値「０」、「１」および「２」によってそれぞれ示される。数字「０」はルータ自体を示し、数字「１」はルータが配置されているローカルエリアネットワークを示し、数字「２」は広域エリアネットワークを示す。他のタイプの文字を指定して、異なるルートタイプを示すこともできる。

ルータ自体は、ルータデバイス自体を指し、本実施形態では、このオプションは、階層的完全性および漸進的関係のためにのみ提供される。

ローカルエリアネットワークとは、ルータが配置されているローカルエリアネットワークを指し、つまり、受信側（宛先ホスト）と送信側は同じローカルエリアネットワークにあり、この場合、クロスドメイン伝送は必要ない。

広域エリアネットワークとは、受信側（宛先ホスト）と送信側が同じローカルエリアネットワーク内になく、クロスドメイン伝送が必要であることを指す。

パケットが３層プロトコルスタックを通過するとき、ルートタイプが最初に読み取られる。ルートタイプのパラメータが０の場合、宛先ホストがローカルエリアネットワークにあることが示されている。この場合、ルート情報を読み取る必要はなく、物理アドレスが直接読み取られ、パケットは読み取られた物理アドレス（つまり、宛先ホストの物理アドレス）に送信される。ルートタイプのパラメータが１の場合、宛先ホストが広域ネットワークにあることが示されている。この場合、ルート情報および物理アドレスが読み取られる必要があり、読み取った物理アドレス（つまり、ネクストホップルートの物理アドレス）にパケットが送信される。

例えば、宛先ホストのインターネットプロトコルアドレス１９２．１６８．０．３に対応する物理アドレスがａａ：ｂｂ：ｃｃ：ｄｄ：ｅｅ：ｆｆである場合、ルート情報は０、ルートタイプは１であり、宛先ホストはローカルエリアネットワークにあり、物理アドレスはａａ：ｂｂ：ｃｃ：ｄｄ：ｅｅ：ｆｆである。宛先ホストのインターネットプロトコルアドレス１９２．１６８．２４．３に対応する物理アドレスがａａ：ｃｃ：ｅｅ：ｄｄ：ｂｂ：ｆａであり、ルート情報が１９２．１６８．１．０であり、ルートタイプが２の場合、以下のことが示される：宛先ホストは広域ネットワークにあり、クロスドメイン伝送が必要であり、ネクストホップルートのインターネットプロトコルアドレスは１９２．１６８．１．０であり、ネクストホップルートの物理アドレスはａａ：ｃｃ：ｅｅ：ｄｄ：ｂｂ：ｆａである。

上記のルートネイバーテーブルのデータ構造は、このステップを実装するための１つの可能なデータ構造にすぎない。ルートネイバーテーブルが設計されている場合、他のタイプの文字を使用して、様々なルート情報またはルートタイプを示すことができる。さらに、ルートネイバーテーブルの情報は、要件に応じて増減でき得る。例えば、ポリシールートをフィールドとして追加したり、１つまたは複数の不要なフィールドを削除したりできる。別の可能な実装スキームを以下に示す。

インターネットプロトコルアドレス、物理アドレス、およびルート情報をフィールドとして使用でき、ルートタイプフィールドは削除される。パケットが３層プロトコルスタックを通過すると、ルート情報とＭＡＣ情報が直接読み取られ、読み取られた物理アドレスにパケットが送信される。

さらに、フィールドは要件に応じて調整および設計でき、ルートネイバーテーブルのデータ構造は、ハッシュテーブルとしてだけでなく、他のツリーベースのデータ構造としても実装できる。ローカルエリアネットワークのレコードが特定の範囲内にある場合、つまりローカルエリアネットワーク内のデバイスの総数が制限されている場合、ローカルエリアネットワーク内の全てのデバイスのルートネイバーテーブル情報は、ルーティングデバイスに記録されることができる。

ステップＳ４０３では、物理アドレスとルートタイプに従ってパケットが送信される。このステップの物理アドレスは、宛先ホストのネットワークアダプタまたはネクストホップルートの物理アドレスを指す。

本発明の第３の実施形態は、別のネットワーク通信方法を提供する。図６は、本発明の第３の実施形態によって提供されるネットワーク通信方法のフローチャートを示す。以下、図６を参照して詳細に説明する。

ステップＳ５０１では、宛先ホストのインターネットプロトコルアドレスを取得するために、パケットが受信および解析される。このステップは、本実施形態の開始ステップである。つまり、宛先ホストのインターネットプロトコルアドレスを取得するため、３層プロトコルスタックがパケットを受信して解析し、このメソッドのプロセス全体が開始される。

パケット（メッセージ）は、ネットワークで交換され、送信されるデータ単位、すなわちサイトが一度に送信するデータブロックである。パケットは、送信される完全なデータ情報を含んでいる。パケットの長さは同じではなく、制限もなく、可変である。

インターネットプロトコルアドレスは、ネットワークでインターネットプロトコル（ＩＰ）を使用するデバイスに割り当てられた数値ラベルである。

ステップＳ５０２では、ルートネイバーテーブルが有効であるかどうかが判定される。有効な場合は、ルートネイバーテーブルに対して単一のクエリが実行され、ネクストホップルートまたは宛先ホストの物理アドレスが見つからない場合は、次のステップが実行される。ネクストホップルートまたは宛先ホストの物理アドレスが見つからないということは、宛先ホストのレコードがルートネイバーテーブルに存在しないことを意味する。

ステップＳ５０３では、ルートマッチングアルゴリズムにより、ネクストホップルートまたは宛先ホストのインターネットプロトコルアドレスが取得される。このステップは、既存の手法を使用して実装でき、ネクストホップルートまたは宛先ホストのインターネットプロトコルアドレスは、ルーティングテーブルの既存のメカニズムを使用して取得される。

ステップＳ５０４では、ネクストホップルートまたは宛先ホストのインターネットプロトコルアドレスに従って、ネクストホップルートまたは宛先ホストの物理アドレスが取得される。このステップは、既存の手法を使用して実装でき、ネクストホップルートまたは宛先ホストの物理アドレスは、ネイバーテーブルの既存のメカニズムを使用して取得される。

ステップＳ５０５では、ネクストホップルートまたは宛先ホストの物理アドレスは、ルートネイバーテーブルに更新され、その物理アドレス宛にパケットが送信される。ここでは、ステップＳ５０３で取得したネクストホップルートまたは宛先ホストのインターネットプロトコルアドレスと、ステップＳ５０４で取得したネクストホップルートまたは宛先ホストの物理アドレスとがルートネイバーテーブルに格納される。

このステップの物理アドレスは、宛先ホストのネットワークアダプタまたはネクストホップルートの物理アドレスを指す。

インターネットプロトコルアドレスとネットワークトポロジに変更が発生する可能性があるため、元のキャッシュでは、これらの変更が原因でクエリ結果が不正確になる可能性がある。したがって、テーブル内の特定の行が一定期間使用されない場合、その行は削除される。これにより、インターネットプロトコルアドレスまたはネットワークトポロジの変更により誤った情報が残ることを防止できる。

本発明の第４の実施形態は、別のネットワーク通信方法を提供する。図７は、本発明の第４の実施形態によって提供されるネットワーク通信方法のフローチャートを示す。以下、図７を参照して詳細に説明する。

ステップＳ６０１では、宛先ホストのインターネットプロトコルアドレスを取得するために、パケットが受信および解析される。このステップは、本実施形態の開始ステップである。つまり、宛先ホストのインターネットプロトコルアドレスを取得するため、３層プロトコルスタックがパケットを受信して解析し、このメソッドのプロセス全体が開始される。

パケット（メッセージ）は、ネットワークで交換され、送信されるデータ単位、すなわちサイトが一度に送信するデータブロックである。パケットは、送信される完全なデータ情報を含んでいる。パケットの長さは同じではなく、制限もなく、可変である。

インターネットプロトコルアドレスは、ネットワークでインターネットプロトコル（ＩＰ）を使用するデバイスに割り当てられた数値ラベルである。

ステップＳ６０２では、ルートネイバーテーブルが有効になっているかどうかが判定され、有効になっていない場合は、宛先ホストのインターネットプロトコルアドレスに従ってルーティングテーブルがクエリされ、ネクストホップルートまたは宛先ホストのインターネットプロトコルアドレスが取得される。

ルートネイバーテーブルが有効でない場合、既存の手法が採用され、ルーティングテーブルの既存のメカニズムを使用して、ネクストホップルートまたは宛先ホストのインターネットプロトコルアドレスが取得される。

ステップＳ６０３では、ネクストホップルートまたは宛先ホストのインターネットプロトコルアドレスに従ってネイバーテーブルがクエリされ、ネクストホップルートの物理アドレスが取得される。このステップは、既存の手法を使用して実装でき、ネクストホップルートまたは宛先ホストの物理アドレスは、ネイバーテーブルの既存のメカニズムを使用して取得される。

ステップＳ６０４では、パケットが物理アドレスに送信される。このステップの物理アドレスは、宛先ホストのネットワークアダプタまたはネクストホップルートの物理アドレスを指す。

本発明の第５の実施形態は、別のネットワーク通信方法を提供する。図８は、本発明の第５の実施形態によって提供されるネットワーク通信方法のフローチャートを示す。以下、図８を参照して詳細に説明する。

ステップＳ７０１では、宛先ホストのインターネットプロトコルアドレスがローカルアドレスであるかどうかが検証され、ローカルアドレスである場合、パケットが受信される。このステップでは、受信側はローカルホストが送信側の宛先ホストであるかどうかを検証し、送信が正しいかどうかを判定する。具体的には、パケットがローカルホストに送信されるか、または非ローカルホストに送信されるかを決定するために、パケットの宛先ホストのインターネットプロトコルアドレスに従って最大プレフィックスマッチングが実行される。パケットがローカルホストに送信される場合、パケットが受信され、アプリケーションはパケットを受信するよう通知される。

ステップＳ７０２において、パケットは、パケットポート番号に従ってターゲットアプリケーションに送信される。

サーバでは、複数のユーザプロセスが同時にＴＣＰを使用することが可能である。各プロセスに関連付けられたデータを識別するために、ポート番号が使用される。各プロセスは１つのポート番号を占有する。このステップでは、パケットは、パケットと同じポート番号を有するアプリケーションに送信される。

パケットが非ローカルホストに送信される場合、転送機能が有効になっていると、ルートネイバーテーブルに対して単一のクエリが実行され、ルータの物理アドレスが取得され、受信したパケットの物理アドレスがルータの物理アドレスに置き換えられ、および受信したパケットがルータの物理アドレスに転送される。

さらに、上記の方法の実施形態に対応して、本発明はさらに、ネットワーク通信装置を提供する。装置の実施形態を以下に説明する。装置の実施形態は、方法の実施形態と同様であり、説明は比較的簡単である。詳細については方法の実施形態を参照されたい。

本発明は、
宛先ホストのインターネットプロトコルアドレスを取得するためにパケットを受信して解析するために使用される解析ユニットと、
ネクストホップルートの物理アドレスおよびルートタイプを取得するために、宛先ホストのインターネットプロトコルアドレスに従ってルートネイバーテーブルに対して単一のクエリを実行するために使用されるクエリユニットと、
物理アドレスおよびルートタイプに従ってパケットを送信するために使用されるパケット送信ユニットと
を含むネットワーク通信装置を提供する。

また、本発明はさらに別のネットワーク通信装置を提供し、ネットワーク通信装置は、
宛先ホストのインターネットプロトコルアドレスを取得するためにパケットを受信して解析するために使用される解析ユニットと、
ルートネイバーテーブルが有効かどうかを判定するために使用される判定ユニットと、
ルートネイバーテーブルが有効な場合、ルートネイバーテーブルに対して単一のクエリを実行して、ネクストホップルートの物理アドレスおよびルートタイプを取得するために使用されるクエリユニットと、
物理アドレスおよびルートタイプに従ってパケットを送信するために使用されるパケット送信ユニットと
を含む。

本発明は、好ましい実施形態を通して上記に開示されているが、それに限定されることは意図されていない。本発明の趣旨および範囲から逸脱することなく、可能な変更および修正を当業者が行うことができる。従って、本発明の保護範囲は、本発明の特許請求の範囲によって定義されるものとする。

典型的な構成では、コンピュータデバイスは、１つまたは複数のプロセッサ（ＣＰＵ）、入出力インターフェース、ネットワークインターフェースおよびメモリを含む。

メモリは、非永続のメモリ、ランダムアクセスメモリ（ＲＡＭ）および／または読み取り専用メモリ（ＲＯＭ）やフラッシュメモリ（フラッシュＲＡＭ）などの不揮発性メモリなどの形態のコンピュータ可読媒体を含むことができる。メモリは、コンピュータ可読媒体の一例である。

コンピュータ可読媒体は、任意の方法または技法によって情報記憶を達成することができる永久的および非永久的、可動および非可動媒体を含む。情報は、コンピュータ可読命令、データ構造、プログラムのモジュールまたは他のデータであり得る。コンピュータの記憶媒体の例には、限定されるわけではないが、相変化メモリ（ＰＲＡＭ）、スタティックランダムアクセスメモリ（ＳＲＡＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、他のタイプのランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、電気的消去可能プログラマブル読み取り専用メモリ（ＥＥＰＲＯＭ）、フラッシュメモリまたはその他のメモリ技術、コンパクトディスク読み取り専用メモリ（ＣＤ−ＲＯＭ）、デジタル多用途ディスク（ＤＶＤ）またはその他の光学式ストレージ、カセットテープ、磁気テープ／磁気ディスクストレージまたはその他の磁気ストレージデバイス、またはその他の非伝送媒体が含まれ、コンピューティングデバイスからアクセス可能な情報を保存するために使用できる。本明細書の定義によれば、コンピュータ可読媒体は、変調されたデータ信号および搬送波などの非一時的なコンピュータ可読媒体（一時的な媒体）を含まない。

当業者は、本発明の実施形態が方法、システムまたはコンピュータプログラム製品として提供され得ることを理解するだろう。したがって、本発明は、完全なハードウェアの実施形態、完全なソフトウェアの実施形態、またはソフトウェアとハードウェアを組み合わせた実施形態の形を使用することができる。さらに、本発明は、コンピュータ使用可能なプログラムコードを含む１つまたは複数のコンピュータ使用可能な記憶媒体（磁気ディスクメモリ、ＣＤ−ＲＯＭ、光学メモリなどを含むがこれらに限定されない）上に実装されるコンピュータプログラム製品の形態を使用することができる。

Claims (31)

1. 宛先ホストのインターネットプロトコルアドレスを取得するために、パケットを受信して解析することと、
   ネクストホップルートの物理アドレスおよびルートタイプを取得するために、宛先ホストのインターネットプロトコルアドレスに従ってルートネイバーテーブルに対して単一のクエリを実行することと、
   物理アドレスおよびルートタイプに従ってパケットを送信することと
   を備えるネットワーク通信方法。
2. 前記ルートネイバーテーブルは、ハッシュデータテーブルであり、前記ルートネイバーテーブルに対して単一のクエリを実行することは、前記ルートネイバーテーブルに対して単一のハッシュクエリを実行することである、請求項１に記載のネットワーク通信方法。
3. 前記パケットが送信される前、前記物理アドレスが前記パケットのイーサネットパケットヘッダにカプセル化される、請求項１に記載のネットワーク通信方法。
4. 前記ルートネイバーテーブルは、ネットワークデバイスのインターネットプロトコルアドレス、物理アドレス、ルート情報、およびルートタイプのフィールドを含むハッシュデータテーブルである、請求項１に記載のネットワーク通信方法。
5. 前記ルートタイプは、ルート、ローカルエリアネットワーク、および広域ネットワークを含む、請求項４に記載のネットワーク通信方法。
6. 前記ルートタイプは、異なる値によって示される、請求項５に記載のネットワーク通信方法。
7. ローカルエリアネットワークのホストの数が数えられる場合、前記ルートネイバーテーブルは、インターネットプロトコルアドレス、物理アドレス、ルート情報、およびルートタイプを格納し、前記ルートタイプの全てはローカルエリアネットワークである、請求項５に記載のネットワーク通信方法。
8. 前記ルートネイバーテーブルは、ネットワークデバイスのインターネットプロトコルアドレス、物理アドレス、およびルート情報のフィールドを含むハッシュデータテーブルである、請求項１に記載のネットワーク通信方法。
9. ローカルエリアネットワークのホストの数が数えられる場合、前記ルートネイバーテーブルは、インターネットプロトコルアドレス、物理アドレス、およびルート情報を格納し、ルートタイプの全てはローカルエリアネットワークである、請求項８に記載のネットワーク通信方法。
10. 前記ルートネイバーテーブルは、ネットワークデバイスのインターネットプロトコルアドレスおよび物理アドレスのフィールドを含むハッシュデータテーブルである、請求項１に記載のネットワーク通信方法。
11. 宛先ホストのインターネットプロトコルアドレスを取得するために、パケットを受信して解析することと、
    ルートネイバーテーブルが有効かどうかを判定し、前記ルートネイバーテーブルが有効な場合、ネクストホップルートの物理アドレスおよびルートタイプを取得するために、前記ルートネイバーテーブルに対して単一のクエリを実行することと、
    前記物理アドレスおよび前記ルートタイプに従って前記パケットを送信することと
    を備えるネットワーク通信方法。
12. 前記ルートネイバーテーブルは、ハッシュデータテーブルであり、前記ルートネイバーテーブルに対して単一のクエリを実行することは、前記ルートネイバーテーブルに対して単一のハッシュクエリを実行することである、請求項１１に記載のネットワーク通信方法。
13. 前記パケットが前記物理アドレスに送信される前、前記物理アドレスが前記パケットのイーサネットパケットヘッダにカプセル化される、請求項１１に記載のネットワーク通信方法。
14. 前記ルートネイバーテーブルは、ネットワークデバイスのインターネットプロトコルアドレス、物理アドレス、ルート情報、およびルートタイプのフィールドを含むハッシュデータテーブルである、請求項１１に記載のネットワーク通信方法。
15. 前記ルートタイプは、ルート、ローカルエリアネットワーク、および広域ネットワークを含む、請求項１４に記載のネットワーク通信方法。
16. ローカルエリアネットワークのホストの数が数えられる場合、前記ルートネイバーテーブルは、インターネットプロトコルアドレス、物理アドレス、ルート情報、およびルートタイプを格納し、前記ルートタイプの全てはローカルエリアネットワークである、請求項１５に記載のネットワーク通信方法。
17. 前記ルートネイバーテーブルは、ネットワークデバイスのインターネットプロトコルアドレス、物理アドレス、およびルート情報のフィールドを含むハッシュデータテーブルである、請求項１１に記載のネットワーク通信方法。
18. ローカルエリアネットワークのホストの数が数えられる場合、前記ルートネイバーテーブルは、インターネットプロトコルアドレス、物理アドレス、およびルート情報を格納し、ルートタイプの全てはローカルエリアネットワークである、請求項１７に記載のネットワーク通信方法。
19. 前記ルートネイバーテーブルは、インターネットプロトコルアドレスおよび物理アドレスのフィールドを含むデータテーブルであり、ネットワークデバイスの情報を記録するために使用される、請求項１１に記載のネットワーク通信方法。
20. 宛先ホストのインターネットプロトコルアドレスを取得するために、パケットを受信して解析することと、
    ルートネイバーテーブルが有効かどうかを判定し、前記ルートネイバーテーブルが有効な場合、前記ルートネイバーテーブルに対して単一のクエリを実行し、ネクストホップルートの物理アドレスが見つからない場合、
    ルートマッチングアルゴリズムにより、前記ネクストホップルートのインターネットプロトコルアドレスを取得することと、
    前記ネクストホップルートの前記インターネットプロトコルアドレスに従って、前記ネクストホップルートの物理アドレスを取得することと
    前記ネクストホップルートの物理アドレスを前記ルートネイバーテーブルに更新し、前記物理アドレスに前記パケットを送信することと
    を実行することと
    を備えるネットワーク通信方法。
21. 前記物理アドレスに前記パケットを送信する前、前記物理アドレスが前記パケットのイーサネットパケットヘッダにカプセル化される、請求項２０に記載のネットワーク通信方法。
22. 前記ルートネイバーテーブルは、ネットワークデバイスのインターネットプロトコルアドレス、物理アドレス、ルート情報、およびルートタイプのフィールドを含むハッシュデータテーブルである、請求項２０に記載のネットワーク通信方法。
23. 前記ルートタイプは、ルート、ローカルエリアネットワーク、および広域ネットワークを含む、請求項２２に記載のネットワーク通信方法。
24. ローカルエリアネットワークのホストの数が数えられる場合、前記ルートネイバーテーブルは、インターネットプロトコルアドレス、物理アドレス、ルート情報およびルートタイプを格納し、ルートタイプの全てはローカルエリアネットワークである、請求項２３に記載のネットワーク通信方法。
25. 前記ルートネイバーテーブルは、ネットワークデバイスのインターネットプロトコルアドレス、物理アドレス、およびルート情報のフィールドを含むデータテーブルである、請求項２０に記載のネットワーク通信方法。
26. ローカルエリアネットワークのホストの数が数えられる場合、前記ルートネイバーテーブルは、インターネットプロトコルアドレス、物理アドレス、およびルート情報を格納し、ルートタイプの全てはローカルエリアネットワークである、請求項２５に記載のネットワーク通信方法。
27. 前記ルートネイバーテーブルは、ネットワークデバイスのインターネットプロトコルアドレスおよび物理アドレスのフィールドを含むハッシュデータテーブルである、請求項２０に記載のネットワーク通信方法。
28. 宛先ホストのインターネットプロトコルアドレスを取得するために、パケットを受信して解析することと、
    ルートネイバーテーブルが有効かどうかを判定し、前記ルートネイバーテーブルが有効ではない場合、ネクストホップルートのインターネットプロトコルアドレスを取得するために、前記宛先ホストのインターネットプロトコルアドレスに従ってルーティングテーブルに対してクエリを実行することと、
    前記ネクストホップルートの物理アドレスを取得するために、前記ネクストホップルートのインターネットプロトコルアドレスに従ってルートネイバーテーブルに対してクエリを実行することと、
    前記物理アドレスに前記パケットを送信することと
    を備えるネットワーク通信方法。
29. 宛先ホストのインターネットプロトコルアドレスがローカルアドレスかどうかを確認し、ローカルアドレスである場合、パケットを受信することと、
    パケットのポート番号に従ってパケットをターゲットアプリケーションに送信することと、
    ローカルアドレスでない場合、転送機能が有効になっているとき、ルータの物理アドレスを取得するために、ルートネイバーテーブルに対して単一のクエリを実行し、受信したパケットの物理アドレスをルータの物理アドレスに置き換え、受信したパケットをルータの物理アドレスに転送することと
    を備えるネットワーク通信方法。
30. 宛先ホストのインターネットプロトコルアドレスを取得するためにパケットを受信して解析するために使用される解析ユニットと、
    ネクストホップルートの物理アドレスおよびルートタイプを取得するために、前記宛先ホストのインターネットプロトコルアドレスに従って、ルートネイバーテーブルに対して単一のクエリを実行するために使用されるクエリユニットと、
    前記物理アドレスおよび前記ルートタイプに従って前記パケットを送信するために使用されるパケット送信ユニットと
    を備えたネットワーク通信装置。
31. 宛先ホストのインターネットプロトコルアドレスを取得するためにパケットを受信して解析するために使用される解析ユニットと、
    ルートネイバーテーブルが有効かどうかを判定するために使用される判定ユニットと、
    前記ルートネイバーテーブルが有効な場合、ネクストホップルートの物理アドレスおよびルートタイプを取得するために、前記ルートネイバーテーブルに対して単一のクエリを実行するために使用されるクエリユニットと、
    前記物理アドレスおよび前記ルートタイプに従って前記パケットを送信するために使用されるパケット送信ユニットと
    を備えたネットワーク通信装置。

Images