メインコンテンツまでスキップ

4. トンネルプロトコル動作 (Tunnel Protocol Operation)

PPTP プロトコルが運ぶユーザーデータは PPP データパケットです。PPP パケットは PAC と PNS の間で運ばれ、GRE パケットにカプセル化され、GRE パケットは IP 上で運ばれます。カプセル化された PPP パケットは、基本的にメディア固有のフレーミング要素を除いた PPP データパケットです。HDLC フラグ、ビット挿入、制御文字、または制御文字エスケープは含まれません。CRC はトンネルを通じて送信されません。PAC と PNS 間のトンネル上で送信される IP パケットは、次の一般的な構造を持ちます：

+--------------------------------+
|          Media Header          |
|        (メディアヘッダー)        |
+--------------------------------+
|           IP Header            |
|          (IP ヘッダー)          |
+--------------------------------+
|           GRE Header           |
|         (GRE ヘッダー)          |
+--------------------------------+
|           PPP Packet           |
|         (PPP パケット)          |
+--------------------------------+

4.1. 拡張 GRE ヘッダー (Enhanced GRE Header)​

PPTP で使用される GRE ヘッダーは、現在の GRE プロトコル仕様 [1,2] で指定されているものから若干拡張されています。主な違いは、新しい確認応答番号 (Acknowledgment Number) フィールドの定義で、特定の GRE パケットまたはパケットのセットがトンネルの遠端に到着したかどうかを判断するために使用されます。この確認応答機能は、ユーザーデータパケットの再送信とは組み合わせて使用されません。代わりに、特定のユーザーセッションのユーザーデータパケットがトンネルを介して送信される速度を決定するために使用されます。拡張 GRE ヘッダーのフォーマットは次のとおりです：

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|R|K|S|s|Recur|A| Flags | Ver |         Protocol Type         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Key (HW) Payload Length    |       Key (LW) Call ID        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  Sequence Number (Optional)                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Acknowledgment Number (Optional)                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

フィールド説明​

C (Bit 0) - Checksum Present (チェックサム存在)

  • 0 に設定します。

R (Bit 1) - Routing Present (ルーティング存在)

  • 0 に設定します。

K (Bit 2) - Key Present (キー存在)

  • 1 に設定します。

S (Bit 3) - Sequence Number Present (シーケンス番号存在)

  • ペイロード（データ）パケットが存在する場合は 1 に設定します。ペイロードが存在しない場合（GRE パケットが確認応答のみ）は 0 に設定します。

s (Bit 4) - Strict Source Route Present (厳密なソースルート存在)

  • 0 に設定します。

Recur (Bits 5-7) - Recursion Control (再帰制御)

  • 0 に設定します。

A (Bit 8) - Acknowledgment Sequence Number Present (確認応答シーケンス番号存在)

  • パケットが以前に送信されたデータを確認するための確認応答番号を含む場合は 1 に設定します。

Flags (Bits 9-12)

  • 0 に設定する必要があります (MUST)。

Ver (Bits 13-15) - Version (バージョン)

  • 1（拡張 GRE）を含む必要があります (MUST)。

Protocol Type (プロトコルタイプ)

  • 16 進数 880B [8] に設定します。

Key (キー)

  • キーフィールドの使用は実装次第です。PPTP は次のように使用します：
    • Payload Length (ペイロード長)（キーの上位 2 オクテット）：ペイロードのサイズ、GRE ヘッダーは含まない
    • Call ID (コール ID)（下位 2 オクテット）：このパケットが属するセッションのピアのコール ID を含みます

Sequence Number (シーケンス番号)

  • ペイロードのシーケンス番号を含みます。S ビット（Bit 3）が 1 の場合に存在します。

Acknowledgment Number (確認応答番号)

  • このユーザーセッションの送信ピアが受信した最も高い番号の GRE パケットのシーケンス番号を含みます。A ビット（Bit 8）が 1 の場合に存在します。

ペイロードセクションには、メディア固有のフレーミング要素を含まない PPP データパケットが含まれます。

関係するシーケンス番号はパケットごとのシーケンス番号です。各ユーザーセッションのシーケンス番号は、セッション開始時にゼロに設定されます。ペイロードを含む（S ビット（Bit 3）が 1 に設定されている）特定のユーザーセッションに対して送信される各パケットには、そのセッションの次の連続したシーケンス番号が割り当てられます。

このプロトコルは、確認応答をデータと一緒に運ぶことを許可し、プロトコル全体をより効率的にし、それによってパケットのバッファリングをより少なくすることができます。

4.2. スライディングウィンドウプロトコル (Sliding Window Protocol)​

PPTP データパス上で使用されるスライディングウィンドウプロトコルは、データ交換の各側によるフロー制御に使用されます。拡張 GRE プロトコルは、パケット確認応答をデータパケット上にピギーバックすることを許可します。確認応答は、データパケットとは別に送信することもできます。繰り返しますが、スライディングウィンドウプロトコルの主な目的はフロー制御です。トンネルピアによる再送信は実行されません。

4.2.1. 初期ウィンドウサイズ (Initial Window Size)​

