JP2001045094A - レイヤー２トンネリングプロトコール（ｌ２ｔｐ）向け受信者開始回復アルゴリズム（ｒｉｒａ） - Google Patents
レイヤー２トンネリングプロトコール（ｌ２ｔｐ）向け受信者開始回復アルゴリズム（ｒｉｒａ）Info
- Publication number
- JP2001045094A JP2001045094A JP2000206313A JP2000206313A JP2001045094A JP 2001045094 A JP2001045094 A JP 2001045094A JP 2000206313 A JP2000206313 A JP 2000206313A JP 2000206313 A JP2000206313 A JP 2000206313A JP 2001045094 A JP2001045094 A JP 2001045094A
- Authority
- JP
- Japan
- Prior art keywords
- l2tp
- value
- packets
- packet
- received
- 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.)
- Granted
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1829—Arrangements specially adapted for the receiver end
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
Abstract
(57)【要約】
【課題】 レイヤー２トンネリングプロトコール（Ｌ２
ＴＰ）向け受信者開始回復アルゴリズム（ＲＩＲＡ） 【解決手段】本発明のレイヤー２トンネリングプロトコ
ール（Ｌ２ＴＰ）向け受信者開始回復アルゴリズム（Ｒ
ＩＲＡ）では、損失あるいは故障したペイロードパケッ
トの数が所定値を超えている場合に、Ｌ２ＴＰ受信者が
受信者開始アルゴリズム（ＲＩＲＡ）を実行する。受信
者は、「受信が期待される次の配列番号」（Ｓｒ）、現
在受信した「次に送信された」（Ｎｓ）配列番号の値を
最後に受信したパケットから保存したＳｎｌという変数
を維持する。Ｓｎｌ＞Ｓｒ＋調整値のとき、受信者側は
Ｓｒの値をＳｎｌの値へ再設定し、全パケットをプロト
コールスタックの上位レイヤーへと通過させ、さらに新
しいＳｒの値を送信者に知らせる。
ＴＰ）向け受信者開始回復アルゴリズム（ＲＩＲＡ） 【解決手段】本発明のレイヤー２トンネリングプロトコ
ール（Ｌ２ＴＰ）向け受信者開始回復アルゴリズム（Ｒ
ＩＲＡ）では、損失あるいは故障したペイロードパケッ
トの数が所定値を超えている場合に、Ｌ２ＴＰ受信者が
受信者開始アルゴリズム（ＲＩＲＡ）を実行する。受信
者は、「受信が期待される次の配列番号」（Ｓｒ）、現
在受信した「次に送信された」（Ｎｓ）配列番号の値を
最後に受信したパケットから保存したＳｎｌという変数
を維持する。Ｓｎｌ＞Ｓｒ＋調整値のとき、受信者側は
Ｓｒの値をＳｎｌの値へ再設定し、全パケットをプロト
コールスタックの上位レイヤーへと通過させ、さらに新
しいＳｒの値を送信者に知らせる。
Description
【０００１】
【発明の属する技術分野】本発明は、通信、とりわけパ
ケット通信システムに関するものである。
ケット通信システムに関するものである。
【０００２】
【従来の技術】レイヤー２トンネリングプロトコール
（Ｌ２ＴＰ）（例えば、K.Hamzeh,T.Kolar,M.Littlewoo
d,G.Singh Pall,J.Valencia,W.Verthein,W.M.Townsley,
B.Palter,A.rubens"Layer Two Tunneling Protocol(L2T
P)",Internet draft,March 1998を参照せよ。）は、イ
ンターネット・エンジニアリング・タスクフォース（IE
TF）L2TPワーキンググループによって設計され、インタ
ーネットサービスプロヴァイダー（ISP）が、従来型の
登録されたインターネットプロトコール（IP）アドレス
をベースとしたサービス以外のサービスを提供すること
を可能にするものである。
（Ｌ２ＴＰ）（例えば、K.Hamzeh,T.Kolar,M.Littlewoo
d,G.Singh Pall,J.Valencia,W.Verthein,W.M.Townsley,
B.Palter,A.rubens"Layer Two Tunneling Protocol(L2T
P)",Internet draft,March 1998を参照せよ。）は、イ
ンターネット・エンジニアリング・タスクフォース（IE
TF）L2TPワーキンググループによって設計され、インタ
ーネットサービスプロヴァイダー（ISP）が、従来型の
登録されたインターネットプロトコール（IP）アドレス
をベースとしたサービス以外のサービスを提供すること
を可能にするものである。
【０００３】例えば、インターネットサービスプロヴァ
イダー（ISP）は、Ｌ２ＴＰトンネル（あるいはＬ２Ｔ
Ｐ接続）を経由することで、顧客が企業イントラネット
へアクセスすることを可能とする仮想ダイヤルアップサ
ービスを提供することができるようになる。
イダー（ISP）は、Ｌ２ＴＰトンネル（あるいはＬ２Ｔ
Ｐ接続）を経由することで、顧客が企業イントラネット
へアクセスすることを可能とする仮想ダイヤルアップサ
ービスを提供することができるようになる。
【０００４】Ｌ２ＴＰ接続においては、コントロールセ
ッション（制御セッション）とデータセッションという
２タイプのセッションが存在する。コントロールセッシ
ョンについては、Ｌ２ＴＰは、伝送の間に失われたコン
トロールメッセージ（コントロールパケットとしても知
られている）の再送信スキームを定義している。しかし
ながら、Ｌ２ＴＰは、データセッションについては失わ
れたペイロードメッセージ（ペイロードパケットとして
も知られている）は再送信しない。
ッション（制御セッション）とデータセッションという
２タイプのセッションが存在する。コントロールセッシ
ョンについては、Ｌ２ＴＰは、伝送の間に失われたコン
トロールメッセージ（コントロールパケットとしても知
られている）の再送信スキームを定義している。しかし
ながら、Ｌ２ＴＰは、データセッションについては失わ
れたペイロードメッセージ（ペイロードパケットとして
も知られている）は再送信しない。
【０００５】その代わりに、ペイロードパケットが失わ
れた際には、Ｌ２ＴＰは、受信機における「次に受信し
た」（Ｎｒ）配列番号をリセットする受信者開始回復ア
ルゴリズム（ＲＩＲＡ）を定義している。とりわけ、伝
送ウインドが時間切れとなる場合（すなわち、送信者
が、先に送信したパケットを有している場合）、送信者
は、所定の「リセットＳｒ」（Ｒビット）インジケータ
ーを含むペイロードメッセージを伝送する。このインジ
ケーターはＮｒ（受信機における）の値を、最初に失わ
れたパケットをちょうど超える値か、あるいは送信者が
現在送信している配列番号の値に再設定（リセット）す
る。
れた際には、Ｌ２ＴＰは、受信機における「次に受信し
た」（Ｎｒ）配列番号をリセットする受信者開始回復ア
ルゴリズム（ＲＩＲＡ）を定義している。とりわけ、伝
送ウインドが時間切れとなる場合（すなわち、送信者
が、先に送信したパケットを有している場合）、送信者
は、所定の「リセットＳｒ」（Ｒビット）インジケータ
ーを含むペイロードメッセージを伝送する。このインジ
ケーターはＮｒ（受信機における）の値を、最初に失わ
れたパケットをちょうど超える値か、あるいは送信者が
現在送信している配列番号の値に再設定（リセット）す
る。
【０００６】
【発明が解決しようとする課題】本発明においては、Ｌ
２ＴＰ受信者は、Ｌ２ＴＰ送信者からパケットを受信
し、失われたペイロードパケットを所定数検知すること
で回復プロセスを開始する。
２ＴＰ受信者は、Ｌ２ＴＰ送信者からパケットを受信
し、失われたペイロードパケットを所定数検知すること
で回復プロセスを開始する。
【０００７】
【課題を解決するための手段】本発明の実施例において
は、Ｌ２ＴＰ接続は、Ｌ２ＴＰアクセスコンセントレー
ター（ＬＡＣ）とＬ２ＴＰネットワークサーバー（ＬＮ
Ｓ）という２つのパケットインタフェース間で設定され
る。これらの各パケットインタフェースの少なくとも一
つを有する受信者は、失われた、あるいは故障したペイ
ロードパケットの数が所定の値を超えた場合に、受信者
開始回復アルゴリズム（ＲＩＲＡ）を実行する。とりわ
け、受信者は以下の複数の変数を維持している。すなわ
ち、「受信が期待される次の配列番号」（Ｓｒ）の値、
及び、本発明において、もっとも最後に受信されたパケ
ットから、現在受信された「次に送信された」（Ｎｓ）
配列番号を保存してある変数であるＳｎｌである。
は、Ｌ２ＴＰ接続は、Ｌ２ＴＰアクセスコンセントレー
ター（ＬＡＣ）とＬ２ＴＰネットワークサーバー（ＬＮ
Ｓ）という２つのパケットインタフェース間で設定され
る。これらの各パケットインタフェースの少なくとも一
つを有する受信者は、失われた、あるいは故障したペイ
ロードパケットの数が所定の値を超えた場合に、受信者
開始回復アルゴリズム（ＲＩＲＡ）を実行する。とりわ
け、受信者は以下の複数の変数を維持している。すなわ
ち、「受信が期待される次の配列番号」（Ｓｒ）の値、
及び、本発明において、もっとも最後に受信されたパケ
ットから、現在受信された「次に送信された」（Ｎｓ）
配列番号を保存してある変数であるＳｎｌである。
【０００８】Ｓｎｌ＞Ｓｒ＋調整値の場合には、受信者
部分はＳｒの値をＳｎｌに再設定（リセット）してすべ
てのパケットをプロトコールスタックの上位のレイヤー
へと通過させる。調整値部分の変数の値は当該受信機が
回復を開始する以前に受信機において破棄されたかある
いは故障したと考えられるパケットの数を表している。
当該受信機はまた（ピギーバッキングまたは0長メッセ
ージを通じて）、当該受信機における新しいＳｒの値を
送信者に知らせるため通知（ＡＣＫ）パケットも送信す
る。
部分はＳｒの値をＳｎｌに再設定（リセット）してすべ
てのパケットをプロトコールスタックの上位のレイヤー
へと通過させる。調整値部分の変数の値は当該受信機が
回復を開始する以前に受信機において破棄されたかある
いは故障したと考えられるパケットの数を表している。
当該受信機はまた（ピギーバッキングまたは0長メッセ
ージを通じて）、当該受信機における新しいＳｒの値を
送信者に知らせるため通知（ＡＣＫ）パケットも送信す
る。
【０００９】
【発明の実施の形態】ここで、本発明の概念について記
述する前に、Ｌ２ＴＰ配列番号について簡潔な説明を行
っておく。この分野におけるバックグラウンドに通じた
者であるならば、「受信者開始回復アルゴリズム（ＲＩ
ＲＡ）」というタイトルのセクションへスキップせよ。
述する前に、Ｌ２ＴＰ配列番号について簡潔な説明を行
っておく。この分野におけるバックグラウンドに通じた
者であるならば、「受信者開始回復アルゴリズム（ＲＩ
ＲＡ）」というタイトルのセクションへスキップせよ。
【００１０】Ｌ２ＴＰ配列番号 Ｌ２ＴＰでは、各人が複数の配列番号の状態を維持して
いる状態にある。一つの配列番号の状態は、すべてのコ
ントロールメッセージについて維持されており、トンネ
ル内の各ユーザーセッションのペイロードにつき、セッ
ション固有の配列番号の状態が維持されている。例え
ば、Ｌ２ＴＰアクセスコンセントレーター（ＬＡＣ）
が、Ｌ２ＴＰネットワークサーバー（ＬＮＳ）との間で
Ｌ２ＴＰトンネルを設定し、当該Ｌ２ＴＰトンネルが２
つのユーザーセッションを伝送しているものとせよ。
いる状態にある。一つの配列番号の状態は、すべてのコ
ントロールメッセージについて維持されており、トンネ
ル内の各ユーザーセッションのペイロードにつき、セッ
ション固有の配列番号の状態が維持されている。例え
ば、Ｌ２ＴＰアクセスコンセントレーター（ＬＡＣ）
が、Ｌ２ＴＰネットワークサーバー（ＬＮＳ）との間で
Ｌ２ＴＰトンネルを設定し、当該Ｌ２ＴＰトンネルが２
つのユーザーセッションを伝送しているものとせよ。
【００１１】そこで、ＬＡＣは、ＬＮＳへのコントロー
ルメッセージについて一つの配列番号の状態、及び各ユ
ーザーセッションにつき一つ、すなわち２つのセッショ
ン固有の配列番号の状態を維持している。さらに、送信
者と受信者は、送信ウインドウのサイズ（パケット内
の）を交渉する。この送信ウインドウのサイズは、先に
送信されたパケット（以下でさらに記述する）について
受信者からの通知を要求する以前に、送信者が送信し得
るパケット数を表している。
ルメッセージについて一つの配列番号の状態、及び各ユ
ーザーセッションにつき一つ、すなわち２つのセッショ
ン固有の配列番号の状態を維持している。さらに、送信
者と受信者は、送信ウインドウのサイズ（パケット内
の）を交渉する。この送信ウインドウのサイズは、先に
送信されたパケット（以下でさらに記述する）について
受信者からの通知を要求する以前に、送信者が送信し得
るパケット数を表している。
【００１２】配列番号の状態は、ＳｒとＳｓという状態
変数の対で表されている。Sｒは、ある利用者からの次
のメッセージについて、期待された配列の値を表してい
る。Ssは、反対側の利用者に対して送信される次のメッ
セージについて、Ns領域の配列値を表している。Sr、Ss
という各状態は、送信された最初のメッセージと各セッ
ションについて受信される事が期待された最初のメッセ
ージの場合、Nsの値は０である。これは、各新しいセッ
ションについて、両者のSsとSrを０に初期化することに
対応している。
変数の対で表されている。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（次に受信された）領域とNs
（次に送信された）領域である。これらの2領域は、コ
ントロールメッセージ内に常に存在しており、選択的に
はペイロードパケット内に存在している。一方が非０長
のメッセージを送信するたびに、当該セッションについ
ての対応するSsの値を1ずつ増やす。この変化は、送信
されるメッセージのNsにSrの現在の値をコピーされた後
に生じる。出力メッセージは、対応するセッションにつ
いてSrの現在の値を、常にそのNr領域内に含んでいる。
（しかしながら、任意のパケットが受信される前に送信
された場合には、Nrは０である。）非０長のメッセージ
が、当該セッションの現在のSrの値と適合するNsの値を
もって受信されると、Srの値は１だけ増やされる。ここ
で、コントロールセッションとペイロードセッションの
両方について、メッセージが現在のSrの値よりも大きい
Nsの値をもって受信されるのであれば、Srの値は修正さ
れないという点には留意されたい。
【００１４】非０長メッセージを受信すると、受信者側
は次の出力メッセージのNr領域内の更新されたSrの値を
送り返す事によってメッセージを通知しなくてはならな
い。この更新されたSrの値は、当該利用者が送り返す事
になりうる任意の非０長メッセージのNr領域内にピギー
バックされることが可能である。
は次の出力メッセージのNr領域内の更新されたSrの値を
送り返す事によってメッセージを通知しなくてはならな
い。この更新されたSrの値は、当該利用者が送り返す事
になりうる任意の非０長メッセージのNr領域内にピギー
バックされることが可能である。
【００１５】０長の本体をもったメッセージ（コントロ
ールあるいはペイロード）は、パケットがNr及びNs領域
を通信するためだけに用いられる。Nr領域及びNs領域
は、上述のように充たされるが、配列番号の状態である
Ssは増やされない。このように、０長メッセージの後に
送信された非０長メッセージは先の０長メッセージと同
じNsの値を含んでいる一方で、非０長メッセージの後に
送信された０長メッセージは、新しいNsの値を含んでい
ることになる。
ールあるいはペイロード）は、パケットがNr及びNs領域
を通信するためだけに用いられる。Nr領域及びNs領域
は、上述のように充たされるが、配列番号の状態である
Ssは増やされない。このように、０長メッセージの後に
送信された非０長メッセージは先の０長メッセージと同
じNsの値を含んでいる一方で、非０長メッセージの後に
送信された０長メッセージは、新しいNsの値を含んでい
ることになる。
【００１６】一方が、非０長メッセージを受信した後に
伝送するメッセージをもっていない場合には、上述のよ
うにタイムアウト（時間切れ）に伴い、SrとSsの最後の
値を含む０長メッセージを送信することになる。このタ
イムアウト（時間切れ）についての示唆される値として
は、受信者側によって計算されている場合には、往復時
間（ＲＴＴ）の１／４であり、あるいは最大で１／２秒
である。このようなタイムアウト（時間切れ）によっ
て、受信者側は、利用者に向けられたペイロードメッセ
ージを得るための合理的な機会を提供すべきで、それに
よって、受信されたメッセージのＡＣＫ（通知）はピギ
ーバックされることが可能となる。（このような時間切
れの値は、示された最大値として取り扱われるべきであ
る。よりよいスループットを提供するため、受信者側は
このような時間切れを完全にスキップすべきであり、ま
た、その受信ウインドウが充たされ、当該接続について
送信すべき待ちデータが何ら存在していないか送信ウイ
ンドウが閉じており待ちデータを送信できない場合に
は、直ちに０長メッセージを送信すべきである。）
伝送するメッセージをもっていない場合には、上述のよ
うにタイムアウト（時間切れ）に伴い、SrとSsの最後の
値を含む０長メッセージを送信することになる。このタ
イムアウト（時間切れ）についての示唆される値として
は、受信者側によって計算されている場合には、往復時
間（ＲＴＴ）の１／４であり、あるいは最大で１／２秒
である。このようなタイムアウト（時間切れ）によっ
て、受信者側は、利用者に向けられたペイロードメッセ
ージを得るための合理的な機会を提供すべきで、それに
よって、受信されたメッセージのＡＣＫ（通知）はピギ
ーバックされることが可能となる。（このような時間切
れの値は、示された最大値として取り扱われるべきであ
る。よりよいスループットを提供するため、受信者側は
このような時間切れを完全にスキップすべきであり、ま
た、その受信ウインドウが充たされ、当該接続について
送信すべき待ちデータが何ら存在していないか送信ウイ
ンドウが閉じており待ちデータを送信できない場合に
は、直ちに０長メッセージを送信すべきである。）
【００１７】タイムアウト（時間切れ）に伴って、Ｓｒ
はＬｒ（最後に送信されたＳｒの値）と比較され、両者
が等しくない場合には、０長のＡＣＫ（通知）が発行さ
れる。両者が等しい場合には、ＡＣＫ（通知）は何ら出
力されず、何らのアクションが取られる必要もない。新
しいメッセージが受信される場合には、アクティブな状
態ではあるが、タイマーは再初期化される必要はない。
というのは、そのようなメッセージは、時間切れとなる
際に通知されるからである。これより、推奨された時間
切れ間隔に等しい最大の間隔をもって、周期的なＡＣＫ
が発行されることが保証される。このような時間間隔
は、ペイロードメッセージが一方向のみに送信されてい
る際に、伝送器における誤った通知の時間切れを生じさ
せない程度に短いものとなされるべきである。そのよう
なＡＣＫについては、元々始動していないデータパス上
で送信されるので、性能についての影響は、無視できな
いにしてもわずかなものとなるはずである。
はＬｒ（最後に送信されたＳｒの値）と比較され、両者
が等しくない場合には、０長のＡＣＫ（通知）が発行さ
れる。両者が等しい場合には、ＡＣＫ（通知）は何ら出
力されず、何らのアクションが取られる必要もない。新
しいメッセージが受信される場合には、アクティブな状
態ではあるが、タイマーは再初期化される必要はない。
というのは、そのようなメッセージは、時間切れとなる
際に通知されるからである。これより、推奨された時間
切れ間隔に等しい最大の間隔をもって、周期的なＡＣＫ
が発行されることが保証される。このような時間間隔
は、ペイロードメッセージが一方向のみに送信されてい
る際に、伝送器における誤った通知の時間切れを生じさ
せない程度に短いものとなされるべきである。そのよう
なＡＣＫについては、元々始動していないデータパス上
で送信されるので、性能についての影響は、無視できな
いにしてもわずかなものとなるはずである。
【００１８】コントロールセッションについては、出力
メッセージが失われた場合には、出力メッセージの再送
信が結果的に受信者側に期待されたメッセージを提供す
ることになるはずである。しかしながら、ペイロードメ
ッセージについては失われたメッセージは再送信される
ことはない。
メッセージが失われた場合には、出力メッセージの再送
信が結果的に受信者側に期待されたメッセージを提供す
ることになるはずである。しかしながら、ペイロードメ
ッセージについては失われたメッセージは再送信される
ことはない。
【００１９】送信されたメッセージが失われた場合に
は、受信者側におけるＳｒの値は、最初に失われたペイ
ロードメッセージのＮｓの値でひっかかる。Ｌ２ＴＰで
は、送信者開始回復アルゴリズム（ＳＩＲＡ）は、図１
で定義され、例示されている。ＳＩＲＡでは、送信者は
伝送されたペイロードパケットが失われたときを決定す
るためにタイマー機構を用いている。このタイマー機構
では、上述の伝送ウインドウ（あるいは「ウインドウの
時間切れ」についての形式とも呼ばれることがある）及
び所定の時間切れ値Ｔを用いている。
は、受信者側におけるＳｒの値は、最初に失われたペイ
ロードメッセージのＮｓの値でひっかかる。Ｌ２ＴＰで
は、送信者開始回復アルゴリズム（ＳＩＲＡ）は、図１
で定義され、例示されている。ＳＩＲＡでは、送信者は
伝送されたペイロードパケットが失われたときを決定す
るためにタイマー機構を用いている。このタイマー機構
では、上述の伝送ウインドウ（あるいは「ウインドウの
時間切れ」についての形式とも呼ばれることがある）及
び所定の時間切れ値Ｔを用いている。
【００２０】図１について、ウインドウのサイズは４パ
ケットであることを前提としている。最初に、Ｌ２ＴＰ
の送信者がパケット＃１（すなわち、配列の番号が１で
あることを表している）をＬ２ＴＰの受信者へ送信す
る。受信することで、Ｌ２ＴＰの受信者は＃２という値
のＮｒを、受信者が受信することを期待する次に配列さ
れているパケットの値として含むパケットを送信するこ
とによって応答する。そこで、Ｌ２ＴＰの送信者は、＃
２のパケットを送信する。しかしながら、図１に示され
ているように、このパケットについては、Ｌ２ＴＰの受
信者には受信されない。続いて、Ｌ２ＴＰの送信者は、
Ｌ２ＴＰの受信者が＃２という値のＮｒを含むパケット
で応答する＃３のパケットを送信する。このように、Ｌ
２ＴＰの送信者は、パケット＃２がＬ２ＴＰの受信者に
よって受信されたという通知を未だ受け取ってはいな
い。図１に示されているように、結果的には、Ｌ２ＴＰ
の送信者はパケット＃２についての通知を受け取ること
なしに（すなわち、ウインドウの時間切れが生じてい
る）、４つのパケット（＃２、＃３、＃４、＃５）を送
信し、時間Ｔの間だけ伝送を停止している。
ケットであることを前提としている。最初に、Ｌ２ＴＰ
の送信者がパケット＃１（すなわち、配列の番号が１で
あることを表している）をＬ２ＴＰの受信者へ送信す
る。受信することで、Ｌ２ＴＰの受信者は＃２という値
のＮｒを、受信者が受信することを期待する次に配列さ
れているパケットの値として含むパケットを送信するこ
とによって応答する。そこで、Ｌ２ＴＰの送信者は、＃
２のパケットを送信する。しかしながら、図１に示され
ているように、このパケットについては、Ｌ２ＴＰの受
信者には受信されない。続いて、Ｌ２ＴＰの送信者は、
Ｌ２ＴＰの受信者が＃２という値のＮｒを含むパケット
で応答する＃３のパケットを送信する。このように、Ｌ
２ＴＰの送信者は、パケット＃２がＬ２ＴＰの受信者に
よって受信されたという通知を未だ受け取ってはいな
い。図１に示されているように、結果的には、Ｌ２ＴＰ
の送信者はパケット＃２についての通知を受け取ること
なしに（すなわち、ウインドウの時間切れが生じてい
る）、４つのパケット（＃２、＃３、＃４、＃５）を送
信し、時間Ｔの間だけ伝送を停止している。
【００２１】時間Ｔが経過する前に通知が何ら受け取ら
れない場合には、Ｌ２ＴＰの送信者は、所定の「リセッ
トＳｒ」（Ｒビット）というインジケーターを含むペイ
ロードメッセージを伝送する。Ｒビットのインジケータ
ーについての受信者側での検知によって、Ｎｓ＞Ｓｒで
ある場合には、受信者側は自らのＳｒの値を、受信され
たペイロードメッセージ（これはＲビットのインジケー
ターを含んでいる）内に含まれたＮｓの値に更新する。
言い換えれば、Ｒビットのインジケーターは、ＳｒをＮ
ｓの値にリセットするために用いられる。送信者は、受
信者のＳｒの値を、一つ前の最初に失われたペイロード
メッセージにリセットしたいのか、あるいは、送信者と
しての現在のＳｓの値にリセットしたいのか、決定する
ことができる。もしＲビットのインジケーターが設定さ
れていない場合には、０長メッセージを受信する側は自
らのＳｒ変数を更新しない。
れない場合には、Ｌ２ＴＰの送信者は、所定の「リセッ
トＳｒ」（Ｒビット）というインジケーターを含むペイ
ロードメッセージを伝送する。Ｒビットのインジケータ
ーについての受信者側での検知によって、Ｎｓ＞Ｓｒで
ある場合には、受信者側は自らのＳｒの値を、受信され
たペイロードメッセージ（これはＲビットのインジケー
ターを含んでいる）内に含まれたＮｓの値に更新する。
言い換えれば、Ｒビットのインジケーターは、ＳｒをＮ
ｓの値にリセットするために用いられる。送信者は、受
信者のＳｒの値を、一つ前の最初に失われたペイロード
メッセージにリセットしたいのか、あるいは、送信者と
しての現在のＳｓの値にリセットしたいのか、決定する
ことができる。もしＲビットのインジケーターが設定さ
れていない場合には、０長メッセージを受信する側は自
らのＳｒ変数を更新しない。
【００２２】受信者開始回復アルゴリズム（ＲＩＲＡ） 本発明においては、レイヤー２トンネリングプロトコー
ル（Ｌ２ＴＰ）の受信者は、Ｌ２ＴＰ送信者からパケッ
トを受信し、失われたペイロードパケットを所定数検知
することで回復プロセスを開始する。
ル（Ｌ２ＴＰ）の受信者は、Ｌ２ＴＰ送信者からパケッ
トを受信し、失われたペイロードパケットを所定数検知
することで回復プロセスを開始する。
【００２３】図２は、本発明の原理にしたがった例示的
な通信システム１００を示している。発明の概念以外、
構成要素についてはよく知られているものであり、詳細
については記述されない。例えば、パーソナルコンピュ
ータ（ＰＣ）１０５は、公衆交換通信網（ＰＳＴＮ）１
１０を通じてインターネット接続を設定するためＩＳＰ
（インターネットサービスプロヴァイダー）Ａへダイヤ
ルアップアクセスを行うデータ通信装置（示されていな
い）を含んでいる。同様に、通信システム１００の構成
要素間での実線は、個々のエンドポイント間での公知の
通信設備を表しているものである。
な通信システム１００を示している。発明の概念以外、
構成要素についてはよく知られているものであり、詳細
については記述されない。例えば、パーソナルコンピュ
ータ（ＰＣ）１０５は、公衆交換通信網（ＰＳＴＮ）１
１０を通じてインターネット接続を設定するためＩＳＰ
（インターネットサービスプロヴァイダー）Ａへダイヤ
ルアップアクセスを行うデータ通信装置（示されていな
い）を含んでいる。同様に、通信システム１００の構成
要素間での実線は、個々のエンドポイント間での公知の
通信設備を表しているものである。
【００２４】例えば、ＰＣ１０５とＰＳＴＮ１１０間で
の接続は、ローカルループ接続を表しており、ＩＳＰ
（インターネットサービスプロヴァイダー）Ａとインタ
ーネット１３０間での接続は、同期光ネットワーク（Ｓ
ＯＮＥＴ）等を介した非同期転送モード（ＡＴＭ）によ
ってサポートされている。
の接続は、ローカルループ接続を表しており、ＩＳＰ
（インターネットサービスプロヴァイダー）Ａとインタ
ーネット１３０間での接続は、同期光ネットワーク（Ｓ
ＯＮＥＴ）等を介した非同期転送モード（ＡＴＭ）によ
ってサポートされている。
【００２５】図２からわかるように、通信システム１０
０は、さらにＩＳＰ（インターネットサービスプロヴァ
イダー）Ａのネットワークで表されているような、ＩＳ
ＰＡを含んでいる。後者は、ネットワークアクセスサー
バー（ＮＡＳ）１５５（ここではまた、Ｌ２ＴＰアクセ
スコンセントレーター（ＬＡＣ）とも呼称される）を含
んでいる。このＮＡＳは、当業者間では公知の存在点
（ＰＯＰ）ルーター（示されていない）、ローカルネッ
トワーク１６０、ルーター１６５を含んでいる。
０は、さらにＩＳＰ（インターネットサービスプロヴァ
イダー）Ａのネットワークで表されているような、ＩＳ
ＰＡを含んでいる。後者は、ネットワークアクセスサー
バー（ＮＡＳ）１５５（ここではまた、Ｌ２ＴＰアクセ
スコンセントレーター（ＬＡＣ）とも呼称される）を含
んでいる。このＮＡＳは、当業者間では公知の存在点
（ＰＯＰ）ルーター（示されていない）、ローカルネッ
トワーク１６０、ルーター１６５を含んでいる。
【００２６】ＩＳＰ Ａについては、遠隔的に位置した
雇用者（ＰＣ１０５をもった）がネットワークサーバー
（ＮＳ）１３５（ここではまた、Ｌ２ＴＰネットワーク
サーバー（ＬＮＳ）とも呼称される）を介して例示的な
企業ネットワークにアクセスするという、仮装私設網
（ＶＰＮ）サービスを提供しているものとせよ。ネット
ワークサーバーについては、幾つかの他機能のなかで
も、ルーティングとファイヤーウォールの機能を提供し
ている。（企業ネットワークについては、例えば、ＬＮ
Ｓの背後で適切に保護されたローカルエリアネットワー
ク（示されていない）の集合体となっているものとす
る。）ここでの記述のため、読み手は上述のＬ２ＴＰプ
ロトコールには把握しているものとする。
雇用者（ＰＣ１０５をもった）がネットワークサーバー
（ＮＳ）１３５（ここではまた、Ｌ２ＴＰネットワーク
サーバー（ＬＮＳ）とも呼称される）を介して例示的な
企業ネットワークにアクセスするという、仮装私設網
（ＶＰＮ）サービスを提供しているものとせよ。ネット
ワークサーバーについては、幾つかの他機能のなかで
も、ルーティングとファイヤーウォールの機能を提供し
ている。（企業ネットワークについては、例えば、ＬＮ
Ｓの背後で適切に保護されたローカルエリアネットワー
ク（示されていない）の集合体となっているものとす
る。）ここでの記述のため、読み手は上述のＬ２ＴＰプ
ロトコールには把握しているものとする。
【００２７】ここで、図３についても参照されなくては
ならない。図３は、本発明の原理にしたがった方法の例
示的な流れ図を示したものである。ここでは、発明の概
念は、ＰＣ１１０へ伝送するパケットを受信するという
意味での、例えばＬＡＣのような、例示的なパケットイ
ンタフェースという文脈で記述される。しかしながら、
本発明の概念は、そのように限定されるべきではなく、
ＬＮＳのような、（なお、ＬＡＣとその他の各サービス
は、ここでは記述されないが、既存のプログラミング技
術を用いて、以下に述べられる方法を実行すべく適切に
プログラミングがなされているものとする。）パケット
を受信する任意のパケットインタフェースに対しても同
じように当てはまるものである。
ならない。図３は、本発明の原理にしたがった方法の例
示的な流れ図を示したものである。ここでは、発明の概
念は、ＰＣ１１０へ伝送するパケットを受信するという
意味での、例えばＬＡＣのような、例示的なパケットイ
ンタフェースという文脈で記述される。しかしながら、
本発明の概念は、そのように限定されるべきではなく、
ＬＮＳのような、（なお、ＬＡＣとその他の各サービス
は、ここでは記述されないが、既存のプログラミング技
術を用いて、以下に述べられる方法を実行すべく適切に
プログラミングがなされているものとする。）パケット
を受信する任意のパケットインタフェースに対しても同
じように当てはまるものである。
【００２８】ステップ２０５では、ＬＡＣは、ＰＣ１１
０とＬＮＳ間でデータを通信するため、ＬＮＳとＬ２Ｔ
Ｐ接続２を設定する。ＬＮＳはもちろん企業ネットワー
ク（詳細には示されていない）へのゲートウエイを提供
している。当該技術分野では公知なように、ステップ２
０５は、ＰＣ１１０を用いている利用者（示されていな
い）とＬＮＳ間での呼をサポートする新たなトンネルを
生成する結果となるか、あるいは、単にＬ２ＴＰ接続を
既存のＬ２ＴＰトンネルに加えるか、いずれかとなる。
（ここでは記述されていないが、ＬＡＣとＰＣ１０５の
間にはポイント対ポイント接続１が存在しているものと
せよ。すなわち、Ｌ２ＴＰ接続２を介したペイロードパ
ケットは、ＬＡＣ／ＬＮＳの対間での利用者セッション
のためにＬ２ＴＰでカプセル化された、ＰＰＰ（ポイン
ト対ポイント）パケットとなっているのである。）
０とＬＮＳ間でデータを通信するため、ＬＮＳとＬ２Ｔ
Ｐ接続２を設定する。ＬＮＳはもちろん企業ネットワー
ク（詳細には示されていない）へのゲートウエイを提供
している。当該技術分野では公知なように、ステップ２
０５は、ＰＣ１１０を用いている利用者（示されていな
い）とＬＮＳ間での呼をサポートする新たなトンネルを
生成する結果となるか、あるいは、単にＬ２ＴＰ接続を
既存のＬ２ＴＰトンネルに加えるか、いずれかとなる。
（ここでは記述されていないが、ＬＡＣとＰＣ１０５の
間にはポイント対ポイント接続１が存在しているものと
せよ。すなわち、Ｌ２ＴＰ接続２を介したペイロードパ
ケットは、ＬＡＣ／ＬＮＳの対間での利用者セッション
のためにＬ２ＴＰでカプセル化された、ＰＰＰ（ポイン
ト対ポイント）パケットとなっているのである。）
【００２９】上述したように、Ｌ２ＴＰ接続には、コン
トロールセッションとペイロードセッションという２タ
イプのＬ２ＴＰセッションが存在している。（ここでま
た、コントロール接続とペイロード接続という用語もそ
れぞれ用いられうるということに留意されたい。）本発
明にしたがって、ステップ２１０では、Ｌ２ＴＰ接続が
設定された後に、Ｌ２ＴＰの送信者（ここではＬＡＣで
示されている）は、失われた、あるいは故障したペイロ
ードパケットの数が所定の値を超えていることを検出し
て、受信者開始回復アルゴリズム（ＲＩＲＡ）を開始す
る。ＬＡＣは必要であれば、ステップ２１５でＬ２ＴＰ
接続が切断されるまでＲＩＲＡを実行し続ける。
トロールセッションとペイロードセッションという２タ
イプのＬ２ＴＰセッションが存在している。（ここでま
た、コントロール接続とペイロード接続という用語もそ
れぞれ用いられうるということに留意されたい。）本発
明にしたがって、ステップ２１０では、Ｌ２ＴＰ接続が
設定された後に、Ｌ２ＴＰの送信者（ここではＬＡＣで
示されている）は、失われた、あるいは故障したペイロ
ードパケットの数が所定の値を超えていることを検出し
て、受信者開始回復アルゴリズム（ＲＩＲＡ）を開始す
る。ＬＡＣは必要であれば、ステップ２１５でＬ２ＴＰ
接続が切断されるまでＲＩＲＡを実行し続ける。
【００３０】ここで図４へ戻ると、ステップ２１０のＲ
ＩＲＡをさらに例示している、別のフローチャートが示
されている。本発明の概念とは別に、ＬＡＣは、先行技
術におけるものとして、上述の配列番号の状態を維持及
び更新することに留意すべきである。ステップ３０５で
は、ＬＡＣはパケットを受信する。ステップ３１０で
は、ＬＡＣは上述の配列番号の状態を更新し、本発明に
したがって、さらに変数Ｓｎｌを維持している。この変
数Ｓｎｌは、もっとも最後に受信されたパケット内にあ
る、現在受信された「次に送信された」（Ｎｓ）配列番
号の値を保存しているものである。
ＩＲＡをさらに例示している、別のフローチャートが示
されている。本発明の概念とは別に、ＬＡＣは、先行技
術におけるものとして、上述の配列番号の状態を維持及
び更新することに留意すべきである。ステップ３０５で
は、ＬＡＣはパケットを受信する。ステップ３１０で
は、ＬＡＣは上述の配列番号の状態を更新し、本発明に
したがって、さらに変数Ｓｎｌを維持している。この変
数Ｓｎｌは、もっとも最後に受信されたパケット内にあ
る、現在受信された「次に送信された」（Ｎｓ）配列番
号の値を保存しているものである。
【００３１】本発明にしたがって、ＬＡＣはステップ３
１５を実行する。もし、Ｓｎｌの値が、（Ｓｒ＋調整
値）よりも、大きくない場合には、ＬＡＣはステップ３
０５においてパケットを受信し続ける。しかしながら、
ステップ３１５において、Ｓｎｌの値が（Ｓｒ＋調整
値）よりも大きい値である場合には、ＬＡＣはＳｒの値
をＳｎｌの値に再設定（リセット）し、すべてのパケッ
トをプロトコールスタック（示されていない）の上位の
レイヤーへと通過させる。（ここで、当該受信者は、故
障したパケット（示されていないを待ち状態のまま維持
しているものとする。しかしながら、仮にパケットが順
番に受信される場合には、さらなる処理のためにプロト
コールスタック（示されていない）の上位のレイヤーへ
と通過される。）
１５を実行する。もし、Ｓｎｌの値が、（Ｓｒ＋調整
値）よりも、大きくない場合には、ＬＡＣはステップ３
０５においてパケットを受信し続ける。しかしながら、
ステップ３１５において、Ｓｎｌの値が（Ｓｒ＋調整
値）よりも大きい値である場合には、ＬＡＣはＳｒの値
をＳｎｌの値に再設定（リセット）し、すべてのパケッ
トをプロトコールスタック（示されていない）の上位の
レイヤーへと通過させる。（ここで、当該受信者は、故
障したパケット（示されていないを待ち状態のまま維持
しているものとする。しかしながら、仮にパケットが順
番に受信される場合には、さらなる処理のためにプロト
コールスタック（示されていない）の上位のレイヤーへ
と通過される。）
【００３２】調整値変数の値は、当該受信者が回復を開
始する前に、受信者において破棄されたか、または故障
したと考えられるパケットの数を表している。調整値の
値のは、経験的に決定される。ここでの例の目的では、
調整値の変数の値は、３パケットに等しいものであるこ
とを前提としている。加えて、ステップ３２０では、Ｌ
ＡＣは送信者（ここではＬＮＳ）に当該受信者における
新しいＮｒの値を知らせるべく通知（ＡＣＫ）パケット
を（ピギーバッキングまたは０長メッセージを通じて）
送信する。
始する前に、受信者において破棄されたか、または故障
したと考えられるパケットの数を表している。調整値の
値のは、経験的に決定される。ここでの例の目的では、
調整値の変数の値は、３パケットに等しいものであるこ
とを前提としている。加えて、ステップ３２０では、Ｌ
ＡＣは送信者（ここではＬＮＳ）に当該受信者における
新しいＮｒの値を知らせるべく通知（ＡＣＫ）パケット
を（ピギーバッキングまたは０長メッセージを通じて）
送信する。
【００３３】受信されたパケット配列の例示的なものと
しては、図５に示されている。箱の配列は、各受信され
たパケットについて、ＬＡＣ内の関連する受信データバ
ッファー（示されていない）を表している。上述の例示
的な方法を用いて、パケット番号２のものが受信された
際には、ＬＡＣはＳｒとＳｎｌの値を３へ更新する。し
かしながら、パケット番号３のものは受信されていな
い。（箱においてはＸというマークで示されている。）
そこで、パケット番号４のものが受信されると、Ｓｒの
値は３のままになっている一方で、Ｓｎｌの値はＬＡＣ
によって5へと増やされる。このような状況が続くので
あれば、すなわち、パケット番号３のものが受信されな
い場合、パケット番号６のものが受信されると、Ｓｎｌ
の値がＳｒの値プラス３という調整値以上となってしま
う。そこで、本発明にしたがって、Ｓｒの値はＳｎｌの
値へと再設定（リセット）されるのである。
しては、図５に示されている。箱の配列は、各受信され
たパケットについて、ＬＡＣ内の関連する受信データバ
ッファー（示されていない）を表している。上述の例示
的な方法を用いて、パケット番号２のものが受信された
際には、ＬＡＣはＳｒとＳｎｌの値を３へ更新する。し
かしながら、パケット番号３のものは受信されていな
い。（箱においてはＸというマークで示されている。）
そこで、パケット番号４のものが受信されると、Ｓｒの
値は３のままになっている一方で、Ｓｎｌの値はＬＡＣ
によって5へと増やされる。このような状況が続くので
あれば、すなわち、パケット番号３のものが受信されな
い場合、パケット番号６のものが受信されると、Ｓｎｌ
の値がＳｒの値プラス３という調整値以上となってしま
う。そこで、本発明にしたがって、Ｓｒの値はＳｎｌの
値へと再設定（リセット）されるのである。
【００３４】ここで、ウインドウサイズを往復時間の
２、３倍に設定することで、相対的に高いスループット
を与えるには十分である。さらに、時間切れ間隔は、往
復時間に加えて２から４の標準的な変位に相当するよう
に選択されることが可能である。最後に、送信者のウイ
ンドウがウインドウの時間切れの値以上の間閉じられて
いる場合にも、当該送信者はＲビットのパケットを送信
することは依然必要とされる。例えば、１２８パケット
のサイズのバッファーが想定される。しかしながら、バ
ッファーのサイズだけが当該ウインドウのサイズ以上の
ものとなる必要とされる。例示的なウインドウのサイズ
としては、７パケットである。例示的なＲＴＴとして
は、４パケットである。
２、３倍に設定することで、相対的に高いスループット
を与えるには十分である。さらに、時間切れ間隔は、往
復時間に加えて２から４の標準的な変位に相当するよう
に選択されることが可能である。最後に、送信者のウイ
ンドウがウインドウの時間切れの値以上の間閉じられて
いる場合にも、当該送信者はＲビットのパケットを送信
することは依然必要とされる。例えば、１２８パケット
のサイズのバッファーが想定される。しかしながら、バ
ッファーのサイズだけが当該ウインドウのサイズ以上の
ものとなる必要とされる。例示的なウインドウのサイズ
としては、７パケットである。例示的なＲＴＴとして
は、４パケットである。
【００３５】本発明の特徴にしたがって、受信者は、当
該受信者が遅延させたＡＣＫパケットを送信する「遅延
フィードバック機能」を導入しうる。遅延フィードバッ
ク機能は、スループット、応答時間、帯域幅利用のオー
バヘッド分といったものの間での性能のトレードオフに
際してある程度の自由度を提供するものである。言いか
えれば、順に受信されたパケットについて通知を発する
（ＡＣＫする）ことを必ずしも即座に行わないでよい自
由を選べるのである。
該受信者が遅延させたＡＣＫパケットを送信する「遅延
フィードバック機能」を導入しうる。遅延フィードバッ
ク機能は、スループット、応答時間、帯域幅利用のオー
バヘッド分といったものの間での性能のトレードオフに
際してある程度の自由度を提供するものである。言いか
えれば、順に受信されたパケットについて通知を発する
（ＡＣＫする）ことを必ずしも即座に行わないでよい自
由を選べるのである。
【００３６】受信者は、そのようなＡＣＫを送信する、
あるフィードバック間隔（変数「フィードバック間隔」
あるいはＫで示されている）を選ぶことができる。１と
いうフィードバック間隔については、受信者は常に順に
受信されたパケットを直ちに通知する。３というフィー
ドバック間隔については、受信者は任意のＡＣＫを３パ
ケット分遅延させる。遅延フィードバック機能の流れ図
については、図６に示されている。
あるフィードバック間隔（変数「フィードバック間隔」
あるいはＫで示されている）を選ぶことができる。１と
いうフィードバック間隔については、受信者は常に順に
受信されたパケットを直ちに通知する。３というフィー
ドバック間隔については、受信者は任意のＡＣＫを３パ
ケット分遅延させる。遅延フィードバック機能の流れ図
については、図６に示されている。
【００３７】図７を簡潔に振りかえって、本発明の原理
にしたがったＲＩＲＡを実行するために用いられる代表
的なパケットインタフェースについての高レベルでのブ
ロック線図が示されている。パケットインタフェース６
０５は、保存されたプログラム制御をベースとしたプロ
セッサーアーキテクチャーであって、プロセッサー６５
０、メモリ６００（プログラム命令とデータを保存する
ため、例えば、図３、図４、図５等に示された例示的な
方法を実行する。）、さらにパス６６６によってパケッ
ト通信装置へと結合させる通信インタフェース６６５を
含んでいる。
にしたがったＲＩＲＡを実行するために用いられる代表
的なパケットインタフェースについての高レベルでのブ
ロック線図が示されている。パケットインタフェース６
０５は、保存されたプログラム制御をベースとしたプロ
セッサーアーキテクチャーであって、プロセッサー６５
０、メモリ６００（プログラム命令とデータを保存する
ため、例えば、図３、図４、図５等に示された例示的な
方法を実行する。）、さらにパス６６６によってパケッ
ト通信装置へと結合させる通信インタフェース６６５を
含んでいる。
【００３８】これまで述べてきたことは、単に本発明の
原理を例示するものに過ぎず、そのため、ここでは明示
的には述べられてはいないものの、当該技術分野の当業
者は、本発明の原理を具現化し、その技術思想及び保護
範囲に含まれる様々な選択的な構成を行うことが可能で
あると考えられる。
原理を例示するものに過ぎず、そのため、ここでは明示
的には述べられてはいないものの、当該技術分野の当業
者は、本発明の原理を具現化し、その技術思想及び保護
範囲に含まれる様々な選択的な構成を行うことが可能で
あると考えられる。
【００３９】
【発明の効果】本発明により、データセッションについ
ては失われたペイロードメッセージは再送信されないＬ
２ＴＰ接続において、Ｌ２ＴＰ受信者は、Ｌ２ＴＰ送信
者からパケットを受信し、失われたペイロードパケット
を所定数検知することで回復プロセスである受信者開始
回復アルゴリズム（ＲＩＲＡ）を開始する方法が提供さ
れた。
ては失われたペイロードメッセージは再送信されないＬ
２ＴＰ接続において、Ｌ２ＴＰ受信者は、Ｌ２ＴＰ送信
者からパケットを受信し、失われたペイロードパケット
を所定数検知することで回復プロセスである受信者開始
回復アルゴリズム（ＲＩＲＡ）を開始する方法が提供さ
れた。
【図１】図１は、先行技術におけるＬ２ＴＰの送信順序
を示している。
を示している。
【図２】図２は、本発明の原理にしたがった通信システ
ムを示している。
ムを示している。
【図３】図３は、本発明の原理にしたがった方法の例示
的な流れ図を示している。
的な流れ図を示している。
【図４】図４は、本発明の原理にしたがった方法の例示
的な流れ図を示している。
的な流れ図を示している。
【図５】図５は、例示的な、受信されたパケットインタ
フェースを示している。
フェースを示している。
【図６】図６は、本発明の原理にしたがった方法の例示
的な流れ図を示している。
的な流れ図を示している。
【図７】図７は、本発明の原理を実施する例示的なパケ
ットインタフェースのブロック線図を示している。
ットインタフェースのブロック線図を示している。
１００ 通信システム １０５ パーソナルコンピュータ（ＰＣ） １１０ 公衆交換網（ＰＳＴＮ） １３０ インターネット １３５ ネットワークサーバー（ＮＳ） １５５ ネットワークアクセスサーバー（ＮＡＳ） １６０ ローカルネットワーク １６５ ルーター ２０５ Ｌ２ＴＰ接続を設定 ２１０ 送信機開始回復アルゴリズム ２１５ Ｌ２ＴＰ接続を切断 ３０５ パケットを受信 ３１０ Ｓｒ、Ｓｎｌを更新 ３１５ Ｓｎｌ＞Ｓｒ＋調整値 ３２０ ＳｒをＳｎｌへと再設定（リセット） 新しいＳｒの値を送信者へ設定 ４０５ 配列しているパケットを受信 ４１０ ＡＣＫを送信する前にＫ個のパケット分待つ ６０５ パケットインタフェース ６５０ プロセッサー ６６０ メモリ ６６５ 通信インタフェース ６６６ パス
───────────────────────────────────────────────────── フロントページの続き (71)出願人 596077259 600 Ｍｏｕｎｔａｉｎ Ａｖｅｎｕｅ, Ｍｕｒｒａｙ Ｈｉｌｌ， Ｎｅｗ Ｊｅ ｒｓｅｙ 07974−0636Ｕ．Ｓ．Ａ. (72)発明者 ムー チョ チュア アメリカ合衆国、07746 ニュージャージ ー、マルボロ、スカイラーク セントラル １
Claims (8)
- 【請求項１】 レイヤー２トンネリングプロトコール
（Ｌ２ＴＰ）受信者において用いられる方法で、 Ｌ２ＴＰ送信者からパケットを受信するステップと、 所定数の損失ペイロードパケットを検出して回復プロセ
スを開始するステップとを、 有することを特徴とする方法。 - 【請求項２】 レイヤー２トンネリングプロトコール
（Ｌ２ＴＰ）受信者において用いられる方法で、前記開
始するステップが、 受信されたパケットからの、現在受信した「次に送信さ
れた」配列番号の値を「受信が期待された次の配列番
号」（Ｓｒ）を表す保存された値と比較するステップ
と、 前記比較するステップの結果が所定の値以上である場合
には前記受信機の回復プロセスを開始するステップと
を、 有することを特徴とする、請求項１の方法。 - 【請求項３】 前記Ｓｒを前記の現在受信した「次に
送信された」配列番号の値に再設定（リセット）するス
テップを、 さらに有することを特徴とする請求項２の方法。 - 【請求項４】 前記回復プロセスのステップを開始す
る以前に所定数のパケットの損失を検出するステップ
を、 さらに含むことを特徴とする請求項１の方法。 - 【請求項５】 前記Ｌ２ＴＰ送信者へ先に受信したパ
ケットについての通知を送信する前に、Ｋ個のパケット
が受信されることを待つステップを、 さらに有することを特徴とする請求項１の方法。 - 【請求項６】 レイヤー２トンネリングプロトコール
（Ｌ２ＴＰ）受信機を形成するために用いられるパケッ
トインタフェースで、 Ｌ２ＴＰ送信者からパケットを受信する通信インタフェ
ースと、 （ａ）受信されたパケットからの現在受信した「次に送
信された」配列番号の値（Ｓｎｌ）と（ｂ）「次に受信
されることが期待される次の配列番号」（Ｓｒ）を保存
するメモリと、 ＳｎｌとＳｒの間の差が所定の値を超えている場合に、
受信者回復プロセスを開始するプロセッサーとを、 有することを特徴とするパケットインタフェース。 - 【請求項７】 前記ＳｎｌとＳｒの間の差が前記所定
の値を超えている場合に、前記プロセッサーが、前記Ｓ
ｒを前記現在受信した「次に送信された」配列番号の値
へ再設定（リセット）することを特徴とする請求項６の
パケットインタフェース。 - 【請求項８】 前記Ｌ２ＴＰ送信者へ先に受信したパ
ケットについての通知を送信する前に、前記プロセッサ
ーがＫ＞１であるＫ個のパケットが受信されることを待
つことを特徴とする請求項６のパケットインタフェー
ス。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/350,431 US6487689B1 (en) | 1999-07-08 | 1999-07-08 | Receiver initiated recovery algorithm (RIRA) for the layer 2 tunneling protocol (L2TP) |
| US09/350431 | 1999-07-08 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001045094A true JP2001045094A (ja) | 2001-02-16 |
| JP3732720B2 JP3732720B2 (ja) | 2006-01-11 |
Family
ID=23376693
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000206313A Expired - Fee Related JP3732720B2 (ja) | 1999-07-08 | 2000-07-07 | レイヤー２トンネリングプロトコール（ｌ２ｔｐ）向け受信者開始回復アルゴリズム（ｒｉｒａ） |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US6487689B1 (ja) |
| EP (1) | EP1067744B1 (ja) |
| JP (1) | JP3732720B2 (ja) |
| CA (1) | CA2313025C (ja) |
| DE (1) | DE60019206T2 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2010283427A (ja) * | 2009-06-02 | 2010-12-16 | Hitachi Ltd | Ｌａｃ装置及びフェイルオーバ方法 |
Families Citing this family (27)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7085273B1 (en) * | 1999-07-08 | 2006-08-01 | Lucent Technologies Inc. | Sender-initiated recovery algorithm (SIRA) for the layer 2 tunneling protocol (L2TP) |
| US6788704B1 (en) * | 1999-08-05 | 2004-09-07 | Intel Corporation | Network adapter with TCP windowing support |
| US7009967B1 (en) * | 1999-08-07 | 2006-03-07 | Shrikumar Hariharasubrahmanian | Systems and methods for transmitting data packets |
| JP2001142845A (ja) * | 1999-11-17 | 2001-05-25 | Toshiba Corp | コンピュータシステムおよびデータ転送制御方法 |
| FI112305B (fi) * | 2000-02-14 | 2003-11-14 | Nokia Corp | Datapakettien numerointi pakettivälitteisessä tiedonsiirrossa |
| US7054321B1 (en) * | 2000-10-27 | 2006-05-30 | Redback Networks Inc. | Tunneling ethernet |
| DE10108146A1 (de) * | 2001-02-20 | 2002-08-29 | Siemens Ag | Datenübertragungsverfahren |
| US7016304B2 (en) * | 2001-05-18 | 2006-03-21 | Intel Corporation | Link level retry scheme |
| JP3668437B2 (ja) * | 2001-05-24 | 2005-07-06 | 松下電器産業株式会社 | 基地局装置、無線通信システム及びパケット通信方法 |
| JP2004112113A (ja) * | 2002-09-13 | 2004-04-08 | Matsushita Electric Ind Co Ltd | リアルタイム通信の適応制御方法、受信報告パケットの連続消失に対する対策方法、受信報告パケットの送出間隔の動的決定装置、リアルタイム通信の適応制御装置、データ受信装置およびデータ配信装置 |
| US7796602B2 (en) * | 2002-11-25 | 2010-09-14 | Intel Corporation | In sequence packet delivery without retransmission |
| US20050160345A1 (en) * | 2003-12-24 | 2005-07-21 | Rod Walsh | Apparatus, system, method and computer program product for reliable multicast transport of data packets |
| US7760636B1 (en) * | 2004-01-26 | 2010-07-20 | Cisco Technology, Inc. | Retransmission and flow control in a logical network tunnel |
| US7573883B2 (en) * | 2004-03-05 | 2009-08-11 | Telefonaktiebolaget Lm Ericsson (Publ) | System, method and operator for increasing the active window size in a NAK-based window protocol |
| JP4268076B2 (ja) * | 2004-03-09 | 2009-05-27 | 株式会社エヌ・ティ・ティ・ドコモ | 移動通信システム、移動端末及びネットワーク側対向装置 |
| US20060168241A1 (en) * | 2004-11-24 | 2006-07-27 | Puthiyandyil Sanil K | Redundant L2TP end points |
| EP1686732B1 (de) * | 2005-01-28 | 2007-10-31 | Siemens Aktiengesellschaft | Verfahren und System zur Übertragung von Telegrammen |
| FI20050158A0 (fi) * | 2005-02-11 | 2005-02-11 | Nokia Corp | Ensimmäisen tunnelipäätepisteen tilainformaation palauttaminen |
| GB2425025A (en) * | 2005-04-08 | 2006-10-11 | 3Com Corp | Intrusion detection state machine for finding attack signatures with reduced buffering requirements for handling out of sequence packets |
| TW200713895A (en) * | 2005-09-21 | 2007-04-01 | Asustek Comp Inc | Method and apparatus for improving transmission delay of status report in a wireless communications system |
| GB2430577B (en) | 2005-09-23 | 2010-09-22 | Agilent Technologies Inc | Real time monitoring of TCP flows |
| US20090201947A1 (en) | 2006-05-30 | 2009-08-13 | Rune Goeran | Method And Arrangement For Reducing The Amount Of Messages Sent In A Communication Network |
| KR100782919B1 (ko) | 2006-12-06 | 2007-12-07 | (주)액텔라 | 왠 최적화를 위한 패킷 손실 탐지 방법 |
| US8582539B2 (en) * | 2008-11-24 | 2013-11-12 | Qualcomm Incorporated | System and method to implement synchronous channel timing in a wireless communications network |
| US8850250B2 (en) | 2010-06-01 | 2014-09-30 | Intel Corporation | Integration of processor and input/output hub |
| US8782456B2 (en) | 2010-06-01 | 2014-07-15 | Intel Corporation | Dynamic and idle power reduction sequence using recombinant clock and power gating |
| US9146610B2 (en) * | 2010-09-25 | 2015-09-29 | Intel Corporation | Throttling integrated link |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2615509B2 (ja) * | 1990-10-30 | 1997-05-28 | 富士通株式会社 | 通信装置 |
| US5963551A (en) * | 1996-09-30 | 1999-10-05 | Innomedia Pte Ltd. | System and method for dynamically reconfigurable packet transmission |
| KR100248080B1 (ko) * | 1997-10-06 | 2000-03-15 | 정선종 | 다자간 멀티미디어 통신에서의 에러제어 방법 |
| US6301249B1 (en) * | 1998-08-04 | 2001-10-09 | Opuswave Networks, Inc | Efficient error control for wireless packet transmissions |
| US6094437A (en) * | 1998-10-09 | 2000-07-25 | Asc - Advanced Switching Communications | Layer two tunneling protocol (L2TP) merging and management |
| US6378099B1 (en) * | 1999-01-29 | 2002-04-23 | Qualcomm Incorporated | Blind frame identification in a communication system |
-
1999
- 1999-07-08 US US09/350,431 patent/US6487689B1/en not_active Expired - Lifetime
-
2000
- 2000-06-27 DE DE60019206T patent/DE60019206T2/de not_active Expired - Lifetime
- 2000-06-27 EP EP00305391A patent/EP1067744B1/en not_active Expired - Lifetime
- 2000-06-29 CA CA002313025A patent/CA2313025C/en not_active Expired - Fee Related
- 2000-07-07 JP JP2000206313A patent/JP3732720B2/ja not_active Expired - Fee Related
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2010283427A (ja) * | 2009-06-02 | 2010-12-16 | Hitachi Ltd | Ｌａｃ装置及びフェイルオーバ方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| EP1067744B1 (en) | 2005-04-06 |
| CA2313025A1 (en) | 2001-01-08 |
| DE60019206T2 (de) | 2006-03-09 |
| DE60019206D1 (de) | 2005-05-12 |
| US6487689B1 (en) | 2002-11-26 |
| JP3732720B2 (ja) | 2006-01-11 |
| EP1067744A2 (en) | 2001-01-10 |
| EP1067744A3 (en) | 2003-09-17 |
| CA2313025C (en) | 2007-11-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3732720B2 (ja) | レイヤー２トンネリングプロトコール（ｌ２ｔｐ）向け受信者開始回復アルゴリズム（ｒｉｒａ） | |
| JP5020076B2 (ja) | 低頻度ａｃｋのシステムに適した高性能ｔｃｐ | |
| JP5005003B2 (ja) | トンネルのトランスポートチャネル上のデータストリームの送信を管理する方法、対応するトンネル終点及びコンピュータ読み取り可能な記憶媒体 | |
| EP1333642B1 (en) | Method and system for integrating performance enhancing functions in a virtual private network (VPN) | |
| Stewart et al. | SCTP: new transport protocol for TCP/IP | |
| US8976798B2 (en) | Method and system for communicating over a segmented virtual private network (VPN) | |
| US7596802B2 (en) | Method and system for providing connection handling | |
| US7643416B2 (en) | Method and system for adaptively applying performance enhancing functions | |
| US20030219022A1 (en) | Method and system for utilizing virtual private network (VPN) connections in a performance enhanced network | |
| EP1443731A2 (en) | Method and system for providing security in performance enhanced network | |
| WO2014037760A1 (zh) | 增加数据流传输的方法和系统 | |
| JP2004297742A (ja) | 通信装置、通信制御方法及びプログラム | |
| JP2003526266A (ja) | 性能向上ピロキシおよび性能向上方法 | |
| JP3746418B2 (ja) | レイヤー２トンネリングプロトコール（ｌ２ｔｐ）向け送信者開始回復アルゴリズム（ｓｉｒａ） | |
| Ding et al. | Delay performance of the new explicit loss notification TCP technique for wireless networks | |
| JP4505575B2 (ja) | 通信システム、ゲートウェイ送信装置、ゲートウェイ受信装置、送信方法、受信方法および情報記録媒体 | |
| JPH09149077A (ja) | データフロー制御方法 | |
| KR101396785B1 (ko) | 네트워크 장치에서 tcp 기능을 수행하는 방법 | |
| Igarashi et al. | Mobility aware TCP congestion control | |
| Suthar et al. | Comparision of SACK TCP performance with and without LSS for high speed network | |
| Qaddoura | Enhanced TCP for wireless local area network |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050111 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20050411 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20050414 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050427 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20050920 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20051013 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091021 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091021 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101021 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111021 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121021 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131021 Year of fee payment: 8 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |