5. 协议操作

使用 L2TP 隧道传送 PPP 会话所需的设置包含两个步骤: (1) 为隧道建立控制连接, 以及 (2) 由入站或出站呼叫请求触发建立会话. 在发起入站或出站呼叫之前, 隧道及其对应的控制连接 MUST 已建立. 在 L2TP 能够开始隧道传送 PPP 帧之前, L2TP 会话 MUST 已建立. 单个隧道上可以存在多个会话, 同一 LAC 和 LNS 之间也可以存在多个隧道.

5.1 控制连接建立

控制连接是在会话能够启动之前, LAC 和 LNS 之间必须首先建立的连接. 建立控制连接包括确认对等方身份, 以及识别对等方的 L2TP 版本, 成帧能力, 承载能力等.

控制连接通过三条消息交换建立. 下面是典型的消息交换:

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

如果没有更多消息在队列中等待发送给该对等方, 则发送 ZLB ACK.

5.1.1 隧道认证

L2TP 在控制连接建立期间包含一个简单的, 可选的, 类 CHAP [RFC1994] 隧道认证系统. 如果 LAC 或 LNS 希望认证其正在联系或被联系的对等方身份, 则在 SCCRQ 或 SCCRP 消息中包含 Challenge AVP. 如果在 SCCRQ 或 SCCRP 中收到 Challenge AVP, 则分别在后续 SCCRP 或 SCCCN 中 MUST 发送 Challenge Response AVP. 如果预期响应与从对等方收到的响应不匹配, 则 MUST 不允许建立隧道.

要参与隧道认证, LAC 和 LNS 之间 MUST 存在单个共享秘密. 这与用于 AVP 隐藏的共享秘密相同 (参见第 4.3 节). Challenge 和 Response AVP 的构造细节见第 4.4.3 节.

5.2 会话建立

控制连接成功建立后, 可以创建各个会话. 每个会话对应 LAC 和 LNS 之间的单个 PPP 流. 与控制连接建立不同, 会话建立相对于 LAC 和 LNS 是有方向的. LAC 请求 LNS 接受入站呼叫的会话, LNS 请求 LAC 接受用于发起出站呼叫的会话.

5.2.1 入站呼叫建立

会话通过三条消息交换建立. 下面是典型事件序列:

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

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

如果没有更多消息在队列中等待发送给该对等方, 则发送 ZLB ACK.

5.2.2 出站呼叫建立

会话通过三条消息交换建立. 下面是典型事件序列:

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

(Perform
 Call
 Operation)

OCCN ->
         <- ZLB ACK

如果没有更多消息在队列中等待发送给该对等方, 则发送 ZLB ACK.

5.3 转发 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 在数据通道上使用序列号

L2TP 报头为控制消息定义序列号, 并可选地为数据消息定义序列号 (参见第 3.1 节). 这些序列号用于提供可靠的控制消息传输 (参见第 5.8 节) 以及可选的数据消息排序. 每个对等方为控制连接以及隧道内的每个独立数据会话维护单独的序列号.

与 L2TP 控制通道不同, L2TP 数据通道不使用序列号来重传丢失的数据消息. 相反, 数据消息可以使用序列号检测丢包和/或恢复在传输期间可能被重排的分组原始顺序. LAC 可以通过 Sequencing Required AVP (参见第 4.4.6 节) 请求数据消息中包含序列号. 如果该 AVP 在会话设置期间存在, 则序列号 MUST 始终存在. 如果该 AVP 不存在, 是否使用序列号由 LNS 控制.

LNS 通过在会话生命周期内任意时刻发送带序列号或不带序列号的数据消息, 控制序列号的启用和禁用. 因此, 如果 LAC 收到不带序列号的数据消息, 它 MUST 停止在后续数据消息中发送序列号. 如果 LAC 收到带序列号的数据消息, 它 MUST 开始在后续出站数据消息中发送序列号.

5.5 Keepalive (Hello)

L2TP 使用 keepalive 机制来区分隧道中断和隧道上长时间没有控制或数据活动的情况. 其实现方式是: 自隧道上收到最后一个数据或控制消息起经过指定时间后, 注入 Hello 控制消息 (参见第 6.5 节). 与任何其他控制消息一样, 如果 Hello 消息未被可靠交付, 则声明隧道已关闭并重置.

5.6 会话拆除

会话拆除可由 LAC 或 LNS 发起, 通过发送 CDN 控制消息完成. 最后一个会话被清除后, 控制连接 MAY 也被拆除 (通常也会如此).

5.7 控制连接拆除

控制连接拆除可由 LAC 或 LNS 发起, 通过发送单个 StopCCN 控制消息完成. StopCCN 的接收方 MUST 发送 ZLB ACK 以确认收到该消息, 并维护足够的控制连接状态, 以便至少在一个完整重传周期内正确接受 StopCCN 重传 (以防 ZLB ACK 丢失). 一个完整重传周期的推荐时间为 31 秒 (参见第 5.8 节).

实现可以通过发送 StopCCN 关闭整个隧道及该隧道上的所有会话. 因此, 拆除整个隧道时无需逐个清除每个会话.

5.8 控制消息的可靠交付

L2TP 为所有控制消息提供较低层级的可靠传输服务. 控制消息报头中的 Nr 和 Ns 字段 (参见第 3.1 节) 属于该传输. L2TP 的上层功能不关心控制消息的重传或排序. 可靠控制消息机制是一个滑动窗口传输, 提供控制消息重传和拥塞控制.

消息序列号 Ns 从 0 开始. 每条后续消息使用下一个递增的序列号发送. 因此, 序列号是一个以 65536 为模表示的自由运行计数器.

(第 5 章完)

---