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

5. Protocol Operation (プロトコル操作)

L2TPでPPPセッションをトンネリングするために必要なセットアップは、(1) トンネルの制御接続の確立、および (2) 着信または発信コール要求によってトリガーされるセッションの確立の2つのステップで構成されます。トンネルと対応する制御接続は、着信または発信コールが開始される前に確立されなければなりません (MUST)。L2TPセッションは、L2TPがPPPフレームのトンネリングを開始できるようになる前に確立されなければなりません (MUST)。単一のトンネル内に複数のセッションが存在でき、同じLACとLNSの間に複数のトンネルが存在できます。

5.1 Control Connection Establishment (制御接続の確立)​

制御接続は、セッションを確立する前にLACとLNSの間で達成されなければならない初期接続です。制御接続の確立には、ピアの識別の確保、およびピアのL2TPバージョン、フレーミング、ベアラー機能などの識別が含まれます。

制御接続を設定するために3メッセージ交換が利用されます。以下は典型的なメッセージ交換です：

LAC or LNS  LAC or LNS
----------  ----------
SCCRQ ->
            <- SCCRP
SCCCN ->
            <- ZLB ACK

そのピアのキューに他のメッセージが待機していない場合、ZLB ACKが送信されます。

5.1.1 Tunnel Authentication (トンネル認証)​

L2TPは、制御接続確立中に、シンプルでオプショナルなCHAPライク [RFC1994] のトンネル認証システムを組み込んでいます。LACまたはLNSが、接続している、または接続されているピアの識別を認証したい場合、Challenge AVPがSCCRQまたはSCCRPメッセージに含まれます。SCCRQまたはSCCRPでChallenge AVPが受信された場合、Challenge Response AVPは、それぞれ後続のSCCRPまたはSCCCNで送信されなければなりません (MUST)。予想される応答とピアから受信された応答が一致しない場合、トンネルの確立を許可してはなりません (MUST)。

トンネル認証に参加するには、LACとLNSの間に単一の共有秘密が存在しなければなりません (MUST)。これは、AVP隠蔽に使用される共有秘密と同じです（セクション4.3を参照）。ChallengeおよびResponse AVPの構築の詳細については、セクション4.4.3を参照してください。

5.2 Session Establishment (セッション確立)​

制御接続の確立が成功した後、個々のセッションを作成できます。各セッションは、LACとLNSの間の単一のPPPストリームに対応します。制御接続の確立とは異なり、セッション確立はLACとLNSに関して方向性があります。LACは着信コールのセッションを受け入れるようLNSに要求し、LNSは発信コールを行うためのセッションを受け入れるようLACに要求します。

5.2.1 Incoming Call Establishment (着信コール確立)​

セッションを設定するために3メッセージ交換が使用されます。以下は典型的なイベントシーケンスです：

LAC         LNS
---         ---
(Call
 Detected)

ICRQ ->
         <- ICRP
ICCN ->
         <- ZLB ACK

そのピアのキューに他のメッセージが待機していない場合、ZLB ACKが送信されます。

5.2.2 Outgoing Call Establishment (発信コール確立)​

セッションを設定するために3メッセージ交換が使用されます。以下は典型的なイベントシーケンスです：

LAC         LNS
---         ---
         <- OCRQ
OCRP ->

(Perform
 Call
 Operation)

OCCN ->
         <- ZLB ACK

そのピアのキューに他のメッセージが待機していない場合、ZLB ACKが送信されます。

5.3 Forwarding PPP Frames (PPPフレームの転送)​

トンネル確立が完了すると、リモートシステムからのPPPフレームがLACで受信され、CRC、リンクフレーミング、および透過性バイトが除去され、L2TPにカプセル化され、適切なトンネルを介して転送されます。LNSはL2TPパケットを受信し、ローカルPPPインターフェースで受信されたかのようにカプセル化されたPPPフレームを処理します。

特定のセッションとトンネルに関連付けられたメッセージの送信者は、すべての発信メッセージのSession IDとTunnel IDヘッダーに、ピアによって指定されたSession IDとTunnel IDを配置します。この方法で、PPPフレームは、特定のLNS-LACペア間の単一のトンネルを介して多重化および逆多重化されます。特定のLNS-LACペア間に複数のトンネルが存在でき、トンネル内に複数のセッションが存在できます。

Session IDとTunnel IDの値0は特別であり、Assigned Session IDまたはAssigned Tunnel IDとして使用してはなりません (MUST NOT)。Session IDがピアによってまだ割り当てられていないケース（すなわち、新しいセッションまたはトンネルの確立中）では、Session IDフィールドは0として送信されなければならず (MUST)、メッセージ内のAssigned Session ID AVPがセッションを識別するために使用されなければなりません (MUST)。同様に、Tunnel IDがピアから割り当てられていないケースでは、Tunnel IDは0として送信されなければならず (MUST)、Assigned Tunnel ID AVPがトンネルを識別するために使用されます。

