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

3. プロトコル動作 (Protocol Operation)

このセクションでは、PPTP プロトコルの動作の詳細について説明します。これには、制御接続状態、コール状態、およびさまざまな動作シナリオの処理フローが含まれます。

3.1. 制御接続状態 (Control Connection States)​

制御接続は、PAC と PNS の間に確立される TCP 接続であり、PPTP 制御メッセージを交換するために使用されます。制御接続の確立は、PAC または PNS のいずれかによって開始できます。

基本的な状態遷移​

制御接続は次の基本状態を経ます：

  1. Idle（アイドル） - 制御接続が存在しない
  2. Wait-Connect（接続待ち） - 接続要求を送信し、応答を待機中
  3. Established（確立済み） - 制御接続が正常に確立された
  4. Wait-Disconnect（切断待ち） - 切断要求を送信し、確認を待機中

3.1.1. 制御接続発信者 (Control Connection Originator)​

制御接続の発信者（PAC または PNS）は次の操作を実行します：

状態：Idle（アイドル）

  • 操作：ピアへの TCP 接続を確立する
  • 送信：Start-Control-Connection-Request
  • 遷移先：Wait-Reply 状態

状態：Wait-Reply（応答待ち）

  • 受信：Start-Control-Connection-Reply (Result = 成功)
    • 遷移先：Established 状態
  • 受信：Start-Control-Connection-Reply (Result = エラー)
    • TCP 接続を閉じる
    • 遷移先：Idle 状態
  • タイムアウト：
    • TCP 接続を閉じる
    • 遷移先：Idle 状態

状態：Established（確立済み）

  • すべての PPTP 制御メッセージを送受信できます
  • 送信：Echo-Request（定期的なキープアライブ）
  • 受信：Echo-Reply（キープアライブへの応答）
  • 送信：Stop-Control-Connection-Request（アクティブなクローズ）
    • 遷移先：Wait-Stop-Reply 状態

状態：Wait-Stop-Reply（停止応答待ち）

  • 受信：Stop-Control-Connection-Reply
    • TCP 接続を閉じる
    • 遷移先：Idle 状態
  • タイムアウト：
    • TCP 接続を閉じる
    • 遷移先：Idle 状態

3.1.2. 制御接続受信者 (Control Connection Receiver)​

制御接続の受信者（PAC または PNS）は次の操作を実行します：

状態：Idle（アイドル）

  • リスン：TCP ポート 1723
  • 受信：TCP 接続要求
    • TCP 接続を受け入れる
    • 遷移先：Wait-Request 状態

状態：Wait-Request（要求待ち）

  • 受信：Start-Control-Connection-Request
    • 検証：プロトコルバージョン、パラメータ
    • 受け入れる場合：
      • 送信：Start-Control-Connection-Reply (Result = 成功)
      • 遷移先：Established 状態
    • 拒否する場合：
      • 送信：Start-Control-Connection-Reply (Result = エラー)
      • TCP 接続を閉じる
      • 遷移先：Idle 状態

状態：Established（確立済み）

  • すべての PPTP 制御メッセージを送受信できます
  • 受信：Echo-Request
    • 送信：Echo-Reply
  • 受信：Stop-Control-Connection-Request
    • 送信：Stop-Control-Connection-Reply
    • TCP 接続を閉じる
    • 遷移先：Idle 状態

3.1.3. Start Control Connection 初期化要求の衝突 (Initiation Request Collision)​

PAC と PNS が同時に制御接続を確立しようとすると、衝突が発生する可能性があります。処理は次のとおりです：

  1. 衝突の検出：一方が Wait-Reply 状態で Start-Control-Connection-Request を受信したとき
  2. 衝突の解決：
    • IP アドレスを比較する（数値）
    • IP アドレスが小さい方：開始した接続を閉じ、ピアの接続を受け入れる
    • IP アドレスが大きい方：開始した接続を続行し、ピアの接続を拒否する
  3. 最終結果：1 つの制御接続のみが確立される

3.1.4. キープアライブとタイマー (Keep Alives and Timers)​

制御接続のアクティブ状態を維持するために、次のメカニズムが実装されています：

Echo-Request/Reply メカニズム

  • 送信頻度：60 秒ごとに Echo-Request を送信することが推奨されます
  • タイムアウト処理：60 秒以内に Echo-Reply を受信しない場合、接続は失敗したと見なされます
  • 再試行戦略：最大 3 回まで再試行でき、各試行の間隔は 60 秒です
  • 接続失敗：連続して複数回タイムアウトした後、制御接続を閉じます

TCP キープアライブ

  • TCP 層のキープアライブメカニズムを補完として使用できます
  • PPTP 層の Echo メカニズムは必須 (MUST) です