各側が受信ウィンドウの最大サイズを示していますが、データの送信を開始するときは保守的なアプローチをとることが推奨されます。送信側の初期ウィンドウサイズは、受信側が要求した最大サイズの半分に設定され、最小サイズは 1 パケットです。確認応答を待っているパケットの数が現在のウィンドウサイズと等しくなると、送信側はパケットの送信を停止します。受信側が各ウィンドウを正常に消化すると、送信側のウィンドウサイズは最大値に達するまで 1 パケットずつ増加します。この方法は、履歴が確立されていないため、システムが既に混雑しているネットワークをフラッディングすることを防ぎます。

4.2.2. ウィンドウのクローズ (Closing the Window)​

パケットでタイムアウトが発生すると、送信側は送信ウィンドウのサイズを失敗時の値の半分に調整します。端数は切り上げられ、最小ウィンドウサイズは 1 です。

4.2.3. ウィンドウのオープン (Opening the Window)​

タイムアウトなしでウィンドウ分のパケットの送信が成功するたびに、送信ウィンドウサイズは、コールが接続されたときに相手側が送信した最大ウィンドウサイズに達するまで 1 パケットずつ増加します。前述のとおり、タイムアウト時に再送信は行われません。タイムアウト後、送信はウィンドウサイズがタイムアウトが発生したときの送信ウィンドウサイズの半分から始まり、送信ウィンドウがタイムアウトなしですべて確認されるパケットで満たされるたびに 1 ずつ上方に調整して再開されます。

4.2.4. ウィンドウオーバーフロー (Window Overflow)​

受信側のウィンドウが着信パケットが多すぎてオーバーフローすると、余分なパケットは破棄されます。送信側と受信側がスライディングウィンドウ手順を適切に遵守している場合、この状況は発生しないはずです。送信側では、パケットが送信用にバッファリングされ、送信バッファがいっぱいになるとパケットソースからパケットを受け入れなくなることが想定されています。

4.2.5. マルチパケット確認応答 (Multi-packet Acknowledgment)​

PPTP スライディングウィンドウプロトコルの 1 つの機能は、単一の確認応答で複数のパケットの確認応答を許可することです。確認応答番号以下のシーケンス番号を持つすべての未処理パケットは確認されたと見なされます。タイムアウト計算は、確認されている最高のシーケンス番号に対応するパケットが送信された時刻を使用して実行されます。

適応的タイムアウト計算は、確認応答を受信したときにのみ実行されます。マルチパケット確認応答が使用される場合、適応的タイムアウトアルゴリズムのオーバーヘッドが削減されます。PAC はマルチパケット確認応答を送信する必要はありません (not required)。代わりに、各パケットが PPP クライアントに配信されるときに個別に確認できます。

4.3. シーケンス外パケット (Out-of-sequence Packets)​

時々、パケットは複雑なインターネットワークを通過する際にシーケンスを失います。たとえば、PNS がパケット 0 から 5 を PAC に送信するとします。インターネットワークでの再ルーティングのため、パケット 4 がパケット 3 よりも先に PAC に到着します。PAC はパケット 4 を確認し、パケット 3 が失われたと想定する可能性があります。この確認応答は、パケット 4 を超えるウィンドウクレジットを付与します。

PAC が実際にパケット 3 を受信した場合、対応する PPP クライアントに送信しようとしてはなりません (MUST NOT)。そうすると問題が発生する可能性があります。正しい PPP プロトコル動作は、パケットを順番に受信することを前提としているためです。PPP はパケットの損失を適切に処理しますが、再順序付けは処理しないため、PNS と PAC 間のシーケンス外パケットは静かに破棄される必要があります (MUST)。または、受信側が再順序付けすることもできます。パケット 5 が到着すると、PAC がこれまでに確認した最後の最高パケットである 4 よりも高いシーケンス番号を持っているため、PAC はそれを確認します。PAC と PNS は GRE パケットを再送信しないため、重複するシーケンス番号を持つパケットは決して発生しないはずです。堅牢な実装は、受信した場合、重複する GRE パケットを静かに破棄します。

4.4. 確認応答タイムアウト (Acknowledgment Time-Outs)​

PPTP は、スライディングウィンドウとタイムアウトを使用して、インターネットワーク全体でユーザーセッションのフロー制御を提供し、受信バッファオーバーフローを引き起こすことなく PAC-PNS データチャネルをいっぱいに保つための効率的なデータバッファリングを実行します。PPTP は、ドロップされたデータまたは確認応答パケットから回復するためにタイムアウトを使用することを要求します。タイムアウトの正確な実装はベンダー固有です。輻輳制御のためのバックオフを伴う適応的タイムアウトを実装することが提案されています。ここで提案されるタイムアウトメカニズムには、次のプロパティがあります：

  • 各セッションの独立したタイムアウト：デバイス（PAC または PNS）は、すべてのアクティブなセッションのタイムアウトを維持および計算する必要があります。
  • 管理者が調整可能な最大タイムアウト (MaxTimeOut)：各デバイスに固有。
  • 適応的タイムアウトメカニズム：変化するスループットを補償します。パケット処理のオーバーヘッドを削減するために、ベンダーは受信したすべての確認応答に対して適応的タイムアウトを再計算しないことを選択できます。このオーバーヘッド削減の結果、タイムアウトは急速なネットワーク変化に迅速に応答しなくなります。
  • タイムアウト時のタイマーバックオフ：輻輳を削減します。バックオフされたタイマー値は、設定可能な最大タイムアウト値によって制限されます。タイマーバックオフは、確認応答タイムアウトが発生するたびに実行されます。

