JP2005027311A

JP2005027311A - 仮想プロトコル中間層を提供する方法およびシステム

Info

Publication number: JP2005027311A
Application number: JP2004194754A
Authority: JP
Inventors: Richard Powell Draves Jr; パウエルドラベスジュニアリチャード
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2003-06-30
Filing date: 2004-06-30
Publication date: 2005-01-27
Also published as: US20070280249A1; CN1578310A; EP1494414A3; BRPI0401950A; EP1494414A2; KR20050002618A; US20040264503A1

Abstract

【課題】通信スタック内の２つのプロトコル層の間に仮想プロトコル「中間層」を提供すること。
【解決手段】通信タスクを実行する必要があり、しかし互換性の問題のために既存のプロトコル層内の実装が配置を妨げる可能性があるとき、本発明の方法を使用してタスクを扱う中間層を作成する。中間層に固有のアドレス指定方式をセットアップする。この中間層は、プロトコルスタック内の他の層が中間層に通信タスクの実行の詳細を委ねることによって、それまで通り動作できるようにする。一実施形態では、中間層は、ＩＳＯ／ＯＳＩプロトコル層２と層３の間に構築される。ソースルーティングは、中間層アドレスを使用してこの中間層の間で実行される。層２または層３のアドレスの代わりに中間層アドレスを使用することにより、ソースルーティングのこの実施形態によって、複数の層３プロトコルおよび複数の層２ネットワークインターフェイスとの互換性が可能になる。
【選択図】図１１

Description

本発明は、一般にコンピュータネットワーク通信に関し、より詳細には階層型通信プロトコルに関する。

現代のコンピュータネットワークシステムは、コンピュータ間でのメッセージの移動という基本的なタスクに加えて、異なる多くの通信タスクを伴い、非常に複雑になりつつある。このさらなる複雑化に対処するために、すべてではないが多くの通信プロトコルを複数の「層」に分割し、各層は、いくつかの重要な通信タスクを扱い、別のタスクを他の層に委ねる。国際標準化機構の開放型システム間接続（ＩＳＯ／ＯＳＩ）プロトコルモデルは、モデルの「スタック」の７つの層の間に通信タスクを割り当てる理論的構成体である。このモデルでは、ネットワーク通信を可能にする全タスクをサブタスクに分割し、これらのサブタスクをそれぞれプロトコルスタックの論理層に割り当てる。スタックは階層型である。各層は、（当然最上層および最下層を除いて）その上下の層との定義済みのインターフェイスを有する。論理的に各層は、別のコンピュータ上のそのピア層と通信し、スタック内のその上の層にサービスを提供し、その下の層によって提供されるサービスを使用する。物理的に、物理層がネットワーク接続の媒体を介してメッセージを実際に送信するまで、メッセージはソースからスタックを下方に流れる。その指定受信側のコンピュータがそのメッセージを受信すると、メッセージはスタックの上方に向かって渡され、各層は、それ宛のデータを取り除き、またそれに応答し、メッセージの残りを上方の次レベルに渡す。例えば、ネットワーク層（層３）は、メッセージがネットワーク間でどのように経路指定されるかを定義する。１つのコンピュータ上のネットワーク層は、データのパケットをそれ自体のコンピュータ上の下方のデータ層（層２）に渡すことによって論理的に別のコンピュータ上のネットワーク層と通信する。データ層は、ネットワーク層のパケットにヘッダーを追加し、したがってデータフレークを作成して、それが物理層（層１）に渡される。物理層は、物理ネットワーク媒体を使用してそのデータフレームを送信する。データフレームが受信側コンピュータによって受信されると、受信側のデータ層は、データフレームを読み取り、それ宛のヘッダー情報をデータフレームから取り除く。次いでデータ層は、ソースコンピュータのデータパケットから成るフレームの残りを取り、それを上方のネットワーク層に送信する。したがって受信側のネットワーク層は、データ層のヘッダーおよびデータパケットを送信するために下層が使用する他の情報をデコードする必要なく、ソース上のネットワーク層によって送信された通りのパケットを読み取る。

この階層型モデルの主な利点は、各プロトコル層が、プロトコルスタック内の他の層によって扱われる無数の詳細にそれ自体が関わることなく、そのピアと通信できることである。つまり各層は、他の層によって行われるタスクとはほぼ関係なくその通信タスクを行う。このことによって、実装の柔軟性が保証される。例えば、１つの層（例えば電気電子技術者協会（ＩＥＥＥ）８０２イーサネット（登録商標）データ層２）の特定の実装は、その上のプロトコル層の任意の数の実装（例えば複数のＩＳＯ／ＯＳＩネットワーク間通信プロトコル層３）に対応する。したがって、新しい層３プロトコルを導入して、層２の装置のインストール済みのインフラストラクチャとの互換性を保持したままで、ネットワーク通信の技術を前進させることができる。同様に、所与の上位プロトコル層は、複数の個別の下層上で動作する。したがって、１つのコンピュータでは、イーサネット（登録商標）層２インターフェイスおよび無線インターフェイス上で単一の層３が稼働することができる。この柔軟性によって、階層型プロトコルは、２０年以上の間生き延び、成長することができた。

この柔軟性によって、各層に複数の実施形態がもたらされ、こうした実施形態は、特定の状況に合うように最適化され、すべて同じ下層上で稼働する。しかし、階層型プロトコルの層間の互換性は保証されているが、１つの層内に含まれる複数の実施形態の間の互換性は保証されていない。例えば、ＩＳＯ／ＯＳＩモデルでは、先験的に、新しい層３プロトコル（ＩＰｖ６など）を前のバージョン（ＩＰｖ４など）と同時に使用できることは保証されていない。この問題は、ＩＳＯ／ＯＳＩモデルの事項に基づいておらず、一般に階層型プロトコルに固有のものである。

層間のこの互換性問題の一例として、無線ネットワーク内でデータを経路指定する通信タスクを考える（この例については、下記の発明を実施するための最良の形態のセクションでより詳しく示し、説明する）。従来、有線のネットワークでは、装置は、ネットワーク内の他の装置（「ローカル装置」）と直接通信したり、ローカルネットワークの境界を超えて装置（「リモート装置」）にデータを送信するルーターと直接通信したりすることができる。しかし無線ネットワークでは、装置は、装置間のノイズ、干渉、距離などのために他のすべてのローカル装置と直接通信することができないことがある。同様に、装置は、無線ネットワークを有線のインターフェイスに接続するルーターと直接通信できないことがある。したがって、無線装置は、ローカル装置およびリモート装置の両方にメッセージを送信することが困難となり得る。一部の無線ネットワークでは、これらの問題に対処するためにプロトコルが実装されている。こうしたネットワークでは、無線装置は、他の装置宛のインターセプトされたメッセージを転送することによって互いに助け合う。これによって、ソース装置によって送信されたメッセージは、指定受信者に到達する前にいくつかの中間装置を「ホップ」または通過することができる。

この転送モデルは、やみくもに実装すると、メッセージが指定受信者に到達する前に「ループする」ので、非効率となり得る。混乱を避ける１組の手法のうち、「ソースルーティングプロトコル」の方法が適用される。一例は後述するが、現時点では、場合によっていくつかの中間装置を経由することもある指定受信者への経路をソースが見つけ出すと言うだけにとどめておく。ソース経路に沿った装置のみがインターセプトされたメッセージを転送し、したがって非効率な過度の中継トラフィックを低減しながらの送達が可能となる。この問題についてのソースルーティング以外の手法も開発されている。

ソースルーティングは一般に、宣伝通りに動作するが、階層型プロトコルの層間の互換性問題をよく例証している。階層型プロトコルスタック内でソースルーティングを配置する場所を決定するときに、こうした問題が生じる。ソースルーティングプロトコルを層３プロトコルの一部とし、したがって層３アドレスを使用する場合、階層型プロトコルモデルによって、ソースルーティングプロトコルは複数の層２と動作することができる。これは、ネットワーク内の装置が異なる無線プロトコルを使用しているとき、またはネットワークが有線および無線の装置を含んでいるとき（または単一の装置が有線および無線のネットワークインターフェイスを有しているとき）はかなり有利である。しかし、上述したように、異なる層３プロトコルは、必ずしも相互に連携して働くとは限らない。したがってＩＰｖ４の層３プロトコル用に開発された層３ソースルーティングは、ＩＰｖ６やＩＰＸなど他の層３プロトコルを使用する装置とは連携して働かないことになる。この問題は、層２にソースルーティングプロトコルを配置し、層２のアドレスを使用することによって進展はするが、解決はされない。層２のソース経路が複数のタイプの層２のネットワークインターフェイスにまたがるようにするには、ソースルーティングプロトコルを層２の技術ごとに再実装する必要があることになる。イーサネット（登録商標）およびＢｌｕｅｔｏｏｔｈ（無線ネットワーク標準）などの異なる層２のネットワークインターフェイスでは、互換性のない異なる形式を各アドレスに使用することができるため、さらに問題が生じる。

Internet Engineering Task Force Internet Draft "The Dynamic Source Routing Protocol for Mobile and Ad Hoc Networks (DSR)"

新しい通信タスクを開発し、それに対処するために、階層型プロトコルシステムは、各層での新しいプロトコルに対応できなければならない。階層型モデルは、新しいプロトコルとプロトコルスタック内のその上下の他のプロトコルとの間に確実に互換性を提供するのを助ける。しかし、ソースルーティングの例が示すように、所与の層内ではプロトコル間の互換性がないことによって、階層型プロトコルの完全な保証が妨げられている。

上記を考慮して、本発明は、通信スタック内の２つのプロトコル層の間に仮想プロトコル「中間層」を提供する。通信タスクを実行する必要があり、しかし互換性の問題のために既存のプロトコル層内の実装が配置を妨げる可能性があるとき、本発明の方法を使用してタスクを扱う中間層を作成する。中間層に固有のアドレス指定方式をセットアップする。中間層は、プロトコルスタック内の他の層が中間層に通信タスクの実行の詳細を委ねることによって、それまで通り動作できるようにする。

