(57)【要約】  インターネットワーキングプロトコルが第１のデータグラム識別子のプールから引き出したデータグラム識別子を使用することに付随する問題の観点から、データグラムがインテグリティを維持する。方法には、特定の識別子のみが許可されるための、データグラム識別子の使用の管理が含まれる。第１のプールとは異なる、第２のデータグラム識別子のプールが生成される。データグラム識別子が第２のプールから引き出され、データグラム識別子がデータグラムのライフタイムの間に再使用されることが規制されるような方式で、データグラムに割り当てられる。利用可能なデータグラム識別子の数が、オプションヘッダフィールドを通じて増加されるか、許可データグラム識別子を追跡することを通じて低減されるかがなされる。第１のホストが、許可された識別子についての第２のホストを認識する。第２のホストは、許可識別子をデータグラム識別子として使用する。
2009533960.tif 000002
【特許請求の範囲】
【請求項１】
制限された数の利用可能なデータグラム識別子を有する第１のデータグラム識別子のプールに起因するデータグラム破損問題を解決する方法であって、方法は、
（ａ）第１のデータグラム識別子のプールとは異なる第２のデータグラム識別子のプールを提供するステップと、
（ｂ）第２のデータグラム識別子のプールから引き出されたデータグラム識別子を、データグラムに割り当てるステップと、を備え、
第２のプールの使用が、データグラム識別子がデータグラムに付随するライフタイムの間に再使用されないことを確実にする、方法。
【請求項２】
第２のデータグラム識別子のプールを提供するステップが、利用可能なデータグラム識別子の数を、制限された値を超えて増加させることを含む、請求項１に記載の方法。
【請求項３】
第２のデータグラム識別子のプールが、ホストペアに関連する、請求項２に記載の方法。
【請求項４】
第２のデータグラム識別子が、ホストペアに関連するプロトコルポートに関連する、請求項３に記載の方法。
【請求項５】
第２のデータグラム識別子のプールを提供するステップが、利用可能なデータグラム識別子の数を、制限された値を下回って減少させることを含む、請求項１に記載の方法。
【請求項６】
利用可能なデータグラム識別子の数が、２Ｎの関数であり、ここでＮは３２未満の整数値である、請求項５に記載の方法。
【請求項７】
利用可能なデータグラム識別子の数が、２未満である、請求項６に記載の方法。
【請求項８】
第２のデータグラム識別子のプールを提供するステップが、ライフタイムに関係する閾値関数に応答する、請求項１に記載の方法。
【請求項９】
閾値関数が、タイムアウト期間の関数である、請求項８に記載の方法。
【請求項１０】
閾値関数が、データグラムが転送される速度の関数である、請求項８に記載の方法。
【請求項１１】
データグラムがインターネットワーキングプロトコルに関連する、請求項１に記載の方法。
【請求項１２】
インターネットワーキングプロトコルが、ＩＰｖ４及びＩＰｖ６の少なくとも１つのプロトコルを含む、請求項１１に記載の方法。
【請求項１３】
データグラムの中のヘッダにオプションヘッダフィールドを加えるステップを更に備え、ヘッダはインターネットワーキングプロトコルに関連し、オプションヘッダフィールドは、データグラム識別子の少なくとも部分を格納する、請求項１１に記載の方法。
【請求項１４】
データグラム識別子が、少なくとも３２ビットを備える、請求項１３に記載の方法。
【請求項１５】
データグラム識別子が、少なくとも４８ビットを備える、請求項１４に記載の方法。
【請求項１６】
データグラムを第１のホストから第２のホストに、ネットワークを通して送信するステップを更に備える、請求項１に記載の方法。
【請求項１７】
データグラム識別子を第１のホストに提案する第２のホストを更に備える、請求項１６に記載の方法。
【請求項１８】
データグラムを介してストレージデバイスとデータをやり取りするために、請求項１６の方法を用いる、ストレージプロトコル。
【請求項１９】
ｉＳＣＳＩ、ＦＣＩＰ、及びｉＦＣＰの、少なくとも１つのプロトコルを備える、請求項１８に記載のストレージプロトコル。
【請求項２０】
処理装置上で実行する命令を格納するコンピュータで読み取り可能なメモリであって、命令は請求項１の方法に従って動作する、メモリ。
【請求項２１】
請求項２０のメモリを備える、ネットワーク上のコンピュータデバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
本特許出願は、２００６年４月１０日出願の米国仮特許出願第６０／７９１，０５１号明細書への優先権を主張する、２００６年５月１５日出願の米国特許出願第１１／４３５２３９号明細書への優先権を主張し、両出願は、その全体が参照により本明細書に組み込まれる。
【０００２】
本発明の分野は、インターネットワーキングプロトコルを通してデータグラムを確実に転送することに関する。
【背景技術】
【０００３】
２００６年４月４日に、インターネット・エンジニアリング・タスク・フォース（ＩＥＴＦ）により維持されているＲＦＣ７９１の中で定義される標準インターネットワーキングプロトコルＩＰｖ４に関連する問題に言及する通知が発行された。Ｊ．Ｈｅｆｆｎｅｒ、Ｍ．Ｍａｔｈｉｓ、及びＢ．Ｃｈａｎｄｌｅｒにより書かれたこの参考資料（その全体が参照により本明細書に組み込まれる、ｈｔｔｐ：／／ｗｗｗ．ｐｓｃ．ｅｄｕ／〜ｊｈｅｆｆｎｅｒ／ｄｒａｆｔｓ／ｄｒａｆｔ−ｈｅｆｆｎｅｒ−ｆｒａｇ−ｈａｒｍｆｕｌ−ＸＸ．ｈｔｍｌ）は、どのようにＩＰｖ４を通して転送されるデータグラムが、ＩＰｖ４ヘッダ内のデータグラム識別表示フィールドに関する問題によりデータ破損を被る可能性があるかを説明している。データグラム破損は、データグラムのライフタイムの間に利用可能なデータグラム識別子の数が限定されていることに起因する。この問題への解決策は、著者たちからは何も提案されていない。
【０００４】
ＩＰｖ４は、規模として６５，５３５（２１６）バイトまでのサイズを有するデータグラムを転送することができる。ＩＰｖ４を含むプロトコルスタックのインターネットワーキングプロトコル（ＩＰ）層は、６５，５３５個の利用可能なデータグラム識別子があることを暗示する１６ビットの識別子を、データグラムに割り当てることができる。通常、ＩＰデータグラム識別子は、データグラム識別子が使用される度にインクリメントされるカウンタとして実装される。カウンタが、１６ビットカウンタに対する最大値である６５，５３５に達すると、値は０に戻る。ＩＰは、大きなデータグラムをより小さな塊に断片化し、これらのフラグメントを、例えばイーサネット（登録商標）などの媒体を通して送信する。イーサネット（登録商標）が１５００バイトのフレームをサポートする場合、ＩＰ層は、それぞれのフレームが同じデータグラム識別子を有し、且つそれぞれがデータグラム内でのあるオフセットを有する、最大４４個までのフレームを生成する。データグラム識別子及びオフセット情報は、リモートホストにより、通信スタックの上位の層にデータグラムを渡す前にデータグラムを再構築するために用いられる。高速媒体に対しては、ホストは、６５，５３５を超えるデータグラムを非常に短時間に送信して、ホストがデータグラム識別子カウンタの値を終わりに（ｗｒａｐ）させることもあり得る。例えば、秒当たり１ギガビット（Ｇｂｐｓ）で動作するイーサネット（登録商標）が用いられるとすると、データグラム識別子カウンタは、比較的な小さいデータグラムを仮定すれば、１秒未満で終わりとなってしまうこともあり得る。殆どの通信スタックは、再構築のために、データグラムを３０〜１２０秒保持する。従って、特定のデータグラム識別子を有するデータグラムが再構築のためにメモリの中に格納され、且つこれのフラグメントの１つが失われてしまった場合、同じ識別子を有するその後の別のデータグラムフラグメントが、最初のデータグラムの破損を起こすこともあり得る。破損は、受信ホストが、第２のデータグラムからのフラグメントを、これが同じデータグラム識別子及びオフセットを有しているという理由で、第１のデータグラムに属するものとして解釈することが原因で起こる。この問題は、ＴＣＰ、ＵＤＰ、ＩＣＭＰ、又はＩＰを通して運ばれる他のデータに当てはまる。この問題は、データグラムがシステム内で活動している間に利用可能なデータグラム識別子の数が限られる、データグラム識別子のプールを用いることに起因するものとして、特徴付けられ得る。
【０００５】
興味深いことに、ネットワークストレージテクノロジーの生産者である、Ｚｅｔｅｒａコーポレーションが、先の問題文書の一般公開と同じ頃に、このデータグラム破損問題に遭遇し、これを解決した。Ｚｅｔｅｒａは、独自仕様のストレージプロトコルであるＺ−ＳＡＮ（登録商標）プロトコルを、１Ｇｂｐｓのイーサネット（登録商標）システム上のＵＤＰ／ＩＰを通して実行している間に、この問題を発見した。Ｚｅｔｅｒａは、その全体が参照により本明細書に組み込まれる、Ｚｅｔｅｒａの２００６年４月１０日出願の米国仮特許出願第６０／７９１，０５１号明細書の中に記述されているように、この問題を解決する解決策を作り出している。
【０００６】
このデータグラム破損問題に関する更なる調査によると、この問題が現れたのは、Ｓｕｎ（登録商標）のＮｅｔｗｏｒｋ  Ｆｉｌｅ  Ｓｙｓｔｅｍ（ＮＦＳ）インプリメンテーションの顧客がデータ破損を被った１９８７年までさかのぼる。ＮＦＳは、上述の理由で破損に至る８ＫＢのＵＤＰデータグラムを用いた。ＮＦＳのインプリメンテーションは、この問題に、アプリケーション層でＮＦＳが応答を待つ時間を短縮することにより、あるいはデータグラムに対する大きなチェックサム値を通じて（３２ビットチェックサム以上）、対処した。このような解決策は、損失の危険を緩和するが、この問題に対する解決策を作り出してはいない。加えて、短いタイムアウトは、システムが追加のリトライを実行しなければならないことから、システムの効率を低下させる。
【０００７】
「Ｐｒｅｖｅｎｔｉｏｎ  ａｎｄ  ｄｅｔｅｃｔｉｏｎ  ｏｆ  ＩＰ  ｉｄｅｎｔｉｆｉｃａｔｉｏｎ  ｗｒａｐａｒｏｕｎｄ  ｅｒｒｏｒｓ」という名称の米国特許第６，８９４，９７６号明細書は、ＩＰデータグラム識別子のラップアラウンドの問題に関連するリスクを、タイムアウト及びチェックサムの使用を通して低減する方法を教示する。しかしながら、この参考文献は、全てのＩＰベースのアプリケーションに当てはまるこの問題に対する実行可能な解決策は提示していない。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
説明された問題は、標準化されたＩＰの生来の部分であり、標準を変更しない限りは普遍的には解決されえない。しかしながら、ネットワークストレージや、他のネットワークデバイス、又はネットワークアプリケーションに適合するようにこの問題を解決することができる真の解決策を有することが望ましい。真の解決策は、標準により採用されるということが予期される。望ましい解決策は、以下の特徴を有するべきである：
・解決策は、アプリケーションを変更する必要がないように、ＩＰ層で動作すべきである。
・解決策は、任意の変更が標準において必要とされる場合に、通信スタックの新バージョンがレガシースタックとともに動作することができるように、下位互換性を有するべきである。
・解決策は、既存のスタックに対しての変更の要求を、最小限とするべきである。
・解決策は、増加の一途をたどるデータ転送速度に関して、将来的に耐えられるべきである（１０Ｇｐｂｓ、１００Ｇｐｂｓ、など）。
・解決策は、データグラム識別子の使用の管理を支援するために、データグラム識別子をデータグラムのライフタイムと結びつけるべきである。
【０００９】
明らかに、データグラム破損問題の解決策に対する、長い間感じられてきた必要性が依然として存在している。解決策は、単に問題が起こる危険性を緩和することよりはむしろ、問題に完全に対処することが望ましい。
【課題を解決するための手段】
【００１０】
本発明の主題は、限られた供給量を有する識別子のプールからデータグラム識別子を使用することに起因するデータグラム破損問題を解決するための方法を備える。方法は、第１のプールとは異なる識別子のプールを提供することと、データグラムに第２のプールから引き出されたデータグラム識別子を割り当てることと、を含む。更に、データグラム識別子は、破損問題が起こらないことを確実にするために、データグラムのライフタイムの間再使用されることを規制される。一部の実施形態では、データグラム識別子の第２のプールは、より大きい数のデータグラム識別子を備え、他の実施形態では、第２のプールは、より小さい数のデータグラム識別子を備える。利用可能なデータグラム識別子の数が増加される好ましい実施形態では、増加された数の識別子が消費される時間は、データグラム転送速度に照らしてデータグラム破損問題が起こり得る時間間隔を上回る。利用可能なデータグラム識別子の数が、減らされる他の好ましい実施形態において特に１個の識別子まで、識別子は後に続くデータグラムとともに再使用されることが規制される。
【００１１】
特に好ましい実施形態は、開示される方法を利用するストレージプロトコルを備える。データは、ストレージプロトコルを用いるストレージデバイスと、意図されたデータグラムを介してやりとりされる。ストレージプロトコルには、独自仕様のストレージプロトコル又は標準ストレージプロトコルを含む。標準ストレージプロトコルの実施例には、ｉＳＣＳＩ、ＦＣＩＰ、又はｉＦＣＰを含む。
【００１２】
一部の実施形態では、第１のホストが、どのデータグラム識別子が現在使用中であるかを追跡する。第１のホストは、第２のホストに利用可能なデータグラム識別子について知らせ、次に第２のホストは、第１のホストに送り返すデータグラムのために、データグラム識別子を使用する。第２のホストは、このデータグラム識別子を、第１のホストがこれが再使用できるということを指し示さない限り、再度用いることはない。第１のホストは、使用済みのデータグラム識別子を、リストを通して追跡する。データグラム識別子は、通信プロトコルスタックが、これらが通常行うようにフラグメントデータグラムを再構築することができるような方式で、データグラムと関連付けされる。最近使用されたデータグラム識別子は、後続のデータグラムが現在のデータグラムの再構築を崩壊させないことを確実にするために、再度使用されることを規制される。
【００１３】
本出願における教示は、インターネットワーキングプロトコルを用いるネットワーキングアプリケーションのデベロッパーにより、データ破壊を起こすデータグラム破損を解決するために、有利に採用されてもよい。提案される方法は、ＴＣＰ、又はＵＤＰ、又はデータグラムの送信のためにＩＰを利用する他のプロトコルとともに、用いられ得る。本方法は、データインテグリティが一番の関心事であるデータストレージアプリケーションを含むクライアントによりアクセス可能なネットワークデバイスの中での展開にとって、特に好都合である。
【００１４】
以下の記述は、本明細書の中で用いられる用語に言及している。これらの用語は、本発明の主題の多様な態様を論じるときに、暗黙の制限なく、明確性を確実にし、且つ、本明細書の本体内の繰り返しを低減するために、提供される。
【００１５】
「データグラム」という用語は、データの塊が、配信を簡略化するためにより小さいピースへと断片化され得る通信リンクを通して送信されるデータの塊を意味する。通常、データグラムは、ＩＰｖ４又はＩＰｖ６を含むインターネットワーキングプロトコル（ＩＰ）に関連している。加えて、データグラムは、フラグメントの再構築を補助するために、データグラム識別子を通して識別される。
【００１６】
本発明のさまざまな目的、特徴、態様、及び利点が、類似の数字が類似の構成要素を表す添付の図面とともに、本発明の好ましい実施形態についての以下の詳細の説明からより明確になってくる。
【発明を実施するための最良の形態】
【００１７】
以下の説明は、本発明の主題の概念を伝える、いくつかの実施例を表す。実施例が用いられているが、これらはいかなる方法において本主題の範囲を決して制限するものではない。提案される実施形態は、これらの最も広い範囲に解釈されるべきである。
【００１８】
高速ネットワーク上での信頼できないＩＰ断片化に関する問題を解決するための解決策が、説明される。ＩＰ断片化は、ＴＣＰ、ＵＤＰ、ＩＣＭＰ、ＩＧＭＰ又はその他を含む他のプロトコルを場合により運ぶデータグラムの断片化を実行し、且つ物理媒体の最大転送単位（ＭＴＵ）にデータグラムをマッチングさせる、通信スタックのＩＰ層に関連する。断片化は、ＩＰが仮想アドレスを用いた通信を処理し、且つＩＰが、通常固定の最大サイズを有する実際の物理媒体にデータグラムを合わせる必要があるならば、必要である。データグラムは、最大６５，５３５バイトまでの長さを有することができるが、８０２．３イーサネット（登録商標）の物理層は、通常最大サイズ１５００バイトである。ＩＰは、送信の間のデータグラムの断片化と、また受信時のデータグラムの再構築との、両方を実行する。例えば、再構築の処理は、送信元ＩＰアドレス（３２ビット）、データグラム識別子フィールド（１６ビット）、フラグ（３ビット）及びフラグメントオフセットフィールド（１３ビット）を含む、ＩＰｖ４内のフィールドを関連付けることを通じてなされる。
【００１９】
インフライトの複数のデータグラムは、ＩＰｖ４において１６ビットの長さを有するデータグラム識別子を通じて識別される。通常、通信スタック内のＩＰ層は、データグラム識別子が使用されるごとに１つだけインクリメントするカウンタを用いる。このカウンタの値が、データグラム識別子を表す。データグラム破損問題は、再構築において発生する。ＩＰ層は、最大１２０秒まで再構築のためのデータグラムのフラグメントを保持する。特に、Ｗｉｎｄｏｗｓ（登録商標）は、６０秒のウインドウを用い、Ｌｉｎｕｘ（登録商標）は、３０秒のウインドウを用いる。最悪のシナリオが、この問題を例示するための構成され得る。
【００２０】
フラグメントの１つが受信されずに、受信バッファが次の１２０秒間再構築を試みる、断片化されたデータグラムを仮定する。通信は、この後、複数のフラグメントを同様に有する更なるＩＰデータグラムを用いて継続する。１Ｇｂｐｓをサポートするネットワーク上では、データグラム識別子は約３０秒で終了となる。特に、５１２バイトのペイロードサイズを用いるプロトコルは、約２７０ミリ秒で終わりに出くわす。ＩＰ層が最大１２０秒まで待つことを考えると、あるフラグメントを元のデータグラムに間違って関連付けるための十分な機会が存在することになり、これにより、データ破損に帰着する。ペイロードチェックサムが、この状況を打ち消すことを試みるために用いられ得るが、１６ビットのチェックサムフィールドと、ランダムデータの使用では、データ破損は、これらの最悪ケース数値を用いると４．８時間毎に起こり得る。１０Ｇｂｐｓは、１０倍速くこの問題を被る。
【００２１】
明らかに、この状態は、対応される必要がある。状況は、データグラムのＩＰヘッダに、追加のオプションフィールドを加えることにより対処され得る。オプションフィールドは、一部の実施形態では、利用可能なデータグラム識別子のプールを増加するためにホストによって使用され得る、拡張されたデータグラム識別子情報を備える。プールが、ネットワークの速度に対して、及びデータグラムが送信される速度に対して十分なサイズを有している場合は、利用可能なデータグラム識別子の増加されたプールは、データグラム破損が起こらないことを確実にする十分な分解能を有する。利用可能なデータグラム識別子は、これらの数が非常に多い（ｓｈｅｅｒ）ことによって、再使用されることを規制される。
【００２２】
各コマンドが明確な応答を有するプロトコルのための代替的な実施形態では、コマンドを備えるデータグラムが、ペイロードの中にデータグラム識別子も同様に含んでいる。次に、応答データグラムが、識別子を自分の応答の中で、ペイロードの中及びＩＰ層ヘッダの中の両方で用いる。ホストが、この後、データグラムのライフタイムの間にデータグラム識別子が再使用されることを避けるために、除外テーブル又はリストを用いる。除外テーブルは次に、タイムアウト期間よりも長く生存しているエントリに基づいて洗浄（ｓｃｒｕｂ）され、このことが、不整合な関連付けがないことを保証する。除外リストが、満杯になった場合は、ネットワークはあまりに汚いと認識される。従って、解決策は、１つのホストにより管理され得る低減された数の利用可能なデータグラムを有する、データグラム識別子のプールを生成することである。
【００２３】
（インターネットワーキングプロトコルのためのデータグラム識別）
インターネットワーキングプロトコル（ＩＰ）は、標準化されたＩＰｓ、例えば、ＩＰｖ４又はＩＰｖ６を含むことができる。ＩＰｖ４及びＩＰｖ６は標準化されたのではあるが、これらは、再構築のためにこれらがどのようにデータグラムを扱うかに起因する上述の問題を有している。
【００２４】
図１Ａは、従来のＩＰｖ４ヘッダを示している。ＩＰｖ４ヘッダは、その全体が参照により本明細書に組み込まれるＲＦＣ７９１の中に完全に記述されている。ヘッダ１００は、以下のフィールドを含む複数の標準化されたフィールドを備える：
・バージョン１０３：ＩＰプロトコルのバージョン。ＩＰｖ４は、４の値を使用する。
・ＩＰヘッダ長１０５：最低値５を伴う、ＩＰｖ４ヘッダ内の３２ビットワードの数。
・サービス種別（ＴｏＳ）１０７：サービスの質の目安を提供する。
・データグラム長１０９：オクテット（バイト）でのデータグラムの長さ。
・識別表示１１０：断片化又は再構築のために、送信元及び宛先に関して他からのデータグラムを区別するための、１６ビット識別子。
・フラグ１１１：断片化を制御するフラグ。
・フラグメントオフセット１１３：現在のフラグメントのオフセット（オクテットでの８バイトインクリメント）。
・生存時間（ＴＴＬ）１１５：データグラムが廃棄される前の許容ホップ数。
・プロトコル１１７：データグラムの搬送に付随するプロトコル番号。プロトコルは、ＩＣＭＰ、ＴＣＰ、ＵＤＰ又は他を含む。
・ヘッダチェックサム１１９：ＩＰｖ４ヘッダ専用のチェックサム。
・送信元アドレス１２１：データグラムの送信元のＩＰｖ４アドレス。
・宛先アドレス１２３：データグラムの宛先のＩＰｖ４アドレス。
・オプション１２０Ａ〜１２０Ｎ：ＩＰｖ４ヘッダを拡張することができるオプション。
【００２５】
ＩＰｖ４標準はＲＦＣ７９１の中で、識別表示１１０は、「インターネットシステムの中でデータグラムがアクティブになる時間の間は、送信先−宛先のペアとプロトコルに対して、一意的でなければならない」と述べている。識別表示１１０に対してある値を選ぶ方法は数え切れないほど多いとはいえ、識別表示１１０がデータグラムのライフタイムの間一意的であることを確実にするための手引きは、標準の中では提供されていない。通常、ＩＰｖ４のインプリメンテーションには、データグラムが用いられるごとに１つだけインクリメントされるカウンタを用いる。明らかに、殆どのＩＰｖ４インプリメンテーションにより実装されるような識別表示１１０は、データグラムのライフタイムが、終了条件（ｗｒａｐ  ｃｏｎｄｉｔｉｏｎ）が起こるために必要な時間を超過する場合には、標準を守ることができない。単純に識別表示１１０に１６ビットの情報を投げ入れていくということは、データグラムのライフタイムの間に一意性を維持するには不十分なデータグラム識別子のプールを意味する。
【００２６】
図１Ｂは、従来のＩＰｖ６ヘッダを示している。ＩＰｖ６標準は、その全体が参照により本明細書に組み込まれるＲＦＣ２４６０の中に記述されている。ＲＦＣ２４６０は、ＩＰｖ６ヘッダ１５０についての詳細を提供している。断片化に関して、ＩＰｖ６ヘッダ１５０は、断片化情報を、メインヘッダ自体の中よりむしろ「ネクストヘッダ」フィールドを通して取り扱う。更に、ＩＰｖ６は、ＩＰｖ４において起こるようにどちらかというとデータグラムを断片にする対向する中継デバイスのように、送信元がデータグラムを断片化することを期待する。ＩＰｖ６ヘッダ１５０は以下のフィールドを備える：
・バージョン１５３：ＩＰプロトコルのバージョン。ＩＰｖ６は、６の値を用いる。
・トラフィッククラス１５５：異なるタイプのトラフィックを優先付けするために用いられる。
・フローラベル１５７：サービスの質を表す。
・ペイロード長１５９：メインヘッダを除き、如何なるネクストヘッダフィールドをも含む、データグラム内のデータの長さである。
・ネクストヘッダ１６１：ネクストヘッダの種類を表す値。これらの値は、明確である。ＩＥＴＦにより維持されているＲＦＣ１７００を参照のこと。
・ホップリミット１６３：データグラムが伝播を許されるホップの数。
・送信元アドレス１６５：データグラムの送信元のＩＰｖ６アドレス。
・宛先アドレス１６７：データグラムの宛先のＩＰｖ６アドレス。
【００２７】
これらのフィールドは、ＩＰｖ６ヘッダ１５０の必須の構成要素を備える。追加のヘッダが、ネクストヘッダ１６１に適切な値を設定することにより、許容されている。例えば、ネクストヘッダ１６１が６の値を有する場合、次のヘッダはＴＣＰヘッダあり、ネクストヘッダ１６１が１７の値を有している場合は、次のヘッダはＵＤＰヘッダあり、又はネクストヘッダ１６１が４４の値を有している場合は、次のヘッダはフラグメントヘッダである。フラグメントヘッダ１８０は、断片化に用いられる以下のフィールドを備える：
・ネクストヘッダ１７１：ネクストヘッダ１６１と同じ番号付け方式を用いてデータグラム内の次のヘッダを指し示す。
・フィールド１７３及び１７７：将来の利用のために保留。
・フラグメントオフセット１７５：現在のフラグメントのオフセット（オクテットでの８バイトインクリメント）。
・更なるフラグメント１７９：フラグメントが更に存在することを示すビット値。
・識別表示１７０：送信元及び宛先に関して、或るデータグラムを他と区別するために用いられる、３２ビットの識別子。
【００２８】
ＩＰｖ４に対するＲＦＣ７９１におけるように、ＲＦＣ２４６０は、識別表示１７０は、「同じ送信元アドレスと宛先アドレスを伴って最近送信された、任意の他のフラグメントパケットのものとは異なってなければならない」値を持つ必要がある、と述べている。ＲＦＣ２４６０は、それぞれのペアに対して複数のカウンタを用いることを提案してはいるが、データグラム識別子のために複数のフィールドを使用することについては提案又は動機付けしていない。識別表示１７０は、３２ビットの値を備えるが、ネットワーキング速度の増加につれて、ＩＰｖ４がより低い速度で起こる同じデータ破損問題を、ＩＰｖ６が起こるということが予想されている。例えば、最小の断片化されたＩＰｖ６データグラムを仮定すると、回線速度が１００Ｇｂｐｓの場合、結果として識別表示１７０のための２３２個の値のプールが、１８０秒未満で、すなわち約３分で消費されて、ネットワーク上のデータグラムのライフタイムに近づいてしまうということもなくはない。回線速度が１０００Ｇｂｐｓであれば、識別表示１７０に対する２３２個の値のプールは、１８秒未満で、すなわちデータグラムのライフタイム３０秒〜１２０秒のはるか下で、消費されてしまうこともあり得る。
【００２９】
記憶媒体から読み書きするために複数のブロックが単一のデータグラムの中に連結され得るのではあるが、ブロックレベルのネットワークストレージが通常５１２バイトブロックで動作するという理由で、先の例では５１２バイトのデータグラムが選択された。更に、ＩＰを、距離が小さく且つデータ転送速度の高い内部通信バスとして用いることが可能なことから、この熟考された通信速度は、非現実的なものではない。
【００３０】
（データグラム識別子）
好ましい一実施形態では、データグラム識別子は、単なるＩＰデータグラムヘッダフィールド内の識別表示フィールド（識別表示１１０及び１７０）というよりも、かなり広い概念を代表している。データグラム識別子は、データグラムのライフタイムの間、このデータグラムが、送信元及び宛先の間で一意的に特定されることを一緒になって可能とする、１つ以上の値を備える。データグラム識別子の「一意性」は、永遠である必要はない。言い換えれば、データグラムのライフタイムが過ぎた後に、データグラム識別子は後に送られる任意のデータグラムを識別するために再び用いることができる。
【００３１】
（複数フィールドデータグラム識別子）
データグラム識別子は、単一フィールド識別子又は複数フィールド識別子を含む。単一フィールド識別子とは、データグラムを識別するためにデータグラムに割り当てられ単一のフィールドに格納される、単一の値を有しているものである。単一フィールド識別子の例には、ＩＰｖ４ヘッダ内の１６ビットの識別表示１１０又はＩＰｖ６ヘッダ内の３２ビット識別表示１７０が含まれる。複数フィールドデータグラム識別子は、２つ以上のフィールドがデータグラム識別子を形成するために組み合わさる、識別子を表している。例えば、識別表示１１０は、データグラム識別子を形成するために、ヘッダ内の他のフィールド又は場合によりペイロードと組み合わされ得る。あるいは、データグラム識別子に対する単一の値が、データグラム内で複数回複製されることもあり得る。例えば、後の章で論じられように、単一のデータグラム識別子値が、ＩＰｖ４パケットのヘッダ内に識別表示１１０として格納されるということもあり得るし、またデータグラム自体のペイロード内で複写されることもあり得る。データグラムのライフタイムにわたってデータグラム識別子の「一意性」を増す、データグラム識別子ＧＵＩＤ、チェックサム、又は他の値の中で用いられることがあり得る他のフィールド。
【００３２】
（複数フィールドデータグラム識別子）：単一値
図２は、データグラム識別子の値が複写される、複数フィールドデータグラム識別子についての可能な実施形態を例示している。好ましい一実施形態では、データグラム識別子は、ＩＰヘッダの識別表示フィールドの中に置かれ、次にデータグラムのペイロードの中にも置かれる。データグラム２００は、ヘッダ２２０と、場合によりペイロード２３０とを有する典型的なＩＰデータグラムを表す。この実施形態では、データグラム識別子２１０が、ヘッダ２２０及びペイロード２３０内で複写されている。ＩＰｖ４データグラムに対しては、ヘッダ２２０内のデータグラム識別子２１０は、図１Ａからの識別表示１１０の中に、少なくとも部分的に格納される。ＩＰｖ６データグラムに対しては、ヘッダ２２０内のデータグラム識別子２１０は、図１Ｂからのフラグメントヘッダ内の識別表示１７０の中に、少なくとも部分的に格納される。データグラム識別子は、１６ビット、３２ビット、４８ビット、６４ビット、又はより大きいものを含む任意のサイズであり得るということが予期されている。
【００３３】
ペイロード２３０内にデータグラム識別子２１０を複写することにより、いくつかの利点がもたらされる。１つの利点は、ＩＰモジュールの内部機能を変更することが実行不可能なアプリケーションに関連している。ペイロード２３０の中へのデータグラム識別子２１０の配置は、データグラム識別子２１０を通してのアプリケーション制御を提供する。追加の利点には、標準データグラムヘッダ構造を必ずしも変更することなしに、データグラム破損問題を解決することが含まれる。以下にて、ペイロードの中にデータグラム識別子２１０を配置することが、どのようにデータグラム識別子の「一意性」に対して大きな統制を提供するかということを、更に明確にする。データグラム識別子の値は、要望に応じ、あるいは有用であれば、あるいは必要であれば、何回でも複写されるということもあり得る。
【００３４】
（複数フィールドデータグラム識別子）：多値
図３は、データグラム識別子が異なるフィールドの中に複数の値を備える、複数フィールドデータグラム識別子についての、可能な実施形態を例示している。データグラム３００は、ヘッダ３２０とペイロード３３０とを備える。本実施形態ではデータグラム３００は、データグラム識別子３１０Ａ〜３１０Ｄにより表されるように、２つ以上フィールドに分割されるデータグラム識別子を介して識別される。フィールドは、要望に応じて、ヘッダ３２０の間に又はペイロード３３０の間に広がる。この付加的なフィールドは、データグラム識別子の分解能を、プール内の可能なデータグラム識別子の数を増加することにより、拡張することを可能とする。
【００３５】
多値フィールドの好ましい一実施形態は、ＩＰデータグラムのヘッダ内のオプションフィールド内に配置される。オプションヘッダフィールドを利用することで、これらのフィールドが随意的であることから、既存のＩＰモジュールへの変更については最小限の影響しか与えない。修正されたＩＰモジュールが、レガシーＩＰモジュールとの間で、オプションヘッダフィールドを有するデータグラムを交換する場合、レガシーＩＰモジュールは、如何なる未知のオプションも無視するはずであり、これにより結果的にレガシーな挙動をもたらす。修正されたＩＰモジュールが、オプションヘッダフィールドを理解している他の修正されたＩＰモジュールとの間でデータグラムを交換する場合は、より高い分解能のデータグラム識別子がデータグラム破損問題を解決する。
【００３６】
（複数フィールドデータグラム識別子）：多値ＩＰｖ４データグラム識別子
図４Ａは、データグラム識別子がＩＰオプションを備えるＩＰｖ４に対する、複数フィールドデータグラム識別子の可能な実施形態を例示している。ＩＰｖ４ヘッダオプション構造は、ＲＦＣ７９１の中に定義されている。オプション４００は、タイプ４０１、長さ４０７、及びオプションデータ４０９を含む、３つのフィールドを備える。長さ４０７は、タイプ４０１、長さ４０７、オプションデータ４０９を含む、オプション内のバイトの総数を表している。オプションデータ４０９は、オプションに関連した情報を含み、情報のゼロ以上のバイトを備えることができる。タイプ４０１は、更に３つのフィールドに分割され、これらも同様にＲＦＣ７９１の中に定義されている。コピー４０２は、オプション４０１がデータグラムの全てのフラグメントの中にコピーされているかどうかを、示している。クラス４０３は、オプション４００が制御用であるのか（値０ｘ０）、又は測定用（値０ｘ３）であるのかを示す。番号４０４は、オプションが実際に表しているものを示す、０〜３２の範囲の値を表している。Ｔｈｅ  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ａｓｓｉｇｎｅｄ  Ｎｕｍｂｅｒ  Ａｓｓｏｃｉａｔｉｏｎ（ＩＡＮＡ）が、これらの値を割り当てする。この文書の作成の時点では、値０〜２１及び２３〜２４が割り当てられている（ｈｔｔｐ：／／ｗｗｗ．ｉａｎａ．ｏｒｇ／ａｓｓｉｇｎｍｅｎｔｓ／ｉｐ−ｐａｒａｍｅｔｅｒｓ  更新日２００５年１０月１８日  参照）。
【００３７】
好ましい一実施形態では、追加のデータグラムヘッダオプションが、ＩＰｖ４ヘッダ４２０の中に例示されるように、拡張されたデータグラム識別子を定義する。ヘッダ長４０５は、５を超える値を有し、ヘッダ内に最低値の５を超える追加の３２ビットワードが存在することを示す。例えば、１つ以上のデータグラムフラグメント識別オプションが、オプション４３０Ｂ及び４３０Ｃとして示されるように、ＩＰｖ４ヘッダ４２０に付加され得る。識別表示４１０Ａは、データグラム識別子の少なくとも一部を格納する。また、識別表示４１０Ｂ及び４１０Ｃは、データグラム識別子の分解能を拡張した。タイプ４０１Ｂ又は４０１Ｃは、オプションが、拡張されたデータグラムフラグメント識別オプションであることを示す、０ｘ１Ａ（コピー＝０ｘ０、クラス＝０ｘ０、番号＝２６（０ｘ１Ａ））の値を有する可能性があるということが、予期されている。長さ４０７Ｂ又は４０７Ｃは、全オプションサイズが４バイトであることを示す、４の値を有することもあり得る。本実施形態では、識別表示４１０Ｂ又は４１０Ｃは、データグラム識別子に追加の１６ビットを提供する。更に分解能が必要な場合は、追加のオプションが付加され得る。例としての実施形態は、識別表示４１０Ａ、４１０Ｂ、及び４１０Ｃを備える、４８ビットを有するデータグラム識別子を例示している。この例は、利用可能なデータグラム識別子のプールを拡張するための一実施形態を示しているが、当業者は、利用可能な識別子のプールを増加する他の可能なインプリメンテーションが、同様に存在することを理解する。例えば、全てのオプション情報を繰り返すよりもむしろ、単一のオプションの長さが、後に続く３２ビットワードからのバイトを含むために増加されるということもあり得、従って、長さフィールドが８バイトの値を持ち、内２バイトはヘッダの識別表示フィールドから、また６バイトがデータグラムフラグメント識別オプションフィールドからであり得る。結果として、オプションは最大４８ビットまでの付加的な分解能を備えて、６４ビットのデータグラム識別子を作り出す。オプション長の値を変更することにより、データグラム識別子の分解能は一度に８ビット増加され得る。
【００３８】
（複数フィールドデータグラム識別子）：多値ＩＰｖ６データグラム識別子
図４Ｂは、データグラム識別子が、複数のフラグメントヘッダオプションを用いてＩＰｖ６ヘッダ内に複数のフィールドを備える、ＩＰｖ６のための複数フィールドデータグラム識別子の、可能な実施形態を示している。ＩＰｖ６ヘッダ４５０は、標準フィールドと、フラグメントヘッダ４８０Ａ及び４８０Ｂにより示される２つ以上のフラグメントヘッダとを含んでいる。ネクストヘッダ４６１は、次のヘッダがフラグメントヘッダであることを示す値４４を格納する。フラグメントヘッダ４８０Ａは、次のヘッダが同様にフラグメントヘッダであるということを示す、ネクストヘッダ４７１Ａを含んでいる。ゼロ以上のフラグメントヘッダが全体のデータグラムの中に含まれ得る。この例としての実施形態では、フラグメントヘッダ４８０Ｂは、ネクストヘッダ４７１Ｂの中に格納された６の値を介して、次のヘッダはＴＣＰであることを示している。このデータグラムに対するデータグラム識別子は、識別表示４７０Ａ及び４７０Ｂにより示される２つ以上の識別表示フィールドを備える。複数のフラグメントヘッダを含むことにより、ＩＰｖ６データグラムが、３２ビットに急拡張されたデータグラム識別子を持つようにする。ＩＰｖ６フラグメントヘッダに対する変更は、ＩＰｖ６モジュールがネットワーク上の状態が変化したときに、要望に応じてフラグメントヘッダを変更することを可能とする上でより有益である、ということが予期されている。複数のフラグメントヘッダの使用は、プール内の可能なデータグラム識別子の数を増加することを可能とし、結果として、プールのサイズは、データグラムのライフタイム内で全てのデータグラム識別子を消費するシステムの能力を超過する。
【００３９】
多値のデータグラム識別子を利用する好ましい実施形態は、既存のヘッダ識別表示フィールドを、データグラム識別子の最下位ビット群（ＬＳＢ）として用いる。既存のフィールドの中にＬＳＢを配置することにより、レガシーＩＰモジュールとの間で相互運用性が維持され得る。新規のオプションヘッダフィールドが、識別表示フィールドの役割を引き継ぐように定義されることもあり得る、ということも同様に予期されている。その結果、データグラム識別子は、単一フィールド識別子として新規のオプションフィールドの中にのみ格納される。
【００４０】
先の実施形態は、データグラムに割り当てることができる利用可能なデータグラム識別子の数を増加することを通して、データグラム識別子のプールを準備することを含む、データグラム破損に対する解決策を提供する。このようにデータグラム識別子を管理することが、データグラム破損問題を解決する。好ましい実施形態では、このようなアプローチは、アプリケーションに影響を与えずにネットワーク通信スタックのＩＰレイヤに、有益に適用することができる。しかしながら、アップデートの必要がある非常に多く（ｓｈｅｅｒ）の数のＩＰモジュールがフィールドに展開しているために、この解決策が展開されるのは実行不可能であり得る。Ｗｉｎｄｏｗｓ（登録商標）又はＬｉｎｕｘ（登録商標）を含む通信スタックが、ある程度迅速にアップデートされることもあり得るということが予期されているが、ルータ、ゲートウエイ、プリンタ、又は他のレガシースタックを有するデバイスを含む、レガシースタックを有して残存する何百万というデバイスが存在する。この場合、単一値を有する複数のフィールドデータグラム識別子を含むアプリケーションレベルのアプローチが、デバイス製造業者により行われ得る。削減された利用可能データグラム識別子数を有するデータグラム識別子のプールが作り出され、データグラム識別子がデータグラムのライフタイムの間管理される。
【００４１】
（削減されたデータグラム識別子プール）
よりアプリケーション志向の解決策が有用な場合、データグラム識別子は、好ましくは、どのデータグラム識別子が使用を許可されているかに関する２つのホスト間の合意を通して、管理される。好ましい一実施形態では、第１のホストが、任意の使用中のデータグラム識別子が、このデータグラム識別子が割り当てられているデータグラムのライフタイムの間は再び使用されないことを確実することにより、データグラム識別子のプールを作成又は管理する。プールは、一部の識別子が現在使用中の恐れがあることから、削減された数の利用可能データグラム識別子を有している。第１のホストは、プールから抽出された提案データグラム識別子を第２のホストに送信する。第２のホストは、提案データグラム識別子を、第１のホストに送り返す応答データグラムの中で使用する。第２のホストは、提案データグラム識別子を、応答データグラムのヘッダの中及びペイロードの中に符号化する。第１のホストは、応答データグラムを正常に受信する。一旦、データグラムが再構築されると、第１のホストは、応答データグラムのペイロードからの提案データグラム識別子を読み取り、これを再利用するためにプールの中に配置戻しをする。
【００４２】
（削減されたデータグラム識別子プール）：許可及び除外データグラム識別子のリスト
図５は、データグラム識別子のメモリ格納リストの実施形態を例示している。メモリ５４０は、削減された数の利用可能データグラム識別子を有するデータグラム識別子のプールを作成又は管理するホストに付随している。許可リスト５３０は、データグラムへの割り当てが認められたデータグラム識別子のリストである。許可リスト５３０は、ＩＤ５３５Ａ〜５３５Ｎにより示される、０個以上のデータグラム識別子を備える。リスト内の各エレメントは、実際の識別子又は識別子への間接的な参照を備えるということもあり得る。好ましくは、リストは、異なるライフタイムを有するという相違に起因して識別子の順番が変わることもあり得ることから、リンクされたリストとして実装される。更に、より好ましいリストは、最も古い識別子群が、リストの先頭近辺にあり、最も最近使用された識別子群が、リストの後部にあるような方式で順序付けされる。配列リスト５３０はこのような方法で、リストから識別子を割り当てられたデータグラムが、使用中でない識別子又は前に使用されたデータグラム識別子のライフタイムを超過した識別子を有することを確実にする。
【００４３】
好ましい一実施形態におけるインフライトリスト５５０は、現在使用されている識別子を表しており、従って、使用されることから除外される識別子を表している。その意味で、インフライトリスト５５０は、除外リストを備える。好ましい一実施形態では、インフライトリスト５５０は、識別子５５５Ａ〜５５５Ｍにより表されるように、タイムアウトにより順番付けされる０個以上の識別子を備える。最初にタイムアウトすると予期される識別子群は、最も最近展開されてリストの後部に置かれる識別子群よりも、リストの先頭のより近くにある。許可リスト５３０と同様に、インフライトリスト５５０は、リンクされたリストを通して実装され得る。
【００４４】
一実施形態では、データグラム識別子が要求された場合、識別子は許可リスト５３０の先頭から引き出され、識別子５３５Ａにより示されるようにインフライトリスト５５０の後部に配置される。一旦許可リスト５３０から削除されると、データグラム識別子は、割り当てられたデータグラムのライフタイムが超過するまで、再度このリストに載ることを規制される。好ましい一実施形態では、インフライトリスト５５０内の識別子が、除去されて、許可リスト５３０に再配置され得る条件が２つある。第１の条件は、識別子が割り当てられたデータグラムが、受信されて正しく再構築されたということである。再構築するとすぐに、データグラムのペイロードが識別子に関してチェックされて、この識別子はインフライトリスト５５０から除去され、且つ識別子５５５Ｂにより示されるように許可リスト５３０の後部に配置される。第２の条件は、データグラムのライフタイムが超過したということである。このような条件の下では、識別子はリスト５５５Ａから除去されて、識別子５５５Ａにより示されるように、許可リスト５３０の後部に配置される。インフライトリスト５５０を管理するために用いられるデータグラムライフタイムは、多くの方法で決定することができるが、とにかくＩＰモジュール内の再構築時間よりも大きいのが好ましい。
【００４５】
例えば、ＩＰｖ４をＩＰを通してのデータグラムの輸送手段として用いる、一実施形態を考えてみる。最初に、許可リスト５３０は、上述のようにＩＰｖ４ヘッダがたった１６ビットの識別表示フィールドをサポートすることから、最大６５，５３５個のデータグラム識別子を備える。データグラム識別子が使用されるにつれ、リストはシャッフルされる。しかしながら、識別子がデータグラムのライフタイムの間存続する限り識別子の値は重要ではないので、これは問題ない。充分なメモリを有するコンピュータワークステーションにとっては、６５，５３５の識別子を格納することは問題ではない。これらの技術を使用することを通して、ホストが、データグラムに割り当てられることを許可された、削減された数の利用可能データグラム識別子を有する、データグラム識別子プールを生成し、その結果データ破損問題を解決する。結果としてのプールは、実際に利用可能なデータグラム識別子の数が異なり、且つ識別子が管理されているということから、最初の利用可能なデータグラム識別子のプールとは異なる。
【００４６】
ワークステーションは通常、リンクされたリスト内の６５，５３５個の識別子を格納するために十分なメモリを有しているけれども、他のシステムはこのような贅沢さは持ち合わせていない。組み込みデバイスは、より少ないメモリしか有しておらず、メモリを節約するためにコンパクトに収める技術を利用するべきである。一部の実施形態は、必要あれば拡張できる、削減された識別子のセットを用いる。例えば、６５，５３５識別子の全てを管理するよりむしろ、デバイスは１から１０２４までの番号を付けられた１０２４個の識別子のみを使う可能性がある。このプールが不十分ならば、１から２０４８の識別子を利用可能にすることにより拡張し、又は、転送速度が下がった場合は、必要に応じ縮減され得る。このような方式でより小さいリストを管理すること又は利用可能な識別子を再利用することは、利用可能な２３２データグラム識別子全てを格納することが現実的でないということもあり得るＩＰｖ６インプリメンテーションに対して利益をもたらす。
【００４７】
削減されたプールが、更なる特徴を有することもあり得るということが予期されている。例えば、第１のホストに１つのデータグラム識別子を第２のホストに提案させることにより、結果としての利用可能なデータグラム識別子の数は事実上１つである、ということに留意すべきである。加えて、殆どのデバイスは、これらに関連する１つ以上のトラフィックのタイプを有している。従って、許可データグラム識別子のリストを、例えば、最上位ビット（ＭＳＢ）のセットを伴う識別子にリストを制限するなどの、特定のビットパターンを有するもののみに縮減できる可能性がある。ＬＳＢのみを使用する識別子は、通常のトラフィックのために使用されるということもあり得る。識別子のブロックが、同様に、第２のホストに提案されて、複数の利用可能なデータグラム識別子を表すということに留意すべきである。
【００４８】
例としての一実施形態を更に例示すると、ＩＰｖ４においては識別表示フィールドは１６ビットである。許可リスト５３０は、４９，１５２（２１６−２１４）個の利用可能な識別子のプールを生成する、２つの最上位ビットを有する識別子のみを備え、１６，３８４（２１４）個の識別子を他のトラフィックのために非管理及び利用可能にするために残しておく、ということもあり得る。好ましくは、プールは、例えば２Ｍ−２Ｎ（ここで、Ｍは識別表示フィールドのビットサイズ、Ｎは３２未満の整数値）などの２の累乗の関数である、利用可能なデータグラム識別子の削減された数を有する。ＮがＭに近づくにつれ、利用可能な数は小さな数、１、又は０にさえ減ることもあり得る。
【００４９】
メモリ５４０は、コンピュータシステムに付随するメモリを表している。好ましい一実施形態では、クライアントとして動作するコンピュータ又はデバイスは、メモリ５４０を備え、リストをリモートデバイスをアクセスするために用いる。例としてのリモートデバイスは、ネットワークストレージデバイス、プリンタ、ファックス、スキャナ、又はＩＰを通信のために用いる他のデバイスを含む。メモリ５４０の実施形態には、ＲＡＭ、フラッシュ、ディスクドライブ、又はネットワーク上のコンピュータデバイスによりアクセス可能な他のデータ記憶メモリが含まれている。
【００５０】
（削減されたデータグラム識別子プール）：識別子を管理する方法の例
図６は、利用可能なデータグラム識別子の削減された数を有する、データグラム識別子のプールから引き出されるデータグラム識別子を管理する方法の例としての実施形態を示している。図６の例は、単一値を有する複数フィールドデータグラム識別子とともに先に説明されたリストを用いている。この例においては、ホストＡが、通信リンクを通して同様にアクセスされ得るホストＢへのアクセスを望む、通信リンク上のデバイスを表している。通信リンクは、データグラムをホストＡからホストＢに運ぶために（逆も同様）、必要あれば断片化をサポートするやりかたでＩＰを利用する。例えば、ホストＡは、クライアントコンピュータを表し、またホストＢはネットワークストレージサーバを表すこともあり得る。一部の実施形態では、クライアントはＵＤＰデータグラムをストレージサーバ上のデータにアクセスするために用いる。
【００５１】
ステップ６０５で、ホストＡは、データグラムを利用してホストＢとメッセージを交換することを望む。この例では、ホストＡは、自分の要求に対する応答を期待している。結果として、ホストＡは、使用することができるデータグラムを表すデータグラム識別子の許可リストから、１つのデータグラム識別子を引き出す。この識別子は、これが割り当てられたデータグラムのライフタイムの間に再度使用されることがないように、インフライトリストの中に置かれる。一方、ステップ６５０で、ホストＢは、ホストＡからのメッセージを待つ。
【００５２】
ステップ６１０では、ホストＡは、ホストＢに対するメッセージを準備する。好ましくは、メッセージは、ホストＢがホストＡのメッセージに応答することを含む、あるアクションを取ることについての要求を備える。ホストＡは、ホストＢへのメッセージの中に識別子を配置する。識別子はデータグラムのペイロードの中に配置される、ということが意図されている。この実施形態の例では、識別子はホストＡのデータグラムには割り当てられず、むしろホストＢの応答を備えるデータグラム用の提案であるということに留意すべきである。
【００５３】
ステップ６１５で、ホストＡは通信リンクを通してホストＢにメッセージを送信する。例えば、ホストＡは、ＢＳＤソケットのｓｅｎｄ（）呼び出しを、ＩＰネットワークを通してメッセージを送信するために呼び出す。ステップ６５５で、ホストＢはホストＡからのデータグラムを受信する。好ましくは、ホストＡからのメッセージは断片化されないほどに十分小さい。例えば、ＩＰｖ４に対してデータグラム全体のサイズが５７６バイト未満の場合、データグラムは断片化されないはずである。ホストＡはホストＢからの応答を期待し、従って、ステップ６２０でホストＡは応答を待つ。ネットワークアプリケーションの当業者は、このシナリオがクライアント−サーバ交換に類似しているということを認識する。
【００５４】
ステップ６６０で、ホストＢは、ホストＡのメッセージへの応答を形成する。このステップの間、ホストＢはホストＡのメッセージを読み、すなわちメッセージのデータグラムを確認して提案された識別子を探す。一部の実施形態では、識別子はメッセージの要求コマンドとともに符号化され、従って、これら２つは容易に発見及び関連付けされ得る。一部の実施形態では、データグラム識別子は、トランザクションＩＤとしても用いられ得る。ステップ６６５では、ホストＢは、識別子を、自分の応答メッセージを備えるデータグラムに対するデータグラム識別子として用いる。ＩＰｖ４の場合、ホストＢは、識別子をＩＰｖ４ヘッダの識別表示フィールドの中に配置し、ＩＰｖ６の場合、ホストＢは、識別子をフラグメントヘッダの識別表示フィールドの中に配置する。加えて、ホストＢは、識別子をデータグラムのペイロードの中に符号化する。洞察力のある読者は、この実施形態においては、ホストＢは、上記のようなデータグラム識別子操作を実行できるように適合されたＩＰモジュールを、有するということに気付く。
【００５５】
ステップ６７０で、ホストＢは、応答メッセージを備えるデータグラムをホストＡに送り返す。ホストＡはデータグラムをステップ６２５で受信する。この時点で、データグラムは、断片化されることも有り得、またある期間にわたって到達し得る。ホストＡは、応答メッセージを含むデータグラムを、識別子の関数として再構築することを試みる。ホストＡが識別子の使用を管理するこの状況では、データグラム破損の危険はない。更に、データグラムが通常のデータグラムとして現れることから、ホストＡは、ホストＡのＩＰモジュールへの変更を要求することなく、ＩＰレイヤで正常に動作する。
【００５６】
好ましい一実施形態では、受信したホストＢからの応答データグラムに関連して考える、２つの状況がある。すなわち、データグラムが適切に再構築されたのか、又はデータグラムが再構築されなかったのか、ということである。データグラムは、１つ以上のフラグメントが失われた可能性があるので、再構築されない可能性がある。データグラムが適切に再構築される場合は、ホストＡは応答を処理することができる。ホストＡが応答を処理する際に、ホストＡは、応答データグラムのペイロードの中に符号化されたデータグラム識別子を読み取る。ホストＡは今、データグラムが安全に到着したことから及びデータグラムのライフタイムが超過したことから、識別子が再利用され得るということを認識し、結果として、ステップ６３０において、ホストＡは、識別子をインフライトリストから削除して、これを許可リストの後部に配置する。データグラムが、フラグメントの喪失により適切に再構築されない場合は、データグラムは、タイムアウトが発生するまで（典型的には、約３０〜１２０秒であり、この後データグラムは廃棄される）、通信スタック（おそらくホストＡのＩＰモジュールの中の）の中に格納される。この時点で、ホストＡはまだ、廃棄されたデータグラムのために識別子を処理しなければならない。好ましくは、ホストＡは、インフライトのデータグラム識別子に関連するタイムアウトを有している。タイムアウトが超過してデータグラムのライフタイムが超過したことを示すと、ホストＡは、インフライトリストから識別子を除去し、これを許可リストの後部に配置する。
【００５７】
識別子のインフライトリストタイムアウトは、データグラムを再構築することに付随するタイムアウト、おそらく３００秒程度よりも長いことが望ましい。特に、好ましい実施形態は、インフライトリストのタイムアウトを通信リンクの状態と結びつける。一部の状態は、ラウンドトリップタイム、スループット、輻輳、エラーレート、又は他の測定可能な状態を含む、測定された値を有している。他の状態は、必ずしも測定されないが、方針に従って設定され得る。例えば、タイムアウトは、管理者により、ネットワークの速度に基づいて構成され得る。
【００５８】
読者は、データグラム識別子が関連するデータグラムのライフタイムの間は再度使用されないことを確実にするための、前述のアプローチが有する利点に留意すべきである。１台のホストが、ホスト上の既存の通信スタックを変更する必要なく識別子リストを管理するために、アプリケーションレベルのコードを用いる。これは、ＩＰモジュールに変更を入れるのが実行不可能な、Ｗｉｎｄｏｗｓ（登録商標）やＬｉｎｕｘ（登録商標）を含む確立したオペレーティングシステム上で動かすソフトウェアアプリケーションを有するインプリメンテーションに対して、好都合である。たいていのアプリケーションデベロッパーは、通信スタック内部へのアクセスはできない。また、このアプローチは、自分のデバイスの通信スタックのソースコードを入手できる組み込みデバイスのベンダにとって、好都合である。ベンダは、デバイスのＩＰモジュールを、上述のように動作するように変更することができる。例えば、ネットワークストレージ製品を生産する会社は、彼らの製品を上述の特性を有するように変更することができる。更に、識別子情報をメッセージ内に符号化することにより、データグラム識別子の一意的な性質を確立するために追加のメッセージの必要はない。加えて、説明されたアプローチは、データグラム識別子がデータグラムのライフタイムの間一意的であることが要求される、ＩＰ標準の遵守を確実にする。
【００５９】
特に、好ましい実施形態は、ストレージプロトコルを含むコマンド応答プロトコルに対して、上述の技術を採用する。ストレージプロトコルは、Ｚｅｔｅｒａ社のＺ−ＳＡＮ（登録商標）プロトコルを含む独自仕様のプロトコル、又は標準プロトコルを含む。標準ストレージプロトコルには、ｉＳＣＳＩ、ＦＣＩＰ、又はｉＦＣＰを含む。この技術は、ＵＤＰ又はＴＣＰをトランスポート層として用いるプロトコルに、適用することができる。例えば、ｉＳＣＳＩインプリメンテーションは、提案データグラム識別子を交換して、ＴＣＰデータグラムが、ｉＳＣＳＩ標準への準拠を維持しつつ、データグラム破損を被らないことを確実にするように、変更されることもあり得る。
【００６０】
（データグラム識別子のプールの提供）
図７は、データグラム識別子のプールを生成してデータグラム破損が起こらないことを確実にする方法の、例としての実施形態を例示している。この提示される例は、先に提示された多くの概念を用いている。
【００６１】
ステップ７００において、第１のデータグラム識別子のプールが確立される。好ましい一実施形態では、第１のプールは、ＩＰの標準機能に従った動作に応答して利用可能なプールを表している。ＩＰｖ４では、第１のプールは、ＩＰｖ４ヘッダの１６ビット識別表示フィールドによって使用できる、２１６個の識別子を備える。ＩＰｖ６では、第１のプールは、利用可能な２３２個の識別子を備える。いずれのケースでも、通常第１のプールは、インクリメントカウンタにより提供される。標準に逆らって、これらのプールは、データグラムが十分に速い通信リンク上で展開される場合、関連するデータグラムのライフタイムを通して一意的な識別子を提供はしない。より強い一意的特性を有する利用可能なデータグラム識別子を提供する第２のプールが、問題を解決する。
【００６２】
レガシーＩＰモジュールへの下位互換性を維持するために、好ましい一実施形態では、第２のデータグラム識別子のプールが有用かどうかを判断する閾値関数を備える。一実施形態では、閾値関数は、第１のホストと第２のホスト間の通信リンクを通しての通信の状態を監視して、データグラム識別子が管理されるべきかどうかを判断する。好ましい一実施形態では、データグラムのライフタイムに関連する関数を用いて、ライフタイムをデータグラム識別子の利用に、より密接に結びつける。
【００６３】
好ましい閾値関数実施形態は、タイムアウト期間、又はデータグラムが通信リンクを介して転送される速度に応じて動作する。特に好ましい実施形態は、タイムアウト期間と速度の両方を用いる。例えば、閾値関数は、特定のデータ転送速度に対し、データグラム識別表示フィールドにおいて終了条件が生起した可能性があるかどうかを計算することを含むこともあり得る。データグラムの転送速度とデータグラム再構築タイムアウトとを掛けた数が、利用可能なデータグラム識別子の数を超過する場合、識別表示フィールド内の終了がデータグラム破損に帰着することもあり得る。このような条件下では、閾値関数は、第２のデータグラム識別子プールが有益であるということを示す。閾値関数は、輻輳を含む、速度やタイムアウト期間以外の他の値に応じて動作することもあり得るということが予期されている。従って、全ての閾値関数が予期されている。同様に、第２のプールは、レガシーＩＰモジュールに適合するために、必要に応じてオン／オフを切り替えられ得る、ということも予期されている。例えば、レガシーＩＰモジュールとともに動作するときは、ＣＰＵサイクルが浪費されないように、第２のプールを使用しないことが有益であり得る。
【００６４】
加えて、閾値関数の中で用いられる値は、測定又は予め定めることができる。測定される値は、システムが動作するときに、リアルタイムで又は時間をかけて取得することができる。例えば、速度は、２つのホスト間のメッセージのラウンドトリップタイムを計算することにより測定されることもあり得るし、又は速度は、通信リンク全体にわたって測定されることもあり得る。既定の値には、ネットワーク帯域幅（例えば、イーサネット（登録商標）に対しては１Ｇｂｐｓ又は１０Ｇｂｐｓ）が含まれる。
【００６５】
ステップ７０５では、第２のデータグラムプールの使用に関する決定がなされる。第２のプールが有益でない場合は、ステップ７９０でデータグラム識別子が第１のデータグラム識別子プールから引き出され、処理は従来の方式で続く。閾値関数により示されるように第２のプールが有益である場合は、第２のプールがインスタンス化され得る。
【００６６】
ステップ７１０では、第２のデータグラム識別子プールが生成される。第２の識別子のプールを提供するということは、第２のプールのデータグラム識別子が、第１のデータグラム識別子プールと比較して、これらがデータグラムのライフタイムに対して一意的であることを確実にする方式で管理される１組の条件を確立するということを、表している。従って、第２のプールは、利用可能なデータグラム識別子の数が異なるか、又はデータグラム識別子に対する規制がより大きいという理由で、第１のプールとは異なる。第２のプールを提供するということには、ＩＰモジュールをランタイムの前に変更すること、又はＩＰ層の動きをランタイム時に若しくはランタイム中に改変するという、自明の事柄（ａ  ｐｒｉｏｒｉ）を含んでいる。第２のプールを創造するということは、更に、データグラム破損問題を起こす限られた第１のプール内での利用可能な供給量を克服するような態様で、利用可能なデータグラム識別子の数を増加することを含んでいる。利用可能なデータグラム識別子の数の増加は、上述のように、拡張されたデータグラム識別子情報を備える付加的なヘッダオプションの使用を通して、実現され得る。第２のプールの創造は同様に、データグラムに対する利用可能なデータグラム識別子の数を低減することを含む。数を低減することは、許可データグラム識別子のリストを維持すること、又は単一のデータグラム識別子若しくは識別子のブロックを提案することを含んでいる。利用可能なデータグラム識別子の数の増加又は数の低減のいずれの場合も、データグラム識別子は、データグラムのライフタイム内でデータグラム破損問題を起こす値を取ることを規制される。さまざまな理由で、１つを超える第２のプールが創造されてもよい。複数の第２のプールは、各ホストペアに対して、プロトコル指定に対して（ＴＣＰ、ＵＤＰ、ＩＣＭＰ、ＩＧＭＰ等）、又は各転送プロトコルポートに対してさえ、１つのプールを確立することを可能とする。例えば、ポート８０上の全てのＨＴＴＰトラフィックがあるプールを有し、一方ポート２１上のＦＴＰトラフィックが異なるプールを有することもあり得る。１つを超える第２のプールを持つことは更に、ＩＰ標準により要求されるように、データグラム識別子が一意的であるということを確実にする。
【００６７】
一旦、データグラム識別子の第２のプールが確立されると、ステップ７２０で、データグラム識別子が第２のプールから引き出される。データグラム識別子を引き出すことには、リスト内の次の識別子を用いること、又は使用するデータグラム識別子の提案を受信することが含まれる。リストを用いる場合には、識別子は識別子の許可リストから取られ、又は大きなプールを有している場合には、識別子はレガシーＩＰモジュールにおいてなされるのと同様のカウンタをインクリメントすることにより生成される。
【００６８】
ステップ７３０で、データグラム識別子は再使用を規制される。好ましい実施形態では、これら識別子は、第２のプールが十分な数の利用可能データグラム識別子を有して、ある識別子がデータグラムライフタイムに付随する定義されたタイムアウト期間内で使用され得ないようにすることを確実にすることにより、データグラムのライフタイムの間に再使用されることを規制される。他の好ましい実施形態では、データグラム識別子は、どの識別子が第２のプールから使用されているのかを追跡することにより、管理される。
【００６９】
ステップ７４０で、データグラム識別子はデータグラムに割り当てられる。好ましい実施形態では、割り当ては、ＩＰヘッダの識別表示フィールドの中にデータグラム識別子の少なくとも一部を配置することを含む。他の実施形態では、識別子の一部がオプションヘッダフィールドの中に配置される。更なる他の実施形態では、識別子の一部がデータグラムのペイロードの中に配置される。一旦データグラムが形成され、データグラム識別子がデータグラムの中に配置されると、データグラムはステップ７５０でリモートホストに送信される。ネットワークアプリケーションの当業者は、データグラムの送信は、ＩＣＭＰ、ＩＧＭＰ、ＵＤＰ、ＴＣＰの利用や、ＩＰ層上での生のデータグラムの構築、又はデータグラムを形成する任意の他のタイプのプロトコルを含む、多様な方法で実現され得る、ということを認識する。
【００７０】
ステップ７５５では、データグラムが受信されたかどうかを調べるためのチェックがなされる。データグラムの送信から受信までの任意の時点で、データグラムは断片化されることもあり得る。ＩＰｖ４ネットワークにおいては、断片化は、ルータを含む中継デバイスによりネットワーク上で起こることもあり得る。ＩＰｖ６では、データグラムの送信元が、データグラムを断片化していることもあり得る。１つ以上のデータグラムのフラグメントが受信された場合、データグラムは、ステップ７６０で、データグラム識別子又は再構築中にデータグラムフラグメントを識別するために役立つ他の情報を用いて、再構築される。他の役立つ情報には、ＩＰアドレス、プロトコル番号、ポート割り当て、又は他のデータグラム情報が含まれる。ステップ７６５では、データグラムが完全に再構築されたかどうかを調べるためのチェックがなされる。
【００７１】
データグラムのフラグメントがまだ何も到着していない場合は、ステップ７７５で、データグラムのライフタイムに関して決定がなされる。一部の実施形態では、チェックは、ホストが応答メッセージを待つアプリケーション層でなされる。データグラムのライフタイムが超過していない場合は、システムは、ステップ７５５に戻ることにより、データグラムを待ち続ける。データグラムを待つことは、データグラムが完全に再構築されるか、又はライフタイムが超過したかのいずれかまで続行する。
【００７２】
システム７８５で、データグラムに付随する識別子が管理されているかどうかを判断するチェックが実行される。好ましい実施形態では、データグラムのペイロードがこの識別子を備えるか、又はオプションヘッダフィールドが用いられている場合は、データグラム識別子は管理されている。そうでなければ、データグラムはレガシーＩＰモジュールが処理するように、普通に処理される。さもなければ、データグラム識別子は、ステップ７８０で再利用され得る。一部の実施形態では、識別子は、インフライトリストすなわち除外リストから許可リストへと移動される。他の実施形態では、第２のプールは十分に大きく、大きなカウンタに基づくデータグラム識別子は終了せず、識別子がデータグラムのライフタイムが超過した後に再使用されることを可能とする。
【００７３】
開示された技術の採用は、データグラム破損問題を解決する際に、多くの利点をもたらす。一実施形態では、この解決手法は、アプリケーション層のはるか下のＩＰ層で動作する。ＩＰ層での解決手法は、アプリケーションが正常に動作するために修正される必要がないということを確実にする。加えて、オプションＩＰヘッダフィールドを用いることにより、レガシーＩＰモジュールを動かすより古いデバイスに対して、最小のインパクトしかない。レガシーＩＰモジュールは、なじみのないオプションヘッダを無視することにより、正常に動作するはずである。また、複数のオプションヘッダを使用することにより、又は拡張された情報を有するオプションヘッダを生成することを通じて、システムは将来も保証される。データ転送速度が増加して利用可能なデータグラム識別子のプールが不十分になった場合、データグラム識別子は、有用であれば、１つ以上のオプションデータグラム識別子フィールドを追加することにより、拡張され得る。ＩＰヘッダ識別表示フィールドの中へのデータグラム識別子のＬＳＢ部分の配置は、レガシーな動作への下位互換性と、これへのフォールバック位置を確実にする。識別子衝突を解決するためのチェックサムの使用は、データグラム破損問題が解決されることから、もはや必要なく、結果として、ＮＦＳと同様のアプリケーションが、スループットを低下させることに帰着することもあり得るＣＰＵサイクル消費を、する必要はない。
【００７４】
１組のホストのＩＰモジュールを変更することが実行不可能な場合は、ネットワークアプリケーションやデバイスを開発するベンダが、同様に開示された技術を用いることができる。利用可能な又はインフライトのデータグラム識別子を管理するということは、データグラム識別子が、場合によってはデータ破損に帰着することもあり得る条件下で再利用されることが規制されることを確実にする。ベンダは、データグラムを保護するために自らの製品に対するＩＰモジュールを変更し、且つ、データグラム識別子を管理するこの製品にアクセスする対応ソフトウェアモジュールを、システム上で有することができる。ネットワークデバイスに対する例としてのソフトウェアモジュールには、デバイスドライバを含む。
【００７５】
データグラムのライフタイムをより密接にデータグラム識別子に結びつけるということは、識別子の一意性に対するより大きな規制となる。結果として、デベロッパーは、既存の標準への適合性及び更なるデータグラム破損問題への将来保証を確実にすることができる。
【００７６】
ネットワークプロトコルの当業者は、本発明の主題の範囲に含まれる更なる概念があることを理解する。概念には、以下の項目を含むが、これらに限定されるものではない。
【００７７】
ＩＣＭＰは、ＩＰ通信問題に対処するために設計された管理メカニズムを提供する。ＩＣＭＰモジュールはまた、付加的なＩＣＭＰメッセージを通じて、又は先行して定義されたＩＣＭＰメッセージを拡張することを通じて、データグラム破損問題を解決することに役立つために、修正されることもあり得る。
【００７８】
開示された方法は、トランザクション志向のプロトコルに対して功を奏する。加えて、この方法は同様に、ＴＣＰを含むストリーミングプロトコルに対して役立つ。
【００７９】
開示された方法は、２つの通信ホストが共にこの方法を用いるように対称的にも、又は１つのホストのみがこの方法を用いるが、一方別のホストがレガシーモードで動作するように非対称的にも、展開され得る。
【００８０】
第３のホストが、データグラム識別子を管理して、システム全体として一意的なデータグラム識別子を用いることを確実にすることもあり得る。ホストが通信するときに、これらは１つ以上の許可データグラム識別子を取得することもあり得るが、好ましくは、許可識別子の大きなブロックを取得する。例えば、ＤＨＣＰサーバが、利用可能なデータグラム識別子のブロックを分配することもあり得る。
【００８１】
一意性が、データグラムのライフタイムの間に対して、標準により定義されているが、グローバル一意識別子（ＧＵＩＤｓ）を含む識別子も同様に、データグラムが、データグラムのライフタイムにかかわらず常に一意的であることを確実にするために、用いられ得る。
【００８２】
一意的なデータグラム識別子は同様に、限定された時間間隔でさえ、トランザクションベースのシステムに対するトランザクション識別子としても機能することができる。例えば、複数の応答を期待するネットワークストレージクライアントは、複数のストレージデバイスからの複数の応答を区別するのを容易にするために、トランザクション識別子を用いることができる。
【００８３】
ＩＰｖ４インフラからＩＰｖ６インフラへのトランザクションの間に、１つ以上の提示された技術が、データグラム破損問題を解決するために採用されることもあり得る。例えば、ＩＰｖ６がＩＰｖ４を通じて貫通（ｔｕｎｎｅｌｅｄ）される場合、ＩＰｖ４アプローチがＩＰｖ６データグラムを保護するために用いられることもあり得る。その後、ＩＰｖ６アプローチがアプリケーションデータを保護するために用いられ得る。
【００８４】
ネットワークストレージデバイスが例として参照されたが、同じ技術が任意のネットワークデバイスに同様に良好に応用され得るということを認識されたい。ネットワークデバイスには、データグラムを用いて通信リンクを通してアクセス可能な、任意のデバイスが含まれる。ネットワークデバイスの例としては、プリンタ、デジタルビデオ記録、メディアプレーヤー、ファックス、スキャナ、複写機、ＶｏＩＰ電話、又は他のデバイスが含まれる。
【００８５】
（ハードウェア）
他の態様は、発明の主題に付随するハードウェアに関する。本発明の主題の物理的態様に関連する、保管、プロトタイピング、製造、操作、管理、包装、検査、物的管理若しくは支援、又は他のアクティビティのための、ハードウェアを開発することもあり得る、ということが予期されている。従って、本発明の主題は、ハードウェアを開発、生産、製造、又は動かすための、システム、方法、又は装置を含む。このような意味で、ハードウェアは、本発明の主題の範囲内に含まれる。
【００８６】
（ソフトウェア）
更なる他の態様においては、本発明の主題の多様な態様及びこれらに付随するインフラを、構成、シミュレーション、又は管理するソフトウェアを作成することもあり得る、ということが予期されている。その観点から、本発明の主題は、このようなソフトウェアの作成、ソフトウェアの機械読み取り可能な形式での記録、ライセンシング、販売、流通、設置、又は適切なハードウェア上でそのようなソフトウェアを動作させる、方法を含む。その上、ソフトウェア自体が、本発明の主題の範囲に含まれると見なされている。
【００８７】
このように、インターネットワーキングプロトコルを用いるデータグラム破損問題を解決する、特定の構成及び方法が、開示された。しかしながら、当業者には、既に開示されたもの以外の更に多くの変更が、本出願の発明の概念から逸脱することなく可能である、ということが明確である。本発明の主題は、従って、本開示の精神を除いては、制限されるべきではない。その上、本開示を解釈する際には、全ての用語が、文脈と一致する最も広い可能なやりかたで解釈されるべきである。特に、用語「備える（ｃｏｍｐｒｉｓｅ）」及び「備えている（ｃｏｍｐｒｉｓｉｎｇ）」は、非排他的なやりかたでエレメント、構成要素、又はステップに言及し、言及されたエレメント、構成要素、又はステップは、明示的に言及されない他のエレメント、構成要素、又はステップとともに、存在し、又は利用され、又は組み合わせられ得るものとして、解釈されるべきである。
【図面の簡単な説明】
【００８８】
【図１Ａ】従来のＩＰｖ４ヘッダを示している。
【図１Ｂ】従来のＩＰｖ６ヘッダを示している。
【図２】データグラム識別子の値が複写される、複数フィールドデータグラム識別子についての可能な実施形態を例示している。
【図３】データグラム識別子が異なるフィールドの中に複数の値を備える、複数フィールドデータグラム識別子についての可能な実施形態を例示している。
【図４Ａ】データグラム識別子がＩＰオプションを備えるＩＰｖ４に対する、複数フィールドデータグラム識別子の可能な実施形態を例示している。
【図４Ｂ】データグラム識別子が、複数のフラグメントヘッダを用いる、ＩＰｖ６ヘッダ内に複数のフィールドを備える、ＩＰｖ６のための複数フィールドデータグラム識別子の可能な実施形態を示している。
【図５】データグラム識別子のメモリ格納リストの実施形態を例示している。
【図６】利用可能なデータグラム識別子の削減された数を有する、データグラム識別子のプールから引き出されるデータグラム識別子の再使用を管理する方法の、例としての実施形態を示している。
【図７】データグラム識別子のプールを生成してデータグラム破損が起こらないことを確実にする方法の、例としての実施形態を例示している。
【図１Ａ】
2009533960.tif 000003
【図１Ｂ】
2009533960.tif 000004
【図２】
2009533960.tif 000005
【図３】
2009533960.tif 000006
【図４Ａ】
2009533960.tif 000007
【図４Ｂ】
2009533960.tif 000008
【図５】
2009533960.tif 000009
【図６】
2009533960.tif 000010
【図７】
2009533960.tif 000011
【手続補正書】
【提出日】平成20年12月5日(2008.12.5)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
第１の数のデータグラム識別子を有する、第１のデータグラム識別子のプールを提供するステップと、
第２の数のデータグラム識別子を有する第２のデータグラム識別子のプールを提供するステップであって、第２の数は、第１の数とは異なる、該ステップと、
通信リンクを通しての第１のホストと第２のホスト間の通信に関連している閾値が、超過されたかどうかを判断するステップと、
閾値が超過されたかの前記判断に少なくとも部分的に基づいて、第１のデータグラム識別子のプールか、又は第２のデータグラム識別子のプールから、データグラム識別子を選択するステップと、
選択されたデータグラム識別子を、通信リンクを通して送信されるべきデータグラムに割り当てるステップと、を備える方法。
【請求項２】
閾値が、タイムアウト期間及び／又はデータグラムが通信リンクを通して転送される速度に関連している、請求項１に記載の方法。
【請求項３】
閾値が、通信のトラフィックのタイプに関連している、請求項１に記載の方法。
【請求項４】
閾値が、データグラムのサイズに関連している、請求項１に記載の方法。
【請求項５】
閾値が超過されたとの判断の上で、第２のプールを提供するステップを更に備える、請求項１に記載の方法。
【請求項６】
第１のプールが、０に設定された識別表示フィールドの１つ以上の上位ビットのそれぞれを有するデータグラム識別子を備え、第２のプールは、１に設定された識別表示フィールドの１つ以上の上位ビットの少なくとも１つを有するデータグラム識別子を備える、請求項１に記載の方法。
【請求項７】
データグラムのヘッダの中にデータグラム識別子の第１の部分を配置するステップと、
データグラムのペイロードの中にデータグラム識別子の第２の部分を配置するステップと、を更に備える、請求項１に記載の方法。
【請求項８】
第２の部分が、第１の部分の複製である、請求項７に記載の方法。
【請求項９】
第２の部分が、第１の部分とは異なる、請求項７に記載の方法。
【請求項１０】
第１のデータグラム識別子を第２のホストに提供するステップと、
第１のデータグラム識別子を含むデータグラムを、第２のホストから受信するステップと、を更に備える、請求項１に記載の方法。
【請求項１１】
第２のデータグラム識別子のプールが、第１のホストの第１のプロトコルポートに関連する、請求項１に記載の方法。
【請求項１２】
第１のホストの第２のプロトコルポートに関連する第３のデータグラム識別子のプールを提供するステップを更に備える、請求項１１に記載の方法。
【請求項１３】
命令を格納するコンピュータで読み取り可能なメモリであって、命令は、第１のホストの処理装置により実行されるときに、第１のホストに、
第１の数のデータグラム識別子を有する、第１のデータグラム識別子のプールを提供することと、
第２の数のデータグラム識別子を有する第２のデータグラム識別子のプールを提供し、第２の数は、第１の数とは異なることと、
通信リンクを通しての第１のホストと第２のホスト間の通信に関連している閾値が、超過されたかどうかを判断することと、
閾値が超過されたかどうかの前記判断に少なくとも部分的に基づいて、第１のデータグラム識別子のプールか、又は第２のデータグラム識別子のプールから、データグラム識別子を選択することと、
選択されたデータグラム識別子を、通信リンクを通して送信されるべきデータグラムに割り当てることと、をもたらす、メモリ。
【請求項１４】
閾値が、タイムアウト期間及び／又はデータグラムが通信リンクを通して転送される速度に関連している、請求項１３に記載のコンピュータで読み取り可能なメモリ。
【請求項１５】
閾値が、通信のトラフィックのタイプに関連している、請求項１３に記載のコンピュータで読み取り可能なメモリ。
【請求項１６】
閾値が、データグラムのサイズに関連している、請求項１３に記載のコンピュータで読み取り可能なメモリ。
【請求項１７】
第１のプールが、０に設定された識別表示フィールドの１つ以上の上位ビットのそれぞれを有するデータグラム識別子を備え、第２のプールは、１に設定された識別表示フィールドの１つ以上の上位ビットの少なくとも１つを有するデータグラム識別子を備える、請求項１３に記載のコンピュータで読み取り可能なメモリ。
【請求項１８】
格納された命令が、処理装置により実行される場合、第１のホストに、
データグラムのヘッダの中にデータグラム識別子の第１の部分を配置することと、
データグラムのペイロードの中にデータグラム識別子の第２の部分を配置することと、を更にもたらす、請求項１３に記載のコンピュータで読み取り可能なメモリ。
【請求項１９】
第２の部分が、第１の部分の複写である、請求項１８に記載のコンピュータで読み取り可能なメモリ。
【請求項２０】
第２の部分が、第１の部分と異なる、請求項１８に記載のコンピュータで読み取り可能なメモリ。
【請求項２１】
格納された命令が、処理装置により実行される場合、第１のホストに、
第１のデータグラム識別子を第２のホストに提供することと、
第１のデータグラム識別子を含むデータグラムを、第２のホストから受信することと、を更にもたらす、請求項１３に記載のコンピュータで読み取り可能なメモリ。
【請求項２２】
第２のデータグラム識別子のプールが、第１のホストの第１のプロトコルポートに関連する、請求項１３に記載のコンピュータで読み取り可能なメモリ。
【請求項２３】
格納された命令が、処理装置により実行される場合、第１のホストに、
第１のホストの第２のプロトコルポートに関連する第３のデータグラム識別子のプールを提供することを更にもたらす、請求項２２に記載のコンピュータで読み取り可能なメモリ。
【国際調査報告】
2009533960.tif 000012
2009533960.tif 000013
2009533960.tif 000014