タイマーパラメータ

  • 制御接続確立タイムアウト：60 秒
  • キープアライブ間隔：60 秒
  • Echo-Reply タイムアウト：60 秒
  • 制御接続クローズタイムアウト：60 秒

これらのタイマー値は推奨値であり、実装は必要に応じて調整できますが、次のことを確認する必要があります：

  • キープアライブ間隔は接続失敗をタイムリーに検出できるよう十分に短い
  • タイムアウト値はネットワーク遅延による誤判定を避けるため十分に長い

3.2. コール状態 (Call States)​

3.2.1. タイミングの考慮事項 (Timing Considerations)​

電話シグナリングのリアルタイム性により、PNS と PAC の両方は、複数のコールに関連するメッセージがシリアライズされてブロックされないように、マルチスレッドアーキテクチャで実装する必要があります。PAC と PNS 間の転送遅延は 1 秒を超えてはなりません (SHOULD NOT)。コールおよび接続状態図は、タイマーによって引き起こされる例外を明示的に指定していません。暗黙の前提は、TCP ベースの制御接続が Keep-Alive メッセージによって検証されているため、コール制御メッセージに対して厳格なタイマーを維持する必要性が少ないということです。

モデムトレーニングおよびネゴシエーションシーケンスを含む国際発信コールの確立には、1 分以上かかる場合があるため、短いタイマーの使用は推奨されません。

状態遷移が 1 分以内に発生しない場合（アイドルまたは確立状態の接続を除く）、ピア間のプロトコル処理の整合性が疑わしいため、制御接続全体 (ENTIRE CONTROL CONNECTION) を閉じて再起動する必要があります。制御接続が開始されるたびに、すべてのコール ID が論理的に解放されます。これは、課金コールが「失われて」永遠にクリアされないことを防ぐのにも役立ちます。

3.2.2. コール ID 値 (Call ID Values)​

各ピアは、要求または受け入れる各ユーザーセッションにコール ID 値を割り当てます。このコール ID 値は、それが属する PNS と PAC 間のトンネル内で一意である必要があります (MUST)。他のピアへのトンネルは同じコール ID 番号を使用できるため、トンネル上のパケットの受信者は、ユーザーセッションを特定のトンネルとコール ID に関連付ける必要があります。各トンネルの潜在的なコール ID 値の数は、特定のトンネルで予想される最大コール数の少なくとも 2 倍であることが推奨されます。

セッションは、3 つ組 (PAC, PNS, Call ID) によって定義されます。

3.2.3. 着信コール (Incoming Calls)​

関連する電話回線が鳴ると、PAC によって Incoming-Call-Request メッセージが生成されます。PAC はコール ID とシリアル番号を選択し、コールベアラータイプを示します。モデムは常にアナログコールタイプを示す必要があります (SHOULD)。ISDN コールは、無制限デジタルサービスまたはレート適応が使用される場合はデジタルを示し、デジタルモデムが関与する場合はアナログを示す必要があります (SHOULD)。発信番号、着信番号、およびサブアドレスが電話ネットワークから利用可能な場合は、メッセージに含めることができます。

PAC が Incoming-Call-Request を送信すると、PNS からの応答を待ちますが、電話ネットワークからのコールには応答しません。次の場合、PNS はコールを受け入れないことを選択できます：

  • より多くのセッションを処理するための利用可能なリソースがない
  • 着信、発信、またはサブアドレスフィールドが承認されたユーザーを示していない
  • ベアラーサービスが承認されていないかサポートされていない

PNS がコールを受け入れることを選択した場合、ウィンドウサイズ（セクション 4.2 参照）も示す Incoming-Call-Reply で応答します。PAC が Outgoing-Call-Reply を受信すると、発信者が切断していないと仮定して、コールの接続を試みます。PAC から PNS への最終的なコール接続メッセージは、PAC と PNS の両方のコール状態が確立状態に入る必要があることを示します。

ダイヤルインクライアントが切断すると、コールは正常にクリアされ、PAC は Call-Disconnect-Notify メッセージを送信します。PNS がコールをクリアしたい場合は、Call-Clear-Request メッセージを送信し、Call-Disconnect-Notify を待ちます。

3.2.3.1. PAC 着信コール状態 (PAC Incoming Call States)​

PAC の着信コールに関連する状態は次のとおりです：

idle（アイドル）

  • PAC は、その電話インターフェースの 1 つで着信コールを検出します。通常、これはアナログ回線が鳴っているか、ISDN TE が着信 Q.931 SETUP メッセージを検出したことを意味します。PAC は Incoming-Call-Request メッセージを送信し、wait_reply 状態に移行します。

wait_reply（応答待ち）

  • PAC は、コールを受け入れる意思がないことを示す Incoming-Call-Reply メッセージ（一般エラーまたは不受理）を受信し、アイドル状態に戻ります。応答メッセージがコールが受け入れられたことを示す場合、PAC は Incoming-Call-Connected メッセージを送信し、確立状態に入ります。