プロトコル中間層の動作の詳細は、それが実行するよう求められるタスクの詳細に応じて異なる。必要な場合、１つの通信装置で同時に複数の中間層をサポートすることはできるが、パフォーマンスの問題によって中間層の増設が妨げられる可能性がある。

必須のネットワーキング環境において中間層のアドレスを割り当て、見つけ出すように、他のプロトコル層ですでに使用されている技術を変更することができる。一部の実施形態では、各ネットワーク装置上の各ネットワークインターフェイスに、グローバルに一意のそれ自体の中間層アドレスが割り当てられる。各ネットワーク装置に単一の中間層アドレスが割り当てられる実施形態では、ネットワーク装置上の複数のネットワークインターフェイス間で違いを識別できるように、インターフェイス識別子を中間層アドレスに追加することができる。

一部の実施形態では、プロトコル中間層は、その上下のプロトコル層に変更を加えることなく導入される。例えば中間層は、その下の層（例えば層２）によって提示された同じインターフェイスをその上の層（例えば層３）に提示する。したがって、既存の上位のプロトコル層は、ちょうど下位のプロトコル層と対話していた場合と同様に中間層と対話する。他の実施形態では、中間層に隣接するプロトコル層へのほんのわずかな変更が必要となる。例えば、受信したメッセージ内の新しいヘッダーフラグは、下層自体がメッセージを処理したり上層に渡したりする代わりに、メッセージを中間層に渡す既存の技術を使用して、下層によって認識することができる。

ソースルーティングは、プロトコル中間層の有用性を実証するのに役立つ例である。一実施形態では、中間層は、ＩＳＯ／ＯＳＩプロトコル層２と層３の間に構築される。ソースルーティングは、中間層アドレスを使用してこの中間層内で実行される。層２または層３のアドレスの代わりに中間層アドレスを使用することにより、ソースルーティングのこの実施形態によって、複数の層３プロトコルおよび複数の層２ネットワークインターフェイスとの互換性が可能になる。

添付の特許請求の範囲には本発明の特徴を詳しく記載しているが、以下の詳細な説明を添付の図面と併せ読めば、本発明、およびその目的および利点を最もよく理解できよう。

図面を参照すると、図中同様の参照番号は同様の要素を指しており、本発明を、適したコンピューティング環境で実施されるものとして示している。以下の説明は、本発明の実施形態に基づいており、本明細書に明示的に記載されていない代替実施形態に関して本発明を限定するものとみなされないものとする。

以下の説明では、特に指定のない限り、１つまたは複数のコンピューティング装置によって実行される動作および操作の象徴を参照して本発明を説明する。したがって、コンピュータで実行されると言うこともあるこうした動作および操作は、コンピューティング装置の処理単位による構造化された形式のデータを表す電気信号の操作を含むことは理解されよう。この操作は、コンピューティング装置のメモリシステム内の複数の場所でデータを変換または維持し、当分野の技術者によってよく理解されているようなやり方で装置の操作を再構成するか、そうでない場合は変更する。データが維持されるデータ構造は、データの形式によって定義される特定の性質を有するメモリの物理位置である。しかし、本発明を上記の文脈で説明しているが、以下に記載する様々な動作および操作をハードウェアでも実施できることを当分野の技術者であれば理解できるように、これに限定されるものではない。

本発明は、通信スタック内の２つのプロトコル層の間に仮想プロトコル「中間層」を提供する。通信タスクを実行する必要があり、しかし互換性の問題のために既存のプロトコル層内の実装が配置を妨げる可能性があるとき、それ自体のアドレス指定方式を備える、タスクを扱う中間層を作成する。

本発明の方法は、幅広く適用可能であり、したがって一般の概念については多少抽象的である。以下の説明では、その一般的な概念を説明するために、特定の実装形態に焦点を置く。ソースルーティングは、プロトコル中間層の有用性を実証するのに役立つ例である。以下で説明する一実施形態では、中間層は、ＩＳＯ／ＯＳＩプロトコル層２と層３の間に構築される。ソースルーティングは、中間層アドレスを使用してこの中間層内で実行される。層２または層３のアドレスを使用する代わりに中間層アドレスを使用することにより、ソースルーティングのこの実施形態によって、複数の層３プロトコルおよび複数の層２ネットワークインターフェイスとの互換性が可能になる。本発明の有用性は、ソースルーティングに限定されるものではないが、他の通信タスクを実行するためにプロトコル中間層を開発することもできる。

ソースルーティングは、従来のルーティング方法が適用されない状況のために開発された１組の技術である。まず、従来のルーティングがどのように動作するかについて考察する。従来の有線ネットワーク上の装置にとって、他のすべての装置は、２つの一般的なクラスに分割される。「ローカル」装置は、同じローカルネットワークとともに配置されており、直接アクセスすることができる。「リモート」装置は、ローカルネットワークの境界を超えて配置されており、ルーターを介してアクセスされる。ルーターは、ローカル装置である。従来のルーティング方法は、ローカル装置およびリモート装置のこの二分法に基づいている。ローカル装置に送信するとき、ソース装置は、単にメッセージを指定受信者にアドレス指定し、メッセージをローカルネットワーク上に送出する。指定受信者を含むすべてのローカル装置は、メッセージを受信する（このあまりに単純な概念は、必ずしも実際のネットワークに当てはまるとは限らない。例えば、イーサネット（登録商標）スイッチは、アドレス指定された装置を含んでいないローカルリンクには、イーサネット（登録商標）フレームを伝えない。しかし、この単純な概念は、例示の目的では有効である。イーサネット（登録商標）スイッチがローカル装置の位置を見つけ出し、それに応じて転送を限定するやり方は、非無線ネットワークにおける「アドホック」ルーティングの優れた例である）。次いで指定受信者を除くすべてのローカル装置は、メッセージを破棄する。指定受信者は、メッセージを読み取り、それ相応に応答する。

指定受信者がソース装置から離れているとき、従来のルーティングは、それだけではないが、「最短パス」アルゴリズムを適用することが多い。ソース装置（または多くの場合ソース装置のネットワーク上のルーター）は、指定受信者までの最短パスを考慮し、ソースのメッセージをその最短パス上の次の装置に送信する。次の装置は、メッセージを受信すると、受信者のアドレスを検査し、この装置が指定受信者である場合はメッセージを受け取り、あるいは再度最短パスアルゴリズムを適用して、メッセージを前方に送信する。最終的にメッセージは指定受信者に到達する。メッセージをルーティングする各装置、ソースおよび中間装置のすべては、メッセージを次に送信するべき場所に関してそれ自体の選択を行うことに留意されたい。ルーターは、終端間ネットワーク技術情報を定期的に共有して、そのそれぞれが最短パスを正確に選択できるようにする。

しかし、従来のルーティング技術は、短距離無線プロトコルを使用して通信する装置をサポートするネットワークにおいては正常に働かない。この第１の理由は、非常に速いペースで無線ネットワークが変化するためである。無線装置は、従来技術によるネットワーク位相情報の検出ではついて行けないほど、非常に速くネットワーキング環境に出入りする。第２に、他の装置のうちどれが現在ネットワーク内にあるかについて、無線装置間で異なることがある。これらの問題は、比較的不変であり、普遍的に認められているといった２つの意味で認識できる位相情報の従来のモデルに違反する。

図１のネットワーク通信環境について考察する。「アドホック」無線ネットワーク１００において、装置１０２、１０４、１０６はすべて、（細長い「Ｚ」で暗に示すように）互いに無線で通信することができる（この文脈では「アドホック」とは、ネットワーク１００の中央構成管理がなく、したがって従来のルーティングアルゴリズムが大いに当てにしているアドレスおよび位相情報のための中央リポジトリがないことを意味する）。装置１０６は、別の装置１１０への無線ローカルエリアネットワーク（ＬＡＮ）接続１０８も含む。装置１１０は、例えば、アドホック無線ネットワーク１００をインターネット１１２に接続するルーターである。しかし、この装置１１０には無線受信機がないため、無線専用装置１０２および１０４は、直接装置１１０と通信することができず、何らかの援助無しには、ルーター１１０を介してインターネット１１２に接続することもできない。

これらの問題に取り組むために、無線装置は、インターセプトされた他の装置宛のメッセージを転送することによって互いに助けあう。これによって、ソース装置によって送信されたメッセージは、指定受信者に到着する前にいくつかの中間装置を「ホップ」または通過する。ソースルーティングプロトコルは、メッセージが指定受信者に向かう途中で複数回同じ中間装置を通過する送信「ループ」を防ぐ１組の手法を形成する。簡潔に言えば、ソース装置は、経路を見つけ出し、場合によっていくつかの中間装置を経由して指定受信者に到達する。ソース経路に沿った装置のみがインターセプトされたメッセージを転送し、したがって非効率な過度の中継トラフィックを低減しながらの送達が可能となる。明瞭にするために、この解説では、ソースルーティングを使用して本発明の方法を示すが、これらの方法は、開発されているこの問題についてのソースルーティング以外の手法にも同じく適用可能である。

図２ａから図２ｃのデータフロー図は、簡単なソースルーティングのシナリオを示す。このシナリオをまずかなり高レベルで示す。次いで図６の解説の後、再度このシナリオを使用してさらにアドレス指定の詳細に注目する。

装置１０２は、装置１１０にメッセージを送信することを望んでいる。メッセージの性質は、この解説では重要ではない。メッセージは、装置１１０上で動作するアプリケーション宛のもの、またはインターネット１１２上の別の装置に経路指定するために装置１１０に送信するものでもよい。いかなる場合でも、装置１０２は、装置１１０と直接には通信できないため、図２ａのステップ２００で、装置１１０へのソース経路を見つけ出す。

