(57)【特許請求の範囲】
【請求項１】
第１のドメイン名を表す第１のセットの情報を含むデータユニットを受信するステップ、
前記ドメイン名をローカルアドレスへ変換するステップ、および
前記データユニットを前記ローカルアドレスへ送信するステップ
を備えることを特徴とするデータ通信方法。
【請求項２】
前記第１のセットの情報が前記第１のドメイン名を含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記第１のセットの情報が前記第１のドメイン名および第２のドメイン名を含み、前記第１のドメイン名がデスティネーションと関連し、前記第２のドメイン名がソースと関連し、前記ローカルアドレスが前記デスティネーションと関連することを特徴とする請求項１に記載の方法。
【請求項４】
前記第１のセットの情報が前記第１のドメイン名の圧縮された形式を含むことを特徴とする請求項１に記載の方法。
【請求項５】
前記第１のセットの情報が前記第１のドメイン名のエンコードされた形式を含むことを特徴とする請求項１に記載の方法。
【請求項６】
前記第１のセットの情報が前記第１のドメイン名の暗号化された形式を含むことを特徴とする請求項１に記載の方法。
【請求項７】
前記データユニットがＴＣＰセグメントを含むことを特徴とする請求項１に記載の方法。
【請求項８】
前記データユニットがＩＰパケットを含むことを特徴とする請求項１に記載の方法。
【請求項９】
前記ＩＰパケットがヘッダを含み、
前記第１のセットの情報が前記ヘッダに記憶される
ことを特徴とする請求項８に記載の方法。
【請求項１０】
前記ヘッダがオプションフィールドを含み、
前記第１のセットの情報が前記オプションフィールドに記憶される
ことを特徴とする請求項９に記載の方法。
【請求項１１】
前記第１のセットの情報が前記第１のドメイン名を示す情報および第２のドメイン名を示す情報を含み、前記第１のドメイン名がデスティネーションと関連し、前記第２のドメイン名がソースと関連し、前記デスティネーションが前記ローカルアドレスと関連する
ことを特徴とする請求項１０に記載の方法。
【請求項１２】
前記ＩＰパケットがヘッダポーションおよびデータポーションを含み、前記第１のセットの情報が前記データポーションに記憶される
ことを特徴とする請求項８に記載の方法。
【請求項１３】
前記変換するステップが前記第１のドメイン名に関連する表の記録を見つけるステップを含み、前記表の前記記録は前記ローカルアドレスを含むことを特徴とする請求項１に記載の方法。
【請求項１４】
前記送信するステップが前記データユニットをルータへ送信するステップを含む
ことを特徴とする請求項１に記載の方法。
【請求項１５】
前記送信するステップが前記データユニットをデスティネーションへ送信するステップを含み、前記デスティネーションが前記ローカルアドレスと関連している
ことを特徴とする請求項１に記載の方法。
【請求項１６】
前記データユニットが、前記受信するステップの前にグローバルデスティネーションアドレスを含む
ことを特徴とする請求項１に記載の方法。
【請求項１７】
さらに、前記データユニットの前記グローバルデスティネーションアドレスを前記ローカルアドレスと置き換えるステップを含み、前記置き換えるステップが前記変換するステップの後に行われることを特徴とする請求項１６に記載の方法。
【請求項１８】
前記データユニットがチェックサムを含み、
前記データ通信方法が、さらに
前記データユニットの前記チェックサムを調整するステップを含み、前記チェックサムを調整するステップが前記グローバルデスティネーションアドレスを置き換えるステップの後に行われる
ことを特徴とする請求項１７に記載の方法。
【請求項１９】
さらに、デスティネーション用の当局（authority）ドメイン名サーバーとして働くステップを含み、前記デスティネーションが前記ローカルアドレスと関連する
ことを特徴とする請求項１に記載の方法。
【請求項２０】
さらに、前記第１のセットの情報に基づき前記第１のドメイン名を識別するステップを含む
ことを特徴とする請求項１に記載の方法。
【請求項２１】
プロセッサ可読記憶媒体上に具現化されるプロセッサ可読コードを有し、前記プロセッサ可読コードが方法を実行するためにプロセッサをプログラムするプロセッサ可読記憶媒体であって、前記方法が、
第１のドメイン名を示す第１のセットの情報を含むデータユニットを受信するステップ、
前記第１のドメイン名をローカルアドレスへ変換するステップ、および
前記データユニットを前記ローカルアドレスへ伝送するステップ
を含むことを特徴とするプロセッサ可読記憶媒体。
【請求項２２】
前記データユニットはＴＣＰセグメントであり、
前記ＴＣＰセグメントがヘッダを含み、
前記第１のセットの情報が前記ヘッダに記憶される
ことを特徴とする請求項２１に記載のプロセッサ可読記憶媒体。
【請求項２３】
前記データユニットはＩＰパケットであり、
前記ＩＰパケットがデータポーションとヘッダポーションを含み、
前記第１のセットの情報が前記データポーションに記憶される
ことを特徴とする請求項２１に記載のプロセッサ可読記憶媒体。
【請求項２４】
前記データユニットはＩＰパケットであり、
前記ＩＰパケットがヘッダを含み、
前記ヘッダがオプションフィールドを含み、
前記第１のセットの情報が、前記オプションフィールドに記憶される
ことを特徴とする請求項２１に記載のプロセッサ可読記憶媒体。
【請求項２５】
前記第１のセットの情報が前記第１のドメイン名を示す情報および第２のドメイン名を示す情報とを含み、前記第１のドメイン名がデスティネーションと関連し、前記第２のドメイン名がソースと関連し、前記デスティネーションが前記ローカルアドレスと関連している
ことを特徴とする請求項２１に記載のプロセッサ可読記憶媒体。
【請求項２６】
前記変換するステップが前記第１のドメイン名に関連する表の記録を見つけるステップを含み、前記表の前記記録は前記ローカルアドレスを含むことを特徴とする請求項２１に記載のプロセッサ可読記憶媒体。
【請求項２７】
前記データユニットが前記受信するステップ前のグローバルデスティネーションアドレスを含む
ことを特徴とする請求項２１に記載のプロセッサ可読記憶媒体。
【請求項２８】
前記方法がさらに、
前記データユニットの前記グローバルデスティネーションアドレスを前記ローカルアドレスと置き換えるステップを含み、前記置き換えるステップは前記変換するステップの後に行われる
ことを特徴とする請求項２７に記載のプロセッサ可読記憶媒体。
【請求項２９】
前記データユニットがチェックサムを含み、
前記データ通信方法が、さらに
前記データユニットの前記チェックサムを調整するステップを含み、前記チェックサムを調整するステップが前記グローバルデスティネーションアドレスを置き換えるステップの後に行われる
ことを特徴とする請求項２８に記載のプロセッサ可読記憶媒体。
【請求項３０】
第１のセットのデータを受信するステップ、
デスティネーションに関連するドメイン名を受信するステップ、および
アプリケーションレーヤ下のプロトコルで使用するデータユニットを作るステップを含み、
前記データユニットを作るステップが、ヘッダを作るステップと、前記第１のセットのデータに前記ヘッダを付け加わえるステップと、前記ドメイン名を示す第１のセットの情報を前記データユニットへ付加するステップと
を含むことを特徴とするデータ通信方法。
【請求項３１】
前記データユニットがＩＰパケットである
ことを特徴とする請求項３０に記載の方法。
【請求項３２】
前記ヘッダがＩＰヘッダであり、
前記ＩＰヘッダがオプションフィールドを含み、
前記第１のセットの情報が前記オプションフィールドに記憶される
ことを特徴とする請求項３０に記載の方法。
【請求項３３】
さらに、前記データユニットを他のエンティティーに送信するステップを含むことを特徴とする請求項３０に記載の方法。
【請求項３４】
第１のセットの情報を付加する前記ステップが、前記第１のセットの情報を前記第１のセットのデータにトレーラとして付加する
ことを特徴とする請求項３０に記載の方法。
【請求項３５】
前記データユニットがＴＣＰセグメントである
ことを特徴とする請求項３０に記載の方法。
【請求項３６】
プロセッサ可読記憶媒体上に具現化されるプロセッサ可読コードを有し、前記プロセッサ可読コードが方法を実行するためにプロセッサをプログラムするプロセッサ可読記憶媒体であって、前記方法が、
第１のセットのデータを受信するステップ、
デスティネーションに関連するドメイン名を受信するステップ、および
アプリケーションレーヤ下のプロトコルで使用するデータユニットを作るステップを含み、
前記データユニットを作るステップが、ヘッダを作るステップと、前記第１のセットのデータに前記ヘッダを付け加わえるステップと、前記ドメイン名を示す第１のセットの情報を前記データユニットへ付加するステップと
を含むことを特徴とするプロセッサ可読記憶媒体。
【請求項３７】
前記データユニットはＩＰパケットである
ことを特徴とする請求項３６に記載のプロセッサ可読記憶媒体。
【請求項３８】
前記ヘッダがＩＰヘッダであり、
前記ＩＰヘッダがオプションフィールドを含み、
前記第１のセットの情報が前記オプションフィールドに記憶される
ことを特徴とする請求項３６に記載のプロセッサ可読記憶媒体。
【請求項３９】
前記データユニットはＩＰパケットであり、
第１のセットの情報を付加する前記ステップが前記第１のセットの情報を前記第１のセットのデータにトレーラとして付加する
ことを特徴とする請求項３６に記載のプロセッサ可読記憶媒体。
【請求項４０】
前記データユニットがＴＣＰセグメントである
ことを特徴とする請求項３６に記載のプロセッサ可読記憶媒体。
【請求項４１】
プロセッサと、
前記プロセッサと接続する第１のネットワークインターフェースと、
前記プロセッサと接続する第２のネットワークインターフェースと、
前記プロセッサと接続するプロセッサ可読記憶要素とを含み、
前記プロセッサ可読記憶要素が以下のステップから成る方法を実行するために前記プロセッサをプログラムするプロセッサ可読コードを記憶するようになっているデータ通信装置であって、前記方法が、
第１のドメイン名を示す第１のセットの情報を含むデータユニットを受信するステップ、
前記第１のドメイン名をローカルアドレスへ変換するステップ、および
前記データユニットを前記ローカルアドレスへ伝送するステップ
を含むことを特徴とするデータ通信装置。
【請求項４２】
前記第１のネットワークインターフェースがイーサネットインターフェースである
ことを特徴とする請求項４１に記載の装置。
【請求項４３】
前記プロセッサ可読記憶要素が表を記憶し、前記表がセットの記録を含み，前記セットの記録の各記録がドメイン名とローカルアドレスを含む
ことを特徴とする請求項４１に記載の装置。
【請求項４４】
前記プロセッサ可読記憶要素が表を記憶し、前記表がセットの記録を含み，前記セットの記録の各記録がドメイン名とグローバルアドレスを含む
ことを特徴とする請求項４１に記載の装置。
【請求項４５】
前記データユニットがＩＰパケットであり、
前記ＩＰパケットがヘッダポーションとデータポーションを含み、
前記第１のセットの情報が前記データポーションに記憶される
ことを特徴とする請求項４１に記載の装置。
【請求項４６】
前記データユニットが前記受信するステップの前にグローバルデスティネーションアドレスを含む
ことを特徴とする請求項４１に記載の装置。
【請求項４７】
さらに、前記データユニットの前記グローバルデスティネーションアドレスを前記ローカルアドレスと置き換えるステップを含み、
前記置き換えるステップは変換するステップの後に行われる
ことを特徴とする請求項４６に記載の装置。
【請求項４８】
前記データユニットがチェックサムを含み、
さらに、前記方法は前記データユニットの前記チェックサムを調整するステップを含み、前記チェックサムを調整するステップは前記グローバルデスティネーションアドレスを置き換えるステップの後に行われる
ことを特徴とする請求項４７に記載の装置。
【発明の詳細な説明】
【０００１】
（技術分野）
本発明は、ネットワーク上のデスティネーションへ送信するデータの経路決めをするインターネットドメイン名を使用するためのシステムに関する。
【０００２】
（背景技術）
インターネット上のマシンの多くが、インターネット上の他のマシンへデータを送信するのにＴＣＰ/ＩＰ（伝達制御プロトコル/インターネットプロトコル）を使用する。ソースからデスティネーションへデータを伝達するには、インターネットプロトコル（ＩＰ）はＩＰアドレスを使用する。ＩＰアドレスは、4バイトであり、ネットワーク番号とホスト番号を備える。
【０００３】
現在のところ、少なくとも３つの異なるネットワーククラス、すなわちクラスＡ、クラスＢ、クラスＣが使われている。各クラスには、ＩＰアドレスのネットワーク番号とホスト番号の組み合わせに対し、異なるフォーマットがある。クラスＡアドレスは、ネットワークの指定に1バイト、ホスト指定に3バイトを含む。クラスＡの１桁目は、クラスＡを示すために０である。クラスＢのアドレスは、ネットワークアドレスに２バイト、ホストアドレスに２バイトを使用する。クラスＢアドレスの第１の２桁は、クラスＢを示すために１０である。クラスＣのアドレスは、ネットワークの指定に２バイト、ホストアドレスに１バイトを含む。クラスＣネットワークアドレスの第１の３桁は、クラスＣを示すために１１０である。前記記載のフォーマットは、各１６００万のホストをもつ１２６のクラスＡネットワーク、各６万４０００のホストをもつ１６，３８２のクラスＢネットワーク、各最大２５６のホストをもつ４００万のクラスＣネットワークが可能である。
【０００４】
書き込まれる場合、ＩＰアドレスは、ドットにより分けられた（例えば１９８．６８．７０．１）４つの番号により指定される。ユーザおよびソフトウェアアプリケーションがホスト、メールボックス、他のリソースのその数字で表されたＩＰアドレスにより言及されることは稀である。番号を使用する代わりにドメイン名と呼ばれるＡＳＣＩＩストリングを使用する。ドメイン名は通常団体の接頭辞名前．トップ  レベル  ドメイン．のフォーマットである。トップレベルドメインには総称、国の２タイプある。総称ドメインは、ｃｏｍ（商業）、ｅｄｕ（教育施設）、ｇｏｖ（米国連邦政府）、ｉｎｔ（国際組織）、ｍｉｌ（米国軍隊）、ｎｅｔ（ネットワークプロバイダ）およびｏｒｇ（非営利的団体）である。国ドメインは、各国に対し１つのエントリーを含む。ドメイン名の１例は、ｓａｔｕｒｎ．ｔｔｃ．ｃｏｍ．である。ｓａｔｕｒｎは接頭辞であり、ネットワークでの特別なホストに言及する。ｔｔｃは団体名であり、外部に対し１つまたはそれ以上を識別するために使用できる。ｃｏｍは本アドレスが商業ドメインにあることを意味する。インターネットは、ドメイン名をＩＰアドレスへ転換するためのドメイン名システムを使用する。
【０００５】
インターネットプロトコルは２０年間以上にわたり使用されている。インターネットの指数関数的増加に示されるように、非常にうまくいった。残念なことにインターネットは急速にその人気の犠牲者となりつつある。すなわち、アドレス不足である。４０億を超えるアドレスが存在するのだが、アドレススペースをクラスへと組織化することにより、何万ものアドレスを無駄にしている。特に、問題はクラスＢネットワークである。団体の多くにとって、１６００万のアドレスをもつクラスＡネットワークは大きすぎ、２５６のアドレスをもつクラスＣネットワークは小さすぎる。クラスＢネットワークがほとんどの企業にとって妥当な解決であるようだ。しかし、現実にはクラスＢアドレスは団体の多くにとってはかなり大きすぎる。多くのクラスＢネットワークは５０未満のホストがある。クラスＣネットワークがこの仕事をやれたはずであったろうが、クラスＢネットワークを求める団体の多くは、いつの日か８ビットのホストフィールドを超えるだろうと思っていた。
【０００６】
アドレスが古くなることへの、問題解決として提案されている１つは、クラスレスドメインルーティング（ＣＩＤＲ）である。ＣＩＤＲの背後にある基本的考えは残っているクラスＣネットワークを多様なサイズのブロックへ配置させることである。サイトに、２，０００アドレスが必要である場合、クラスＢネットワークアドレスではなく、１ブロックの隣接するクラスＣネットワークが与えられる。ユニットとして隣接するクラスＣネットワークブロックを使用するのに加え、クラスＣアドレスに対する配置ルールもまたその世界を４つのゾーンに分割することにより変更できる。各ゾーンは前記定義のクラスＣネットワーク数を含む。ＣＩＤＲにはかなりの年月を要するでろうが、ＩＰアドレスは予測可能な未来に不足するであろう。
【０００７】
別の提案されている解決法は、ネットワークアドレストランスレーション（ＮＡＴ）である。本概念にはクラスＣネットワーク数、もしくはローカルアドレス（またはプライベートアドレスと呼ばれる）をあらかじめ定めることが含まれる。残りのアドレスはグローバルアドレスとみなされる。グローバルアドレスは特別のアドレスである。すなわちインターネット上に２つが同じグローバルアドレスをもつことはない。ローカルアドレスは特別ではなく、１つ以上の団体またはネットワークにより使用できる。しかし、ローカルアドレスはインターネット上では使用できない。ローカルアドレスはプライベートネットワーク内でのみ使用できる。ＮＡＴはプライベートネットワーク上の全てのマシンが必ずしも、常にインターネットへアクセスする必要はないと考える。それゆえ、各マシンがグローバルアドレスをもつ必要はない。企業は、１つまたはそれ以上のゲートウェイコンピュータに割当られた少数のグローバルアドレスで機能できる。プライベートネットワーク上の残りのマシンはローカルアドレスを割当られる。ローカルアドレスを使用しているプライベートネットワーク上のある特殊なマシンが、プライベートネットワーク外のマシンへの通信を始めようとする時は（例えばインターネットを通じて）、ゲートウェイマシンは通信を傍受しソースマシンのローカルアドレスをグローバルアドレスへ変更し、グローバルアドレスとローカルアドレス間の変換表をセットアップする。表はデスティネーションアドレス、ポート数、シークエンス情報、バイト数、ホストアドレスと関連した各接続のための内部フラッグを含む。入ってくるパケットは表上のエントリーと比較され、その通過を有効なものとする適切な接続が存在する場合のみ、ゲートウェイを通ることを認められる。ＮＡＴアプローチの問題の１つは、それが働くのは、ネットワーク内のホストによりグローバルＩＰアドレスをもつインターネット上のホストへ始められる通信に対してのみだということである。ＮＡＴアプローチは特に、通信がプライベートネットワーク外のホストにより始められ、プライベートネットワーク上のローカルアドレスをもつホストを指名する場合は働かない。
【０００８】
提案されてきた別の解決法は、ＩＰｖ６と呼ばれる（またはＩＰｖ４として知られているインターネットプロトコルバージョン６）インターネットプロトコルの新バージョンである。ＩＰｖ６は既存のインターネットプロトコル（ＩＰｖ４）とは互換性がない。例えば，ＩＰｖ６はＩＰｖ４より長いアドレスをもつ。更に、ＩＰｖ６のヘッダはＩＰｖ４のヘッダとは異なる。ＩＰｖ６はＩＰｖ４とは互換性がないので、インターネット上のほぼ全てのルート装置がＩＰｖ６と互換性のある最新装置と置き換えられなければならない。こうした今までの装置の広範囲にわたる置き換えは、莫大な費用がかかる。
【０００９】
これまで見てきたように、残り少なくなるＩＰアドレスの問題解決への最新の提案は、不適切に及び／若しくは不当に費用がかかる。それゆえ不当な費用がかからず、残り少なくなるＩＰアドレス問題を効果的に緩和するシステムが必要である。
【００１０】
（発明の開示）
本発明は、簡単に述べると、ネットワーク上のデスティネーションへ送信されるデータの経路決めをするドメイン名を使用するためのシステムを提供する。１例にはスタブネットワーク上のデスティネーションへデータを経路させることを含む。スタブネットワークは、１つまたはそれ以上のゲートウェイを通じ、インターネットへ接続されている団体によって所有されたネットワークである。スタブネットワーク内のノードは、インターネット上の他のノード、もしくはインターネットを通じ内部接続されている他のスタブネットワーク上の他のノードを認識できる。クラスＡ、Ｂ、Ｃネットワーク用全セットのグローバルアドレスを使用するより、各企業体またはスタブネットワークに、１つまたは少数のグローバルアドレスを割当できる。各ホストにはローカルアドレスが割当できる。同じローカルアドレスが、多くの異なる団体により使用できる。ソースがローカルアドレスをもつスタブネットワーク内のデスティネーションへデータを送信する時、データはデスティネーションのネットワーク用のグローバルアドレスへ送信される。グローバルアドレスは、デスティネーションのネットワークと通信するドメインネームルータへ割当られる。ドメインネームルータは、インターネットとスタブネットワーク間のゲートウェイとして動く。ドメインネームルータは、（世界的に特別なＩＰアドレスにより識別された）インターネット上のノードとスタブネットワークノード間のＩＰ網の経路を定める。ソースエンティティーはデスティネーションドメイン名とそれ自身のドメイン名をデータ内のどこかへ埋め込む。ドメインネームルータはデータを受信し、データからデスティネーションドメイン名を引き出し、当該ドメイン名をスタブネットワークのローカルアドレスへ伝送し、データをデスティネーションへ送信する。ソースエンティティーは、ローカルアドレスまたはグローバルアドレスのいずれかをもち、なおかつ本発明を利用できる。
【００１１】
本発明を実行する方法の１つは、ネットワーク上のエンティティーへ通信されるべき少なくとも下位セットのデータを、データユニットへパッケージすることを含む。データユニットはドメインネームルータまたは他の類似のエンティティーへ送信される。デスティネーションのドメイン名を示す情報がデータユニットから引き出され、デスティネーションのローカルアドレスを決定するために使用される。一旦ローカルアドレスが決定されるとデータユニットは当該ローカルアドレスへ送信される。
【００１２】
データユニットは、第１のセットの情報とドメイン名を受信することにより形成される。１フィールド（または他のサブセット）が生成され、それはドメイン名を示す第１のセットの情報を含む。フィールドはデータユニットを創るために第１のデータセットへアペンドされる。データユニットはドメインネームルータへ送信される。ドメイン名がデータから確実に引き出される限り、データユニットは本発明の使用に適したＩＰパケット、ＴＣＰセグメントもしくは他のデータユニットでありうる。１つの形態では、ドメイン名を示すために使用される情報は、ドメイン名の暗号化されたバージョン，ドメイン名のエンコードされたバージョン，ドメイン名の圧縮されたバージョンを含みうる。
【００１３】
１つの形態では、ドメインネームルータへ送信されるデータユニットはドメインネームルータのためのグローバルＩＰアドレスを含む。ドメイン名をローカルアドレスへ移した後、ドメインネームルータはドメインネームルータ用グローバルアドレスをデスティネーションのローカルアドレスと置き換える。グローバルアドレスをローカルアドレスと置き換えるステップは、データユニットの適切なチェックサムや他の必要なフィールドを調整することを含むことができる。
【００１４】
ドメインネームルータはプロセッサの可読記憶媒体に記憶されたソフトウェアを使用して実行でき、コンピュータやルータ上で実行される。別法として、ドメインネームルータはここに記載された方法を実行するために設計された特別なハードウェアになりうる。
本発明のこれらの、または他の目的および利点は、図面と関連し説明された発明を実施するための最良の形態での下記の詳細な記載から、さらに明らかになるであろう。
【００１５】
（発明を実施するための最良の形態）
図１はネットワークを設計し、作り上げるためのＴＣＰ/ＩＰのリファレンスモデルを示す。モデルは４レーヤ、すなわち、物理的およびデータリンクレーヤ１２、ネットワークレーヤ１４、トランスポートレーヤ１６、及びアプリケーションレーヤ１８を含む。物理的およびデータリンクレーヤ１２の物理的レーヤポーションは通信チャンネル上の未加工ビットの伝達と関連している。設計課題は片側が１ビットを送信すると、もう片方より０ビットとしてではなく１ビットとして受信されることを保証することを含む。存在する代表的な問題点は、１ビットを示すため何ボルトを使用するべきか、０ビットを示すため何ボルトを使用するべきか、１ビットにつき何マイクロセカンド継続するか、伝達を両側で同時に処理するかどうか、いかに初期接続を確立するか、両側が終了するといかに接続をきるか、およびネットワークコネクタがいくつのピンをもっているかである。物理的およびデータリンクレーヤ１２のデータリンクポーションは未加工伝達の設備を使い、比較的伝達エラーがないようにみえるラインへ変換される。これは、入力データをフレーム中へ分割し、フレームを伝送し、受信装置により送信がもどされた認識フレームを処理する送信装置をもつことにより、このタスクを完了する。
【００１６】
ネットワークレーヤ１４により、ホストがパケットをネットワークへ投入し、独立してデスティネーションへ運ぶことが可能となる。インターネット上のネットワークレーヤ１４に使用されるプロトコルはインターネットプロトコル（ＩＰ）と呼ばれている．
トランスポートレーヤ１６によりソースとデスティネーション上のピアエンティティーが”会話”を実行することができるようになっている。インターネット上では、２つのエンドツーエンドプロトコルが使用される。第１の１つである伝達制御プロトコル（ＴＣＰ）は、１つのマシンに基づく１バイトのストリームが、インターネット上の他のマシンへエラーなしに運ばれる信頼のおける接続志向のプロトコルである。これは入ってくるバイトストリームを別々のパケットへ分割し、各々をネットワークレーヤ１４へ渡す。デスティネーションでは、受信するＴＣＰ処理が、受信されたパケットを出力ストリームへ新たに組み立てる。ＴＣＰはまた、高速受信装置が、低速受信装置が取り扱うことができる以上のパケットで、低速受信装置を混乱させることがないよう、フロー制御を行う
インターネット上のトランスポートレーヤ１６で使用される第２のプロトコルであるユーザデータグラムプロトコル（ＵＤＰ）は、ＴＣＰが配列したり、フロー制御することを望まないアプリケーション用信頼性のない接続はしないプロトコルである。ＵＤＰは、すばやい送達が、的確な送達より重要である、１ショット、およびアプリケーション用クライアントサーバタイプ要求ー応答クエリーに対して使用されている。トランスポートレーヤ１６は、ネットワークレーヤ１４がトランスポートレーヤ１６にサービスを提供いていることを示すために、ネットワークレーヤ１４上にあるものとして示されている。同様に、トランスポートレーヤ１６は、トランスポートレーヤ１６がアプリケーションレーヤ１８へサービスを提供いていることを示すために、アプリケーションレーヤ１８の下側に示されている。
【００１７】
アプリケーションレーヤ１８は、例えばテルネット、ファイルトランスファプロトコル（ＦＴＰ）、電子メール、シンプルメールトランスファプロトコル（ＳＭＴＰ）およびハイパーテキストトランスファプロトコル（ＨＴＴＰ）などの高レベルのプロトコルを含む。
【００１８】
以下の論議では更に詳細にネットワークとトランスポートレーヤを記載する。ネットワークレーヤ１４の主機能は、ソースエンティティーからデスティネーションエンティティーへのパケットの経路を定めることである。サブネットの多くで、パケットは運搬に多くのホップが必要である。ネットワークレーヤソフトウェアは、入ってきたパケットがどの出力パケットで伝達されるべきかを決定する１つまたはそれ以上のルート方法を使用する。ネットワークレーヤで使用できる技術には既知の多くのルート方法がある。本特許の目的のためには何の特別なルート方法は要求されない。既知のいかなる適したルート方法でも十分である。既知のルート方法の例には、短路ルート、フラッド、フローベースのルート、遠隔ベクタルート、リンクステートルート、階層的ルート、移動ホスト用ルート、放送ルート、および多放送ルートを含む。また、インターネット上のネットワーク内で、適したルート方法はディスタンスベクタプロトコル、または後継のオープンショータパスファースト（ＯＳＰＦ）プロトコルに基づくことができる。インターネット上のネットワーク間では、ボーダーゲートウェイプロトコル（ＢＧＰ）が使用できる。
【００１９】
インターネット上の通信は以下のように機能する。トランスポートレーヤ１６はアプリケーションレーヤ１８からのデータの流れを、数多くのセグメントへと分割す。ネットワークレーヤ１４は、インターネットプロトコルを使用し、これらのマシンまたはエンティティーが同じネットワークにあるか否かには無関係に、１つまたはそれ以上のＩＰパケットで、セグメントをソースからデスティネーションへ運ぶ。各セグメントは運搬されるとき、小さいユニットへ分割される。全セグメントが最終的にデスティネーションマシンへ着くと、ネットワークレーヤ１４により、もともとのセグメントへ再組立される。当該セグメントはその後トランスポートレーヤ１６へ渡され、受信プロセス（アプリケーションレーヤ１８）の入力ストリームへ入力される。
【００２０】
ＩＰパケットはヘッダとデータポーションを有する。ＩＰヘッダのフォーマットを図２に示す。図２は、ヘッダを作る６列を示す。各列は３２ビットである。ヘッダの第１の５列はヘッダの２０バイト固定ポーションを有する。ヘッダの最終列は多様なサイズのオプションセクション２２を提供する。バージョンフィールド２４は、プロトコルのどのバージョンにパケットが属するか形跡をたどる。インターネット上で使用されている現在のバージョンはバージョン４である。ＩＨＬフィールド２６は、３２ビットワードでのヘッダ長を記載する。タイプフィールド２８は要求されるサービスタイプを示す。多種の組合せの信頼性と速度が可能である。長さフィールド３０はヘッダとデータを含むパケットのサイズを含む。識別フィールド３２は、デスティネーションホストがどのセグメントが受信したセグメントに属するかを決定することを可能にするために必要である。セグメントの全フラグメントは同じ識別価値を含んでいる。次には、使用されていないビット３３と２つの１ビットフィールド３４と３６を含む３フラッグがくる。本発明の形態の１つでは、使用されていないビット３３が、世界的に唯一のＩＰアドレスを用いる代わりに、パケットのソースがインターネット上で唯一の識別用のドメイン名を使用していることを示すために使用される。ＤＦフィールド３４はフラグメント化してないこと、を表す。それはセグメントをばらばらにしないようルータへの命令である、というのはデスティネーションは、ばらばらになったものを再度戻すことができないからである。ＭＦフィールド３６は、更にフラグメント化すること、を表す。最後を除き全フラグメントにはこのビットセットがある。フラグメントオフセットフィールド３８は、現在のセグメントでこのフラグメントが属する場所を示す。ライブフィールド４０への時間はパケットの寿命を制限するために使用される。秒で数えられると考えられ、最大２５５秒まで可能である。実際にはホップも数えられる。時間はルータにより各ホップ上で減少される。ライブ時間が０になると、パケットは捨てられ、警告がインターネット制御メッセージプロトコル（ＩＣＭＰ）を使用しソースへ返信される。本特徴によりパケットが永遠にさまようのを防ぐ。プロトコルフィールド４２はどのトランスポートレーヤタイプがセグメントを受信するかを示す。ＴＣＰが１つの可能性であり、ＵＤＰが別の可能性である。本発明は特別なプロトコルには制限されない。チェックサムフィールド４４はヘッダを確認する。チェックサムを実行する方法の１つは、結果が到着したとき全１６ビットハーフワードに加算し、それを結果の補足とみなすことである。ライブフィールドへの時間は変化するので、各ホップでチェックサムは再計算されなければならないことに注意すること。ソースフィールド４６はパケットのソース用ＩＰアドレスを示し、デスティネーションフィールド４８はパケットのデスティネーション用ＩＰアドレスを示す。
【００２１】
オプションフィールド２２は他の情報を保つために設計された可変長フィールドである。現在のところ、インターネット上で使用されているオプションは、安全性、提案ルートパス、これまでのルートパス、タイムスタンプその他を示す。本発明の形態の１では、ソースとドメイン名はオプションフィールド２２に付加されることが企図される。別法の１つにおいて、実際の全ＡＳＣＩＩストリングは、最初にソースドメイン名をリストし、次ぎにデスティネーションドメイン名が続く（またはその逆）オプションフィールドに直接付加できる。別の方法は、２つのドメイン名が、エンコード、圧縮、暗号化でき、そうでなければ、記憶スペース、安全性あるいは互換性の更に効果的な使用を提供するよう変更することができる。ドメイン名がエンコード、圧縮、暗号化等される形態では、記憶された情報はドメイン名を示すといわれている。すなわちエンティティーがその情報を読み取ることができ、その情報からドメイン名を引き出す（識別する）。その引出しまたは識別はデコード、暗号解読、解凍、エンコード解読等になされる。
【００２２】
別の形態では、ソース、デスティネーションもしくは両方のドメイン名が、トレーラとしてパケットのデータポーション（例えば図４のデータフィールド１０８）の最後に付加される。この場合長さフィールド３０はデータフィールドの最後に付加される余分なバイトを計上する必要がある。これまでのルータはこのトレーラをデータの一体部分として扱い、それを無視する。
【００２３】
ネットワークレーヤ１４は、ソース、デスティネーションあるいは可能なら１つまたはそれ以上のルータからの多くのプロセスを有する。ソースまたはデスティネーションマシン上でネットワークレーヤを実行するプロセスは、オペレーティングシステムの中心部、個別のユーザ処理、ライブラリパケッジ、ネットワークアプリケーション、ネットワークインターフェースカードあるいは他の適当な構成におかれる。
【００２４】
ネットワークエンティティー、すなわちネットワークレーヤを実行するプロセスはトランスポートレーヤプロセスからセグメントを受信する。ネットワークエンティティーは、パケットを形成するためにヘッダをセグメントへ付け加える。パケットはネットワーク上またはインターネット上のルータへ送信される。各ルータは、多くの遠隔ネットワーク用ＩＰアドレスと、ルータに最も近いネットワークでのホスト用ＩＰアドレスをリストした表をもつ。ＩＰパケットが着くと、そのデスティネーションアドレスはルート表で調べられる。パケットが遠隔ネットワーク用である場合、表にリストされている次のルータへ伝送される。遠隔ネットワークがルート表にない場合、パケットは更に詳細な表を持つデフォルトルータへ伝送される。パケットがローカルホスト用（例えばルータのローカルエリアネットワーク（ＬＡＮ））である場合、直接デスティネーションへ送信される。
【００２５】
インターネットの全てのマシンがＩＰアドレスをもつが、データリンクレーヤがインターネットアドレスを理解できないため、このアドレスだけではパケット送信には使用できない。ホストのほとんどがＬＡＮアドレスだけを理解するインターフェースボードにより、ＬＡＮへつながれている。例えば、全てのイーサネットボードは４８ビットイーサネットアドレスを備える。イーサネットボード製造者は中央当局（Authority）から２つのボードが同じアドレスをもつことがないよう１ブロックのアドレスを求められている。ボードは４８ビットイーサネットアドレスに基づきフレームを送受信する。あるエンティティーがイーサネットアドレスを使用する同一ＬＡＮ上の他のエンティティーにデータを送信する場合、エンティティーはアドレスレゾルーションプロトコル（ＡＲＰ）を使用できる。このプロトコルは、誰が懸案の特定のＩＰアドレスを所有するかを探すイーサネット上のパケットを広く送信する送信装置を含む。そのパケットはイーサネット上の全てのマシンへ着信し、各マシンはそのＩＰアドレスをチェックする。特定のＩＰアドレスを所有するマシンは、イーサネットアドレスに反応する。送信マシンは今では、データを直接ＬＡＮ上のデスティネーションへ送信するイーサネットアドレスをもつ。この時点で、受信装置上のデータリンクレーヤ１２は、デスティネーションへイーサネットフレームアドレスを作り、パケットをフレームのペイロードフィールドへ置き、フレームをイーサネットへ排出する。デスティネーション上のイーサネットボードはフレームを受信し、それ自体がフレームであることを確認し、フレームからＩＰパケットを取り出す。
【００２６】
トランスポートレーヤ１６の目標は効率的で信頼のおけるサービスをそのユーザ（アプリケーションレーヤ１８の処理）へ提供することである。本目標達成のため、トランスポートレーヤ１６がネットワークレーヤ１４に備えられているサービスを利用する。トランスポートレーヤを実行する１つまたはそれ以上のプロセスは、トランスポートエンティティーとよばれている。トランスポートエンティティーは、オペレーティングシステムの中心部、個別のユーザプロセス、ライブラリパケッジ、ネットワークアプリケーション、あるいはネットワークインターフェースカードにおくことができる。一般的にはトランスポートエンティティーまたはネットワークエンティティーを実行する実行可能ソフトウェアは、プロセッサ可読記憶媒介（例えばハードディスク、ＣＯ−ＲＯＭ、フロッピーディスク，テープ、メモリなど）に記憶されるであろう。
【００２７】
トランスポートレーヤはネットワークレーヤのサービスの質を高める。例えば、仮にトランスポートエンティティーが、そのネットワーク接続が突然切断されたことを長距離送信を介して途中で知らされると、新たなネットワーク接続を遠隔トランスポートエンティティーへセットすることができる。この新ネットワーク接続を使用し、トランスポートエンティティーはどのデータが到着し、どれが到着してないか探しているデスティネーションへ質問を送り、それが残されている場所を探し出すことができる。本質的に、トランスポートレーヤ１６は、基礎にあるネットワークサービスより、トランスポートサービスをより信頼があるものとすることを可能にする。失われたデータは検索され、トランスポートレーヤ１６により捕捉される。更にトランスポートサービス基本要素は、ネットワークからネットワークへかなり変化するネットワークサービス基本要素から独立したものとして設計できる。
【００２８】
ＴＣＰは信頼性のないインターネットワークより信頼性のあるエンドツーエンドバイトストリームを提供するよう特に設計された。インターネットワークは、個別の部分が個別のトポロジー、帯域幅、遅れ、パケットサイズ、および他のパラメータを持つことができるので、単一のネットワークとは異なる。ＴＣＰを支える各マシンはＴＣＰエンティティーをもつ。ＴＣＰエンティティーはローカルプロセス（アプリケーションレーヤ）からユーザデータストリームを受け入れ、ばらばらにし、各片を別々のセグメントとしてネットワークエンティティーへ送信する。セグメントがマシンへ到達するとＴＣＰエンティティーへ与えられ、元々のバイトストリームを作りなおす。ＩＰレーヤはセグメントが適切に運ばれるか保証しないので、時間切れはＴＣＰエンティティーにかかっており、必要であればそれを再伝送する。到着するセグメントは間違った順番でそれを行うかもしれない。それを適切な順番でメッセージへ再組立するのもＴＣＰエンティティーにまたかかっている。つまり、ＴＣＰは、ユーザのほとんどが望み、インターネットプロトコルが提供しない信頼性を備えていなければならない。
【００２９】
ＴＣＰサービスは送受信装置が共にソケットと呼ばれる端点を持つことで得られる。各ソケットはホストのＩＰアドレスとポートと呼ばれるそのホストへの１６ビットの番号からなるソケット番号（またはアドレス）をもつ。ＴＣＰサービスを得るため、接続が送信マシン上のソケットと受信マシン上のソケット間に明確に確立されなければならない。２５６未満のポート番号は、既知のポートと呼ばれ、標準サ−ビスのために確保される。例えば、ＦＴＰを使用するファイルを伝送するホストへの接続を確立したいと願うプロセスは、デスティネーションホストポート２１へ接続できる。同様にテルネットを使用する遠隔ログインセッションを確立するためにはポート２３が使用される。
【００３０】
アプリケーションが遠隔アプリケーションプロセスへの接続の確立を望む時は、アプリケーションプロセスはトランスポートレーヤが２つのソケット間の接続の確立を要求する接続基本要素を出す。接続が成功すると、プロセスは、その後の呼び出しで接続を識別するために使用される、ＴＣＰリファレンス番号を戻す。接続が確立された後は、アプリケーションプロセスは、送信命令を出し、デスティネーションへ送信するデータ（またはデータへのポインタ）をもつＴＣＰリファレンス番号を渡すことができる。本発明は、アプリケーションがその接続命令を出すと、２つのソケットアドレスを送信するのに加え、アプリケーションがまたトランスポートエンティティーにデスティネーション用ドメイン名を提供することも要求する。さらに、オペレーティングシステムまたはアプリケーションは接続命令に利用できるソースのドメイン名を作らなくてはならない。このことを達成する別法の１つとして、オペレーティングシステムにＤＮＲから、または逆のＤＮＳ  ＩＰルックアップを通じて、ローカルＤＮＳからドメイン名を取り戻させることがある。ソースのドメイン名は、ノードのスタートアップ時間で取り戻すことができ、ネットワークレーヤが利用できるようになる。他の別法としては、アプリケーションにソースのドメイン名を直接にあるいは逆のＤＮＳ  ＩＰルックアップを通じて提供させることである。本ドメイン名はＴＣＰリファレンス番号と関連する。あるいは、ドメイン名はデータを送信する要求がなされる毎に、トランスポートレーヤへ渡すことができる。
【００３１】
データを送信する要求を受信すると、ＴＣＰエンティティーはセグメントと呼ばれるデータユニットを作り出す。ＩＣＰエンティティーは、ネットワークエンティティーにパケットを送信あるいは受信するかのいずれかの要求をすることにより、ネットワークエンティティーへインターフェースする。パケットを送信する要求は７パラメータまで含むことができる。第１のパラメータは接続識別名であろう。第２のパラメータは、更にデータがくることを示すフラッグである。３番目のパラメータはパケットタイプを示す。４番目のパラメータは伝達されるべき実際のデータ（例えばセグメント）へのポインタである。５番目のパラメータはセグメントのバイト数を示す。６番目のパラメータはデスティネーションのドメイン名である。
【００３２】
ＴＣＰエンティティーで生成され、ＩＰエンティティーへ渡されたセグメントは、ヘッダセクションとデータセクションを含む。図３はＴＣＰヘッダの配置である。ヘッダは可変長オプションフィールド３０に続く固定フォーマット２０バイトのヘッダからなる。全ヘッダはセグメントを有するためのデータへ付け加えられる。図３では各第１の５列が３２ビットを表す。オプションフィールド８０は１つまたはそれ以上の３２ビットワードでありうる。ソースフィールド６２はソースポートを示す。デスティネーションフィールド６４はデスティネーションポートを識別する。シーケンス番号フィールド６６と認識番号フィールド６８は送受信装置間で交換されたセグメントシーケンスを追跡するために使用される。ヘッダ長フィールド７０はＴＣＰヘッダに含まれる３２ビットワード数を示す。ヘッダ長フィールド７０に続き６つの１ビットフラッグ７２がある。第１のフラッグは緊急データの存在を示す。第２のフラッグは認識番号６８が有効であることを示す。３番目のフラッグはデータが押し出しデータ（即座に送信すべきデータ）であることを示す。４番目のフラッグが接続をリセットするために使用される。５番目のフラッグが接続を確立するために使用され、６番目のフラッグは接続を解除するために使用される。ウィンドサイズフィールド７４は認識を待たずに送信できる最大バイト数を示す。チェックサムフィールド７６はヘッダ、データおよび概念的擬似ヘッダ用チェックサムを提供する。擬似ヘッダはソースの３２ビットＩＰアドレス、デスティネーションの３２ビットＩＰアドレス、ＴＣＰ用プロトコル番号、およびＴＣＰセグメント用（ヘッダを含む）バイト総数を示す。
【００３３】
オプションフィールド８０は通常のヘッダではカバーされない余分の便宜を追加する手段を提供するよう設計されている。一部の例では、オプションフィールドはホストが受け入れたい最大ＴＣＰペイロードを明記することができるよう使用されている。本発明形態の１つでは、ソースドのメイン名および／もしくはデスティネーションのドメイン名がオプションフィールド８０に記憶されている。他の形態では、ソースの、および／もしくはデスティネーションドのメイン名がＴＣＰセグメントのデータポーション（図４のデータポーション１０２）に記憶されている。
【００３４】
また、ＴＣＰ／ＩＰリファレンスモデルは接続なしのトランスポートプロトコルＵＤＰを支援する。ＵＤＰはアプリケーションがカプセルに包まれた未処理のＩＰソケットを送信し、接続を確立する必要なくそれらを送信する手段を提供する。ＵＤＰセグメントはデータを伴った８バイトヘッダよりなる。ヘッダはソースポート、デスティネーションポート、ヘッダおよびデータ長、およびチェックサムを含む。
【００３５】
図４はセグメント、パケット、フレーム間の関係を示す。アプリケーションがデータを送信する要求を出すと、ＴＣＰはデータをセグメントへ分割する。セグメントはヘッダ１０４とペイロード（データポーション）１０２を含む。セグメントはＩＰエンティティー（ネットワークレーヤエンティティー）へ渡される。ＩＰエンティティーはセグメントをデータポーション（ＩＰペイロード）へ組み込み、ヘッダ１１０をパケット形成のためのデータポーションへ付け加える。ＩＰパケットはその後パケットを取り込み、ヘッダ１１４をフレーム形成のためパケットへ付け加えるデータリンクレーヤ１２へ与えられる。このようにＩＰパケットはフレームのためのペイロード１１２である。
【００３６】
本発明はドメイン名をネットワーク上のデスティネーションへ送信するデータの経路決めをするためにドメインネームルータ（ＤＮＲ）を提供する。ＩＰアドレススペースはグローバルアドレスとローカルアドレスへ分割される。グローバルアドレスはインターネットへアクセスする１つのエンティティーによりのみ使用される特別なアドレスである。ローカルアドレスはインターネットへの直接アクセスをもたないエンティティーのために使用される。ローカルアドレスは一般的にインターネット上で使用されないので、多くの個人ネットワークは同じローカルアドレスを使用するエンティティーをもつ。衝突を避けるため、いかなるエンティティーもインターネット上でローカルアドレスを使用すべきではない。
【００３７】
クラスＡ、Ｂ、Ｃネットワーク用全セットのグローバルアドレスを使用するより、各共同エンティティーをまたはネットワークが、ＤＮＲによって使用される１つまたは少数のグローバルアドレスを割当られる。ネットワーク上の各ホストにはローカルアドレスが割当できる。同じローカルアドレスが、多くの異なるネットワークにより使用できる。ソースエンティティーがローカルアドレスをもつデスティネーションエンティティーへデータを送信する時、データはデスティネーションのネットワーク用のグローバルアドレスへ送信される。ソースエンティティーはデスティネーションドメイン名とそれ自身のドメイン名をデータ内のどこかへ埋め込む。デスティネーションのネットワーク用ＤＮＲはデスティネーションのネットワーク用のグローバルアドレスへ割当られるので、ＤＮＲはデータを受信する。ＤＮＲはデータからデスティネーションドメイン名を引き出し、そのドメイン名をローカルアドレスへ伝送し、データをデスティネーションへ送信する。ソースエンティティーは、ローカルアドレスまたはグローバルアドレスのいずれかをもっていて、なおかつ本発明を利用できる。
【００３８】
図５はインターネット１４０に接続された２つのＬＡＮ１２０と１３０を示す。ＬＡＮ１３０は各々およびＤＮＲ１３８に接続された３つのホスト１３２、１３４、１３６を含む。ＤＮＲ１３８はまたインターネット１４０に接続される。ネットワーク１２２は各々およびルータ１５６に接続された３つのホスト１５０、１５２、１５４を含む。ルータ１５６はまたインターネット１４０に接続される。ＤＮＲ１３８はまた、インターネットから受信されたＩＰパケットを、本発明に従うドメイン名を使用することによりローカルホスト（１３２、１３４、１３６）へ経路決めできる。１つの形態では、ルータ１５６はまたＤＮＲであるが、ルータ１５６はＤＮＲである必要はない。
【００３９】
図６はＤＮＲ用ハードウェアアーキテクチャの一例を示す。ＤＮＲはプロセッサ２０２、メモリ２０４、大量記憶装置２０６、ポータブル記憶装置２０８、第１ネットワークインターフェース２１０、第２のネットワークインターフェース２１２およびＩ/Ｏ装置２１４を含む。プロセッサ２０２はペンティアムプロセッサまたは他の適切なプロセッサでありうる。プロセッサ選択は十分な速度とパワーをもつ適切なプロセッサが選択される限り重大ではない。メモリ２０４はどの従来のコンピュタメモリでありうるだろう。大量記憶装置２０６、ハードドライブ、ＣＤ−ＲＯＭまたは他の大量記憶装置を含むことができるであろう。ポータブル記憶２０８はフロッピディスクドライブまたは他のポータブル記憶装置を含むことができるであろう。ＤＮＲは２つのネットワークインターフェースを含む。形態の１つではＤＮＲ２つ以上のネットワークインターフェースを含むことができるであろう。ネットワークインターフェースはイーサネットまたは他のＬＡＮタイプへ接続するためのネットワークカードを含むことができる。さらに、１つまたはそれ以上のネットワークインターフェースがＬＡＮへ接続されるであろう。Ｉ/Ｏ装置２１４は１つまたはそれ以上次のもの、すなわち、キーボード、マウス、モニタ、前面パネル、ＬＥＤディスプレイ等を含む。経路決めする方法および／もしくは図１０及び図１１の方法を実行するため使用されるソフトウェアは、大量記憶装置２０６（あるいは、あらゆる形式の非揮発性記憶装置）、ポータブル記憶媒介（例えば、フロッピディスクやテープ）および時によってはメモリ２０４に普通記憶される。上記記載のハードウェアアーキテクチャは一般化され、簡素化された形式で描かれたまさに適切な一例である。ＤＮＲはコンピュタ上で動くソフトウェア、専用のハードウェア、ドメイン名経路決めを実行するソフトウェアをもつ専用のルータあるいは適した他のソフトウェアおよび／もしくはハードウェアアーキテクチャを含むことができるであろう。
【００４０】
形態の１つでは，ドメイン名経路決めがネットワークレーヤでなされる。こうしてドメイン名はＩＰヘッダのオプションフィールド２２へ挿入される。他の形態は、データポーション（データへのトレーラなど）を含むＩＰパケットの他のポーションにドメイン名を置くことができる。他の別法では、ドメイン名は、ＴＣＰセグメントのオプションフィールド、ＴＣＰセグメントのデータポーション、ＴＣＰセグメントの他のフィールド、アプリケーションレーヤから送信されたデータもしくは他のデータユニットに記憶できる。ドメイン名がオプションフィールド２２へ挿入される場合、それをオプションフィールド８０へ置く必要はない。同様にもし、ドメイン名がオプションフィールド８０へ挿入されると、それがオプションフィールド２２で現れる必要はない。しかし、形態の１つでは、ドメイン名を多データユニット（例えば、両方のオプションフィールド）で置く方がより簡素であろう。ポイントはドメイン名がペイロード（またはトレーラ）またはヘッダにであろうが、ＩＰパケット内のどこかにあるべきだということである。
【００４１】
図７〜図１０は本発明によりデータを送信するプロセスを記載するフローチャートである。メッセージはホスト１５０からホスト１３２へ送信されているといている。本例では、ホスト１３２はローカルアドレスをもち、ホスト１５０はグローバルアドレスをもつとしている。例の目的からして、ホスト１５０と１３２はコンピュータであると仮定している。別法として、ホスト１５０と１５２はインターネット上で通信できる他の電子装置とすることができる。
【００４２】
図７は、ホスト１５０で優勢に動くアプリケーションレーヤプロセスを記載している。ステップ３０２では、ホスト１３０がドメイン名を解決する。ユーザはデータを他の処理へ送信したいと欲する。ユーザはデスティネーションのドメイン名を提供する。解決プロセスはドメイン名をＩＰアドレスへ転換する。
【００４３】
全てのドメインは、シングルホストまたはトップレベルホストであろうが、それと関連する一組のリソース記録をもつ。シングルホストに対しては、共通リソースのほとんどは、そのＩＰアドレスである。解決プロセスがドメイン名をドメイン名システムへ与える時、そのドメイン名と関連するリソース記録へそれを戻す。
【００４４】
リソース記録には、ドメイン名、ライブ時間、クラス、タイプおよび値の５つのフィールドがある。ライブフィールドへの時間は記録がいかに安定しているかを示す。特に安定している情報は、１日の秒数といった大きな値を割当られている。３番目のフィールドはクラスである。インターネットにとってクラスはＩＮである。４番目のフィールドはリソース記録のタイプを伝える。１つのドメインは多くのリソースを持つことができる。この説明において重要な少なくとも８つのリソース記録がある。すなわち、ＳＯＡ、Ａ、ＭＸ、ＮＳ、ＣＮＡＭＥ、ＰＴＲ、ＨＩＮＦＯおよびＴＸＴである。ＳＯＡ記録の値フィールドはネームサーバゾーン、その管理人のＥメールアドレス、独自のシリアルナンバーと多様なフラッグおよび値フィールドにおける時間切れについての情報の主ソース名を提供する。Ａ記録の値フィールドは、ホスト用３２ビットＩＰアドレスをもつ。ＭＸ記録用値フィールドは、その特定のドメイン名に対してＥメールを受け入れたいエンティティーのドメイン名を保持している。ＮＳ記録は、ネームサーバを明記する。ＣＮＡＭＥ記録は、別名が値フィールドで生成されることを可能にする。ＰＴＲ記録は、値フィールドで別の名前を指摘するだけで、特定のドメイン名のＩＰアドレスを調べることを可能にする。ＨＩＮＦＯ記録の値フィールドは、ドメイン名が対応するマシンのタイプとオペレーティングシステムを示す。ホスト用リソースフィールド記録の例は以下の表１に見られる。
表１
ドメイン名    ライブ時間    クラス    タイプ      値
saturn.tte.com.  86400       IN       HINFO     Sun unix
saturn.tte.com.  86400       IN         A         188.68.70.1
saturn.tte.com.  86400       IN        MIX       mars.ttc.com
【００４５】
表１はsaturn.tte.com.のドメイン名をもつエンティティーのための３つのリソース記録を示す。第１のリソース記録は、８６，４００秒（１日）のライブ時間を示す。第２のタイプはＨＩＮＦＯで、値はエンティティーがＵＮＩＸオペレーティングシステムを動かすＳｕｎワークステーションであることを示す。２行目はタイプＡのリソース記録であり、saturn.tte.com.のＩＰアドレスが１９８．６８．７０．１であることを示す。３行目はsaturn.tte.com.のＥメールアドレスがmars.ttc.com.に送信されなければならないことを示す。mars.ttc.com.のＩＰアドレスを示すＤＮＳがありうる。
【００４６】
ＤＮＳ名前スペースはノンオーバーラッピングゾーンに分割される。各ゾーンはインターネットスペースのあるポーションであり、ゾーンについてのオーソリティの情報をもつネームサーバを含む。通常ゾーンは１つの主ネームサーバと、主ネームサーバからの情報を得る１つまたはそれ以上の二次的ネームサーバをもつであろう。解決プロセスにドメイン名についての質問がある時、その質問をローカルネームサーバの１つに渡す。探されたホストがそのネームサーバの支配下に入ると、そのドメインネームサーバオーソリティのリソース記録を戻す。オーソリティの記録は記録を管理するオーソリティからくる１つである。しかし、ホストが遠く、要求されたホストに関する情報がローカルでは何も入手できない場合は、ネームサーバは要求されたホストのためトップレベルのネームサーバへ質問メッセージを送信する。トップレベルのネームサーバは、情報を受け取り、元の解決プロセスに伝送するローカルネームサーバへリソース記録を供給する。ローカルネームサーバで受け取られた情報はオーソリティの記録ではないので、ライブ時間はその情報を使用するためのどのくらいの時間かをを決定するために使用される。
【００４７】
１つの形態において、ＤＮＲ１３０はＬＡＮ１２０上のホスト用オーソリティＤＮＳサーバとしては働く。このようにＤＮＲ１３０はホスト１３２用リソース記録を記憶するだろう。ホスト１３２用リソース記録の１つは、ホスト１３２用ドメイン名をもつＤＮＲ１３０のグローバルアドレスと関連するタイプＡ記録であろう。
【００４８】
図７を見なおすと、ドメイン名が解決されると、アプリケーションプロセスは、その望ましいデスティネーションのＩＰアドレス処理にある。ステップ３０４で、アプリケーションプロセスは、トランスポートレーヤ（例えばＴＣＰ）に接続を確立するよう要求する。ソースとデスティネーションの両方にソケットがセットされなければならない。アプリケーションプロセスはソースのソケット、デスティネーションのソケット、ソースのドメイン名およびデスティネーションのドメイン名をトランスポートレーヤへ出す。ステップ３０６では、アプリケーションはトランスポートレーヤにデータの送信を要求する。ステップ３０８で、アプリケーションプロセスはトランスポートレーヤにデータの受信（任意選択）を要求できる。ステップ３１０では、ソースとデスティネーション間の接続は切断される。
【００４９】
図８はホスト１５０のトランスポートレーヤが、図７のステップのアプリケーションレーヤによる要求に関連して、いかにデータを送信するかを説明する。ステップ３５０では、トランスポートレーヤ（例えばＴＣＰ）はアプリケーションレーヤからの接続要求を受信する。ステップ３５２では、トランスポートレーヤはソースソケットとデスティネーションソケット間の接続を確立する。１つの形態では、接続要求はソースとデスティネーションのドメイン名を含む。別法として、ドメイン名はステップ３５４の間に通過できる。ステップ３５４では、トランスポートレーヤはアプリケーションレーヤから、デスティネーションソケットへ送信されるデータを受信する。ステップ３５４は実際の受信データもしくはデータへのポインタを含むことができる。受信されたデータは、１つまたはそれ以上のセグメントへくずされ、各セグメントは別々に送信される。ステップ３５６では、１つまたはそれ以上のセグメントが生成される。セグメントを創るステップは、ヘッダを創るステップ（ステップ３５８）、ソースのドメイン名とデスティネーションのドメイン名をヘッダまたはデータポーションへ追加するステップ（ステップ３６０）、およびヘッダをデータ（ステップ３６２）へ付け加えるステップを含む。ドメイン名がＴＣＰセグメントではなく、ＩＰパケットへ付加されるならば、ステップ３６０は省略できる。セグメントが生成されると、トランスポートレーヤはステップ３７０においてセグメントを送信する。セグメントの送信には、セグメントのネットワークレーヤへの通過を含む。
【００５０】
図９はホスト１５０上のネットワークにより、図８のステップに対応したデータを送信するために行われるステップを記載する。ステップ４００では、ネットワークレーヤは、インターネット（または他のネットワーク）上のパケットを送信するセグメントと要求を受信する。上記にて議論されたように、パケットを送信する要求はソースとデスティネーションのドメイン名を通過する。別法として、ドメイン名をデータへ取り込むことができる。ステップ４０２において、パケットが生成される。パケットを創るステップは、ヘッダを創るステップ（ステップ４０４）、ソースとデスティネーションのドメインをヘッダまたはデータポーションへ追加するステップ（ステップ４０６）、ヘッダをデータへ付け加えるステップ（ステップ４０８）を含む。ドメイン名がＴＣＰセグメントではなく、ＩＰパケットへ付加されるならば、ステップ４０６は省略できる。パケットが生成されると、ネットワークレーヤはステップ４１０でパケットの経路を決める。パケットは、ホスト１５０からルータ１５６を通じ、インターネット１４０を通じ、ＤＮＲへ経路される。経路決めされたパケットは、ＤＮＲ１３８のデスティネーションＩＰアドレスとホスト１５０のソースＩＰアドレスを含み、両方ともグローバルアドレスである。ＩＰパケットはまたホスト１３２と１５０のドメイン名を含む。１つの形態では、ＩＰパケットはソースのドメイン名を含まないであろう。図９のステップは各セグメントに対して繰り返すことができる。
【００５１】
１つの形態では、ホスト１５０はローカルアドレスをもち、ルータ１５６はＤＮＲである。ホスト１５０から送信されたＩＰパケットがルータ１５６で受信されると、ホスト１５０のローカルアドレスはルータ１５６のグローバルアドレスと置きかえられる。
【００５２】
図１０は、ＤＮＲ１３８がホスト１５０からＩＰパケットを受信する時、ＤＮＲ１３８により実行されるステップを記載する。ステップ５０２では、ＤＮＲ１３８はＩＰパケットを受信する。ステップ５０４では、ＤＮＲ１３８はパケットからのデスティネーションのドメイン名を識別する。ドメイン名を認識することは、ヘッダ、データポーションもしくはＩＰパケット、ＴＣＰセグメント、アプリケーションデータ等での他のロケーションのドメイン名を探すことを含むことができるであろう。ドメイン名を識別することは、ＡＳＣＩＩストリングを読み込むことを含むことができるであろう。別法として、ドメイン名が圧縮、暗号化、エンコード化等されている場合、ＤＮＲ１４８はデコード、圧縮の解除、暗号化解読等をする必要があるだろう。ステップ５０６では、ＤＮＲ１３８はデスティネーションのドメイン名をローカルアドレスへ伝送し、ステップ５０８では、パケットはローカルアドレスをもったデスティネーションへ経路される。
【００５３】
図１１は、デスティネーションのドメイン名をローカルアドレス（図１０のステップ５０６）へ伝送するステップを行うための１つの代表的形態を記載する。ドメイン名を変換する他の適当な方法がまた使用できる。ドメイン名の変換は図１１の全ステップより少ないステップを含むことができる。ステップ５１２では、ＤＮＲはメモリまたは他の記憶装置に記憶されたＤＮＲ表中のドメイン名を調べる。１つの形態では、ＤＮＲ表はまたイーサネットアドレスを含むこともできる。ローカルネットワークがツリー形式の複数ＤＮＲを含むことは可能である。このように、特定のドメイン名についてＤＮＲ表へエントリすることは、他のＤＮＲに対するアドレスそのものでありうる。次に、パケットは別のＤＮＲへ、およびその後デスティネーションまたは他のＤＮＲ等への最終の（または次の）ローカルアドレスを見つけるためにドメイン名を使用する第２のＤＮＲへ、送信されるであろう。ＤＮＲ表はネットワークの管理人により手動でセットアップでき、また、組み込まれているソフトウェア、ファームウェアまたはハードウェアを通じ自動でセットアップできる。
【００５４】
ステップ５１４では、ドメイン名用の記録が見つけ出されたかどうかをＤＮＲが決定する。記録が見つからない場合、エラーメッセージがステップ５１６でホスト１５０へ戻される。記録が見つかる場合、ＩＰパケット内のＤＮＲ１３８用グローバルアドレスが表のローカルアドレスと置き換えられる。ステップ５２０では、必要であればＩＰヘッダのチェックサムが調整される。デスティネーションＩＰアドレスがヘッダ内で変更されたので、それに従いチェックサムが調整される必要があるであろう。アプリケーションが、ＩＰパケットにより使用される情報をそのデータペイロードへ組込む場合、そうしたアプリケーションパケットは、デスティネーションＩＰアドレスの変更の結果として調整が必要となるかもしれない。
【００５５】
パケットがホストにより受信されると、ネットワークレーヤはソースとデスティネーションドメイン名をトランスポートレーヤ（少なくとも各接続に対し１度）へ渡す。トランスポートレーヤは、ソースとデスティネーションドメイン名をアプリケーションレーヤへ渡すことができる。レーヤのいずれも応答を送信するためソースのドメイン名を使用できる。
【００５６】
図５は、ＬＡＮとインターネットの間に接続され、配置されるＤＮＲ１３８を示すが、ＤＮＲ１３８はＬＡＮ内にもまた配置することができるであろう。本発明は、ＴＣＰ／ＩＰリファレンスモデルおよび／もしくはインターネット以外のネットワークへの実施でも使用することができる。
【００５７】
前述の本発明の詳細な記載は、図解と記載の目的のために提示した。本発明を開示された正確な形式に対して網羅的な意図もなければ、限定する意図もなく、多くの修正形態および変形形態が上記教示に照らし合わせ可能であることは明らかである。記載された実施形態は、当業者が本発明を多くの実施形態および考えられる特定の使用に適するような多様な修正形態で最適に利用できるように、本発明の原理およびその実際の応用を最善に説明するために選択したものである。本発明の範囲は、ここに添付の請求項により定義されることを意図している。
【図面の簡単な説明】
【図１】  ＴＣＰ／ＩＰリファレンスモデルのレーヤを示す概念図である。
【図２】  インターネットプロトコル（ＩＰ）ヘッダを示す。
【図３】  伝送制御プロトコル（ＴＣＰ）ヘッダを示す。
【図４】  セグメント、パケットおよびフレームのネスティングを示す。
【図５】  インターネットに接続された２つのスタブネットワークのブロック図である。
【図６】  ドメイン名ルータを実行するための１つの代表的なハードウェアプラットフォームの簡略ブロック図である。
【図７】  本発明によるデータを送信するアプリケーションプロセスにより使用されるステップを記載しているフローチャートである。
【図８】  本発明によるデータを送信するトランスポートレーヤプロセスにより使用されるステップを記載しているフローチャートである。
【図９】  本発明によるデータを送信するネットワークレーヤプロセスにより使用されるステップを記載しているフローチャートである。
【図１０】  ドメイン名ルータにより実行されるステップを記載しているフローチャートである。
【図１１】  図１０の変換ステップを記載しているフローチャートである。
【図１】
0004130962.tif 000002
【図２】
0004130962.tif 000003
【図３】
0004130962.tif 000004
【図４】
0004130962.tif 000005
【図５】
0004130962.tif 000006
【図６】
0004130962.tif 000007
【図７】
0004130962.tif 000008
【図８】
0004130962.tif 000009
【図９】
0004130962.tif 000010
【図１０】
0004130962.tif 000011
【図１１】
0004130962.tif 000012