JP2003520461A - データ送信の適正化方法 - Google Patents

データ送信の適正化方法

Info

Publication number
JP2003520461A
JP2003520461A JP2000587508A JP2000587508A JP2003520461A JP 2003520461 A JP2003520461 A JP 2003520461A JP 2000587508 A JP2000587508 A JP 2000587508A JP 2000587508 A JP2000587508 A JP 2000587508A JP 2003520461 A JP2003520461 A JP 2003520461A
Authority
JP
Japan
Prior art keywords
datagram
header
tcp
indication
network element
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2000587508A
Other languages
English (en)
Inventor
ルーツ、ユッシ
マ、ジアン
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia Oyj
Original Assignee
Nokia Mobile Phones Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Mobile Phones Ltd filed Critical Nokia Mobile Phones Ltd
Publication of JP2003520461A publication Critical patent/JP2003520461A/ja
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/167—Adaptation for transition between two IP versions, e.g. between IPv4 and IPv6
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)
  • Optical Communication System (AREA)

Abstract

(57)【要約】 本発明はＴＣＰ／ＩＰネットワークにおけるデータ通信の適正化、さらに詳しくは暗号化トラフィックの通信によって生じる問題に関する。本発明によれば、ＩＰデータグラムの暗号化されたペイロードにおいて実行されるＴＣＰ ＡＣＫの表示が、データグラムのＩＰヘッダーに追加される。表示は、単にＴＣＰアクノリッジメントの存在を表示するフラグであってもよい。また、表示は、アクノリッジメントの数に基づいて、暗号化されたトラフィックの処理が許される、アクノリッジメントの数を含んでもよい。ＩＰｖ４のデータグラムにおいて、表示は、エクストラオプションフィールドとして挿入されてもよい。ＩＰｖ６のデータグラムにおいて、表示は、エクステンションヘッダーとして挿入されてもよい。

Description