見つけ出されたソース経路は、装置１０６を通過する。装置１０２は、装置１０６と直接通信することができ、また装置１０６は、装置１１０と直接通信することができる。多くのプロトコルは、このソース経路を見つけ出すために存在し、その複雑さはこの解説の範囲を超えている。ソースルーティングのこれ以上の背景、および特定のソースルーティングプロトコルの詳細については、参照により全部本明細書に組み込まれている非特許文献１を考察されたい。

図３は、ソース経路３００を示す。ソール経路３００は、ソース装置１０２（フィールド３０２）で始まり、次いで装置１０６（フィールド３０４）に進む。装置１０６は、１つはアドホックネットワーク１００における無線装置への、もう１つはＬＡＮ１０８への２つのネットワークインターフェイスを有しているので、フィールド３０４では、これら２つのインターフェイスのどちらがソース経路３００上の前の装置からメッセージを受信するかも指定する。ここでは、装置１０６の無線インターフェイスは、無線専用装置１０２からメッセージを受信することになっている。ソース経路３００における次のエントリまたは「ホップ」は、メッセージがどのように装置１０６（フィールド３０６）から出力されるかを指定する。メッセージは、ＬＡＮインターフェイスを介して出力されることになっている。次ホップは、最後のもの、つまり指定受信者、フィールド３０８で指定されている装置１１０である。ソース経路の形式および内容は、様々なソースルーティングプロトコル間で異なり得るため、図３は、単にソース経路の内容を例として示すためのものである。例えば、ソース経路の中には、中間フィールド３０４および３０６のみを含み、それぞれソースフィールド３０２および宛先フィールド３０８をそれぞれソース経路自体の一部とはみなさないものもある。当然、実際のソース経路は、図３の簡単な例よりかなり複雑であり得る。

装置１０２は、装置１１０宛のメッセージを作成し、その中にソース経路３００を含める。メッセージは、ソース経路上の次ホップ、この場合では装置１０６にアドレス指定される。図２ａのステップ２０２では、メッセージは、無線通信ネットワーク１００に送信される。他の無線装置１０４および１０６は、ステップ２０４でメッセージを受信し、次いでステップ２０６でメッセージの宛先アドレスを検査する。この次ホップ先は一般に、ソース経路３００における最終的な受信側アドレスではないことに注意されたい。宛先アドレスが装置１０４のものに一致しないため、その装置は、ステップ２０８でメッセージを破棄する。

一方、宛先アドレスが装置１０６のものと一致し、その結果、装置は、続いてステップ２１０でメッセージ、特にソース経路３００を検査する。ソース経路３００を検査することによって、装置１０６は、このメッセージの指定受信者ではないことがわかる。そのため、装置１０６は、図２ｂのステップ２１２で、ソース経路３００において次ホップ、装置１１０を見つけ出し、メッセージを転送する。

装置１１０は、ステップ２１４でメッセージを受信し、ステップ２１６で宛先アドレスを検査する。そのアドレスは装置１１０のものに一致しているため、装置１１０は、続いてステップ２１８でメッセージ内のソース経路３００を検査する。図２ｃのステップ２２０で、装置１１０は、メッセージの指定受信者であることを認識する。装置１１０は、必要に応じてメッセージの内容を処理する。

図２ａから図２ｃの上記の解説では、階層型プロトコル全般についても、どの層がどの通信タスクを行うかの詳細についても言及していない。この解説が階層型プロトコル、特に以下の階層型プロトコルにおけるアドレス指定の解説のきわめて一般的な基礎を提供することができるように、それについての言及は、意図的に省略している。図６に伴う解説の後、このシナリオを再検査して、以下で階層型アドレス指定について考察する。

図１のネットワーク装置１０２、１０４、１０６、および１１０は、任意のアーキテクチャのものでよい。図４は、一般に本発明をサポートするコンピュータシステムの例を示すブロック図である。図４のコンピュータシステムは、適した環境の一例にすぎず、本発明の使用または機能の範囲に関する限定を示唆するものではない。また、装置１０２を、図４の例に示した構成要素のいずれか１つ、またはその組合せに関連する依存性または必要条件を有しているものと解釈すべきではない。本発明は、他の多くの汎用または専用コンピューティング環境または構成で動作可能である。本発明との使用に適したよく知られているコンピューティングシステム、環境、および構成の例には、それだけには限定されないが、パーソナルコンピュータ、サーバー、ハンドヘルドまたはラップトップ装置、タブレット装置、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラム可能家庭用電化製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記の任意のシステムまたは装置を含む分散コンピューティング環境などがある。その最も基本的な構成では、装置１０２は一般に、少なくとも１つの処理ユニット４００およびメモリ４０２を含む。メモリ４０２は、揮発性（ＲＡＭなど）、不揮発性（ＲＯＭやフラッシュメモリなど）、またはその２つの何らかの組合せとすることができる。この最も基本的な構成を、図４の破線４０４内に示している。装置１０２は、追加の特徴および機能を有し得る。例えば装置１０２は、それだけには限定されないが、磁気および光ディスクおよびテープを含む別の記憶装置（リムーバブルおよび非リムーバブル）を含むことができる。こうした別の記憶装置は、図４に、リムーバブル記憶装置４０６および非リムーバブル記憶装置４０８で示している。コンピュータ記憶媒体には、コンピュータ可読命令、データ構造、プログラムモジュール、他のデータなど、情報を記憶するための任意の方法または技術で実施される揮発性および不揮発性のリムーバブルおよび非リムーバブル媒体がある。メモリ４０２、リムーバブル記憶装置４０６、および非リムーバブル記憶装置４０８は、すべてコンピュータ記憶装置媒体の例である。コンピュータ記憶媒体には、それだけには限定されないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置、他の磁気記憶装置、所望の情報の格納に使用でき、装置１０２からアクセスできる他の任意の媒体などがある。こうした任意のコンピュータ記憶媒体を装置１０２の一部とすることができる。装置１０２は、装置が他の装置と通信できるようにする通信チャネル４１０を含むこともできる。通信チャネル４１０は、通信媒体の例である。通信媒体は一般に、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータを搬送波または他の移送機構などの変調されたデータ信号に組み込む。これには任意の情報配送媒体がある。「変調されたデータ信号」という用語は、信号内の情報を符号化するように設定または変更された１つまたは複数のその特徴を有する信号を意味する。通信媒体には、それだけには限定されないが一例として、有線ネットワーク、直接配線された接続などの有線媒体、および音響、ＲＦ、赤外線、その他の無線媒体などの無線媒体がある。「コンピュータ可読媒体」という用語は、本明細書で使用する場合、記憶媒体および通信媒体の両方を含む。装置１０２は、キーボード、マウス、ペン、音声入力装置、タブレット、タッチ入力装置などの入力装置４１２を含むこともできる。ディスプレイ（タッチ入力装置と一体化してもよい）、スピーカー、プリンタなどの他の装置４１４を含めることもできる。こうした装置はすべて、当分野ではよく知られており、ここで詳細に説明する必要はない。

ネットワーク装置１０２、１０４、１０６、および１１０は、いくつかの通信プロトコルのうちのいずれかを使用することができる。上記の背景技術のセクションで説明したように、全部ではないが今日の通信プロトコルの多くは、図５ａに示すＩＳＯ／ＯＳＩプロトコルモデルに従う。このモデルでは、ネットワーク通信を可能にする全タスクをサブタスクに分割し、これらのサブタスクをそれぞれプロトコルスタックの論理層に割り当てる。論理的に各層は、別の装置上のそのピア層と通信し、スタック内のその上の層にサービスを提供し、その下の層によって提供されるサービスを使用する。物理的に、ここではＬＡＮ１０８として示したネットワーク接続の媒体を介して物理層５００がメッセージを実際に送信するまで、メッセージは発信者からスタックを下方に流れる。その指定受信者がそのメッセージを受信すると、メッセージは、スタックを上方に向かって渡され、各層は、それ宛のデータを取り除き、またそれに応答し、メッセージの残りを上方の次レベルに渡す。この階層型モデルの主な利点は、各プロトコル層が、プロトコルスタック内の他の層によって扱われる無数の詳細にそれ自体が関わることなく、そのピアと通信できることである。つまり各層は、他の層によって行われるタスクとはほぼ関係なくその通信タスクを行う。

ＩＳＯ／ＯＳＩプロトコルスタックは、概念上のモデルにすぎず、プロトコルはそれに正確には従わないことに注意されたい。しかし、今日普及している多くのプロトコルは、大なり小なりこのモデルに従っており、このモデルによって、それが定義する通信タスクの解説がより理解しやすくなる。

ＩＳＯ／ＯＳＩモデルは、ＩＳＯ／ＯＳＩ階層型通信プロトコルをサポートするのに必要なタスクを装置１０２がどのように内的に実装すべきかは指定しない。図５ｂは、普及している伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）スタックをサポートするタスクの１つの可能な実装を示している。必ずしもすべての実施形態においてではないが、この実施形態では、通信は、ＩＳＯ／ＯＳＩモデルにおける階層型スタックに酷似したコンピューティング構成要素のスタックを上下に流れる。ネットワーク通信サービスは、ソケット層５１０によってアプリケーションプログラム５０６に提示される。ソケット層５１０は、ＩＳＯ／ＯＳＩ通信プロトコルの詳細からアプリケーションプログラム５０６を分離する。この分離は、装置１０６などの装置が複数のネットワークに接続されており、複数の通信プロトコルを稼動させているときに、とくに価値がある。アプリケーションプログラム５０６がソケット層５１０においてルーチンを呼び出し、別の装置上のアプリケーションプログラム５０６にメッセージを送信すると、要求はプロトコル構成要素のスタックを下り、各構成要素はＩＳＯ／ＯＳＩモデルに従って他の装置上のそのピアと通信する。しかし、この実施形態でさえも、構成要素の中には、ＩＳＯ／ＯＳＩ層に直接マップしないものもある。ここでは特定の層５（セッション層）が欠如しているが、一部のプロトコルには、ＩＳＯ／ＯＳＩ層のすべてを実装していないものもある。また、一実装形態では、いくつかのＩＳＯ／ＯＳＩ層の機能を１つの構成要素にまとめることもできる。図５ｂでは、層３（図５ａのネットワーク層５０４）および層４（トランスポート層５０８）は、複合ＴＣＰ／ＩＰドライバ５１６によってサポートされている。ＴＣＰ／ＩＰなどの複雑なプロトコルは、データの簡単なトランスポートを超えたいくつかのタスクを必要とする。図５ｂでは、これらの機能を、認証サービスを提供する８０２．１Ｘ構成要素５１２、および非静的層３アドレスを提供する動的ホスト構成プロトコル５１４によって表している。