一般に、このメカニズムは、タイムアウト時に迅速にバックオフし、タイムアウトなしでパケットが配信されるときにタイムアウト値をゆっくりと減少させる望ましい動作を持っています。

定義​

Packet Processing Delay (PPD) - パケット処理遅延

  • 各側が受信パケットスライディングウィンドウにバッファリングされた最大データ量を処理するのに必要な時間。PPD は、コールが確立されたときに PAC と PNS の間で交換される値です。PNS の場合、この数値は小さいはずです。モデム接続を行う PAC の場合、この数値は大きい可能性があります。

Sample (サンプル)

  • パケットの確認応答を受信するために実際に発生した時間量。サンプルは測定されるものであり、計算されるものではありません。

Round-Trip Time (RTT) - ラウンドトリップタイム

  • 特定の送信されたパケットの確認応答を受信するための推定ラウンドトリップタイム。ネットワークリンクがローカルネットワークの場合、この遅延は最小（ゼロでない場合）になります。ネットワークリンクがインターネットの場合、この遅延は大きく、大きく変動する可能性があります。RTT は適応的です：パケットが送信されてからその確認応答を受信するまでの時間に寄与する PPD および変動するネットワーク遅延を含むように調整されます。

Adaptive Time-Out (ATO) - 適応的タイムアウト

  • 確認応答が失われたと見なされる前に経過しなければならない時間。タイムアウト後、スライディングウィンドウは部分的に閉じられ、ATO がバックオフされます。

パケット処理遅延 (PPD) パラメータは、コール制御フェーズ中に交換される 16 ビットワードで、10 分の 1 秒を表します（64 は 6.4 秒を意味します）。プロトコルは、パラメータが交換されることのみを指定し、それがどのように計算されるかを指定しません。PPD 値の計算方法は実装依存であり、可変である必要はありません（静的タイムアウトが許可されます）。実装で一定のままであっても、PPD はコール接続シーケンスで交換される必要があります (MUST)。PPD を計算する 1 つの可能な方法は：

PPD' = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / ConnectRate
PPD = PPD' + PACFudge

ここで：

  • Header は IP および GRE ヘッダーの合計サイズで、36 です
  • MTU は PAC と PNS 間のインターネットワークリンクの全体的な MTU です
  • WindowSize はスライディングウィンドウ内のパケット数を表し、実装依存です
  • 定数 8 はオクテットをビットに変換します（ConnectRate がビット毎秒である場合を想定）
  • PACFudge は必須ではありませんが、PAC の全体的な処理オーバーヘッドを考慮に入れるために使用できます

PPD の値は、初期 RTT[n-1] 値を使用して適応的アルゴリズムをシードするために使用されます。

4.4.1. 適応的確認応答タイムアウトの計算 (Calculating Adaptive Acknowledgment Time-Out)​

確認応答を返すのに許可する時間をまだ決定する必要があります。タイムアウトが高すぎる設定の場合、ドロップされたパケットに対して不必要に長い時間待つ可能性があります。タイムアウトが短すぎる場合、確認応答が到着する直前にタイムアウトする可能性があります。確認応答タイムアウトも合理的であり、変化するネットワーク状態に応答する必要があります。

提案される適応的アルゴリズムは、TCP 1989 実装に基づいており、[11] で説明されています。'n' は現在のパケットを意味し、'n-1' は前のパケットを意味します：

Err[n] = Sample[n] - RTT[n-1]
RTT[n] = RTT[n-1] + (g * Err[n])
Dev[n] = Dev[n-1] + h * (|Err[n]| - Dev[n-1])
ATO[n] = RTT[n] + (f * Dev[n])

ここで：

  • g はゲイン係数（推奨値は 0.125）
  • h は偏差ゲイン係数（推奨値は 0.25）
  • f は偏差乗数係数（推奨値は 4）

4.4.2. 輻輳制御：タイムアウトの調整 (Congestion Control: Adjusting for Time-Out)​

このセクションでは、タイムアウトが発生した場合に ATO の計算がどのように変更されるかについて説明します。タイムアウトが発生すると、タイムアウト値は急速に上方に調整される必要があります。タイムアウトが発生したときに GRE パケットは再送信されませんが、タイムアウトは最大制限に向けて調整される必要があります。変化するインターネットワークの時間遅延を補償するために、タイムアウトが期限切れになったときにタイムアウトを増やす戦略を採用する必要があります（タイムアウトを増やすことに加えて、次のセクションで説明するようにウィンドウのサイズも縮小していることに注意してください）。

タイムアウトが発生した間隔の場合：

ATO[n] = MIN(2 * ATO[n-1], MaxTimeOut)

ここで、MaxTimeOut は管理者が設定した最大タイムアウト値です。

に最終更新