Skip to main content

5. Protocol Operation (协议操作)

使用 L2TP 隧道传输 PPP 会话所需的设置包括两个步骤：(1) 为隧道建立控制连接 (Control Connection)，以及 (2) 由传入或传出呼叫请求触发建立会话 (Session)。隧道和相应的控制连接必须 (MUST) 在启动传入或传出呼叫之前建立。L2TP 会话必须 (MUST) 在 L2TP 可以开始隧道传输 PPP 帧之前建立。多个会话可以存在于单个隧道中，并且多个隧道可以存在于同一 LAC 和 LNS 之间。

                  +-----+                               +-----+
                  |     |~~~~~~~~~~L2TP Tunnel~~~~~~~~~~|     |
                  | LAC |                               | LNS |
                  |     #######Control Connection########     |
[Remote]          |     |                               |     |
[System]------Call----------*============L2TP Session=============*  |
  PPP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++  |
                  |     |                               |     |
[Remote]          |     |                               |     |
[System]------Call----------*============L2TP Session=============*  |
  PPP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++  |
                  |     |                               |     |
                  |     |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|     |
                  +-----+                               +-----+

图 5.1 隧道传输 PPP

5.1 Control Connection Establishment (控制连接建立)​

控制连接是在会话可以建立之前必须在 LAC 和 LNS 之间实现的初始连接。控制连接的建立包括确保对等方的身份，以及识别对等方的 L2TP 版本、成帧和承载能力等。

使用三消息交换来建立控制连接。以下是典型的消息交换：

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

如果该对等方的队列中没有其他消息等待，则发送 ZLB ACK。

5.1.1 Tunnel Authentication (隧道认证)​

L2TP 在控制连接建立期间包含一个简单的、可选的、类似 CHAP [RFC1994] 的隧道认证系统。如果 LAC 或 LNS 希望认证其正在联系或被联系的对等方的身份，则在 SCCRQ 或 SCCRP 消息中包含 Challenge AVP。如果在 SCCRQ 或 SCCRP 中收到 Challenge AVP，则必须 (MUST) 在随后的 SCCRP 或 SCCCN 中分别发送 Challenge Response AVP。如果预期的响应与从对等方收到的响应不匹配，则必须 (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 (传入呼叫建立)​

使用三消息交换来建立会话。以下是典型的事件序列：

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

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

如果该对等方的队列中没有其他消息等待，则发送 ZLB ACK。

5.2.2 Outgoing Call Establishment (传出呼叫建立)​

使用三消息交换来建立会话。以下是典型的事件序列：

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 是特殊的，不得 (MUST NOT) 用作 Assigned Session ID 或 Assigned Tunnel ID。对于对等方尚未分配 Session ID 的情况（即，在建立新会话或隧道期间），Session ID 字段必须 (MUST) 作为 0 发送，并且消息中的 Assigned Session ID AVP 必须 (MUST) 用于标识会话。类似地，对于对等方尚未分配 Tunnel ID 的情况，Tunnel ID 必须 (MUST) 作为 0 发送，并使用 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 的初始协商阶段始终启用序列号，并且仅在风险被认为可接受时才禁用。例如，如果正在隧道传输的 PPP 会话不使用任何有状态压缩或加密协议，并且仅承载 IP（由建立的 PPP NCP 确定），则 LNS 可能决定禁用排序，因为 IP 对数据报丢失和重新排序具有容忍性。

5.5 Keepalive (Hello) (保活)​

L2TP 采用保活机制，以便将隧道中断与隧道上没有控制或数据活动的延长期区分开来。这是通过在自隧道上接收到最后一个数据或控制消息以来经过指定时间段后注入 Hello 控制消息（参见第 6.5 节）来实现的。与任何其他控制消息一样，如果 Hello 消息未可靠传递，则隧道被声明为关闭并被重置。传输重置机制与 Hello 消息的注入确保在隧道的两端检测到 LNS 和 LAC 之间的连接故障。

5.6 Session Teardown (会话拆除)​

会话拆除可以由 LAC 或 LNS 启动，并通过发送 CDN 控制消息来完成。在清除最后一个会话后，控制连接也可以 (MAY) 被拆除（通常是这样）。以下是典型控制消息交换的示例：

LAC or LNS  LAC or LNS

CDN ->
(Clean up)

            <- ZLB ACK
               (Clean up)

5.7 Control Connection Teardown (控制连接拆除)​

控制连接拆除可以由 LAC 或 LNS 启动，并通过发送单个 StopCCN 控制消息来完成。StopCCN 的接收者必须 (MUST) 发送 ZLB ACK 以确认收到消息，并维护足够的控制连接状态以正确接受至少一个完整重传周期内的 StopCCN 重传（以防 ZLB ACK 丢失）。完整重传周期的推荐时间为 31 秒（参见第 5.8 节）。以下是典型控制消息交换的示例：

LAC or LNS  LAC or LNS

StopCCN ->
(Clean up)

            <- ZLB ACK
               (Wait)
               (Clean up)

实现可以通过发送 StopCCN 来关闭整个隧道和隧道上的所有会话。因此，在拆除整个隧道时，不必单独清除每个会话。

5.8 Reliable Delivery of Control Messages (控制消息的可靠传递)​

L2TP 为所有控制消息提供较低级别的可靠传输服务。控制消息头部的 Nr 和 Ns 字段（参见第 3.1 节）属于此传输。L2TP 的上层功能不关心控制消息的重传或排序。可靠控制消息是一种滑动窗口传输，提供控制消息重传和拥塞控制。每个对等方为隧道内的控制连接维护单独的序列号状态。

消息序列号 Ns 从 0 开始。每个后续消息都以序列号的下一个增量发送。因此，序列号是以模 65536 表示的自由运行计数器。如果接收消息头部中的序列号的值位于最后接收的编号和前面的 32767 个值（含）的范围内，则认为该序列号小于或等于最后接收的编号。例如，如果最后接收的序列号为 15，则序列号为 0 到 15 以及 32784 到 65535 的消息将被认为小于或等于。这样的消息将被认为是已经接收的消息的重复，并从处理中被忽略。但是，为了确保所有消息都得到正确确认（特别是在 ZLB ACK 消息丢失的情况下），必须 (MUST) 确认收到重复消息。

(第5章完成)

Last updated on