図６は、ＩＳＯ／ＯＳＩプロトコルの通信タスクをサポートする１つの可能なソフトウェア実装を示している。このシステムの例では、アプリケーションプログラム５０６は、装置１０６上で稼動する。アプリケーションプログラムは、階層型サーバープロバイダ６００を介して、装置１０６によって提供される標準通信ハードウェアおよびソフトウェアと通信する。この場合、ネットワークプロトコルスタック６０２は、その内部バッファとともに通信タスクを扱う。入力／出力マネージャ６０４は、通信チャネルをセットアップし、取り壊す。ネットワークプロトコルスタック６０２は、ハードウェア抽象層６０６と通信し、ハードウェア抽象層は、ＬＡＮ通信リンク１０８を稼動させるネットワークインターフェイス６０８と通信する。別のネットワークインターフェイス（図示せず）は、装置１０６の無線リンクを稼動させる。

図２ａから２ｃのシナリオをさらに掘り下げ、図５ａのＩＳＯ／ＯＳＩ階層型プロトコルモデルを指標として使用すると、各ホップ（ステップ２０２、２０６、２１２、および２１６）で使用する宛先アドレスは、層２アドレスである（ＩＥＥＥ８０２ネットワークでは、これらはメディアアクセス制御アドレスと呼ばれる）。これらのアドレスは、ローカルネットワーク内では一意であるが、グローバルに一意でなくてもよい。異なるタイプのネットワーク（有線ＬＡＮ１０８対無線ネットワーク１００）は、互換性のない異なるアドレス形式を使用することができる。こうした層２アドレスに加えて、層３またはより上位の任意の層によって作成されたメッセージは、ソースおよび指定受信者の層３アドレスを含む。

図３は、ソース経路３００の例ではプロトコル中間層アドレスを使用していることを示している。従来技術のソースルーティングプロトコルは、層２アドレスまたは層３アドレスのいずれかを使用する。いかなる場合でも、ソース経路は、そのアドレスを提供するプロトコル層にとって理解できるだけである。したがってソース経路が層２アドレスを使用する場合、ソース経路は、層２プロトコルドライバ５１８によって検査されることになる（ステップ２１０および２１８）。あるいは、これらのステップで、層３アドレスベースのソース経路が層３プロトコルドライバ５１６によって検査されることになる。背景技術のセクションで上述したように、ソースルーティングプロトコルをＩＳＯ／ＯＳＩプロトコルスタック内のどこに配置するかの選択は重要である。というのは、階層型プロトコルの中間層の互換性問題のため、各選択には長所および短所があるからである。ソースルーティングプロトコルを受信しないいずれの層も、明らかにソースルーティングするように動作することができ、したがってそれ自体の互換性の基準を保持することはできるが、ソースルーティングプロトコルが稼動している層では、それ自体の層における他の実装との互換性がなくなる。プロトコル中間層の使用は、（不適切な単語の選択ではあるが）ソースルーティングを層２にも層３にも配置しないことによって層間の非互換性問題に対処する。

以下の解説では、ＩＳＯ／ＯＳＩプロトコルスタックの層２と層３の間にあるプロトコル中間層におけるソースルーティングの特定の実装形態について詳述する。この例では、図１の環境および図２ａから図２ｃの通信のシナリオを再度使用する。

図７は、装置１０２の層３プロトコルドライバ５１６がどのようにシナリオを開始するかを示している。図７の方法は、図２ａのステップ２００の前に行われる。ステップ７００で、ソース（装置１０２）および指定受信者（装置１１０）の層３アドレスを含む層３データパケットが作成される。下位のプロトコル層は、層３アドレスを使用してデータパケットを経路指定することができないため、ステップ７０２で、これらのアドレスは、プロトコル中間層によって指定されたアドレスに変換される。この変換プロセスは、図８に示すようなアドレス関連表への簡単な照会でよい。アドレス表８００で、装置の層３（ＩＰ）アドレスをキーとして使用して、その同じ装置の中間層アドレスを含むレコードを探す。層３プロトコルドライバ５１６は、中間層アドレスの形式を理解する必要はなく、表８００から値を引き出すだけでよいことに注意されたい。ステップ７０４で、層３プロトコルドライバ５１６は、層３データパケットを、中間層のソースアドレスおよび宛先アドレスとともにプロトコル中間層に送達する。

一部の実装形態では、層３プロトコルドライバ５１６は、プロトコル中間層に対応するのにまったく変更なく図７の手順に従うことができることに注意されたい。層３プロトコルドライバ５１６は、ステップ７０２で、層２アドレスを要求していることを確信できることになる。この要求はインターセプトされ、代わりに中間層アドレスが戻される。同様に、層３プロトコルドライバ５１６は、ステップ７０４で、層３データパケットをプロトコル中間層の代わりに層２プロトコルドライバ５１８に送達していることを確信できることになる。層３および層２のプロトコルの結合によって、プロトコル中間層が層３プロトコルドライバ５１６にとってまさに別の層２プロトコルドライバ５１８のように見えるようになる。これは、その上のプロトコルドライバに少しの変更も加えることなくプロトコル中間層を導入することができる一例である。この可能性は、決定的な互換性および広範な実装の利点を有している。

プロトコル中間層は、図９ａのステップ９００で層３からデータパケットを受信する。受信した中間層ソースアドレスは層２プロトコルドライバ５１８からは理解できないため、中間層は、ステップ９０２で、このアドレスを層２ソースアドレスに変換する（層２プロトコルドライバ５１８は、それ自体の層２アドレスを知っている可能性があるため、実際にはこの変換ステップは任意選択である）。変換は、図８のアドレス関連表８００を使用することができる。

ステップ９０４で、プロトコル中間層は、まず、このデータパケットにソースルーティングの方法を適用するかどうかを決定する。例えば、層３データパケットが装置１０６で生成され、装置１１０に宛てられる場合、ＬＡＮ１０８は、パケットを直接運び、ソースルーティングは必要ない。一方、図２ａから図２ｃのシナリオでは、ソース装置１０２から受信側装置１１０にデータパケットをトランスポートするのにソースルーティングが必要である。これを認識して、プロトコル中間層は、ステップ９０４（図２ａのステップ２００に対応）で適切なソース経路を探し出す。このステップの詳細は、使用されるソースルーティングプロトコルによって決まり、非常に複雑となり得る。装置１０２は、適切なソース経路を表にすでに格納しておくことができ、したがってステップ９０４で経路を取り出すだけでよい。そうでない場合、装置１０２は、その周りの装置に問い合わせることによって経路を見つけ出すことができる。この例では、探し出したソース経路は、装置１０６を通過し、図３に示すような中間層アドレスを使用する。

ステップ９０６で、プロトコル中間層は、それ自体のヘッダーを層３データパケットに追加して中間層データフレームを作成する。中間層ヘッダーの形式の例については、図１１を参照して後述する。

プロトコル中間層は、ステップ９０８で、次ホップの中間層アドレスを層２のアドレスに変換する。ソースルーティングが適切ではない（例えば装置１０６が直接装置１１０に発送している）場合、次ホップは受信側装置である。ソース経路を含むメッセージの場合、アドレスは、その経路内の次の装置の層２アドレスである。このシナリオでは、これは、装置１０６の層２アドレスである。

ステップ９１０で、プロトコル中間層は、メッセージの送信に使用する特定の層２プロトコルドライバ５１８を選択するために、次ホップの中間層アドレスのインターフェイスインデックスを使用する。このステップは、送信側装置が層２のインターフェイスを複数有するときに適用される。このシナリオでは、層２のインターフェイスが１つしかないため、このステップは装置１０２には適用されない。

図９ｂのステップ９１２で、層３データパケット、それに結び付けられた中間層ヘッダー、ソース層２アドレス、および次ホップの層２アドレスが選択された層２プロトコルドライバ５１８に送達される。

ステップ９１４および９１６は、任意選択であるが、一部のソースルーティングプロトコルによって指定される。これらのプロトコルでは、ステップ９１２で層２のプロトコルドライバ５１８に送達されるデータパケットにタイマが関連付けられる。送達の成功を示す表示が受信されない（が、指定受信者またはソース経路上の中間層装置から来ることになっている）場合、送信側装置は、その選択されたソース経路に関してどこか異常があることがわかる。これは、選択されたソース経路上の装置が、範囲外に移動し得る、または完全になくなり得るアドホックネットワークではよくあることである。タイマが期限切れになると、ソース装置は、ソースルーティングプロトコルによって指定された方法を適用してソース経路を修正する、または取り替える。次いでメッセージは、新しいソース経路を使用して転送される。

層２のプロトコルドライバ５１８は、プロトコル中間層からメッセージを受信すると、代わりに層３プロトコルドライバ５１６からメッセージを受信したかのように続行する。装置１０６にアドレス指定され、層３データパケットおよび中間層ヘッダーを含む層２のデータフレームは、図２ａのステップ２０２で、装置１０２の無線送信機によって送信される。

図２ａから図２ｃのシナリオでは、層２のデータフレームがネットワーク接続を介して受信される場所が２つある。ステップ２０４の装置１０４および１０６、およびステップ２１４の装置１１０である。これらのステップで、受信側の層２のプロトコルドライバ５１８は、図１０の手順を使用することができる。層２のデータフレームは、ステップ１０００で受信され、ステップ１００２の適切な層２の通常のやり方に従って処理される。こうしたやり方は、フレーム内の層２の宛先アドレスを現在の装置のアドレスと比較することを含む（この比較は、ステップ２０６およびステップ２１６で行われる）。この比較を行った後、装置１０４は、違いに気づき、データフレームがそれ宛ではないため、ステップ２０８でデータフレームを破棄する。この破棄は、層２の通常のやり方に基づいて行われるため、メッセージに含まれるソース経路には依存しないことに留意されたい。

