(57)【特許請求の範囲】
【請求項１】
レイヤー２トンネリングプロトコル（Ｌ２ＴＰ）受信機において用いられる方法であって、
Ｌ２ＴＰ送信元からパケットを受信するステップ、
受信されたパケットからの、現在受信した「次に送信された」配列番号の値を、「次に受信されることが期待される」配列番号を表す保存された値（Ｓｒ）と比較するステップ、及び
該比較するステップの結果が所定値よりも大きい場合に、Ｓｒを該現在受信した「次に送信された」配列番号の値に再設定（リセット）するステップ
からなる方法。
【請求項２】
請求項１記載の方法であって、さらに、
該再設定するステップを実行する前に、所定数のパケットの喪失を検出するステップからなる方法。
【請求項３】
請求項１記載の方法であって、さらに、
前記Ｌ２ＴＰ送信元へ先に受信したパケットについての通知を送信する前に、Ｋ＞１であるＫ個のパケットが受信されることを待つステップからなる方法。
【請求項４】
レイヤー２トンネリングプロトコル（Ｌ２ＴＰ）受信機を形成するために用いられるパケットインターフェイスであって、
Ｌ２ＴＰ送信元からパケットを受信するための通信インターフェイス（６６５）、
メモリであって、（ａ）受信されたパケットからの現在受信した「次に送信された」配列番号の値（Ｓｎｌ）、及び（ｂ）「次に受信されることが期待される」配列番号（Ｓｒ）を保存するメモリ（６６０）、及び
ＳｎｌとＳｒの差が所定値を超えた場合に、Ｓｒを該現在受信した「次に送信された」配列番号の値に再設定するよう動作するプロセッサ（６５０）
からなるパケットインターフェイス。
【請求項５】
請求項４記載のパケットインターフェイスにおいて、前記Ｌ２ＴＰ送信元へ先に受信したパケットについての通知を送信する前に、該プロセッサがＫ＞１であるＫ個のパケットが受信されることを待つことを特徴とするパケットインターフェイス。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、通信、とりわけパケット通信システムに関するものである。
【０００２】
【従来の技術】
レイヤー２トンネリングプロトコール（Ｌ２ＴＰ）（例えば、K.Hamzeh,T.Kolar,M.Littlewood,G.Singh Pall,J.Valencia,W.Verthein,W.M.Townsley,B.Palter,A.rubens"Layer Two Tunneling Protocol(L2TP)",Internet draft,March 1998を参照せよ。）は、インターネット・エンジニアリング・タスクフォース（IETF）L2TPワーキンググループによって設計され、インターネットサービスプロヴァイダー（ISP）が、従来型の登録されたインターネットプロトコール（IP）アドレスをベースとしたサービス以外のサービスを提供することを可能にするものである。
【０００３】
例えば、インターネットサービスプロヴァイダー（ISP）は、Ｌ２ＴＰトンネル（あるいはＬ２ＴＰ接続）を経由することで、顧客が企業イントラネットへアクセスすることを可能とする仮想ダイヤルアップサービスを提供することができるようになる。
【０００４】
Ｌ２ＴＰ接続においては、コントロールセッション（制御セッション）とデータセッションという２タイプのセッションが存在する。コントロールセッションについては、Ｌ２ＴＰは、伝送の間に失われたコントロールメッセージ（コントロールパケットとしても知られている）の再送信スキームを定義している。しかしながら、Ｌ２ＴＰは、データセッションについては失われたペイロードメッセージ（ペイロードパケットとしても知られている）は再送信しない。
【０００５】
その代わりに、ペイロードパケットが失われた際には、Ｌ２ＴＰは、受信機における「次に受信した」（Ｎｒ）配列番号をリセットする受信者開始回復アルゴリズム（ＲＩＲＡ）を定義している。とりわけ、伝送ウインドが時間切れとなる場合（すなわち、送信者が、先に送信したパケットを有している場合）、送信者は、所定の「リセットＳｒ」（Ｒビット）インジケーターを含むペイロードメッセージを伝送する。このインジケーターはＮｒ（受信機における）の値を、最初に失われたパケットをちょうど超える値か、あるいは送信者が現在送信している配列番号の値に再設定（リセット）する。
【０００６】
【発明が解決しようとする課題】
本発明においては、Ｌ２ＴＰ受信者は、Ｌ２ＴＰ送信者からパケットを受信し、失われたペイロードパケットを所定数検知することで回復プロセスを開始する。
【０００７】
【課題を解決するための手段】
本発明の実施例においては、Ｌ２ＴＰ接続は、Ｌ２ＴＰアクセスコンセントレーター（ＬＡＣ）とＬ２ＴＰネットワークサーバー（ＬＮＳ）という２つのパケットインタフェース間で設定される。これらの各パケットインタフェースの少なくとも一つを有する受信者は、失われた、あるいは故障したペイロードパケットの数が所定の値を超えた場合に、受信者開始回復アルゴリズム（ＲＩＲＡ）を実行する。とりわけ、受信者は以下の複数の変数を維持している。すなわち、「受信が期待される次の配列番号」（Ｓｒ）の値、及び、本発明において、もっとも最後に受信されたパケットから、現在受信された「次に送信された」（Ｎｓ）配列番号を保存してある変数であるＳｎｌである。
【０００８】
Ｓｎｌ＞Ｓｒ＋調整値の場合には、受信者部分はＳｒの値をＳｎｌに再設定（リセット）してすべてのパケットをプロトコールスタックの上位のレイヤーへと通過させる。調整値部分の変数の値は当該受信機が回復を開始する以前に受信機において破棄されたかあるいは故障したと考えられるパケットの数を表している。当該受信機はまた（ピギーバッキングまたは0長メッセージを通じて）、当該受信機における新しいＳｒの値を送信者に知らせるため通知（ＡＣＫ）パケットも送信する。
【０００９】
【発明の実施の形態】
ここで、本発明の概念について記述する前に、Ｌ２ＴＰ配列番号について簡潔な説明を行っておく。この分野におけるバックグラウンドに通じた者であるならば、「受信者開始回復アルゴリズム（ＲＩＲＡ）」というタイトルのセクションへスキップせよ。
【００１０】
Ｌ２ＴＰ配列番号
Ｌ２ＴＰでは、各人が複数の配列番号の状態を維持している状態にある。一つの配列番号の状態は、すべてのコントロールメッセージについて維持されており、トンネル内の各ユーザーセッションのペイロードにつき、セッション固有の配列番号の状態が維持されている。例えば、Ｌ２ＴＰアクセスコンセントレーター（ＬＡＣ）が、Ｌ２ＴＰネットワークサーバー（ＬＮＳ）との間でＬ２ＴＰトンネルを設定し、当該Ｌ２ＴＰトンネルが２つのユーザーセッションを伝送しているものとせよ。
【００１１】
そこで、ＬＡＣは、ＬＮＳへのコントロールメッセージについて一つの配列番号の状態、及び各ユーザーセッションにつき一つ、すなわち２つのセッション固有の配列番号の状態を維持している。さらに、送信者と受信者は、送信ウインドウのサイズ（パケット内の）を交渉する。この送信ウインドウのサイズは、先に送信されたパケット（以下でさらに記述する）について受信者からの通知を要求する以前に、送信者が送信し得るパケット数を表している。
【００１２】
配列番号の状態は、ＳｒとＳｓという状態変数の対で表されている。Sｒは、ある利用者からの次のメッセージについて、期待された配列の値を表している。Ssは、反対側の利用者に対して送信される次のメッセージについて、Ns領域の配列値を表している。Sr、Ssという各状態は、送信された最初のメッセージと各セッションについて受信される事が期待された最初のメッセージの場合、Nsの値は０である。これは、各新しいセッションについて、両者のSsとSrを０に初期化することに対応している。
【００１３】
Ｌ２ＴＰでは、パケットに２つの利用領域が存在する。すなわち、Nr（次に受信された）領域とNs（次に送信された）領域である。これらの2領域は、コントロールメッセージ内に常に存在しており、選択的にはペイロードパケット内に存在している。一方が非０長のメッセージを送信するたびに、当該セッションについての対応するSsの値を1ずつ増やす。この変化は、送信されるメッセージのNsにSrの現在の値をコピーされた後に生じる。出力メッセージは、対応するセッションについてSrの現在の値を、常にそのNr領域内に含んでいる。（しかしながら、任意のパケットが受信される前に送信された場合には、Nrは０である。）非０長のメッセージが、当該セッションの現在のSrの値と適合するNsの値をもって受信されると、Srの値は１だけ増やされる。ここで、コントロールセッションとペイロードセッションの両方について、メッセージが現在のSrの値よりも大きいNsの値をもって受信されるのであれば、Srの値は修正されないという点には留意されたい。
【００１４】
非０長メッセージを受信すると、受信者側は次の出力メッセージのNr領域内の更新されたSrの値を送り返す事によってメッセージを通知しなくてはならない。この更新されたSrの値は、当該利用者が送り返す事になりうる任意の非０長メッセージのNr領域内にピギーバックされることが可能である。
【００１５】
０長の本体をもったメッセージ（コントロールあるいはペイロード）は、パケットがNr及びNs領域を通信するためだけに用いられる。Nr領域及びNs領域は、上述のように充たされるが、配列番号の状態であるSsは増やされない。このように、０長メッセージの後に送信された非０長メッセージは先の０長メッセージと同じNsの値を含んでいる一方で、非０長メッセージの後に送信された０長メッセージは、新しいNsの値を含んでいることになる。
【００１６】
一方が、非０長メッセージを受信した後に伝送するメッセージをもっていない場合には、上述のようにタイムアウト（時間切れ）に伴い、SrとSsの最後の値を含む０長メッセージを送信することになる。このタイムアウト（時間切れ）についての示唆される値としては、受信者側によって計算されている場合には、往復時間（ＲＴＴ）の１／４であり、あるいは最大で１／２秒である。このようなタイムアウト（時間切れ）によって、受信者側は、利用者に向けられたペイロードメッセージを得るための合理的な機会を提供すべきで、それによって、受信されたメッセージのＡＣＫ（通知）はピギーバックされることが可能となる。（このような時間切れの値は、示された最大値として取り扱われるべきである。よりよいスループットを提供するため、受信者側はこのような時間切れを完全にスキップすべきであり、また、その受信ウインドウが充たされ、当該接続について送信すべき待ちデータが何ら存在していないか送信ウインドウが閉じており待ちデータを送信できない場合には、直ちに０長メッセージを送信すべきである。）
【００１７】
タイムアウト（時間切れ）に伴って、ＳｒはＬｒ（最後に送信されたＳｒの値）と比較され、両者が等しくない場合には、０長のＡＣＫ（通知）が発行される。両者が等しい場合には、ＡＣＫ（通知）は何ら出力されず、何らのアクションが取られる必要もない。新しいメッセージが受信される場合には、アクティブな状態ではあるが、タイマーは再初期化される必要はない。というのは、そのようなメッセージは、時間切れとなる際に通知されるからである。これより、推奨された時間切れ間隔に等しい最大の間隔をもって、周期的なＡＣＫが発行されることが保証される。このような時間間隔は、ペイロードメッセージが一方向のみに送信されている際に、伝送器における誤った通知の時間切れを生じさせない程度に短いものとなされるべきである。そのようなＡＣＫについては、元々始動していないデータパス上で送信されるので、性能についての影響は、無視できないにしてもわずかなものとなるはずである。
【００１８】
コントロールセッションについては、出力メッセージが失われた場合には、出力メッセージの再送信が結果的に受信者側に期待されたメッセージを提供することになるはずである。しかしながら、ペイロードメッセージについては失われたメッセージは再送信されることはない。
【００１９】
送信されたメッセージが失われた場合には、受信者側におけるＳｒの値は、最初に失われたペイロードメッセージのＮｓの値でひっかかる。Ｌ２ＴＰでは、送信者開始回復アルゴリズム（ＳＩＲＡ）は、図１で定義され、例示されている。ＳＩＲＡでは、送信者は伝送されたペイロードパケットが失われたときを決定するためにタイマー機構を用いている。このタイマー機構では、上述の伝送ウインドウ（あるいは「ウインドウの時間切れ」についての形式とも呼ばれることがある）及び所定の時間切れ値Ｔを用いている。
【００２０】
図１について、ウインドウのサイズは４パケットであることを前提としている。最初に、Ｌ２ＴＰの送信者がパケット＃１（すなわち、配列の番号が１であることを表している）をＬ２ＴＰの受信者へ送信する。受信することで、Ｌ２ＴＰの受信者は＃２という値のＮｒを、受信者が受信することを期待する次に配列されているパケットの値として含むパケットを送信することによって応答する。そこで、Ｌ２ＴＰの送信者は、＃２のパケットを送信する。しかしながら、図１に示されているように、このパケットについては、Ｌ２ＴＰの受信者には受信されない。続いて、Ｌ２ＴＰの送信者は、Ｌ２ＴＰの受信者が＃２という値のＮｒを含むパケットで応答する＃３のパケットを送信する。このように、Ｌ２ＴＰの送信者は、パケット＃２がＬ２ＴＰの受信者によって受信されたという通知を未だ受け取ってはいない。図１に示されているように、結果的には、Ｌ２ＴＰの送信者はパケット＃２についての通知を受け取ることなしに（すなわち、ウインドウの時間切れが生じている）、４つのパケット（＃２、＃３、＃４、＃５）を送信し、時間Ｔの間だけ伝送を停止している。
【００２１】
時間Ｔが経過する前に通知が何ら受け取られない場合には、Ｌ２ＴＰの送信者は、所定の「リセットＳｒ」（Ｒビット）というインジケーターを含むペイロードメッセージを伝送する。Ｒビットのインジケーターについての受信者側での検知によって、Ｎｓ＞Ｓｒである場合には、受信者側は自らのＳｒの値を、受信されたペイロードメッセージ（これはＲビットのインジケーターを含んでいる）内に含まれたＮｓの値に更新する。言い換えれば、Ｒビットのインジケーターは、ＳｒをＮｓの値にリセットするために用いられる。送信者は、受信者のＳｒの値を、一つ前の最初に失われたペイロードメッセージにリセットしたいのか、あるいは、送信者としての現在のＳｓの値にリセットしたいのか、決定することができる。もしＲビットのインジケーターが設定されていない場合には、０長メッセージを受信する側は自らのＳｒ変数を更新しない。
【００２２】
受信者開始回復アルゴリズム（ＲＩＲＡ）
本発明においては、レイヤー２トンネリングプロトコール（Ｌ２ＴＰ）の受信者は、Ｌ２ＴＰ送信者からパケットを受信し、失われたペイロードパケットを所定数検知することで回復プロセスを開始する。
【００２３】
図２は、本発明の原理にしたがった例示的な通信システム１００を示している。発明の概念以外、構成要素についてはよく知られているものであり、詳細については記述されない。例えば、パーソナルコンピュータ（ＰＣ）１０５は、公衆交換通信網（ＰＳＴＮ）１１０を通じてインターネット接続を設定するためＩＳＰ（インターネットサービスプロヴァイダー）Ａへダイヤルアップアクセスを行うデータ通信装置（示されていない）を含んでいる。同様に、通信システム１００の構成要素間での実線は、個々のエンドポイント間での公知の通信設備を表しているものである。
【００２４】
例えば、ＰＣ１０５とＰＳＴＮ１１０間での接続は、ローカルループ接続を表しており、ＩＳＰ（インターネットサービスプロヴァイダー）Ａとインターネット１３０間での接続は、同期光ネットワーク（ＳＯＮＥＴ）等を介した非同期転送モード（ＡＴＭ）によってサポートされている。
【００２５】
図２からわかるように、通信システム１００は、さらにＩＳＰ（インターネットサービスプロヴァイダー）Ａのネットワークで表されているような、ＩＳＰ  Ａを含んでいる。後者は、ネットワークアクセスサーバー（ＮＡＳ）１５５（ここではまた、Ｌ２ＴＰアクセスコンセントレーター（ＬＡＣ）とも呼称される）を含んでいる。このＮＡＳは、当業者間では公知の存在点（ＰＯＰ）ルーター（示されていない）、ローカルネットワーク１６０、ルーター１６５を含んでいる。
【００２６】
ＩＳＰ  Ａについては、遠隔的に位置した雇用者（ＰＣ１０５をもった）がネットワークサーバー（ＮＳ）１３５（ここではまた、Ｌ２ＴＰネットワークサーバー（ＬＮＳ）とも呼称される）を介して例示的な企業ネットワークにアクセスするという、仮装私設網（ＶＰＮ）サービスを提供しているものとせよ。ネットワークサーバーについては、幾つかの他機能のなかでも、ルーティングとファイヤーウォールの機能を提供している。（企業ネットワークについては、例えば、ＬＮＳの背後で適切に保護されたローカルエリアネットワーク（示されていない）の集合体となっているものとする。）ここでの記述のため、読み手は上述のＬ２ＴＰプロトコールには把握しているものとする。
【００２７】
ここで、図３についても参照されなくてはならない。図３は、本発明の原理にしたがった方法の例示的な流れ図を示したものである。ここでは、発明の概念は、ＰＣ１０５へ伝送するパケットを受信するという意味での、例えばＬＡＣのような、例示的なパケットインタフェースという文脈で記述される。しかしながら、本発明の概念は、そのように限定されるべきではなく、ＬＮＳのような、（なお、ＬＡＣとその他の各サービスは、ここでは記述されないが、既存のプログラミング技術を用いて、以下に述べられる方法を実行すべく適切にプログラミングがなされているものとする。）パケットを受信する任意のパケットインタフェースに対しても同じように当てはまるものである。
【００２８】
ステップ２０５では、ＬＡＣは、ＰＣ１０５とＬＮＳ間でデータを通信するため、ＬＮＳとＬ２ＴＰ接続２を設定する。ＬＮＳはもちろん企業ネットワーク（詳細には示されていない）へのゲートウエイを提供している。当該技術分野では公知なように、ステップ２０５は、ＰＣ１０５を用いている利用者（示されていない）とＬＮＳ間での呼をサポートする新たなトンネルを生成する結果となるか、あるいは、単にＬ２ＴＰ接続を既存のＬ２ＴＰトンネルに加えるか、いずれかとなる。（ここでは記述されていないが、ＬＡＣとＰＣ１０５の間にはポイント対ポイント接続１が存在しているものとせよ。すなわち、Ｌ２ＴＰ接続２を介したペイロードパケットは、ＬＡＣ／ＬＮＳの対間での利用者セッションのためにＬ２ＴＰでカプセル化された、ＰＰＰ（ポイント対ポイント）パケットとなっているのである。）
【００２９】
上述したように、Ｌ２ＴＰ接続には、コントロールセッションとペイロードセッションという２タイプのＬ２ＴＰセッションが存在している。（ここでまた、コントロール接続とペイロード接続という用語もそれぞれ用いられうるということに留意されたい。）本発明にしたがって、ステップ２１０では、Ｌ２ＴＰ接続が設定された後に、Ｌ２ＴＰの送信者（ここではＬＡＣで示されている）は、失われた、あるいは故障したペイロードパケットの数が所定の値を超えていることを検出して、受信者開始回復アルゴリズム（ＲＩＲＡ）を開始する。ＬＡＣは必要であれば、ステップ２１５でＬ２ＴＰ接続が切断されるまでＲＩＲＡを実行し続ける。
【００３０】
ここで図４へ戻ると、ステップ２１０のＲＩＲＡをさらに例示している、別のフローチャートが示されている。本発明の概念とは別に、ＬＡＣは、先行技術におけるものとして、上述の配列番号の状態を維持及び更新することに留意すべきである。ステップ３０５では、ＬＡＣはパケットを受信する。ステップ３１０では、ＬＡＣは上述の配列番号の状態を更新し、本発明にしたがって、さらに変数Ｓｎｌを維持している。この変数Ｓｎｌは、もっとも最後に受信されたパケット内にある、現在受信された「次に送信された」（Ｎｓ）配列番号の値を保存しているものである。
【００３１】
本発明にしたがって、ＬＡＣはステップ３１５を実行する。もし、Ｓｎｌの値が、（Ｓｒ＋調整値）よりも、大きくない場合には、ＬＡＣはステップ３０５においてパケットを受信し続ける。しかしながら、ステップ３１５において、Ｓｎｌの値が（Ｓｒ＋調整値）よりも大きい値である場合には、ＬＡＣはＳｒの値をＳｎｌの値に再設定（リセット）し、すべてのパケットをプロトコールスタック（示されていない）の上位のレイヤーへと通過させる。（ここで、当該受信者は、故障したパケット（示されていないを待ち状態のまま維持しているものとする。しかしながら、仮にパケットが順番に受信される場合には、さらなる処理のためにプロトコールスタック（示されていない）の上位のレイヤーへと通過される。）
【００３２】
調整値変数の値は、当該受信者が回復を開始する前に、受信者において破棄されたか、または故障したと考えられるパケットの数を表している。調整値の値のは、経験的に決定される。ここでの例の目的では、調整値の変数の値は、３パケットに等しいものであることを前提としている。加えて、ステップ３２０では、ＬＡＣは送信者（ここではＬＮＳ）に当該受信者における新しいＮｒの値を知らせるべく通知（ＡＣＫ）パケットを（ピギーバッキングまたは０長メッセージを通じて）送信する。
【００３３】
受信されたパケット配列の例示的なものとしては、図５に示されている。箱の配列は、各受信されたパケットについて、ＬＡＣ内の関連する受信データバッファー（示されていない）を表している。上述の例示的な方法を用いて、パケット番号２のものが受信された際には、ＬＡＣはＳｒとＳｎｌの値を３へ更新する。しかしながら、パケット番号３のものは受信されていない。（箱においてはＸというマークで示されている。）そこで、パケット番号４のものが受信されると、Ｓｒの値は３のままになっている一方で、Ｓｎｌの値はＬＡＣによって5へと増やされる。このような状況が続くのであれば、すなわち、パケット番号３のものが受信されない場合、パケット番号６のものが受信されると、Ｓｎｌの値がＳｒの値プラス３という調整値以上となってしまう。そこで、本発明にしたがって、Ｓｒの値はＳｎｌの値へと再設定（リセット）されるのである。
【００３４】
ここで、ウインドウサイズを往復時間の２、３倍に設定することで、相対的に高いスループットを与えるには十分である。さらに、時間切れ間隔は、往復時間に加えて２から４の標準的な変位に相当するように選択されることが可能である。最後に、送信者のウインドウがウインドウの時間切れの値以上の間閉じられている場合にも、当該送信者はＲビットのパケットを送信することは依然必要とされる。例えば、１２８パケットのサイズのバッファーが想定される。しかしながら、バッファーのサイズだけが当該ウインドウのサイズ以上のものとなる必要とされる。例示的なウインドウのサイズとしては、７パケットである。例示的なＲＴＴとしては、４パケットである。
【００３５】
本発明の特徴にしたがって、受信者は、当該受信者が遅延させたＡＣＫパケットを送信する「遅延フィードバック機能」を導入しうる。遅延フィードバック機能は、スループット、応答時間、帯域幅利用のオーバヘッド分といったものの間での性能のトレードオフに際してある程度の自由度を提供するものである。言いかえれば、順に受信されたパケットについて通知を発する（ＡＣＫする）ことを必ずしも即座に行わないでよい自由を選べるのである。
【００３６】
受信者は、そのようなＡＣＫを送信する、あるフィードバック間隔（変数「フィードバック間隔」あるいはＫで示されている）を選ぶことができる。１というフィードバック間隔については、受信者は常に順に受信されたパケットを直ちに通知する。３というフィードバック間隔については、受信者は任意のＡＣＫを３パケット分遅延させる。遅延フィードバック機能の流れ図については、図６に示されている。
【００３７】
図７を簡潔に振りかえって、本発明の原理にしたがったＲＩＲＡを実行するために用いられる代表的なパケットインタフェースについての高レベルでのブロック線図が示されている。パケットインタフェース６０５は、保存されたプログラム制御をベースとしたプロセッサーアーキテクチャーであって、プロセッサー６５０、メモリ６００（プログラム命令とデータを保存するため、例えば、図３、図４、図５等に示された例示的な方法を実行する。）、さらにパス６６６によってパケット通信装置へと結合させる通信インタフェース６６５を含んでいる。
【００３８】
これまで述べてきたことは、単に本発明の原理を例示するものに過ぎず、そのため、ここでは明示的には述べられてはいないものの、当該技術分野の当業者は、本発明の原理を具現化し、その技術思想及び保護範囲に含まれる様々な選択的な構成を行うことが可能であると考えられる。
【００３９】
【発明の効果】
本発明により、データセッションについては失われたペイロードメッセージは再送信されないＬ２ＴＰ接続において、Ｌ２ＴＰ受信者は、Ｌ２ＴＰ送信者からパケットを受信し、失われたペイロードパケットを所定数検知することで回復プロセスである受信者開始回復アルゴリズム（ＲＩＲＡ）を開始する方法が提供された。
【図面の簡単な説明】
【図１】  図１は、先行技術におけるＬ２ＴＰの送信順序を示している。
【図２】図２は、本発明の原理にしたがった通信システムを示している。
【図３】図３は、本発明の原理にしたがった方法の例示的な流れ図を示している。
【図４】図４は、本発明の原理にしたがった方法の例示的な流れ図を示している。
【図５】図５は、例示的な、受信されたパケットインタフェースを示している。
【図６】図６は、本発明の原理にしたがった方法の例示的な流れ図を示している。
【図７】図７は、本発明の原理を実施する例示的なパケットインタフェースのブロック線図を示している。
【符号の説明】
１００  通信システム
１０５  パーソナルコンピュータ（ＰＣ）
１１０  公衆交換網（ＰＳＴＮ）
１３０  インターネット
１３５  ネットワークサーバー（ＮＳ）
１５５  ネットワークアクセスサーバー（ＮＡＳ）
１６０  ローカルネットワーク
１６５  ルーター
２０５  Ｌ２ＴＰ接続を設定
２１０  送信機開始回復アルゴリズム
２１５  Ｌ２ＴＰ接続を切断
３０５  パケットを受信
３１０  Ｓｒ、Ｓｎｌを更新
３１５  Ｓｎｌ＞Ｓｒ＋調整値
３２０  ＳｒをＳｎｌへと再設定（リセット）
新しいＳｒの値を送信者へ設定
４０５  配列しているパケットを受信
４１０  ＡＣＫを送信する前にＫ個のパケット分待つ
６０５  パケットインタフェース
６５０  プロセッサー
６６０  メモリ
６６５  通信インタフェース
６６６  パス
【図１】
0003732720.tif 000002
【図２】
0003732720.tif 000003
【図３】
0003732720.tif 000004
【図４】
0003732720.tif 000005
【図５】
0003732720.tif 000006
【図６】
0003732720.tif 000007
【図７】
0003732720.tif 000008