5.4 Using Sequence Numbers on the Data Channel (データチャネルでのシーケンス番号の使用)​

シーケンス番号は、制御メッセージ用およびオプションでデータメッセージ用のL2TPヘッダーで定義されています（セクション3.1を参照）。これらは、信頼性の高い制御メッセージ転送（セクション5.8を参照）およびオプションのデータメッセージシーケンシングを提供するために使用されます。各ピアは、トンネル内の制御接続と各個別データセッションに対して個別のシーケンス番号を維持します。

L2TP制御チャネルとは異なり、L2TPデータチャネルは、失われたデータメッセージを再送信するためにシーケンス番号を使用しません。むしろ、データメッセージは、失われたパケットを検出したり、転送中に並べ替えられた可能性のあるパケットの元のシーケンスを復元したりするためにシーケンス番号を使用する場合があります。LACは、Sequencing Required AVP（セクション4.4.6を参照）を介してデータメッセージにシーケンス番号が存在することを要求できます。セッションセットアップ中にこのAVPが存在する場合、シーケンス番号は常に存在しなければなりません (MUST)。このAVPが存在しない場合、シーケンシングの存在はLNSの制御下にあります。

LNSは、セッションの存続期間中いつでも、シーケンス番号の有無にかかわらずデータメッセージを送信することにより、シーケンス番号の有効化と無効化を制御します。したがって、LACがシーケンス番号なしのデータメッセージを受信した場合、将来のデータメッセージでシーケンス番号の送信を停止しなければなりません (MUST)。LACがシーケンス番号付きのデータメッセージを受信した場合、将来の送信データメッセージでシーケンス番号の送信を開始しなければなりません (MUST)。LNSがセッションの早い段階でシーケンシングを無効にした後にシーケンシングを有効にする場合、シーケンス番号の状態は以前に中断した場所から再開されます。

LNSは、セッション中のいつでも（送信される最初のデータメッセージを含む）シーケンシングの無効化を開始できます。並べ替えまたはパケット損失が発生する可能性のある接続では、PPPの初期ネゴシエーション段階でシーケンス番号を常に有効にし、リスクが許容可能と見なされる場合にのみ無効にすることをお勧めします。

5.5 Keepalive (Hello) (キープアライブ)​

L2TPは、トンネルの停止とトンネル上の制御またはデータアクティビティがない長期間を区別するために、キープアライブメカニズムを採用しています。これは、トンネルで最後のデータまたは制御メッセージが受信されてから指定された期間が経過した後にHello制御メッセージ（セクション6.5を参照）を注入することによって実現されます。他の制御メッセージと同様に、Helloメッセージが確実に配信されない場合、トンネルはダウンと宣言され、リセットされます。

5.6 Session Teardown (セッションティアダウン)​

セッションティアダウンは、LACまたはLNSによって開始され、CDN制御メッセージを送信することによって実行されます。最後のセッションがクリアされた後、制御接続も切断される場合があります (MAY)（通常はそうです）。

5.7 Control Connection Teardown (制御接続ティアダウン)​

制御接続ティアダウンは、LACまたはLNSによって開始され、単一のStopCCN制御メッセージを送信することによって実行されます。StopCCNの受信者は、メッセージの受信を確認するためにZLB ACKを送信しなければならず (MUST)、少なくとも完全な再送信サイクルにわたってStopCCN再送信を適切に受け入れるのに十分な制御接続状態を維持しなければなりません（ZLB ACKが失われた場合）。完全な再送信サイクルの推奨時間は31秒です（セクション5.8を参照）。

実装は、StopCCNを送信することにより、トンネル全体とトンネル上のすべてのセッションをシャットダウンできます。したがって、トンネル全体を切断する場合、各セッションを個別にクリアする必要はありません。

5.8 Reliable Delivery of Control Messages (制御メッセージの信頼性の高い配信)​

L2TPは、すべての制御メッセージに対して低レベルの信頼性の高いトランスポートサービスを提供します。制御メッセージヘッダーのNrおよびNsフィールド（セクション3.1を参照）はこのトランスポートに属します。L2TPの上位レベル機能は、制御メッセージの再送信や順序付けに関与しません。信頼性の高い制御メッセージは、制御メッセージの再送信と輻輳制御を提供するスライディングウィンドウトランスポートです。

メッセージシーケンス番号Nsは0から始まります。後続の各メッセージは、シーケンス番号の次の増分で送信されます。したがって、シーケンス番号はモジュロ65536で表される自由実行カウンターです。

(第5章完了)

に最終更新