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

3. Protocol Overview (プロトコル概要)

L2TPは、制御メッセージ (control messages) とデータメッセージ (data messages) の2種類のメッセージを利用します。制御メッセージは、トンネルと呼の確立、維持、およびクリアに使用されます。データメッセージは、トンネルを介して伝送されるPPPフレームをカプセル化するために使用されます。制御メッセージは、L2TP内の信頼性の高い制御チャネル (reliable Control Channel) を利用して配信を保証します（詳細については、セクション5.1を参照してください）。データメッセージは、パケット損失が発生しても再送信されません。

+-------------------+
| PPP Frames        |
+-------------------+    +-----------------------+
| L2TP Data Messages|    | L2TP Control Messages |
+-------------------+    +-----------------------+
| L2TP Data Channel |    | L2TP Control Channel  |
| (unreliable)      |    | (reliable)            |
+------------------------------------------------+
|      Packet Transport (UDP, FR, ATM, etc.)     |
+------------------------------------------------+

図3.0 L2TPプロトコル構造

図3.0は、L2TP制御チャネルとデータチャネル上のPPPフレームと制御メッセージの関係を示しています。PPPフレームは、最初にL2TPヘッダーでカプセル化され、次にUDP、フレームリレー、ATMなどのパケット転送でカプセル化された信頼性のないデータチャネルを介して渡されます。制御メッセージは、同じパケット転送上でインバンドでパケットを送信する信頼性の高いL2TP制御チャネルを介して送信されます。

すべての制御メッセージにはシーケンス番号が存在しなければならず (MUST)、制御チャネル上で信頼性の高い配信を提供するために使用されます。データメッセージは、パケットを並べ替え、失われたパケットを検出するためにシーケンス番号を使用できます (MAY)。

すべての値は、それぞれのフィールドに配置され、ネットワーク順序（上位オクテット優先）で送信されます。

3.1 L2TP Header Format (L2TPヘッダー形式)​

制御チャネルとデータチャネルのL2TPパケットは、共通のヘッダー形式を共有します。各ケースでフィールドがオプションの場合、フィールドが存在しないとマークされている場合、そのフィールドのスペースはメッセージ内に存在しません。データメッセージではオプションですが、以下でオプションとしてマークされているLength、Ns、およびNrフィールドは、すべての制御メッセージに存在しなければならない (MUST) ことに注意してください。

このヘッダーは次のようにフォーマットされています：

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|L|x|x|S|x|O|P|x|x|x|x|  Ver  |          Length (opt)         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Tunnel ID           |           Session ID          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Ns (opt)          |             Nr (opt)          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Offset Size (opt)        |    Offset pad... (opt)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

図3.1 L2TPメッセージヘッダー

Type (T) ビットは、メッセージのタイプを示します。データメッセージの場合は0、制御メッセージの場合は1に設定されます。

Length (L) ビットが1の場合、Lengthフィールドが存在します。このビットは、制御メッセージの場合、1に設定されなければなりません (MUST)。

x ビットは、将来の拡張のために予約されています。すべての予約ビットは、送信メッセージでは0に設定されなければならず (MUST)、受信メッセージでは無視されます。

Sequence (S) ビットが1に設定されている場合、NsおよびNrフィールドが存在します。Sビットは、制御メッセージの場合、1に設定されなければなりません (MUST)。

Offset (O) ビットが1の場合、Offset Sizeフィールドが存在します。Oビットは、制御メッセージの場合、0（ゼロ）に設定されなければなりません (MUST)。

Priority (P) ビットが1の場合、このデータメッセージは、ローカルキューイングおよび送信において優先的な処理を受けるべきです (SHOULD)。たとえば、リンクのキープアライブとして使用されるLCPエコー要求は、通常、このビットを1に設定して送信されるべきです (SHOULD)。これがないと、ローカル輻輳の一時的な間隔によってキープアライブメッセージが妨害され、リンクが不必要に失われる可能性があります。この機能は、データメッセージにのみ使用されます。Pビットは、すべての制御メッセージに対して0に設定されなければなりません (MUST)。