【発明の詳細な説明】
【０００１】 ［発明の属する技術分野］ 本発明はＴＣＰ／ＩＰネットワークにおけるデータ通信の適正化、さらに詳し
くは暗号化トラフィックの通信によって生じる問題に関する。
【０００２】 ［発明の背景］ ＴＣＰ／ＩＰネットワーク技術は、現在広範囲に使用されており、インターネ
ットは通信制御プロトコル（ＴＣＰ）とインターネット・プロトコル（ＩＰ）を
使用して実現された明白な例である。ＩＰプロトコルは、エラー・チェッキング
、応答またはフロー制御なしに基本パケット・データ送信機構を提供する。ＴＣ
Ｐプロトコルは送信エラー修正、フロー制御および多数の他の機能を伴う信頼で
きるデータ通信機構を提供する。ＩＰプロトコルは、仕様ＲＦＣ７９１中に規定
され、またＴＣＰプロトコルは仕様ＲＦＣ７９３中に規定されている。これらの
プロトコルについての説明はＲＦＣ１１８０中に提示されている。
【０００３】 ＲＦＣ７９１によって規定されたＩＰプロトコル・バージョン４（ＩＰｖ４）
は、ソースとあて先アドレスがほんの３２ビット長である限定されたアドレス・
スペースを有している。インターネットの目下の拡張と技術の開発により、アド
レス・スペースは急速にいっぱいになりつつある。したがって、ＩＰプロトコル
のバージョン６（ＩＰｖ６）が設計されている。ＩＰｖ６のアドレスは１２８ビ
ット長であり、非常に大きいアドレス・スペースが許容される。ＩＰｖ６の背後
にはさらなる動機付けと、ＩＰｖ４とＩＰｖ６間に他の違いがある。本発明に関
連するＴＣＰとＩＰプロトコルの詳細については、図１、２および３を参照して
説明する。
【０００４】 ＩＰプロトコルにおいて、データはヘッダー部分とペイロード・データ部分を
含む、いわゆるデータグラムで送信される。図１はＩＰｖ４ヘッダーの構成を示
す。以後、ヘッダー・フィールドのある部分のみを説明する。詳細な説明は前述
したＲＦＣ７９１から見つけることができる。第１フィールドである４ビット長
バージョン・フィールドは、ＩＰｖ４が４であるバージョン数を含んでいる。全
長フィールドは、オクテット数すなわち８ビットのグループとしてデータグラム
、ヘッダーおよびデータ部分の組み合わされた長さを示す。ソースとあて先アド
レスが、送信者と意図した受信者のＩＰアドレスを特定する。種々のオプション
がオプション・フィールド内に特定することができ、その長さはデータグラムに
よって変化する。オプション・フィールド内で特定付けられる異なるオプション
の数も同様に変化する。オプション・フィールドは必須ではなく、すなわち、あ
る種のデータグラムにおいて、まったくオプション・フィールドがないこともあ
る。ヘッダーが３２ビット境界で終わることを保証するのにパッディング・フィ
ールドが使用される。パッデイング・フィールドはゼロで満たされる。パッデイ
ング・フィールドからペイロード・データ部分に達したのち、ペイロード部分の
長さは全長フィールドの長さからヘッダーの長さを引き算することによって、デ
ータグラムの受信によって見つけることができる。
【０００５】 図２はＩＰｖ６の構造を示す。ＩＰｖ６ヘッダーはＩＰｖ４ヘッダーよりも簡
単であり、送信ノード内でのデータグラムの高速処理が許容される。ヘッダーの
最初の四つのビットがバージョン・フィールドを構成し、ＩＰｖ６では値６を含
んでいる。ペイロード長さフィールドは、データ部分の長さをオクテット数で特
定する。ネクストヘッダーフィールドは、このヘッダーに続くあらゆるヘッダー
のタイプを特定する。ネクストヘッダーは、たとえばＩＰデータグラムがＴＣＰ
パケットを保有している場合ＴＣＰヘッダーであり、そうでなければエクステン
ション・ヘッダーである。各アドレスのために合計１２８ビットを与えている各
々四つの３２ビットからなるソースとあて先アドレスフィールドがデータグラム
の送信側と意図する受信側とを特定する。オプション・フィールドの代わりに、
ヘッダー内にオプション・データを包含するものが、いわゆるエクステンション
・ヘッダーとしてＩＰｖ６に設けられている。種々のエクステンション・ヘッダ
ー・タイプがＲＦＣ１８８３に開示されている。ＩＰｖ６内にはゼロ、一つまた
はそれ以上のエクステンション・ヘッダーがある。各ＩＰｖ６データグラムは、
このデータグラムを使用するこれらの装置のみのためのエクステンション・ヘッ
ダーを備えている。これらのエクステンション・ヘッダーは、主要ヘッダーの後
につぎつぎとチェーン状に続くようにして配備される。各エクステンション・ヘ
ッダーは、ネクストヘッダーフィールドを備えている。主ヘッダーのネクストヘ
ッダーフィールドは第１エクステンション・ヘッダーのタイプを特定し、また各
エクステンション・ヘッダーのネクストヘッダーフィールドは次のエクステンシ
ョン・ヘッダーのタイプを特定する。ネクストヘッダーフィールド内の特定値は
、もはやこの特定ヘッダーに続くヘッダーが存在しないことを指定する。
【０００６】 図３はＴＣＰヘッダーの構造を示す。最も関係の深いフィールドを次に説明す
る。
【０００７】 ＴＣＰヘッダーの他のフィールドについては前述したＲＦＣ７９３に開示され
ている。
【０００８】 ＴＣＰヘッダーは、パケットが送られる受信ホストにおけるあて先ポート番号
を示す。ＴＣＰプロトコルはポートの概念を導入することによって、多数の異な
るサービスを単一のＩＰアドレスを通して可能にする。プログラムは特定ポート
を聞くことができ、またそのポートに送られるどのデータも受信できる。逆に、
プログラムはパケットを遠くのホストにある特定ポートに送ることができる。し
たがって、あて先ポート番号は、ＩＰアドレスによって特定されたホストにおい
てどのサービスまたはプログラムがパケットを受信するかを規定する。同様にし
て、ソースポート番号は、ＴＣＰパケットを送信したサービスまたはプログラム
を示す。
【０００９】 ホストによって送られたＴＣＰデータ・オクテットは、順番に番号付けされる
。データ部分内のデータの最初のオクテットの番号は、ＴＣＰヘッダー内のシー
ケンス番号フィールドに含まれる。この番号に基づいて、受信する第２のホスト
はＴＣＰパケットが正しい順序で送信ネットワークを介して到達しているか、ま
たいずれかのパケットが失われているかどうかをチェックする。第２ホストは、
通常受信されたパケット毎に受信の確認メッセージを第１ホストに送る。この確
認メッセージは第２ホストによって第１ホストに送られる通常のＴＣＰパケット
中に含まれる。応答がＡＣＫフラグと応答番号によって示される。応答数が次の
オクテットのシーケンス数であり、そのパケットの送信側が他のエンドからの受
信を予期されている第２ホストから第１ホストへ送られるべき他のデータがなけ
れば、ペイロード・データ部分が、このような応答パケット中を空にすることが
できる。第２ホストが第１ホストへの送信データであれば、応答があるペイロー
ド・データを含むパケットのヘッダー内に指示することができる。したがって、
ＡＣＫメッセージは常に送信ロードを付加していない。ホストがタイムアウト周
期内であるデータのための応答を受信しなければ、データが返送される。
【００１０】 データ部分がＴＣＰヘッダーの後に続いている。データ部分の長さはＩＰプト
コルに含まれており、ＴＣＰヘッダー内に対応するフィールドはない。
【００１１】 ＴＣＰはその混雑制御機構を有している数少ない送信プロトコルの一つである
。ＴＣＰ内のキー混雑制御機構は「スロー・スタート」機構であり、次のように
機能する。ＴＣＰプロトコルによれば、送信側は非常に遅い速度で送信をはじめ
、データが失われていないかどうかを受信側からの着信確認（ＡＣＫ ｍｅｓｓ
ａｇｅ）によって監視する。データが失われていなければ、すなわち、送信側が
常にＡＣＫを受信していれば、ＴＣＰ送信ホストがデータレート（送信速度）を
増やす。データが失われるまで送信側はデータレートを増やし、送信側はＡＣＫ
メッセージの喪失として観測する。データの減少は一般的に中間ホストの特性に
よるものであり、中間ノードが混雑のためにデータ・パケットに転送できなけれ
ば、ノードは単にパケットを破棄する。パケットの消失のためにＡＣＫメッセー
ジが受信ホストから受信されないので、送信側ホストはそののちにパケットを再
送する。あるデータ・パケットのためのＡＣＫメッセージが受信されないことが
送信側ホストに知れたときに、送信側ホストは、データがそれ以上失われなくな
るまでデータレートを低下させる。各送信パケットが再度ＡＣＫメッセージを受
信できるようになったとき、ホストがデータレートを再度増やし始める。
【００１２】 その結果、ＴＣＰ送信が１から２秒の周期で発振する発振特性となり、またデ
ータがサイクルの一部で失われ、さらにネットワークの容量がサイクルの他の部
分で最適に使用されなくなる。
【００１３】 最近、ＴＣＰ／ＩＰネットワークにおける混雑状況を制御するための新規な機
構が提示されている。たとえば、Ｈａｎｇｚｈｏｕで１９９８年４月６〜１０日
に開催されたｗｍＴＭ ’９８の議事録で発表されたＪｉａｎ Ｍａ による「
サテライトＡＴＭネットワークを介するＴＣＰ／ＩＰのための簡単な高速流れ制
御」がある。高速ＴＣＰまたはＦＴＣＰと呼ばれるこの機構は、発振の問題を軽
減する。この機構において、中間ノードが混雑状況を検出したときに、受信側か
ら戻されたＡＣＫメッセージを遅らせる。遅延されたＡＣＫメッセージの結果と
して、送信側ホストが、さらなるデータ・パケットの送信を遅らせ、混雑を減少
させる。このようにして、データが失われることなく混雑が制御される。
【００１４】 高速ＴＣＰは、ＩＰパケットの内容の識別、すなわち、ＴＣＰメッセージの識
別に依存した種々の制御機構のほんの一例である。この種の機構の他の例には、
Ｒ．Ｓａｔｙａｖｏｌｕ他によるＡＴＭフォーミュラ・ドキュメント９８−０１
５２「ＴＣＰアプリケーションの明示的な流れ制御」に開示された方法があり、
ＴＣＰトラフィックの流れ制御のためにＴＣＰヘッダーに含まれるウインドウ値
を利用している。この方法の主たる考えは、ＴＣＰヘッダー内のウインドウ・サ
イズ・フィールドの内容を修正することである。この方法は、ネットワーク要素
が暗号化されたＩＰペイロードにアクセスできなければ、すなわちオリジナル・
ウインドウ・サイズを識別しなければ、これを読み取らなければ、またＩＰデー
タグラムをもつＴＣＰソースに対して修正値も連絡できなければ、稼働しない。
ＴＣＰトラフィックの制御に関連する他の例はＭＩＴおよびインターネット・リ
サーチ・タスク・フォースのエンド・ツー・エンドのリサーチ・グループによっ
て提案されており、それぞれグローブコム’９７、１９９７年１１月、「ＡＴＭ
を介するＴＣＰフローを調整するための応答バケット・スキーム」に、およびイ
ンターネット・ドラフト、１９９７年７月、「不充分なバッファリアングをとも
なう高遅延帯域パスのためのＡＣＫスペーシング」である。１９９７年１２月、
「ＡＣＲ情報によるＴＣＰフロー制御」と称するＡＴＭフォーラム文献、ＡＴＭ
Ｆ９７−７５８ｒｌは、フロー制御相互作用媒体としてＴＣＰ ＡＣＫを使用す
る一例を開示している。
【００１５】 ＩＰトラフィックの暗号化はしばしば安全性の理由で望ましいものである。暗
号化されたＩＰトラフィックにおいては、ＩＰデータグラムのすべてのペイロー
ド・データが暗号化されている。ＴＣＰヘッダーおよびデータはＩＰデータグラ
ム内にペイロード・データとして含まれているので、すべてのＴＣＰヘッダー情
報はＴＣＰデータとともに同様に暗号化されている。
【００１６】 しかし、ＴＣＰメッセージの識別に依存したあらゆる機構が使用されるときに
、ＩＰ暗号化は問題を生じる。ＴＣＰ ＡＣＫメッセージを認識し可能な処理に
依存しているどの機構も、機構中で関係する中間ノードの少なくともいくつかが
ＩＰパケットの内容を読み取みとれることを必要とする。ＩＰトラフィックが暗
号化されれば、中間ノードがＴＣＰメッセージを識別することができない。した
がって、中間ノードはＴＣＰ ＡＣＫメッセージに基づいて制御機構を実行する
ことができない。
【００１７】 ［発明の要約］ 本発明の目的は、ＴＣＰパケットのヘッダーに含まれた情報に基づくデータ送
信の制御を可能にする、暗号化ＩＰトラフィックを送信するための方法を実現す
ることである。本発明のさらなる目的は、ＴＣＰ ＡＣＫメッセージの制御およ
び（または）処理を可能にする、暗号化ＩＰトラフィックを送信する方法を実現
することである。
【００１８】 本発明の目的は、ＴＣＰパケットを含むＩＰデータグラムのヘッダー内に、少
なくとも制御の基礎となる情報の存在の表示を挿入することによって達成される
。前記少なくとも表示の挿入は、少なくとも制御の基礎となる情報のコピーをＩ
Ｐデータグラムのヘッダーに挿入することからなる。
【００１９】 本発明の方法は、独立した方法クレームの特徴部分に特定されたものによって
特徴付けられる。従属クレームはさらに本発明の有利な実施の形態を開示する。
【００２０】 本発明によれば、少なくともＴＣＰ ＡＣＫの表示または処理の基礎として使
用された他のＴＣＰ情報の表示が、このような情報がＩＰデータグラムに含まれ
ておれば、ＩＰデータグラムのＩＰヘッダーに配備される。そのような表示は単
にＴＣＰ応答の存在を表示するフラグであることもある。この表示はまた応答番
号または他のＴＣＰヘッダー情報を包含しており、応答番号または他のＴＣＰヘ
ッダー情報に基づいて暗号化トラフィックの処理を可能にする。ＩＰｖ４データ
グラムにおいては、この表示はエクストラ・オプション・フィールドとして挿入
されてもよい。ＩＰｖ６データグラムにおいては、表示はエクステンション・ヘ
ッダーとして挿入されてもよい。
【００２１】 ［発明の実施の形態］ つぎに本発明を添付の図面を参照しつつ詳しく説明する。
【００２２】 同じ参照番号が、図中において同様の構成要素に使用される。
【００２３】 次の説明で、本発明の４つの実施の形態をさらに詳細に開示する。
【００２４】 実施の形態１ 実施の形態の第１グループにおいては、応答されるＴＣＰトラフィックの元に
なるソースがＴＣＰトラフィックの復号化を実行する。中間ネットワーク要素を
してＡＣＫを基本とする処理を実行せしめるために、受信されたパケット中に含
まれるＡＣＫメッセージに関する情報が、ＡＣＫを基本とする処理を実行する中
間ネットワーク要素に対して信号化される。暗号化されたＩＰパケットはＴＣＰ
ソース・ホストで復号化され、通常のＴＣＰ処理の前に、ＡＣＫ情報がＡＣＫを
基本とする制御ないし処理を実行するエンティティ（ネットワーク要素）にルー
ト（配信）される。一つまたはそれ以上のこの種のエンティティがある。一つよ
り多いこの種のエンティティがあるとき、ＡＣＫ情報がこれらのエンティティに
送られる。エンティティは中間ネットワーク要素、またはＴＣＰソース・ホスト
内の制御要素であってもよい。
【００２５】 図４は本発明の有利な実施の形態を示し、この実施の形態は実施の形態の第１
グループの例である。図４はソース・ネットワーク要素１０、中間ネットワーク
要素２０およびあて先ネットワーク要素３０、さらに要素間の通信リンク５を示
す。図４はさらに各要素におけるプロトコル・スタックを示し、このスタックに
おいて、物理的階層が最も下にあり、物理的階層の上にＩＰ階層があり、またＩ
Ｐ階層の上にＴＣＰ階層がある。本実施の形態によれば、さらなる通信チャネル
６がソース・ネットワーク要素１０と中間ネットワーク要素２０とのあいだに設
けられ、その通信チャネルは受信されたパケット中に包含されたＡＣＫメッセー
ジに関する情報を送信するのに使用される。この形態は中間ネットワーク要素を
して、たとえＩＰトラフィックが暗号化されていても、トラフィックの処理を可
能にする。
【００２６】 本発明の一つの有利な実施の形態においては、ＡＣＫメッセージがソース・ホ
ストにおけるキュー内に記憶され、またメッセージに関する情報がＡＣＫ処理ネ
ットワーク要素に対して信号化される。ソース・ホストは、ネットワーク要素か
らの命令が来るまでキュー内に記憶されたＡＣＫメッセージのさらなる処理を待
機する。
【００２７】 本発明の他の有利な実施の形態においては、復号化パケット中で見つかったＡ
ＣＫメッセージ情報がネットワーク要素に対して信号化され、続いてソース・ホ
ストによって破棄される。本実施の形態において、ネットワーク要素がトラフィ
ック内にたとえば未暗号化ＡＣＫメッセージを挿入する。ソース・ホストが未暗
号化ＡＣＫメッセージを受信したときに、ソース・ホストは平常のＡＣＫ処理を
実行する。本実施の形態において、ソース・ホストは応答メッセージ・ルーチン
グユニットを備え、このユニットが暗号化パケット内で見つかったＡＣＫメッセ
ージを、ＡＣＫに基づく処理を実行するどの中間ネットワーク要素へもルートし
、また未暗号化パケット内に見つかったＡＣＫメッセージをして、ソース・ホス
トによって通常の方法で処理せしめる。
【００２８】 本発明のさらなる有利な実施の形態においては、ＡＣＫに基づいた処理はソー
ス・ホスト内で実行され、そこで暗号化ＩＰトラフィックが復号化される。本実
施の形態において、未暗号化トラフィックのためにＡＣＫ処理を実行するネット
ワーク要素が、暗号化トラフィックの場合においてソース・ホストに対するＡＣ
Ｋ処理のために必要とされるさらなる情報を信号化する。これによってソース・
ホストは同様の処理を実行することが可能である。前記のさらなる情報は、たと
えばネットワーク要素によって観測されたネットワークの混雑状況に関する情報
であってもよい。
【００２９】 実施の形態２ 暗号化ＩＰトラフィックのＡＣＫ処理に関連する問題は、ＩＰパケットに対す
る複合化機能を伴う処理を実行するネットワーク要素を提供することによっても
解決することができる。このような実施の形態において、ネットワーク要素はＩ
Ｐパケットを復号化することができ、また通常の方法でＦＴＣＰ処理のようなネ
ットワーク制御機能を実行する。この種の実施の形態は、ソースまたはあて先ホ
ストのいずれにおいてもたとえばＴＣＰおよびＩＰ処理、およびＩＰ暗号化と復
号化を実行するプログラムに変更が必要でないという利点を有している。このよ
うな実施の形態の実際の実現化は当然ＩＰデータグラムの暗号化のために使用さ
れる暗号化システムに依存している。たとえば、暗号化を実行するエンティティ
は、ネットワーク要素にＩＰデータグラムの復号化に必要とされる復号化キーを
送信してもよい。他の実施の形態として、ネットワーク要素が多数のＴＣＰ接続
（通信）のための復号化キーをもっていてもよく、この接続はネットワーク要素
によって処理される。
【００３０】 実施の形態３ 暗号化ＩＰトラフィックのＡＣＫ処理に関する問題は、プレーン、すなわち未
暗号化ＡＣＫメッセージを使用することによって解決することもできる。このよ
うな実施の形態において、ＩＰデータグラム・ペイロード・データの暗号化を実
行するエンティティは、ＴＣＰ ＡＣＫメッセージを含んでいるデータグラムを
未暗号化のまま残留させる。他のデータグラムは通常の方法で暗号化される。こ
の方法はＡＣＫメッセージが暗号化されないので、中間ネットワーク要素によっ
てＡＣＫメッセージを通常の方法で処理することができる。
【００３１】 本実施の形態において、ＴＣＰのあて先ホストは同じＴＣＰ接続に属する暗号
化パケットとプレーン・パケットの両方を生成することが必要とされ、ＩＰソー
ス・ホストは暗号化パケットとプレーンＩＰパケット両方を受信できることが必
要とされる。
【００３２】 好ましくは、本実施の形態において、ＴＣＰ ＡＣＫメッセージは別の方法で
空のＴＣＰパケットとして送られる。すなわち、未暗号化ペイロード・データの
送信を回避するために、ＡＣＫメッセージを含んでいるパケットにはなんのデー
タも送られない。
【００３３】 本実施の形態は、付加的な信号チャネルを必要とせず、また一つを超えるネッ
トワーク要素が、特別な構成なしにＡＣＫメッセージを観測することができると
いう利点を有する。したがって、本実施の形態は中間ネットワーク要素の数を増
やすようなネットワーク形態の変更を容易にすることができる。
【００３４】 実施の形態４ 本発明のさらなる実施の形態によれば、ＴＣＰ ＡＣＫメッセージが暗号化Ｉ
Ｐデータグラムを含んでいるという表示が、ＩＰデータグラムのヘッダー内に配
備される。これにより、ＡＣＫメッセージ自体が暗号化されているにもかかわら
ず、これが中間ネットワーク要素をしてＡＣＫメッセージに基づいた処理の実行
を許容せしめる。ＡＣＫ番号なしにＡＣＫメッセージを表示することは、ＡＣＫ
番号を必要としないような処理に対しては充分である。本発明の別の実施の形態
において、ＡＣＫ番号がさらにＩＰヘッダーに配備される。これにより、何らか
のかたちでＡＣＫ番号を必要とするような機構を機能させる。たとえば、この種
の機構はＡＣＫ番号を修正する。
【００３５】 ＩＰｖ４データグラムによれば、ＡＣＫメッセージの表示は、エクストラ・オ
プション・フィールドとしてＩＰヘッダー内に組み入れてもよい。ＡＣＫ番号も
同様にエクストラ・オプション・フィールドとしてＩＰヘッダー内に組み入れて
もよい。ＡＣＫメッセージの表示とＡＣＫ番号は、同じオプション・フィールド
内に含められてもよく、またはこれらは別々のオプション・フィールド内に配備
されてもよい。本発明は、エクストラ・オプション・フィールドまたはいずれか
のフィールドにおけるＡＣＫメッセージの表示のエンコーディング方法を限定す
るものではなく、またＡＣＫ番号のエンコーディング方法を限定するのもでもな
い。当該技術に習熟した人は、ＡＣＫの表示とＡＣＫ番号をＩＰｖ４ヘッダーの
エクストラ・オプション・フィールド内でエンコードする多数の異なる方法を考
えることができる。
【００３６】 ＡＣＫメッセージまたはＡＣＫメッセージの表示は、ＩＰｖ４ヘッダー内で多
くの方法でエンコードすることができる。たとえば、ＡＣＫメッセージの表示は
タイプ・オブ・サービス（ＴＯＳ）フィールド内に含ませることができる。ＴＯ
Ｓフィールドのビット６と７は、現在のＩＰｖ４仕様によれば使用されないので
、これら二つのビットのうちの一つが、たとえばＡＣＫメッセージを表示するの
に使用できる。たとえば、本発明の一実施の形態において、ＩＰデータグラムの
ＴＯＳフィールドの６ビットは、ＩＰデータグラムがＴＣＰ ＡＣＫメッセージ
を含んでいれば、１に設定され、ＩＰデータグラムがＴＣＰ ＡＣＫメッセージ
を含んでいなければ、０に設定される。
【００３７】 本発明の別の有利な実施の形態において、ＡＣＫメッセージのエンコーディン
グはＴＣＰヘッダーの少なくとも一部をＩＰｖ４データグラムのオプション・フ
ィールド内にコピーすることによって実現される。図５はオプション・フィール
ドの構造を示す。オプション・フィールドは、オプション・タイプ・オクテット
のみか、オプション・タイプ・オクテット、オプション長さオクテットおよびデ
ータのいずれかを含んでいる。オプション・タイプ・オクテットの第１ビット、
すなわち、ビット番号０は、ＩＰデータグラムがその通信中、ある点でフラグメ
ント化されたときに、オプション・フィールドがＩＰデータグラムの第１フラグ
メントにのみコピーされなければならないかどうかを示している。第１ビットが
０に設定されていれば、第１フラグメントのみがオプション・フィールドを含ん
でいることになる。第１ビットが１に設定されていれば、オプション・フィール
ドは全てのフラグメントに対してコピーされることになる。ビット１と２、すな
わち、オプション・クラス・ビットはオプションのクラスを示している。実施の
形態のこの例において、これらのビットは０に設定することができ、この場合オ
プション・クラス・ビットは、オプション・クラスが「コントロール」であるこ
とを表示しており、すなわち、フィールドの内容がデータグラムまたはネットワ
ーク・コントロールをともなっている。オプション・クラス・オクテットの残り
のビット、すなわち、オプション番号フィールドはオプション・フィールドの使
用を表示している。本発明の本実施の形態において、目下使用されていないオプ
ション番号の一つが、オプション・フィールドがＩＰデータグラム内に保有され
たＴＣＰヘッダーの少なくとも一部を含んでいることを示すように規定されなけ
ればならない。たとえば、オプション番号１５がこのことを示すように規定する
ことができる。オプション・クラス・ビットとオプション番号ビットの種々の値
の意味は、前述の仕様ＲＦＣ７９１に規定されている。オプション長さオクテッ
トは、オプション・フィールド全体の長さをオクテット数で示している。オプシ
ョン・フィールドのデータ部分は、オプション・フィールドの実際のデータを含
んでいる。好ましくは、本実施の形態において、データ部分は少なくともＴＣＰ
応答番号を含んでいる。データ部分はＴＣＰヘッダーの全体を含んでいてもよい
。
【００３８】 本発明の有利な実施の形態において、ＴＣＰヘッダーを含んでいるオプション
・フィールドの存在は、ＴＣＰ ＡＣＫまたは他のＴＣＰ情報の表示として使用
される。
【００３９】 本発明の有利な実施の形態において、ＡＣＫメッセージの情報は、エクステン
ション・ヘッダーとしてＩＰｖ６データグラム内に組み入れられる。ＡＣＫ番号
は同様にエクステンション・ヘッダーとして組み入れられてもよく、また、表示
とＡＣＫ番号は同じエクステンション・ヘッダーに、または別々のエクステンシ
ョン・ヘッダーとして組み入れることもできる。本発明のこの実施の形態によれ
ば、新しいエクステンション・ヘッダー・タイプを規定する必要があり、すなわ
ち、そのタイプは、エクステンション・ヘッダーが少なくともＴＣＰヘッダーの
一部を含んでいることを特定する必要がある。以下、この種のエクステンション
・ヘッダーはＴＣＰエクステンション・ヘッダーと呼ばれる。
【００４０】 ＴＣＰエクステンション・ヘッダーは、たとえば、ＩＰｖ６データグラムにお
いては、認証およびカプセル化保証ペイロード（ＥＳＰ）のエクステンション・
ヘッダーの前に挿入することができる。
【００４１】 図６は本発明の有利な実施の形態によるＴＣＰエクステンション・ヘッダーの
構造の一例を示す。本実施の形態において、ＴＣＰエクステンション・ヘッダー
はネクストヘッダーのタイプを特定するネクスト・ヘッダー・フィールド、エク
ステンションの長さを特定する８−オクテット単位のレングス・フィールド、Ｔ
ＣＰヘッダーまたはその少なくとも一部および、場合によってはエクステンショ
ン・ヘッダーの長さがＲＦＣ１８８３で要求されているように８−オクテット単
位の倍数となるまで、残りのスペースをいっぱいにするパディングを含んでいる
。このパディングは、たとえばＲＦＣ１８８３のセクション４．２に開示された
方法、すなわち、パディングのただ一つのオクテットが必要なときは単一オクテ
ットのゼロによって、また、Ｎオクテットのペディングが必要なときは、単独オ
クテットの１と、パディング長さ引く２を特定するオクテットと、Ｎ−２オクテ
ットのゼロとで実現することができる。
【００４２】 好ましくは、ＩＰデータグラムの暗号化を実行するエンティティが、ＩＰヘッ
ダー内にＡＣＫメッセージの表示の導入を実行する。導入を実行するエンティテ
ィはＴＣＰのあて先ホストであるのが好ましく、それがＡＣＫメッセージを形成
する。
【００４３】 しかし、本発明はＴＣＰあて先ホスト内でのＡＣＫメッセージの表示の導入に
限定されるものではない。たとえば、ＩＰデータグラムを暗号化するＴＣＰあて
先ホストが、情報をさらなる処理エンティティに連絡してもよい。その情報は、
どのＩＰデータグラムがＡＣＫメッセージや関連するＡＣＫ番号を含んでいるか
を示している。つぎに、さらなる処理エンティティが、ＡＣＫメッセージの表示
と、場合によってはＡＣＫ番号を、ＡＣＫメッセージを含むＴＣＰあて先ホスト
によって指示された暗号化ＩＰデータグラムに付加する。したがって、ＡＣＫメ
ッセージの表示の導入の処理は、ＩＰ暗号化を実行するエンティティと同じエン
ティティによって実行される必要はない。
【００４４】 ＡＣＫメッセージの表示のＩＰヘッダーへの導入は、たとえば、ＩＰ復号化と
ＴＣＰ処理を実行するＴＣＰソース・ホスト・プログラムを変更することが必ず
しも必要でないという利点を有する。ソース・ホストは、ＡＣＫメッセージの表
示を単に無視することができる。本発明のような、ＡＣＫ番号がまたＩＰヘッダ
ーに組み入れられ、また中間ノード中の種々の処理機構がＡＣＫ番号を修正する
実施の形態では、従来のＴＣＰソース・ホスト・プログラムは、ＩＰヘッダーか
らの修正されたＡＣＫ番号を使用するが、また復号化ＴＣＰパケットからの変更
されていないＡＣＫは使用しないという程度に修正する必要がある。
【００４５】 ＡＣＫメッセージの表示をＩＰヘッダーに組み入れることは、たとえば、たと
えＴＣＰパケットがＡＣＫメッセージとペイロード・データの両方を含んでいて
も、ＴＣＰペイロード・データを暗号化せずに送る必要がないという利点をも有
する。
【００４６】 図７は実施の形態の第４グループに属する一実施の形態による信号処理の一例
を示す。図７はソース・ホスト１０、ネットワーク要素２０とあて先ホスト３０
間の信号処理を示す。第１に、ソース・ホスト１０がパケット１００をネットワ
ーク要素２０に送り、このネットワーク要素があて先ホスト３０にパケット１１
０を転送する。次にあて先ホストがソース・ホストに返信するためにデータグラ
ムを暗号化する。この場合において、データグラム内のＴＣＰパケットは、応答
（ＡＣＫ）を含んでおり、そのためにあて先ホストが暗号化されたＩＰパケット
のヘッダー内にＡＣＫメッセージの表示１１５を挿入する。パケットに応答を含
める準備ののち、あて先ホストがパケット１２０をネットワーク要素２０に送る
。ネットワーク要素が、ＩＰヘッダーからこのパケットがＡＣＫメッセージを含
んでいることを観測する。この例において、ネットワークはこの時点で混雑して
おり、そのためにネットワーク・エレメントがＡＣＫを含んでいるデータグラム
１３０を遅延させる。混雑が充分緩和されたときに、ネットワーク要素がデータ
グラム１４０をソース・ホストに転送する。図７はまた混雑していない場合にお
ける信号化のさらなる例を示す。ソース・ホスト１０が、パケット１５０をネッ
トワーク要素２０に送り、このネットワーク要素がパケット１６０をあて先ホス
ト３０に転送する。次にあて先ホストが、ソース・ホストに返信するためにデー
タグラムを暗号化する。この場合において、データグラム内のＴＣＰパケットは
応答を含んでおり、そのためにあて先ホストがＡＣＫメッセージの表示１６５を
暗号化ＩＰパケットのヘッダーに挿入する。パケットに応答を含める準備ののち
、あて先ホストがパケット１７０をネットワーク要素２０に送る。この場合にお
いて、ネットワークは混雑していない。これによってネットワーク要素は単にパ
ケット１８０をソース・ホストに転送する。混雑の検出は、たとえばパケットの
遅延、応答メッセージの遅延に基づいて、または当該技術に習熟した人に知られ
ている他の方法によって実行される。
【００４７】 本明細書において、暗号化ＩＰデータグラムなる用語は、データ・ペイロード
が少なくとも一部で暗号化されているＩＰデータグラムを意味する。
【００４８】 本発明はこれまでに説明した高速ＴＣＰ機構と組み合わせて有利に使用するこ
とができる。しかし、本発明はこのような実施の形態に限定されるものではない
。本発明は、ウインドウ・サイズまたは応答メッセージのようなＴＣＰヘッダー
情報に基づいてＴＣＰトラフィックを処理する他の機構と組み合わせて有利に使
用することもできる。したがって、ＡＣＫ処理の前述の例は、いずれにしても本
発明を限定するものではない。本発明の種々の実施の形態において、同様の処理
がたとえばＡＣＫ番号の代わりにウインドウ・サイズ値に基づいて実行できる。
【００４９】 これまでの説明に照らして、当該技術に習熟した人にとっては、種々の修正例
が本発明の範囲内でなされることは明白となろう。本発明の好ましい実施の形態
につき詳細に説明したが、多数の修正例およびバリエーションも可能であること
は明白であり、これら全ては本発明の真の精神と範囲内にある。
【図面の簡単な説明】
【図１】 ＩＰｖ４ヘッダーの構成を示す図である。
【図２】 ＩＰｖ６ヘッダーの構成を示す図である。
【図３】 ＴＣＰヘッダーの構成を示す図である。
【図４】 本発明の一つの有利な実施の形態を示す図である。
【図５】 ＩＰｖ４ヘッダー内のオプション・フィールドのオプション・コード・オクテ
ットの構成を示す図である。
【図６】 本発明の実施の形態によるＩＰｖ６エクステンション・ヘッダーの構成を示す
図である。
【図７】 本発明の有利な実施の形態による信号処理を示す図である。
───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＳＤ，ＳＬ，ＳＺ，ＴＺ，ＵＧ，ＺＷ )，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ， ＴＪ，ＴＭ)，ＡＥ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ， ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，Ｃ Ｒ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＤＭ，ＥＥ，ＥＳ，ＦＩ ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ， ＩＬ，ＩＮ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，Ｋ Ｚ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＡ ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ， ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，Ｓ Ｋ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＴＺ，ＵＡ，ＵＧ ，ＵＳ，ＵＺ，ＶＮ，ＹＵ，ＺＡ，ＺＷ (72)発明者 マ、ジアン フィンランド共和国、フィン−02940 エ スポー、ピハラヤマルヤンチエ 13−15 セー １ Ｆターム(参考） 5J104 AA01 PA07 5K030 HA08 HB11 HB18 HB28 LA02 LD19

Claims (11)

    【特許請求の範囲】
  1. 【請求項１】 ＩＰデータグラム中にあるＴＣＰヘッダー内の情報に基づい
    てＩＰトラフィックを処理する方法において、トラフィックがＩＰデータグラム
    の少なくともいくつかが暗号化されているＩＰトラフィックを処理する方法であ
    って、 暗号化されるべきＩＰデータグラムが、処理のために基準として使用されるＴ
    ＣＰヘッダー情報を含んでおれば、処理の基本となる情報の少なくともその表示
    が前記データグラムのヘッダーに挿入されることを特徴とするＩＰデータグラム
    中にあるＴＣＰヘッダー内の情報に基づいてＩＰトラフィックを処理する方法。
  2. 【請求項２】 暗号化されるべきＩＰデータグラムがＴＣＰ応答を含んでお
    れば、応答の表示が前記データグラムのヘッダーに挿入される請求項１記載の方
    法。
  3. 【請求項３】 前記データグラムのヘッダーへの少なくとも前記表示の挿入
    が、少なくともデータグラムの処理の基本となる情報のコピーの挿入からなる請
    求項１記載の方法。
  4. 【請求項４】 前記データグラムのヘッダーへの少なくとも前記表示の挿入
    が、ＴＣＰヘッダーの全ての情報の前記データグラムのヘッダーへの挿入からな
    る請求項３記載の方法。
  5. 【請求項５】 ＴＣＰ応答番号のコピーが前記データグラムのヘッダーに挿
    入される請求項３記載の方法。
  6. 【請求項６】 ＴＣＰヘッダーのウインドウ・サイズ・フィールドの内容の
    コピーが、前記データグラムのヘッダーに挿入される請求項３記載の方法。
  7. 【請求項７】 前記データグラムがＩＰｖ４データグラムであれば、前記少
    なくとも表示が前記データグラムのオプション・フィールドに挿入される請求項
    １記載の方法。
  8. 【請求項８】 前記データグラムがＩＰｖ６データグラムであれば、前記少
    なくとも表示が前記データグラムのエクステンション・ヘッダーに挿入される請
    求項１記載の方法。
  9. 【請求項９】 ソース・ネットワーク要素がＩＰデータグラムを生成し、 中間ネットワーク要素がＩＰデータグラムをあて先ネットワーク要素に転送し
    、 あて先ネットワーク要素がＩＰデータグラムを受信する方法において、 中間ネットワーク要素が処理の基本となる情報の前記コピーを修正する請求項
    ３記載の方法。
  10. 【請求項１０】 前記あて先ネットワーク要素がＩＰデータグラムのペイロ
    ードとしてもっている情報の暗号化バージョンの代わりに情報の前記修正コピー
    を使用する請求項９記載の方法。
  11. 【請求項１１】 ＴＣＰ／ＩＰネットワーク中の混雑制御に使用される方法
    であって、 前記暗号化ＩＰデータグラムがＴＣＰ応答の表示を含み、また前記ネットワー
    ク要素がネットワークの混雑を検出すれば、ネットワーク要素によって暗号化Ｉ
    Ｐデータグラムの送信を遅延する工程を備える請求項１記載の方法。
JP2000587508A 1998-12-08 1999-12-07 データ送信の適正化方法 Pending JP2003520461A (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FI982651A FI106417B (fi) 1998-12-08 1998-12-08 Menetelmä tiedonsiirron optimoimiseksi
FI982651 1998-12-08
PCT/FI1999/001008 WO2000035163A1 (en) 1998-12-08 1999-12-07 A method for optimizing of data transmission

Publications (1)

Publication Number Publication Date
JP2003520461A true JP2003520461A (ja) 2003-07-02

Family

ID=8553065

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2000587508A Pending JP2003520461A (ja) 1998-12-08 1999-12-07 データ送信の適正化方法

Country Status (8)

Country Link
US (1) US7032111B1 (ja)
EP (1) EP1138143B1 (ja)
JP (1) JP2003520461A (ja)
AT (1) ATE282921T1 (ja)
AU (1) AU1661700A (ja)
DE (1) DE69922045D1 (ja)
FI (1) FI106417B (ja)
WO (1) WO2000035163A1 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004533741A (ja) * 2001-03-16 2004-11-04 テレフオンアクチーボラゲツト エル エム エリクソン（パブル） インターネットプロトコルのアドレス機構
JP2013078004A (ja) * 2011-09-30 2013-04-25 Nec Corp 通信システム、データ送信装置、データ受信装置、パケット再送制御方法、パケット再送制御プログラム
WO2020012973A1 (ja) * 2018-07-09 2020-01-16 日本電気株式会社 通信制御装置、方法、プログラム、及びコンピュータに読み取り可能な非一時的記録媒体

Families Citing this family (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002278903A (ja) * 2001-03-15 2002-09-27 Sony Corp 情報処理装置および方法、記録媒体、並びにプログラム
US7248582B2 (en) * 2002-02-13 2007-07-24 Sun Microsystems, Inc. Method and system for labeling data in a communications system
DE10212589B4 (de) * 2002-03-15 2007-06-06 Siemens Ag Verfahren zum Übertragen von Nutzdaten mittels eines IP-Paketes und IP-Paket
US7143157B2 (en) * 2002-03-25 2006-11-28 Hewlett-Packard Development Company, L.P. Managing the network impact of a digital transmitter
EP1357719A1 (de) * 2002-04-26 2003-10-29 Siemens Aktiengesellschaft Verfahren und Vorrichtung zum Übertragen von Datenpaketen in einem Kommunikationssystem bei Verwendung PEP und eines RAN
EP1500249B1 (de) * 2002-04-26 2018-02-21 Siemens Aktiengesellschaft Verfahren und vorrichtung zum übertragen von datenpaketen in einem kommunikationssystem bei verwendung pep und eines ran
US7616638B2 (en) 2003-07-29 2009-11-10 Orbital Data Corporation Wavefront detection and disambiguation of acknowledgments
US8270423B2 (en) 2003-07-29 2012-09-18 Citrix Systems, Inc. Systems and methods of using packet boundaries for reduction in timeout prevention
US7565443B2 (en) * 2002-12-13 2009-07-21 Sap Ag Common persistence layer
US8437284B2 (en) 2003-07-29 2013-05-07 Citrix Systems, Inc. Systems and methods for additional retransmissions of dropped packets
US20050097242A1 (en) 2003-10-30 2005-05-05 International Business Machines Corporation Method and system for internet transport acceleration without protocol offload
CN1297119C (zh) * 2004-03-30 2007-01-24 中国科学院计算技术研究所 应用层协议转换网关的包序号控制方法
US7581005B2 (en) 2005-01-20 2009-08-25 Citrix Systems, Inc. Systems and methods for preserving transport layer protocol options
KR100651469B1 (ko) * 2005-10-07 2006-11-29 삼성전자주식회사 비대칭 무선 네트워크 환경에서의 ｔｃｐ의 ａｃｋ피기배킹을 이용한 데이터 전송률을 향상시킬 수 있는방법과 그 단말 및 시스템
CN1960324B (zh) * 2005-11-02 2010-07-21 盛科网络（苏州）有限公司 以回路完成隧道封装和解封装处理的网络交换机和方法
WO2008092023A2 (en) * 2007-01-24 2008-07-31 Viasat, Inc. Enhanced error control communication systems and methods
US7664857B2 (en) 2007-01-26 2010-02-16 Citrix Systems, Inc. Systems and methods of using an IP ID field for automatic WAN/LAN detection
JP2008227642A (ja) * 2007-03-09 2008-09-25 Hitachi Ltd 再送制御方法、および無線通信システム
US7809820B2 (en) * 2007-07-17 2010-10-05 Microsoft Corporation Optimizing encrypted wide area network traffic
ES2393501B1 (es) * 2010-09-03 2013-11-11 Telefónica, S.A. Método y sistema para clasificación de tráfico.
US9215184B2 (en) 2011-10-17 2015-12-15 Hewlett-Packard Development Company, L.P. Methods of and apparatus for managing non-congestion-controlled message traffic in a datacenter
US20140369189A1 (en) * 2013-06-18 2014-12-18 Dasan Networks, Inc. Method of controlling packet transmission in network system and network system transmitting packet using pseudo-tcp agent
US10834065B1 (en) 2015-03-31 2020-11-10 F5 Networks, Inc. Methods for SSL protected NTLM re-authentication and devices thereof
US10404698B1 (en) 2016-01-15 2019-09-03 F5 Networks, Inc. Methods for adaptive organization of web application access points in webtops and devices thereof
US10826876B1 (en) * 2016-12-22 2020-11-03 Amazon Technologies, Inc. Obscuring network traffic characteristics
US11005659B2 (en) * 2018-01-23 2021-05-11 Forcepoint Llc Protocol independent forwarding of traffic for content inspection service

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5070528A (en) 1990-06-29 1991-12-03 Digital Equipment Corporation Generic encryption technique for communication networks
FR2686755A1 (fr) * 1992-01-28 1993-07-30 Electricite De France Procede de chiffrement de messages transmis entre reseaux interconnectes, appareil de chiffrement et dispositif de communication de donnees chiffrees mettant en óoeuvre un tel procede.
US5757924A (en) 1995-09-18 1998-05-26 Digital Secured Networks Techolognies, Inc. Network security device which performs MAC address translation without affecting the IP address
JPH10178421A (ja) * 1996-10-18 1998-06-30 Toshiba Corp パケット処理装置、移動計算機装置、パケット転送方法及びパケット処理方法
US6038216A (en) * 1996-11-01 2000-03-14 Packeteer, Inc. Method for explicit data rate control in a packet communication environment without data rate supervision
US5987022A (en) * 1996-12-27 1999-11-16 Motorola, Inc. Method for transmitting multiple-protocol packetized data
IL130774A0 (en) * 1997-01-03 2001-01-28 Fortress Technologies Inc Improved network security device
US5974028A (en) * 1997-02-24 1999-10-26 At&T Corp. System and method for improving transport protocol performance in communication networks having lossy links
US5937169A (en) * 1997-10-29 1999-08-10 3Com Corporation Offload of TCP segmentation to a smart adapter
US6249530B1 (en) * 1997-12-22 2001-06-19 Sun Microsystems, Inc. Network bandwidth control
FI105753B (fi) * 1997-12-31 2000-09-29 Ssh Comm Security Oy Pakettien autentisointimenetelmä verkko-osoitemuutosten ja protokollamuunnosten läsnäollessa
US6160793A (en) * 1998-10-13 2000-12-12 Nokia Telecommunications, Oy ECN-based approach for congestion management in hybrid IP-ATM networks

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004533741A (ja) * 2001-03-16 2004-11-04 テレフオンアクチーボラゲツト エル エム エリクソン（パブル） インターネットプロトコルのアドレス機構
JP2013078004A (ja) * 2011-09-30 2013-04-25 Nec Corp 通信システム、データ送信装置、データ受信装置、パケット再送制御方法、パケット再送制御プログラム
WO2020012973A1 (ja) * 2018-07-09 2020-01-16 日本電気株式会社 通信制御装置、方法、プログラム、及びコンピュータに読み取り可能な非一時的記録媒体
JPWO2020012973A1 (ja) * 2018-07-09 2021-06-24 日本電気株式会社 通信制御装置、方法、及びプログラム
JP7111162B2 (ja) 2018-07-09 2022-08-02 日本電気株式会社 通信制御装置、方法、及びプログラム

Also Published As

Publication number Publication date
AU1661700A (en) 2000-06-26
FI982651A0 (fi) 1998-12-08
EP1138143A1 (en) 2001-10-04
FI982651A (fi) 2000-06-09
ATE282921T1 (de) 2004-12-15
DE69922045D1 (de) 2004-12-23
US7032111B1 (en) 2006-04-18
WO2000035163A1 (en) 2000-06-15
FI106417B (fi) 2001-01-31
EP1138143B1 (en) 2004-11-17

Similar Documents

Publication Publication Date Title
JP2003520461A (ja) データ送信の適正化方法
US7143282B2 (en) Communication control scheme using proxy device and security protocol in combination
US6732314B1 (en) Method and apparatus for L2TP forward error correction
US7965729B2 (en) Transferring data such as files
Kent et al. Fragmentation considered harmful
Perkins IP encapsulation within IP
US6553423B1 (en) Method and apparatus for dynamic exchange of capabilities between adjacent/neighboring networks nodes
US7948921B1 (en) Automatic network optimization
EP1122925B1 (en) Header compression for general packet radio service tunneling protocol (GTP)
EP1774750B1 (en) Method, apparatuses and computer readable medium for establishing secure end-to-end connections by binding IPSec Security Associations
US8082447B2 (en) Systems and methods for end-to-end resource reservation authentication
US7177272B2 (en) System and method for optimizing link throughput in response to non-congestion-related packet loss
US20060224753A1 (en) Session relay apparatus, session relay method and program
Kent et al. Fragmentation considered harmful
JPH11112574A (ja) 異種ネットワークでデータ・パケットを生成する方法およびシステム
US7275093B1 (en) Methods and device for managing message size transmitted over a network
JP2002044135A (ja) 暗号装置及び暗号通信システム
US7197046B1 (en) Systems and methods for combined protocol processing protocols
Thornburgh Adobe's Secure Real-Time Media Flow Protocol
US6996105B1 (en) Method for processing data packet headers
Deering et al. RFC1883: Internet Protocol, version 6 (IPv6) specification
Perkins RFC2003: IP Encapsulation within IP
US6963568B2 (en) Method for transmitting data packets, method for receiving data packets, data packet transmitter device, data packet receiver device and network including such devices
US20060107168A1 (en) Method and apparatus for transmitting/receiving virtual block information for multiple segment recovery in data network using transmission control protocol
EP1505759B1 (en) Method and device for transmitting/receiving data using acknowledged transport layer protocols