装置１０４の場合とは異なり、装置１０６でのステップ２０６、および装置１１０でのステップ２１６における層２の宛先アドレスの比較によって、これらの装置が受信したデータフレームの指定の宛先であることが明らかになる。したがってこれらの装置は、続いて図１０のステップ１００４でデータフレームの内容を検査する。この検査によって、データフレームが図１１の１１０４などの中間層ヘッダーを含んでいることが明らかになる。層２のプロトコルは、同時に存在する複数の層３プロトコルをサポートするよう設計されているため、これらのプロトコルは、データフレームをどの層３プロトコルドライバ５１６に宛てるべきかを層２のプロトコルドライバ５１８に伝えるフラグの値を指定する。この実施形態では、そのフラグはフィールド１１０６である。フラグには、中間層に関連する値が与えられる。したがって、層２のプロトコルドライバ５１８は、フラグ１１０６を読み取り、それがちょうどフラグの他の値に応答するようにその値に応答する。データフレーム１１００は、プロトコル中間層がまるで別の層３プロトコルドライバ５１６であるかのようにプロトコル中間層に渡される。データフレームが中間層ヘッダーなしに受信されると、層２のプロトコルドライバ５１８は、ステップ１００８で層３パケットの有無についてフレームを検査し、層３パケットが見つかった場合は、それをステップ１０１０で（フラグの値で決定したように）適切な層３プロトコルドライバ５１６に送達する。

プロトコル中間層の導入では、現時点でステップ１００４で中間層ヘッダーの存在を認識し、それを必要に応じて送達しなければならないという点でのみ層２のプロトコルドライバ５１８を変更するだけであることに注意されたい。層２プロトコルはすでに多くのタイプの層３フラグ値に精通しており、その結果この変更は単に、別の普遍的に認識された（フィールド１１０６内の）フラグの値の、層２のプロトコルドライバ５１８によってすでに認識されているものへの追加である。また、中間層の存在によって、すべてのメッセージがそこを通過する必要はないが、必要に応じてメッセージを（ステップ１００８および１０１０のように）引き続き層２から層３に直接渡すことができることにも注意されたい。

プロトコル中間層は、それぞれ装置１０６でのステップ２１０および装置１１０での２１８において、層２のプロトコルドライバ５１８からデータフレーム１１００を受信する。受信側中間層は、図１２ａおよび１２ｂの方法を適用する。ステップ１２００で、その中間層ヘッダー１１０４を含むデータフレーム１１００を受信する。ステップ１２０２で、装置は、そのソースルーティングプロトコルによって定義された適切な方法を適用する。次いでステップ１２０４で、受信側装置は、中間層ヘッダー１１０４内の宛先中間層アドレス３０８を検査する。上記のステップ２０６および２１６で検査した層２の宛先アドレスとは異なり、これは、メッセージの最終的な受信者のアドレスであることに注意されたい。宛先中間層アドレス３０８は、ステップ１２０６で現在の装置に割り当てられている中間層アドレスと比較される。装置１１０（図２ｂのステップ２１８）では、この比較によって、この装置１１０がメッセージの指定受信者であることが明らかになる。次いでメッセージは、ステップ１２０８で層３プロトコルドライバ５１６に渡されて、層３プロトコルドライバ５１６はメッセージをそれ相応に処理する（図２ｃのステップ２２０）。

ステップ１２０６の比較が装置１０６で実行され、しかしこの装置１０６は、メッセージの指定受信者ではなかったことがわかる。次いで装置１０６は、ソース経路３００内の次ホップの中間層アドレスについて中間層ヘッダー１１０４を検査し、その次装置にメッセージを渡す準備をする。続いてそれを行う手順が行われる。これは、ソース経路３００内の第１の装置にメッセージを送信する際にソース装置１０２によって実行される。図１２ａおよび図１２ｂでは、ステップ９０２および９０８から９１６について上記で使用したのと同じ番号付けを使用することによってこの関係を強調している。図２ａから図２ｃのシナリオでは、次ホップは、装置１１０へのものであり、（ソース経路３００のフィールド３０６内のインターフェイスインデックスで指定したように）装置１０６のＬＡＮ１０８ネットワークインターフェイスを使用する。装置１０６は、それ自体のソース層２アドレス（図１２ａのステップ９０２）、および装置１１０の層２アドレス（図１２ｂのステップ９０８）をデータパケットに追加する。次いでパケットは、ＬＡＮ１０８ネットワークインターフェイスを扱う層２のプロトコルドライバ５１８に送信される（図２ｂのステップ２１２）。

上述したシナリオは、その上下の層にわずかな変更を加えて、または変更を加えることなく、重要な通信タスクを扱うプロトコル中間層をどのようにしてプロトコルスタックに追加することができるかを示す。中間層の動作の詳細は、実行が求められるタスクの詳細に応じて決まる。しかし、こうした詳細とは関係なく、中間層アドレスの割当に使用されている方法がある。当分野でよく知られているいくつかのアドレス割当方法を中間層アドレスに使用することができる。図１３に一例を示している。手順は、ステップ１３００で開始し、装置がそれ自体の中間層アドレスを選択する。選択は、完全に無作為に行うことができる。装置が複数のネットワークインターフェイスを有している場合、ステップ１３０２でインターフェイスインデックスがこれらのインターフェイスに割り当てられる。ステップ１３０４で、装置は、他の装置の中間層アドレスの学習を開始する。これらのアドレスは、例えば、近隣探索（ＮｅｉｇｈｂｏｒＤｉｓｃｏｖｅｒｙ）およびアドレス解決プロトコル（ＡＲＰの例については以下を参照）などの既存のプロトコルの方法を適用することによって必要なときに見つけ出すことができる。ステップ１３０６でアドレスの競合が見つかると、ステップ１３０８で、競合する装置の少なくとも一方は、そのアドレスを変更する必要がある（実際に中間層のアドレス空間のサイズの適切な選択によってアドレスの競合の可能性をきわめて少なくすることができるので、このチェックは絶対に必要というわけではない）。アドレスは固有の意味を持たないため、ステップ１３０８の手順は、単に装置が無作為に別のアドレスを選択し、競合についてそれを検討することにより競合を見つけ出すことを含むこともできる。選択されたアドレスは、他のアドレスとともに図８のアドレス関連表８００に格納される。手順はステップ１３１０で終了し、別の競合が見つかるまで行われない。

ソースルーティングは、多層プロトコルタスクの稼働に関与する多くの通信タスクのうちのほんの１つである。本発明の方法は、上述したようにプロトコル中間層に対応するよう変更する必要なく他の通信タスクを進めることができるように設計されている。一例として、また中間層のブロードキャストアドレス指定の一例として、図１４ａおよび１４ｂの通信のシナリオを考察する。このシナリオは、図１から知られる同じ装置を含むが、今回は、装置１０２上の層３プロトコルドライバ５１６が装置１１０の層３アドレスに関連する層２アドレスを見つけ出すことを望んでいる。少なくともそれが、層３プロトコルドライバ５１６が望んでいると確信していることである。しかし、これらの装置によって、実際に中間層アドレスを有するプロトコル中間層が稼働している。したがって、層３プロトコルドライバ５１６は、装置１１０の層３アドレスに関連する中間層アドレスを本当に知りたがっている（上記のシナリオでは、装置１０２はすでにこの情報を知っており、それを図８のアドレス関連表８００に格納していると仮定する）。

ＩＰｖ４として知られる層３プロトコルでは、ＡＲＰを使用して、層３アドレスを層２アドレスに関連付ける。図１４ａおよび１４ｂのシナリオでは、代わりにＡＲＰを使用して層３アドレスを中間層アドレスに関連付ける方法を示している。装置１０２上の層３プロトコルドライバ５１６は、対象の層３アドレスを含むＡＲＰ要求パケットを作成する。層３プロトコルドライバ５１６によって選択された宛先中間層アドレスは、ブロードキャストアドレス（おそらくすべて１）である。というのは、装置１０２は、メッセージを指定受信側装置１１０にアドレス指定をする方法を知らないからである（使用するアドレスを知っているとしたら、ＡＲＰを呼び出す必要はないことになる）。宛先中間層ブロードキャストアドレスは、宛先層２ブロードキャストアドレスに変換され、ステップ１４０２でＡＲＰメッセージが送信される。

ステップ１４０４で、ＡＲＰ要求は、無線範囲内のすべての装置、つまり装置１０４および１０６によって受信される。宛先層２アドレスがブロードキャストアドレスなので、ステップ１４０６で、これらの装置はメッセージの内容を検査する。要求は、中間層ヘッダーを含んでいるので、両方の装置のプロトコル中間層に渡される。プロトコル中間層は、宛先アドレスを検査する。これもまたブロードキャストアドレスである。次いでプロトコル中間層は、ＡＲＰ要求を層３プロトコルドライバ５１６に渡す。

さらにステップ１４０６で、両方の装置１０４および１０６の層３プロトコルドライバ５１６は、ＡＲＰ要求を検査し、要求に含まれている対象の層３アドレスを、ローカル装置に割り当てられている層３アドレスと比較する。いずれの装置も一致しない。装置１０４は、それ以上行えないので、ステップ１４０８でＡＲＰ要求を破棄する。