established（確立済み）

  • データがトンネルを介して交換されます。コールは次の場合にクリアされる可能性があります：
    • 電話接続上のイベント。PAC は Call-Disconnect-Notify メッセージを送信
    • Call-Clear-Request の受信。PAC は Call-Disconnect-Notify メッセージを送信
    • ローカルな理由。PAC は Call-Disconnect-Notify メッセージを送信

3.2.3.2. PNS 着信コール状態 (PNS Incoming Call States)​

PNS の着信コールに関連する状態は次のとおりです：

idle（アイドル）

  • Incoming-Call-Request メッセージを受信します。リクエストが受け入れられない場合、Incoming-Call-Reply が PAC に送信され、PNS はアイドル状態のままです。Incoming-Call-Request メッセージが受け入れられる場合、結果コードで受け入れを示す Incoming-Call-Reply が送信されます。セッションは wait_connect 状態に移行します。

wait_connect（接続待ち）

  • PAC でセッションが接続されると、PAC は PNS に着信コール接続メッセージを送信し、PNS は確立状態に移行します。PAC は、着信発信者が接続できなかったことを示すために Call-Disconnect-Notify を送信する場合があります。これは、たとえば、電話ユーザーが誤って PAC への標準音声コールを行い、着信モデムでのハンドシェイクが失敗した場合に発生する可能性があります。

established（確立済み）

  • セッションは、PAC からの Call-Disconnect-Notify メッセージの受信または Call-Clear-Request の送信によって終了されます。Call-Clear-Request が送信されると、セッションは wait_disconnect 状態に入ります。

wait_disconnect（切断待ち）

  • Call-Disconnect-Notify を受信すると、セッションはアイドル状態に戻ります。

3.2.4. 発信コール (Outgoing Calls)​

発信メッセージは PNS によって開始され、PAC に電話インターフェースでコールを発信するよう指示します。発信コールには 2 つのメッセージしかありません：Outgoing-Call-Request と Outgoing-Call-Reply。PNS は、着信先の電話番号とサブアドレス、および速度とウィンドウパラメータを指定して Outgoing-Call-Request を送信します。PAC は、次のことを判断すると、Outgoing-Call-Reply メッセージで Outgoing-Call-Request メッセージに応答する必要があります (MUST)：

  • コールが正常に接続された
  • 次のような理由でコール失敗が発生した：ダイヤルアウトに使用可能なインターフェースがない、着信先が話中または応答しない、またはダイヤル用に選択されたインターフェースでダイヤルトーンが検出されない

3.2.4.1. PAC 発信コール状態 (PAC Outgoing Call States)​

PAC の発信コールに関連する状態は次のとおりです：

idle（アイドル）

  • Outgoing-Call-Request を受信しました。これがエラーで受信された場合、エラー条件が設定された Outgoing-Call-Reply で応答します。それ以外の場合は、ダイヤルする物理チャネルを割り当てます。発信コールを発信し、接続を待ち、wait_cs_ans 状態に移行します。

wait_cs_ans（回線交換応答待ち）

  • コールが不完全な場合、ゼロ以外のエラーコードを含む Outgoing-Call-Reply を送信します。発信コールのタイマーが期限切れになった場合、ゼロ以外のエラーコードを含む Outgoing-Call-Reply を送信します。回線交換接続が確立された場合、成功を示す Outgoing-Call-Reply を送信します。

established（確立済み）

  • Call-Clear-Request を受信した場合、適切なメカニズムを介して電話コールを解放するべきであり (SHOULD)、PNS に Call-Disconnect-Notify メッセージを送信するべきです (SHOULD)。クライアントまたは電話インターフェースによってコールが切断された場合、PNS に Call-Disconnect-Notify メッセージを送信するべきです (SHOULD)。

3.2.4.2. PNS 発信コール状態 (PNS Outgoing Call States)​

PNS の発信コールに関連する状態は次のとおりです：

idle（アイドル）

  • 上位層アプリケーションからのオープン指示により、Outgoing-Call-Request が送信され、wait_reply 状態に移行します。

wait_reply（応答待ち）

  • エラーを含む Outgoing-Call-Reply を受信した場合、アイドル状態に戻ります。成功した Outgoing-Call-Reply を受信した場合、確立状態に移行します。Outgoing-Call-Reply を待っている間に中止が発生した場合、Call-Clear-Request を送信し、wait_disconnect 状態に移行します。

established（確立済み）

  • Call-Disconnect-Notify を受信した場合、アイドル状態に移行します。ローカル終了が発生した場合、Call-Clear-Request を送信し、wait_disconnect 状態に移行します。

wait_disconnect（切断待ち）

  • Call-Disconnect-Notify を受信した場合、アイドル状態に移行します。
に最終更新