Verは2でなければならず (MUST)、この文書で説明されているL2TPデータメッセージヘッダーのバージョンを示します。値1は、L2F [RFC2341] パケットがL2TPパケットと混在して到着した場合にそれらを検出できるように予約されています。未知のVerフィールドを持つパケットを受信した場合、破棄されなければなりません (MUST)。

Lengthフィールドは、メッセージの全長をオクテット単位で示します。

Tunnel IDは、制御接続の識別子を示します。L2TPトンネルは、ローカルでのみ意味を持つ識別子によって名前が付けられます。つまり、トンネルの各端は、同じトンネルに異なるTunnel IDを与えます。各メッセージのTunnel IDは、送信者ではなく、意図された受信者のIDです。Tunnel IDは、トンネルの作成中にAssigned Tunnel ID AVPとして選択および交換されます。

Session IDは、トンネル内のセッションの識別子を示します。L2TPセッションは、ローカルでのみ意味を持つ識別子によって名前が付けられます。つまり、セッションの各端は、同じセッションに異なるSession IDを与えます。各メッセージのSession IDは、送信者ではなく、意図された受信者のIDです。Session IDは、セッションの作成中にAssigned Session ID AVPとして選択および交換されます。

Nsは、このデータまたは制御メッセージのシーケンス番号を示し、ゼロから始まり、送信される各メッセージごとに1ずつ（2**16でモジュロ）増加します。このフィールドの使用に関する詳細については、セクション5.8および5.4を参照してください。

Nrは、受信する次の制御メッセージで期待されるシーケンス番号を示します。したがって、Nrは、最後に順序どおりに受信されたメッセージのNsに1を加えた値（2**16でモジュロ）に設定されます。データメッセージでは、Nrは予約されており、存在する場合（Sビットによって示される）、受信時に無視されなければなりません (MUST)。制御メッセージでこのフィールドを使用する方法の詳細については、セクション5.8を参照してください。

Offset Sizeフィールド（存在する場合）は、L2TPヘッダーを過ぎてペイロードデータが開始すると予想される位置までのオクテット数を指定します。オフセットパディング内の実際のデータは未定義です。オフセットフィールドが存在する場合、L2TPヘッダーは、オフセットパディングの最後のオクテットの後に終了します。

3.2 Control Message Types (制御メッセージタイプ)​

Message Type AVP（セクション4.4.1を参照）は、送信される制御メッセージの特定のタイプを定義します。セクション3.1から、これは制御メッセージ、つまりTビットが1に設定されたメッセージにのみ適用されることを思い出してください。

この文書では、以下の制御メッセージタイプを定義しています（各メッセージの構成と使用の詳細については、セクション6.1から6.14を参照してください）：

制御接続管理 (Control Connection Management)

  • 0 (reserved) 予約済み
  • 1 (SCCRQ) Start-Control-Connection-Request (制御接続開始要求)
  • 2 (SCCRP) Start-Control-Connection-Reply (制御接続開始応答)
  • 3 (SCCCN) Start-Control-Connection-Connected (制御接続開始完了)
  • 4 (StopCCN) Stop-Control-Connection-Notification (制御接続停止通知)
  • 5 (reserved) 予約済み
  • 6 (HELLO) Hello (ハロー)

呼管理 (Call Management)

  • 7 (OCRQ) Outgoing-Call-Request (発信呼要求)
  • 8 (OCRP) Outgoing-Call-Reply (発信呼応答)
  • 9 (OCCN) Outgoing-Call-Connected (発信呼接続完了)
  • 10 (ICRQ) Incoming-Call-Request (着信呼要求)
  • 11 (ICRP) Incoming-Call-Reply (着信呼応答)
  • 12 (ICCN) Incoming-Call-Connected (着信呼接続完了)
  • 13 (reserved) 予約済み
  • 14 (CDN) Call-Disconnect-Notify (呼切断通知)

エラー報告 (Error Reporting)

  • 15 (WEN) WAN-Error-Notify (WANエラー通知)

PPPセッション制御 (PPP Session Control)

  • 16 (SLI) Set-Link-Info (リンク情報設定)
に最終更新