しかし装置１０６は、２つのネットワークインターフェイスを有する。装置１０６は、無線インターフェイス上でＡＲＰ要求を受信したので、ステップ１４１０で、ＡＲＰ要求をもう一方のインターフェイス、つまりＬＡＮ１０８に渡す。ＡＲＰメッセージは再度ブロードキャストされる。装置１１０は、図１４ｂのステップ１４１２でブロードキャストされたＡＲＰ要求を受信する。装置１１０は、装置１０４および１０６によって以前実行された検査と同じ検査を行う。しかしこのとき、装置１１０は、それ自体の層３アドレスとＡＲＰ要求に含まれる対象のアドレスの間に一致を見つける。次いでステップ１４１６で、装置１１０は、それ自体の中間層アドレスを含むＡＲＰ応答を送信する。ＡＲＰ応答は、元の要求側装置１０２に戻る。その装置は、ここでアドレス関連表８００を装置１１０の層３アドレスおよび関連の中間層アドレスで埋めることができる。

このＡＲＰの全シナリオの間、各装置の層３プロトコルドライバ５１６は、プロトコル中間層がない場合と同一の動作を行う。したがって、中間層の存在によって、ＡＲＰが稼働する層３プロトコルドライバ５１６を変更する必要なく、ＡＲＰの結果が（層３／層２のアドレス関連の作成から層３／中間層のアドレス関連の作成に）変わる。この例は、プロトコル中間層が、どのようにして他の層の通信タスクを妨害することなくそれ自体の通信タスクを行うことができるかを示している。

本発明の原理を適用できる多くの可能な実施形態を考慮して、図面との関連で本明細書に記載した実施形態は、例示的なものにすぎず、本発明の範囲を限定するものとみなされるべきではないことを理解されたい。例えば、本発明の意図から逸脱することなく、プロトコル中間層を、ソースルーティング以外の状況をカバーするように開発できることを当分野の技術者は理解されよう。本発明は、ソフトウェアモジュールまたは構成要素の観点で説明しているが、こうしたことは、ハードウェア構成要素に等しく置き換えることができることを当分野の技術者は理解されよう。したがって、本明細書に記載した本発明は、特許請求の範囲、およびその均等物の範囲内に含まれ得るすべての実施形態を含む。

有線ホストおよび無線ホストをサポートする通信環境を示すブロック図である。ソース経路を使用することによって、図１の２つのホストが中間の装置を介してどのように相互通信するかを示すデータフロー図である。ソース経路を使用することによって、図１の２つのホストが中間の装置を介してどのように相互通信するかを示すデータフロー図である。ソース経路を使用することによって、図１の２つのホストが中間の装置を介してどのように相互通信するかを示すデータフロー図である。中間層アドレスを使用するソース経路を示すデータ構造図である。本発明をサポートするコンピュータシステムの例を示す概略図である。階層型ネットワーク通信プロトコル用の国際標準化機構の開放型システム間接続（ＩＳＯ／ＯＳＩ）モデルを示す論理図である。ＩＳＯ／ＯＳＩプロトコルスタックの稼働に関与する通信タスクのいくつかを示すブロック図である。図５ｂに関連して示したタスクを実行するための１つの可能なソフトウェア実装を示す概略図である。上位プロトコル層がプロトコル中間層と対話する本発明による方法の例を示すフロー図である。アドレス関連表を示すデータ構造図である。プロトコル中間層の例が上位プロトコル層から受信したメッセージに応答する流れを示すフロー図である。プロトコル中間層の例が上位プロトコル層から受信したメッセージに応答する流れを示すフロー図である。プロトコル中間層向けのメッセージを受信するときに下位プロトコル層の例によって使用可能な方法を示すフロー図である。中間層ヘッダーを含むデータフレームを示すデータ構造図である。プロトコル中間層の例が下位プロトコル層から受信したメッセージに応答する流れを示すフロー図である。プロトコル中間層の例が下位プロトコル層から受信したメッセージに応答する流れを示すフロー図である。中間層アドレスを割り当て、見つけ出す方法の例を示すフロー図である。アドレス解決プロトコルがプロトコル中間層の存在下でどのように動作し得るかを示すデータフロー図である。アドレス解決プロトコルがプロトコル中間層の存在下でどのように動作し得るかを示すデータフロー図である。

符号の説明

１００アドホック無線ネットワーク
１０２無線専用装置
１０４無線専用装置
１０８ＬＡＮ接続
１１０ルーター

Claims

上位プロトコル層および下位プロトコル層を含む多層プロトコルをサポートする通信環境において、前記上位プロトコル層と前記下位プロトコル層の間で論理的に動作するプロトコル中間層を提供する方法であって、
前記上位プロトコル層から宛先中間層アドレスを含むデータを受信するステップと、
前記宛先中間層アドレスを中間層ヘッダーに入れるステップ、前記中間層ヘッダーを前記データに追加するステップ、および宛先下層アドレスを前記データに追加するステップを含む、前記受信したデータを処理するステップと、
前記処理されたデータを前記下位プロトコル層に送達するステップと
を含むことを特徴とする方法。
前記多層プロトコルは国際標準化機構／開放型システム間接続モデル（ＩＳＯ／ＯＳＩ）に従い、前記上位プロトコル層はネットワーク間通信プロトコルであり、前記下位プロトコル層はデータリンクプロトコルであることを特徴とする請求項１に記載の方法。
前記データリンクプロトコルは電気電子技術者協会（ＩＥＥＥ）８０２プロトコルであり、ネットワーク間通信プロトコルはＩＰｖ４、ＩＰｖ６、ＩＰＸから成るグループから選択されることを特徴とする請求項２に記載の方法。
前記方法は１つのコンピューティング装置上で実行され、前記上位プロトコル層からデータを受信するステップは、前記コンピューティング装置上のソフトウェア構成要素からデータを受信するステップを含み、前記処理されたデータを前記下位プロトコル層に送達するステップは、前記処理されたデータを前記コンピューティング装置上のソフトウェア構成要素に送達するステップを含むことを特徴とする請求項１に記載の方法。
前記コンピューティング装置はホスト装置およびルーター装置から成るグループから選択されることを特徴とする請求項４に記載の方法。
前記上位プロトコル層からデータを受信するステップは前記宛先中間層アドレスに送信されるデータパケットを受信するステップを含むことを特徴とする請求項１に記載の方法。
前記データパケットは、アドレス解決プロトコル（ＡＲＰ）および近隣探索（ＮＤ）プロトコルから成るグループから選択されるプロトコルのメッセージを含むことを特徴とする請求項６に記載の方法。
前記宛先中間層アドレスは前記宛先下層アドレスと同じ形式のものであることを特徴とする請求項１に記載の方法。
前記宛先中間層アドレスは前記宛先下層アドレスのものと異なる形式のものであることを特徴とする請求項１に記載の方法。
前記宛先中間層アドレスは、ユニキャストアドレス、マルチキャストアドレス、およびブロードキャストアドレスから成るグループから選択された形式のものであることを特徴とする請求項１に記載の方法。
前記宛先中間層アドレスはＩＥＥＥメディアアクセス制御アドレスの形式のものであることを特徴とする請求項１に記載の方法。
前記宛先中間層アドレスはインターフェイスインデックスを含むことを特徴とする請求項１に記載の方法。
前記受信されたデータはソース中間層アドレスを含むことを特徴とする請求項１に記載の方法。
前記受信したデータを処理するステップは前記宛先中間層アドレスを対応する下層アドレスに変換するステップを含むことを特徴とする請求項１に記載の方法。
宛先下層アドレスを前記データに追加するステップは前記宛先中間層アドレスの変換を前記データに追加するステップを含むことを特徴とする請求項１４に記載の方法。
前記受信したデータを処理するステップはアドホックルーティングプロトコルの方法を適用するステップを含むことを特徴とする請求項１４に記載の方法。
前記アドホックルーティングプロトコルは、ＡｄＨｏｃＯｎ−ＤｅｍａｎｄＤｉｓｔａｎｃｅＶｅｃｔｏｒルーティングプロトコル、ＣｏｒｅＥｘｔｒａｃｔｉｏｎＤｉｓｔｒｉｂｕｔｅｄＡｄＨｏｃＲｏｕｔｉｎｇプロトコル、ＤｙｎａｍｉｃＳｏｕｒｃｅＲｏｕｔｉｎｇプロトコル、Ｌｏｏｐ−ＢａｓｅｄＳｏｕｒｃｅＲｏｕｔｉｎｇプロトコル、Ｍｕｌｔｉ−ＰａｔｈＤｙｎａｍｉｃＳｏｕｒｃｅＲｏｕｔｉｎｇプロトコル、ＯｐｔｉｍｉｚｅｄＬｉｎｋＳｔａｔｅＲｏｕｔｉｎｇプロトコル、Ｐｏｗｅｒ−ＡｗａｒｅＳｏｕｒｃｅＲｏｕｔｉｎｇプロトコル、Ｓｅｃｕｒｉｔｙ−ＡｗａｒｅＡｄａｐｔｉｖｅＤｙｎａｍｉｃＳｏｕｒｃｅＲｏｕｔｉｎｇプロトコル、およびＴｏｐｏｌｏｇｙＤｉｓｓｅｍｉｎａｔｉｏｎＢａｓｅｄｏｎＲｅｖｅｒｓｅ−ＰａｔｈＦｏｒｗａｒｄｉｎｇルーティングプロトコルから成るグループから選択されることを特徴とする請求項１６に記載の方法。
前記受信したデータを処理するステップは前記宛先中間層アドレスへのソース経路を探し出すステップを含むことを特徴とする請求項１６に記載の方法。
前記宛先中間層アドレスへのソース経路を探し出すステップは格納されているソース経路にアクセスするステップを含むことを特徴とする請求項１８に記載の方法。
前記宛先中間層アドレスへのソース経路を探し出すステップは、前記アドホックルーティングプロトコルの方法を適用することによってソース経路を見つけ出すステップを含むことを特徴とする請求項１８に記載の方法。
前記受信したデータを処理するステップは、前記探し出したソース経路を中間層ヘッダー内に入れるステップと、前記中間層ヘッダーを前記データに追加するステップとを含むことを特徴とする請求項１８に記載の方法。
前記追加された中間層ヘッダーは中間層アドレスを含むことを特徴とする請求項２１に記載の方法。
宛先下層アドレスを前記データに追加するステップは、前記探し出したソース経路上の次ホップの下層アドレスを追加するステップを含むことを特徴とする請求項１８に記載の方法。
タイマを前記受信したデータに関連付けるステップと、
正常な送達の受領通知を受信する前に前記関連するタイマが期限切れになった場合、前記アドホックルーティングプロトコルの方法を適用することによって前記ソース経路のメンテナンスを行うステップと
をさらに含むことを特徴とする請求項１８に記載の方法。
前記正常な送達の受領通知は、前記宛先中間層アドレスおよび前記探し出したソース経路上の次ホップのアドレスから成るグループから選択されたアドレスへの正常な送達の受領を通知することを特徴とする請求項２４に記載の方法。
宛先下層アドレスを前記データに追加するステップは、ユニキャストアドレス、マルチキャストアドレス、およびブロードキャストアドレスから成るグループから選択された形式の下層アドレスを追加するステップを含むことを特徴とする請求項１に記載の方法。
宛先下層アドレスを前記データに追加するステップは、ＩＥＥＥメディアアクセス制御アドレスの形式の下層アドレスを追加するステップを含むことを特徴とする請求項１に記載の方法。
前記多層プロトコルは論理的に並列して動作する複数の下位プロトコル層を含み、
少なくとも一部前記宛先中間層アドレスに基づいて、前記処理されたデータを送達するために前記複数の下位プロトコル層の１つを選択するステップ
をさらに含むことを特徴とする請求項１に記載の方法。
前記宛先中間層アドレスはインターフェイスインデックスを含み、前記複数の下位プロトコル層の１つを選択するステップは、少なくとも一部インターフェイスインデックスに基づくことを特徴とする請求項２８に記載の方法。
前記複数の下位プロトコル層は、複数のＩＥＥＥ８０２データリンクプロトコルを含むことを特徴とする請求項２８に記載の方法。
多層プロトコルの上位プロトコル層と下位プロトコル層の間で論理的に動作するプロトコル中間層を提供する方法であって、
前記上位プロトコル層から宛先中間層アドレスを含むデータを受信するステップと、
前記宛先中間層アドレスを中間層ヘッダーに入れるステップ、前記中間層ヘッダーを前記データに追加するステップ、および宛先下層アドレスを前記データに追加するステップとを含む、前記受信したデータを処理するステップと、
前記処理されたデータを前記下位プロトコル層に送達するステップと
を含むことを特徴とする方法を実行するコンピュータ実行可能命令を含むコンピュータ可読媒体。
上位プロトコル層および下位プロトコル層を含む多層プロトコルをサポートする通信環境において、前記上位プロトコル層と前記下位プロトコル層の間で論理的に動作するプロトコル中間層を提供する方法であって、
前記下位プロトコル層から中間層ヘッダーおよび宛先中間層アドレスを含むデータを受信するステップと、
前記宛先中間層アドレスを検査するステップを含む、前記受信したデータを処理するステップと、
少なくとも一部前記受信した宛先中間層アドレスの前記検査に基づいて、前記処理されたデータを前記上位プロトコル層に送達するかどうかを決定するステップと
を含むことを特徴とする方法。
前記下位プロトコル層からデータを受信するステップは前記宛先中間層アドレスに送信されるデータパケットを受信するステップを含むことを特徴とする請求項３２に記載の方法。
前記データパケットはＡＲＰおよびＮＤから成るグループから選択されたプロトコルのメッセージを含むことを特徴とする請求項３３に記載の方法。
前記宛先中間層アドレスはインターフェイスインデックスを含むことを特徴とする請求項３２に記載の方法。
前記宛先中間層アドレスを検査するステップは、前記宛先中間層アドレスを、前記方法が稼働する装置に割り当てられた中間層アドレスと比較するステップを含み、前記宛先中間層アドレスが前記方法が稼働する前記装置に割り当てられた前記中間層アドレスに一致する場合、前記処理されたデータを前記上位プロトコル層に送達するよう前記決定がなされることを特徴とする請求項３２に記載の方法。
前記受信したデータを処理するステップはアドホックルーティングプロトコルの方法を適用するステップを含むことを特徴とする請求項３２に記載の方法。
前記アドホックルーティングプロトコルは、ＡｄＨｏｃＯｎ−ＤｅｍａｎｄＤｉｓｔａｎｃｅＶｅｃｔｏｒルーティングプロトコル、ＣｏｒｅＥｘｔｒａｃｔｉｏｎＤｉｓｔｒｉｂｕｔｅｄＡｄＨｏｃＲｏｕｔｉｎｇプロトコル、ＤｙｎａｍｉｃＳｏｕｒｃｅＲｏｕｔｉｎｇプロトコル、Ｌｏｏｐ−ＢａｓｅｄＳｏｕｒｃｅＲｏｕｔｉｎｇプロトコル、Ｍｕｌｔｉ−ＰａｔｈＤｙｎａｍｉｃＳｏｕｒｃｅＲｏｕｔｉｎｇプロトコル、ＯｐｔｉｍｉｚｅｄＬｉｎｋＳｔａｔｅＲｏｕｔｉｎｇプロトコル、Ｐｏｗｅｒ−ＡｗａｒｅＳｏｕｒｃｅＲｏｕｔｉｎｇプロトコル、Ｓｅｃｕｒｉｔｙ−ＡｗａｒｅＡｄａｐｔｉｖｅＤｙｎａｍｉｃＳｏｕｒｃｅＲｏｕｔｉｎｇプロトコル、およびＴｏｐｏｌｏｇｙＤｉｓｓｅｍｉｎａｔｉｏｎＢａｓｅｄｏｎＲｅｖｅｒｓｅ−ＰａｔｈＦｏｒｗａｒｄｉｎｇルーティングプロトコルから成るグループから選択されることを特徴とする請求項３７に記載の方法。
前記受信したデータを処理するステップは前記受信したデータに含まれるソース経路を検査するステップを含むことを特徴とする請求項３７に記載の方法。
前記ソース経路は中間層アドレスを含むことを特徴とする請求項３９に記載の方法。
前記ソース経路は前記宛先中間層アドレスを含むことを特徴とする請求項４０に記載の方法。
前記宛先中間層アドレスを検査するステップは、前記宛先中間層アドレスを、前記方法が稼働する装置に割り当てられた中間層アドレスと比較するステップを含み、前記宛先中間層アドレスが前記方法が稼働する前記装置に割り当てられた前記中間層アドレスに一致していない場合、
前記ソース経路内の次ホップのアドレスを見つけ、
前記ソース経路内の前記次ホップの宛先下層アドレスを前記データに追加し、
前記処理されたデータを前記下位プロトコル層に送達する
ことを特徴とする請求項３９に記載の方法。
前記方法は１つのコンピューティング装置上で実行され、前記処理されたデータを前記下位プロトコル層に送達するステップは、前記処理されたデータを前記コンピューティング装置上のソフトウェア構成要素に送達するステップを含むことを特徴とする請求項４２に記載の方法。
タイマを前記受信したデータに関連付けるステップと、
正常な送達の受領通知を受信する前に前記関連するタイマが期限切れになった場合、前記アドホックルーティングプロトコルの方法を適用することによって前記ソース経路のメンテナンスを行うステップと
をさらに含むことを特徴とする請求項４２に記載の方法。
前記正常な送達の受領通知は、前記宛先中間層アドレスおよび前記探し出したソース経路上の前記次ホップの前記アドレスから成るグループから選択されたアドレスへの正常な送達の受領を通知することを特徴とする請求項４４に記載の方法。
前記多層プロトコルは論理的に並列して動作する複数の下位プロトコル層を含み、
少なくとも一部前記ソース経路内の前記次ホップの前記アドレスに基づいて、前記処理されたデータを送達するために前記複数の下位プロトコル層の１つを選択するステップ
をさらに含むことを特徴とする請求項４２に記載の方法。
前記ソース経路内の前記次ホップの前記アドレスはインターフェイスインデックスを含み、前記複数の下位プロトコル層の１つを選択するステップは、少なくとも一部前記インターフェイスインデックスに基づくことを特徴とする請求項４６に記載の方法。
多層プロトコルの上位プロトコル層と下位プロトコル層の間で論理的に動作するプロトコル中間層を提供する方法であって、
前記下位プロトコル層から中間層ヘッダーおよび宛先中間層アドレスを含むデータを受信するステップと、
前記宛先中間層アドレスを検査するステップを含む、前記受信したデータを処理するステップと、
少なくとも一部前記受信した宛先中間層アドレスの前記検査に基づいて、前記処理されたデータを前記上位プロトコル層に送達するかどうかを決定するステップと
を含むことを特徴とする方法を実行するコンピュータ実行可能命令を含むコンピュータ可読媒体。
上位プロトコル層および下位プロトコル層を含む多層プロトコルをサポートする通信環境において、前記下位プロトコル層が前記上位プロトコル層と前記下位プロトコル層の間で論理的に動作するプロトコル中間層と連携して働く方法であって、
データを受信するステップと、
中間層ヘッダーの有無について前記受信したデータを検査するステップを含む、前記受信したデータを処理するステップと、
前記受信したデータ内に中間層ヘッダーが見つかった場合、前記処理されたデータを前記プロトコル中間層に送達するステップと
を含むことを特徴とする方法。
前記受信したデータは、前記中間層アドレスに送信されるデータパケットを含むことを特徴とする請求項４９に記載の方法。
前記データパケットはＡＲＰおよびＮＤから成るグループから選択されたプロトコルのメッセージを含むことを特徴とする請求項５０に記載の方法。
下層プロトコル層が多層プロトコルの上位プロトコル層と前記下位プロトコル層の間で論理的に動作するプロトコル中間層と連携して働く方法であって、
データを受信するステップと、
中間層ヘッダーの有無について前記受信したデータを検査するステップを含む、前記受信したデータを処理するステップと、
前記受信したデータ内に中間層ヘッダーが見つかった場合、前記処理されたデータを前記プロトコル中間層に送達するステップと
を含むことを特徴とする方法を実行するコンピュータ実行可能命令を含むコンピュータ可読媒体。
上位プロトコル層および下位プロトコル層を含む多層プロトコルをサポートする通信環境において、前記上位プロトコル層と前記下位プロトコル層の間で論理的に動作するプロトコル中間層が中間層アドレスを割り当てる方法であって、
下層アドレスを有するコンピューティング装置の中間層アドレスを選択するステップと、
前記選択された中間層アドレスを前記下層アドレスに関連付けて格納するステップと、
他のコンピューティング装置から中間層アドレス／下層アドレスの関連を引き出すステップと
を含むことを特徴とする方法。
前記選択するステップは、少なくとも一部任意の数に基づくことを特徴とする請求項５３に記載の方法。
前記多層プロトコルは論理的に並列して動作する複数の下位プロトコル層を含み、
インターフェイスインデックスを選択するステップと、
前記選択されたインターフェイスインデックスを前記選択された中間層アドレス、前記下層アドレス、および前記複数の下位プロトコル層の１つと関連付けて格納するステップと
をさらに含むことを特徴とする請求項５３に記載の方法。
中間層アドレス／下層アドレスの関連を引き出すステップは、
受信したデータを調べるステップと、
前記受信したデータから中間層アドレス／下層アドレスの関連を抽出するステップと
を含むことを特徴とする請求項５３に記載の方法。
中間層アドレス／下層アドレスの関連は、ＡＲＰ、ＮＤ、近隣要請／近隣通知、ルーター要請／ルーター通知から成るグループから選択されたプロトコルの方法を適用するステップを含むことを特徴とする請求項５３に記載の方法。
多層プロトコルの上位プロトコル層と下位プロトコル層の間で論理的に動作するプロトコル中間層が中間層アドレスを割り当てる方法であって、
下層アドレスを有するコンピューティング装置の中間層アドレスを選択するステップと、
前記選択された中間層アドレスを前記下層アドレスに関連付けて格納するステップと、
他のコンピューティング装置から中間層アドレス／下層アドレスの関連を引き出すステップと
を含むことを特徴とする方法を実行するコンピュータ実行可能命令を含むコンピュータ可読媒体。
上位プロトコル層および下位プロトコル層を含む多層プロトコルをサポートする通信環境において、前記上位プロトコル層と前記下位プロトコル層の間で論理的に動作するプロトコル中間層を提供するシステムであって、
宛先上層アドレスを対応する宛先中間層アドレスに変換し、前記宛先中間層アドレスを１組のデータに追加し、前記追加された宛先中間層アドレスを含む前記１組のデータを前記プロトコル中間層に送達するように構成されている前記上位プロトコル層と、
前記１組のデータを前記上位プロトコル層から受信し、前記宛先中間層アドレスを中間層ヘッダーに入れるステップを含めて、前記受信したデータを処理し、前記中間層ヘッダーを前記データに追加し、宛先下層アドレスを前記データに追加するように構成されている前記プロトコル中間層と、
前記処理されたデータを受信し、前記処理されたデータを前記宛先下層アドレスに送達するように構成されている前記下位プロトコル層と
を含むことを特徴とするシステム。
第１のコンピューティング装置は前記上位プロトコル層と、前記プロトコル中間層と、前記下位プロトコル層とを含むことを特徴とする請求項５９に記載のシステム。
前記１組のデータを前記上位プロトコル層から前記プロトコル中間層に送達するステップは、前記第１のコンピューティング装置の第１のソフトウェア構成要素から第２のソフトウェア構成要素に前記１組のデータを送達するステップを含み、前記処理されたデータを前記プロトコル中間層から前記下位プロトコル層に送達するステップは、前記第１のコンピューティング装置の第３のソフトウェア構成要素から第４のソフトウェア構成要素に前記データを送達するステップを含むことを特徴とする請求項６０に記載のシステム。
前記下位プロトコル層は、第２のコンピューティング装置からデータを受信し、中間層ヘッダーの有無について前記受信したデータを検査するステップを含めて、前記受信したデータを処理し、前記受信したデータ内に中間層ヘッダーが見つかった場合は前記処理されたデータを前記プロトコル中間層に送達するようにさらに構成されており、
前記プロトコル中間層は、前記下層で処理されたデータを受信し、前記中間層ヘッダーを検査するステップを含めて、前記受信したデータを処理し、少なくとも一部前記受信した中間層ヘッダーの前記検査に基づいて前記処理されたデータを前記上位プロトコル層に送達するかどうかを決定するようにさらに構成されており、
前記上層プロトコルは、前記プロトコル中間層で処理されたデータを受信するようにさらに構成されている
ことを特徴とする請求項６０に記載のシステム。
前記中間層ヘッダーはソース経路を含み、前記プロトコル中間層は、前記宛先中間層アドレスを、前記第１のコンピューティング装置に割り当てられている中間層アドレスと比較し、前記宛先中間層アドレスが前記第１のコンピューティング層に割り当てられている前記中間層アドレスに一致しない場合、前記ソース経路内の次ホップのアドレスを見つけ、前記ソース経路内の前記次ホップの宛先下層アドレスを前記処理されたデータに追加し、前記処理されたデータを前記下位プロトコル層に送達するようにさらに構成されていることを特徴とする請求項６２に記載のシステム。
前記プロトコル中間層は、下層アドレスを有する前記第１のコンピューティング装置の中間層アドレスを選択し、前記選択された中間層アドレスを前記下層アドレスと関連付けて格納し、中間層アドレス／下層アドレスの関連を他のコンピューティング装置から引き出すようにさらに構成されていることを特徴とする請求項６０に記載のシステム。
論理的に並列して動作する複数の下位プロトコル層をさらに含み、
前記プロトコル中間層は、少なくとも一部前記宛先中間層アドレスに基づいて、前記処理されたデータを送達するために前記複数の下位プロトコル層の１つを選択するようにさらに構成されている
ことを特徴とする請求項５９に記載のシステム。
前記宛先中間層アドレスはインターフェイスインデックスを含み、前記プロトコル中間層は、少なくとも一部前記インターフェイスインデックスに基づいて前記複数の下位プロトコル層の１つを選択するようにさらに構成されていることを特徴とする請求項６５に記載のシステム。
多層プロトコルの上位プロトコル層と下位プロトコル層の間で論理的に動作するプロトコル中間層を提供するシステムであって、
宛先上層アドレスを対応する宛先中間層アドレスに変換し、前記宛先中間層アドレスを１組のデータに追加し、前記追加された宛先中間層アドレスを含む前記１組のデータを前記プロトコル中間層に送達するように構成されている前記上位プロトコル層と、
前記１組のデータを前記上位プロトコル層から受信し、前記宛先中間層アドレスを中間層ヘッダーに入れるステップを含めて、前記受信したデータを処理し、前記中間層ヘッダーを前記データに追加し、宛先下層アドレスを前記データに追加するように構成されている前記プロトコル中間層と、
前記処理されたデータを受信し、前記処理されたデータを前記宛先下層アドレスに送達するように構成されている前記下位プロトコル層と
を含むことを特徴とするシステムを提供するコンピュータ実行可能命令を含むコンピュータ可読媒体。
上位プロトコル層アドレスを表すデータを含む第１のデータフィールドと、
プロトコル中間層アドレスを表すデータを含む第２のデータフィールドと、
下位プロトコル層アドレスを表すデータを含む第３のデータフィールドと
を含むことを特徴とするアドレス関連データ構造（ａｄｄｒｅｓｓａｓｓｏｃｉａｔｉｏｎｄａｔａｓｔｒｕｃｔｕｒｅ）を含むコンピュータ可読媒体。
前記上位プロトコル層アドレスはネットワーク間通信プロトコルアドレスであり、前記下位プロトコル層アドレスはデータリンクプロトコルアドレスであることを特徴とする請求項６８に記載のアドレス関連データ構造。
前記データリンクプロトコルアドレスはＩＥＥＥメディアアクセス制御アドレスであることを特徴とする請求項６９に記載のアドレス関連データ構造。
前記プロトコル中間層アドレスは前記下位プロトコル層アドレスと同じ形式のものであることを特徴とする請求項６８に記載のアドレス関連データ構造。
前記プロトコル中間層アドレスは前記下位プロトコル層アドレスのものと異なる形式のものであることを特徴とする請求項６８に記載のアドレス関連データ構造。
前記プロトコル中間層アドレスはインターフェイスインデックスを含むことを特徴とする請求項６８に記載のアドレス関連データ構造。
下位プロトコル層ヘッダーを表すデータを含む第１のデータフィールドと、
プロトコル中間層ヘッダーを表すデータを含み、第３のデータフィールドおよび第４のデータフィールドを含む第２のデータフィールドと、
前記プロトコル中間層ヘッダーを識別するフラグを表すデータを含む前記第３のデータフィールドと、
プロトコル中間層アドレスを表すデータを含む前記第４のデータフィールドと
を含むことを特徴とするプロトコル中間層メッセージ構造を含むコンピュータ可読媒体。
前記下位プロトコル層はＩＥＥＥ８０２データリンクプロトコルヘッダーであることを特徴とする請求項７４に記載のプロトコル中間層メッセージ構造。
前記プロトコル中間層アドレスは、ユニキャストアドレス、マルチキャストアドレス、およびブロードキャストアドレスから成るグループから選択された形式のものであることを特徴とする請求項７４に記載のプロトコル中間層メッセージ構造。
前記プロトコル中間層アドレスはＩＥＥＥメディアアクセス制御アドレスの形式のものであることを特徴とする請求項７４に記載のプロトコル中間層メッセージ構造。
前記プロトコル中間層アドレスはインターフェイスインデックスを含むことを特徴とする請求項７４に記載のプロトコル中間層メッセージ構造。
前記プロトコル中間層ヘッダーはソース経路を含むことを特徴とする請求項７４に記載のプロトコル中間層メッセージ構造。