RFC 2637 - 点对点隧道协议 (Point-to-Point Tunneling Protocol)
- 状态: Informational
- 发布日期: July 1999
- Stream: IETF
- 勘误: 无勘误
文档信息
RFC编号: 2637
类别: Informational
发布日期: 1999年7月
作者: K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, G. Zorn
摘要
本文档规定了一种协议, 允许点对点协议 (Point to Point Protocol, PPP) 通过IP网络进行隧道传输.PPTP并未对PPP协议本身进行任何修改, 而是描述了一种承载PPP的新方式.定义了一种客户端-服务器架构, 以便将当前网络接入服务器 (Network Access Servers, NAS) 中存在的功能进行解耦, 并支持虚拟专用网 (Virtual Private Networks, VPNs).
PPTP网络服务器 (PPTP Network Server, PNS) 设计为在通用操作系统上运行, 而客户端称为PPTP接入集中器 (PPTP Access Concentrator, PAC), 在拨号接入平台上运行.PPTP指定了一种呼叫控制和管理协议, 该协议允许服务器控制从PSTN或ISDN发起的拨入电路交换呼叫的接入, 或发起出站电路交换连接.PPTP使用增强的GRE (Generic Routing Encapsulation, 通用路由封装) 机制, 为承载PPP数据包提供具有流量控制和拥塞控制的封装数据报服务.
IESG 注记
PPTP协议由供应商联盟开发.PPTP的文档作为信息提供给互联网社区.PPP工作组目前正在定义一个标准跟踪协议 (L2TP) 用于在分组交换网络上隧道传输PPP.
本备忘录的状态
本备忘录为互联网社区提供信息.它不指定任何类型的互联网标准.本备忘录的分发不受限制.
目录
规范要求
在本文档中, 关键词 "MAY"、"MUST"、"MUST NOT"、"optional"、"recommended"、"SHOULD" 和 "SHOULD NOT" 应按照 [RFC 2119] 中的描述进行解释.
1. 简介 (Introduction)
PPTP允许使用客户端-服务器架构来分离现有的网络接入服务器 (Network Access Server, NAS) 功能.传统上, NAS实现以下功能:
-
与PSTN或ISDN的物理本地接口, 以及对外部调制解调器或终端适配器的控制.
NAS可以直接连接到电信模拟或数字电路, 或通过外部调制解调器或终端适配器连接.电路交换连接的控制通过调制解调器控制或DSS1 ISDN呼叫控制协议来实现.
NAS与调制解调器或终端适配器一起, 可能执行速率适配、模拟到数字转换、同步到异步转换或对数据流的多种其他修改.
-
点对点协议 (Point-to-Point-Protocol, PPP) 链路控制协议 (Link Control Protocol, LCP) 会话的逻辑终结.
-
参与PPP认证协议 [3,9,10].
-
PPP多链路协议的信道聚合和捆绑管理.
-
各种PPP网络控制协议 (NCP) 的逻辑终结.
-
NAS接口之间的多协议路由和桥接.
PPTP将这些功能在PAC和PNS之间进行划分.PAC负责功能1、2, 可能还有功能3.PNS可能负责功能3, 并负责功能4、5和6.用于在PAC和PNS之间承载PPP协议数据单元 (PDUs) 以及呼叫控制和管理的协议由PPTP解决.
NAS功能解耦提供以下好处:
-
灵活的IP地址管理 (Flexible IP address management): 拨入用户在拨入不同的PAC时可以保持单一的IP地址, 只要它们由同一个PNS提供服务.如果企业网络使用未注册的地址, 则与企业关联的PNS分配对专用网络有意义的地址.
-
支持IP网络后面的拨号网络的非IP协议 (Support of non-IP protocols for dial networks behind IP networks): 这允许例如Appletalk和IPX通过仅支持IP的提供商进行隧道传输.PAC无需能够处理这些协议.
-
"多链路寻线组分割"问题的解决方案 (A solution to the "multilink hunt-group splitting" problem): 多链路PPP通常用于聚合ISDN B信道, 要求组成多链路捆绑的所有信道聚合在单个NAS上.由于多链路PPP捆绑可以由单个PNS处理, 因此组成捆绑的信道可以分布在多个PAC上.
1.1. 协议目标和假设 (Protocol Goals and Assumptions)
PPTP协议仅由PAC和PNS实现.其他系统无需了解PPTP.拨号网络可以连接到PAC而无需了解PPTP.标准PPP客户端软件应当继续在隧道PPP链路上运行.
PPTP也可用于通过IP网络隧道传输PPP会话.在这种配置中, PPTP隧道和PPP会话在同两台机器之间运行, 呼叫方充当PNS.
预计PAC和PNS之间将存在多对多关系.一个PAC可以为许多PNS提供服务.例如, 互联网服务提供商可能选择为多个专用网络客户端支持PPTP并为他们创建VPN.每个专用网络可能运行一个或多个PNS.单个PNS可能与许多PAC关联, 以聚合来自大量地理上分散的站点的流量.
PPTP使用GRE的扩展版本来承载用户PPP数据包.这些增强允许对用于在PAC和PNS之间承载用户数据的隧道提供低级拥塞和流量控制.此机制允许有效使用隧道可用的带宽, 并避免不必要的重传和缓冲区溢出.PPTP不规定用于此低级控制的特定算法, 但它确实定义了为允许此类算法工作而必须通信的参数.第4节包含建议的算法.
1.2. 术语 (Terminology)
Analog Channel (模拟信道)
一种电路交换通信路径, 旨在在每个方向上承载3.1 Khz音频.
Digital Channel (数字信道)
一种电路交换通信路径, 旨在在每个方向上承载数字信息.
Call (呼叫)
PSTN或ISDN上两个终端端点之间的连接或尝试连接, 例如, 两个调制解调器之间的电话呼叫.
Control Connection (控制连接)
为每个PAC、PNS对创建控制连接, 并通过TCP [4] 运行.控制连接管理隧道和分配给隧道的会话的各个方面.
Dial User (拨号用户)
连接到按需PSTN或ISDN的终端系统或路由器, 它是呼叫的发起方或接收方.
Network Access Server (NAS) (网络接入服务器)
为用户提供临时、按需网络接入的设备.此接入使用PSTN或ISDN线路进行点对点通信.
PPTP Access Concentrator (PAC) (PPTP接入集中器)
连接到一条或多条PSTN或ISDN线路的设备, 能够进行PPP操作和处理PPTP协议.PAC只需实现TCP/IP即可将流量传递到一个或多个PNS.它也可以隧道传输非IP协议.
PPTP Network Server (PNS) (PPTP网络服务器)
PNS设计为在通用计算/服务器平台上运行.PNS处理PPTP协议的服务器端.由于PPTP完全依赖于TCP/IP并且独立于接口硬件, 因此PNS可以使用任何IP接口硬件的组合, 包括LAN和WAN设备.
Session (会话)
PPTP是面向连接的.PNS和PAC为连接到PAC的每个用户维护状态.当在拨号用户和PNS之间尝试端到端PPP连接时, 将创建一个会话.与会话相关的数据报通过PAC和PNS之间的隧道发送.
Tunnel (隧道)
隧道由PNS-PAC对定义.隧道协议由GRE [1,2] 的修改版本定义.隧道在PAC和PNS之间承载PPP数据报.多个会话在单个隧道上复用.通过TCP运行的控制连接控制会话和隧道本身的建立、释放和维护.
1.3. 协议概述 (Protocol Overview)
PPTP有两个并行组件: 1) 在每个PAC-PNS对之间通过TCP运行的控制连接, 以及 2) 在同一PAC-PNS对之间运行的IP隧道, 用于传输该对之间用户会话的GRE封装的PPP数据包.
1.3.1. 控制连接概述 (Control Connection Overview)
在PAC和PNS之间可以进行PPP隧道传输之前, 必须在它们之间建立控制连接.控制连接是一个标准的TCP会话, 通过它传递PPTP呼叫控制和管理信息.控制会话在逻辑上与通过PPTP隧道隧道传输的会话相关联, 但是独立的.对于每个PAC-PNS对, 都存在一个隧道和一个控制连接.控制连接负责建立、管理和释放通过隧道承载的会话.它是PNS被通知关联PAC上的传入呼叫的方式, 也是PAC被指示拨出呼叫的方式.
控制连接可以由PNS或PAC建立.在建立所需的TCP连接之后, PNS和PAC使用Start-Control-Connection-Request和-Reply消息建立控制连接.这些消息还用于交换有关PAC和PNS基本操作能力的信息.一旦建立了控制连接, PAC或PNS可以通过请求出站呼叫或响应入站请求来发起会话.控制连接可以使用Set-Link-Info消息传达单个用户会话的操作特性变化.单个会话可以由PAC或PNS通过控制连接消息释放.
控制连接本身通过保活回显消息维护.这确保可以及时检测到PNS和PAC之间的连接故障.其他故障可以通过也在控制连接上的Wan-Error-Notify消息报告.
预期控制连接将来还将承载管理相关消息, 例如允许PNS请求给定PAC状态的消息; 这些消息类型尚未定义.
1.3.2. 隧道协议概述 (Tunnel Protocol Overview)
PPTP要求为每个通信的PNS-PAC对建立一个隧道.此隧道用于承载涉及给定PNS-PAC对的所有用户会话PPP数据包.GRE头部中存在的密钥指示特定PPP数据包属于哪个会话.
以这种方式, PPP数据包在给定PNS-PAC对之间的单个隧道上进行复用和解复用.要在密钥字段中使用的值由在控制连接上进行的呼叫建立过程建立.
GRE头部还包含确认和排序信息, 用于对隧道执行一定程度的拥塞控制和错误检测.同样, 控制连接用于确定用于调节通过隧道为特定会话传输PPP数据包的流量的速率和缓冲参数.PPTP不指定用于拥塞控制和流量控制的特定算法.本文档第4.4节包含用于确定自适应超时以从隧道上丢失的数据或确认中恢复的建议算法.
1.4. 消息格式和协议可扩展性 (Message Format and Protocol Extensibility)
PPTP定义了一组在PNS和给定PAC之间的控制连接上作为TCP数据发送的消息.通过发起到端口1723 [6] 的TCP连接来建立控制连接的TCP会话.源端口分配给任何未使用的端口号.
每个PPTP控制连接消息都以8个八位字节的固定头部部分开始.此固定头部包含以下内容: 消息的总长度、PPTP消息类型指示符和"Magic Cookie".
PPTP消息类型字段指示两种控制连接消息类型:
- 1 - 控制消息 (Control Message)
- 2 - 管理消息 (Management Message)
管理消息当前未定义.
Magic Cookie始终作为常量0x1A2B3C4D发送.其基本目的是允许接收方确保它与TCP数据流正确同步.它不应该用作在发送方发出格式不正确的消息时重新同步TCP数据流的手段.同步丢失必须导致立即关闭控制连接的TCP会话.
为清楚起见, 下一节中的所有控制连接消息模板都包括完整的PPTP控制连接消息头部.前面带有0x的数字是十六进制值.
当前定义的控制消息按功能分组如下:
控制消息 (Control Message) - 消息代码 (Message Code)
(控制连接管理, Control Connection Management)
- Start-Control-Connection-Request - 1
- Start-Control-Connection-Reply - 2
- Stop-Control-Connection-Request - 3
- Stop-Control-Connection-Reply - 4
- Echo-Request - 5
- Echo-Reply - 6
(呼叫管理, Call Management)
- Outgoing-Call-Request - 7
- Outgoing-Call-Reply - 8
- Incoming-Call-Request - 9
- Incoming-Call-Reply - 10
- Incoming-Call-Connected - 11
- Call-Clear-Request - 12
- Call-Disconnect-Notify - 13
(错误报告, Error Reporting)
- WAN-Error-Notify - 14
(PPP会话控制, PPP Session Control)
- Set-Link-Info - 15
Start-Control-Connection-Request和-Reply消息确定将使用哪个版本的控制连接协议.这些消息中携带的版本号字段由高八位字节中的版本号和低八位字节中的修订号组成.版本处理在第2节中描述.版本号字段的当前值是0x0100, 表示版本1, 修订版0.
第4.1节指定了用于封装PPP用户数据包的类GRE头部的使用.
封装在GRE中的用户数据包的MTU为1532个八位字节, 不包括IP和GRE头部.
2. 控制连接协议规范 (Control Connection Protocol Specification)
控制连接消息用于建立和清除用户会话.第一组控制连接消息用于维护控制连接本身.控制连接由PNS或PAC在建立底层TCP连接后发起.确定建立哪些TCP连接所需的过程和配置信息不在本协议的覆盖范围内.
以下所有控制连接消息都作为用户数据在给定PNS-PAC对之间建立的TCP连接上发送.请注意, 已注意确保所有字 (2个八位字节) 和长字 (4个八位字节) 值都从适当的边界开始.所有数据都以网络顺序 (高位八位字节在前) 发送.任何"保留"字段必须 (MUST) 作为0值发送以允许协议可扩展性.
2.1. Start-Control-Connection-Request
Start-Control-Connection-Request是用于在PNS和PAC之间建立控制连接的PPTP控制消息.每个PNS-PAC对都需要建立专用的控制连接.在发出任何其他PPTP消息之前, 必须建立控制连接.控制连接的建立可以由PNS或PAC发起.第3.1.3节描述了处理PNS和PAC的Start-Control-Connection-Requests冲突发生的过程.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Version | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Framing Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bearer Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Channels | Firmware Revision |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Host Name (64 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Vendor String (64 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length (长度): 此PPTP消息的总长度 (以八位字节为单位), 包括整个PPTP头部.
PPTP Message Type (PPTP消息类型): 1表示控制消息.
Magic Cookie (魔法Cookie): 0x1A2B3C4D.此常量值用作对接收到的消息的完整性检查 (见第1.4节).
Control Message Type (控制消息类型): 1表示Start-Control-Connection-Request.
Reserved0 (保留0): 此字段必须 (MUST) 为0.
Protocol Version (协议版本): 发送方希望使用的PPTP协议版本.
Reserved1 (保留1): 此字段必须 (MUST) 为0.
Framing Capabilities (成帧能力): 指示此消息发送方可以提供的成帧类型的位集合.当前定义的位设置为:
- 1 - 支持异步成帧 (Asynchronous Framing supported)
- 2 - 支持同步成帧 (Synchronous Framing supported)
Bearer Capabilities (承载能力): 指示此消息发送方可以提供的承载能力的位集合.当前定义的位设置为:
- 1 - 支持模拟接入 (Analog access supported)
- 2 - 支持数字接入 (Digital access supported)
Maximum Channels (最大信道数): 此PAC可以支持的单个PPP会话的总数.在PNS发出的Start-Control-Connection-Requests中, 此值应当 (SHOULD) 设置为0.PAC必须 (MUST) 忽略它.
Firmware Revision (固件修订版): 当由PAC发出时, 此字段包含发出PAC的固件修订号, 或者当由PNS发出时包含PNS PPTP驱动程序的版本.
Host Name (主机名): 包含发出PAC或PNS的DNS名称的64个八位字节字段.如果长度小于64个八位字节, 此字段的其余部分应当 (SHOULD) 填充值为0的八位字节.
Vendor Name (供应商名称): 包含供应商特定字符串的64个八位字节字段, 描述正在使用的PAC类型, 或者如果此请求由PNS发出, 则描述正在使用的PNS软件类型.如果长度小于64个八位字节, 此字段的其余部分应当 (SHOULD) 填充值为0的八位字节.
2.2. Start-Control-Connection-Reply
Start-Control-Connection-Reply是响应接收到的Start-Control-Connection-Request消息而发送的PPTP控制消息.此消息包含指示控制连接建立尝试结果的结果代码.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Version | Result Code | Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Framing Capability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bearer Capability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Channels | Firmware Revision |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Host Name (64 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Vendor String (64 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length (长度): 此PPTP消息的总长度 (以八位字节为单位), 包括整个PPTP头部.
PPTP Message Type (PPTP消息类型): 1表示控制消息.
Magic Cookie (魔法Cookie): 0x1A2B3C4D.
Control Message Type (控制消息类型): 2表示Start-Control-Connection-Reply.
Reserved0 (保留0): 此字段必须 (MUST) 为0.
Protocol Version (协议版本): 发送方希望使用的PPTP协议版本.
Result Code (结果代码): 指示命令信道建立尝试的结果.当前有效的结果代码值为:
- 1 - 成功建立信道 (Successful channel establishment)
- 2 - 一般错误 (General error) - 错误代码指示问题
- 3 - 命令信道已存在 (Command channel already exists)
- 4 - 请求方未被授权建立命令信道 (Requester is not authorized to establish a command channel)
- 5 - 不支持请求方的协议版本 (The protocol version of the requester is not supported)
Error Code (错误代码): 除非存在"一般错误", 否则此字段设置为0, 在这种情况下, 结果代码设置为2, 并且此字段设置为与第2.2节中指定的一般错误条件相对应的值.
Framing Capabilities (成帧能力): 指示此消息发送方可以提供的成帧类型的位集合.当前定义的位设置为:
- 1 - 支持异步成帧 (Asynchronous Framing supported)
- 2 - 支持同步成帧 (Synchronous Framing supported)
Bearer Capabilities (承载能力): 指示此消息发送方可以提供的承载能力的位集合.当前定义的位设置为:
- 1 - 支持模拟接入 (Analog access supported)
- 2 - 支持数字接入 (Digital access supported)
Maximum Channels (最大信道数): 此PAC可以支持的单个PPP会话的总数.在PNS发出的Start-Control-Connection-Reply中, 此值应当 (SHOULD) 设置为0, 并且PAC必须 (MUST) 忽略它.PNS不得 (MUST NOT) 使用此值来尝试跟踪PAC将允许的剩余PPP会话数.
Firmware Revision (固件修订版): 此字段包含发出PAC的固件修订号, 或者如果由PNS发出, 则包含PNS PPTP驱动程序的版本.
Host Name (主机名): 包含发出PAC或PNS的DNS名称的64个八位字节字段.如果长度小于64个八位字节, 此字段的其余部分应当 (SHOULD) 填充值为0的八位字节.
Vendor Name (供应商名称): 包含供应商特定字符串的64个八位字节字段, 描述正在使用的PAC类型, 或者如果此请求由PNS发出, 则描述正在使用的PNS软件.如果长度小于64个八位字节, 此字段的其余部分应当 (SHOULD) 填充值为0的八位字节.
2.3. Stop-Control-Connection-Request
Stop-Control-Connection-Request是PAC-PNS控制连接的一个对等方发送给另一个对等方的PPTP控制消息, 通知另一个对等方应关闭控制连接.除了关闭控制连接之外, 所有活动的用户呼叫都隐式清除.发出此请求的原因在Reason字段中指示.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason | Reserved1 | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length (长度): 此PPTP消息的总长度 (以八位字节为单位), 包括整个PPTP头部.
PPTP Message Type (PPTP消息类型): 1表示控制消息.
Magic Cookie (魔法Cookie): 0x1A2B3C4D.
Control Message Type (控制消息类型): 3表示Stop-Control-Connection-Request.
Reserved0 (保留0): 此字段必须 (MUST) 为0.
Reason (原因): 指示控制连接关闭的原因.当前有效的原因值为:
- 1 (None) - 清除控制连接的一般请求 (General request to clear control connection)
- 2 (Stop-Protocol) - 不能支持对等方的协议版本 (Can't support peer's version of the protocol)
- 3 (Stop-Local-Shutdown) - 请求方正在关闭 (Requester is being shut down)
Reserved1, Reserved2 (保留1, 保留2): 这些字段必须 (MUST) 为0.
2.4. Stop-Control-Connection-Reply
Stop-Control-Connection-Reply是PAC-PNS控制连接的一个对等方在收到另一个对等方的Stop-Control-Connection-Request后发送的PPTP控制消息.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code | Error Code | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length (长度): 此PPTP消息的总长度 (以八位字节为单位), 包括整个PPTP头部.
PPTP Message Type (PPTP消息类型): 1表示控制消息.
Magic Cookie (魔法Cookie): 0x1A2B3C4D.
Control Message Type (控制消息类型): 4表示Stop-Control-Connection-Reply.
Reserved0 (保留0): 此字段必须 (MUST) 为0.
Result Code (结果代码): 指示关闭控制连接尝试的结果.当前有效的结果代码值为:
- 1 (OK) - 控制连接已关闭 (Control connection closed)
- 2 (General Error) - 由于错误代码中指示的原因, 控制连接未关闭 (Control connection not closed for reason indicated in Error Code)
Error Code (错误代码): 除非存在"一般错误", 否则此字段设置为0, 在这种情况下, 结果代码设置为2, 并且此字段设置为与第2.2节中指定的一般错误条件相对应的值.
Reserved1 (保留1): 此字段必须 (MUST) 为0.
2.5. Echo-Request
Echo-Request是PAC-PNS控制连接的任一对等方发送的PPTP控制消息.此控制消息用作控制连接的"保活".接收对等方对收到的每个Echo-Request发出Echo-Reply.如第3.1.4节所述, 如果发送方未收到对Echo-Request的Echo-Reply, 它最终将清除控制连接.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length (长度): 此PPTP消息的总长度 (以八位字节为单位), 包括整个PPTP头部.
PPTP Message Type (PPTP消息类型): 1表示控制消息.
Magic Cookie (魔法Cookie): 0x1A2B3C4D.
Control Message Type (控制消息类型): 5表示Echo-Request.
Reserved0 (保留0): 此字段必须 (MUST) 为0.
Identifier (标识符): Echo-Request发送方设置的值, 用于将回复与相应的请求匹配.
2.6. Echo-Reply
Echo-Reply是PAC-PNS控制连接的任一对等方响应收到的Echo-Request而发送的PPTP控制消息.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code | Error Code | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length (长度): 此PPTP消息的总长度 (以八位字节为单位), 包括整个PPTP头部.
PPTP Message Type (PPTP消息类型): 1表示控制消息.
Magic Cookie (魔法Cookie): 0x1A2B3C4D.
Control Message Type (控制消息类型): 6表示Echo-Reply.
Reserved0 (保留0): 此字段必须 (MUST) 为0.
Identifier (标识符): 接收到的Echo-Request的标识字段的内容被复制到此字段.
Result Code (结果代码): 指示接收Echo-Request的结果.当前有效的结果代码值为:
- 1 (OK) - Echo-Reply有效 (The Echo-Reply is valid)
- 2 (General Error) - 由于错误代码中指示的原因, Echo-Request未被接受 (Echo-Request not accepted for the reason indicated in Error Code)
Error Code (错误代码): 除非存在"一般错误"条件, 否则此字段设置为0, 在这种情况下, 结果代码设置为2, 并且此字段设置为与第2.2节中指定的一般错误条件相对应的值.
Reserved1 (保留1): 此字段必须 (MUST) 为0.
2.7. Outgoing-Call-Request
Outgoing-Call-Request是PNS发送到PAC的PPTP控制消息, 指示要建立来自PAC的出站呼叫.此请求向PAC提供拨打呼叫所需的信息.它还向PAC提供信息, 一旦建立会话, 该信息用于调节向PNS传输此会话数据的速率.
(由于字数限制,此部分及后续部分省略详细格式图,但保留完整字段说明)
Call ID (呼叫ID): PNS分配给此会话的唯一标识符, 对于特定PAC-PNS对是唯一的.它用于对通过PNS和PAC之间的隧道发送的数据进行复用和解复用.
Call Serial Number (呼叫序列号): PNS为此会话分配的标识符, 用于在记录的会话信息中标识此特定会话.与呼叫ID不同, PNS和PAC都将相同的呼叫序列号与给定会话关联.IP地址和呼叫序列号的组合应当 (SHOULD) 是唯一的.
Minimum BPS (最小BPS): 此会话可接受的最低线速度 (以位/秒为单位).
Maximum BPS (最大BPS): 此会话可接受的最高线速度 (以位/秒为单位).
Bearer Type (承载类型): 指示此出站呼叫所需的承载能力的值.当前定义的值为:
- 1 - 在模拟信道上拨打呼叫 (Call to be placed on an analog channel)
- 2 - 在数字信道上拨打呼叫 (Call to be placed on a digital channel)
- 3 - 可以在任何类型的信道上拨打呼叫 (Call can be placed on any type of channel)
Framing Type (成帧类型): 指示此出站呼叫要使用的PPP成帧类型的值.
- 1 - 使用异步成帧的呼叫 (Call to use Asynchronous framing)
- 2 - 使用同步成帧的呼叫 (Call to use Synchronous framing)
- 3 - 可以使用任一类型的成帧的呼叫 (Call can use either type of framing)
Packet Recv. Window Size (数据包接收窗口大小): PNS将为此会话缓冲的接收数据包数.
Packet Processing Delay (数据包处理延迟): 从PNS发送到PAC的数据可能施加的数据包处理延迟的度量.此值以1/10秒为单位指定.
Phone Number Length (电话号码长度): 下一个字段中拨号方电话号码的实际长度 (以八位字节为单位).
Reserved1 (保留1): 此字段必须 (MUST) 为0.
Phone Number (电话号码): 此字段是包含要拨打的电话号码的64个八位字节字段的变长.电话号码可以是二进制编码的 (与ISDN控制信令一起使用) 或ASCII编码的 (与PSTN调制解调器一起使用) 当与PAC关联的物理介质需要时.此字段的ASCII编码值由可打印的数字字符、空格字符和连字符符号 ('-') 组成.如果长度小于64个八位字节, 此字段的其余部分应当 (SHOULD) 填充值为0的八位字节.
Subaddress (子地址): 包含要拨打的子地址的64个八位字节字段.如果长度小于64个八位字节, 此字段的其余部分应当 (SHOULD) 填充值为0的八位字节.
2.8. Outgoing-Call-Reply
Outgoing-Call-Reply是PAC发送到PNS的PPTP控制消息, 响应接收到的Outgoing-Call-Request消息.Outgoing-Call-Reply消息指示发起呼叫的尝试的结果.它还向PNS提供信息, 该信息用于调节此会话的数据从PNS到PAC的传输速率.
关键字段包括:
- Call ID: PAC分配给此会话的呼叫ID
- Peer's Call ID: 从Outgoing-Call-Request接收到的呼叫ID的值
- Result Code: 指示呼叫尝试的结果
- Connect Speed: 使用的实际连接速度 (以位/秒为单位)
- Packet Recv. Window Size: PAC将为此会话缓冲的接收数据包数
- Packet Processing Delay: 从PAC发送到PNS的数据可能施加的数据包处理延迟
- Framing Type: 此呼叫使用的PPP成帧类型
2.9. Incoming-Call-Request
Incoming-Call-Request是PAC发送到PNS的PPTP控制消息, 指示检测到入站呼叫.它向PNS提供有关呼叫的参数信息, 允许PNS确定是否接受呼叫.
2.10. Incoming-Call-Reply
Incoming-Call-Reply是PNS发送到PAC的PPTP控制消息, 响应接收到的Incoming-Call-Request消息.它指示PNS是否接受入站呼叫以及呼叫应如何连接.
2.11. Incoming-Call-Connected
Incoming-Call-Connected是PAC发送到PNS的PPTP控制消息, 作为入站呼叫连接过程的最后阶段.它向PNS提供有关呼叫连接方式的信息, 特别是传输速度、成帧和窗口大小.
2.12. Call-Clear-Request
Call-Clear-Request是PNS发送到PAC的PPTP控制消息, 指示应断开特定呼叫.被清除的呼叫可以是处于任何状态的呼入或呼出呼叫.PAC使用Call-Disconnect-Notify消息响应此消息.
2.13. Call-Disconnect-Notify
Call-Disconnect-Notify消息是PAC发送到PNS的PPTP控制消息.每当呼叫断开时, 无论是由于PAC收到Call-Clear-Request还是由于任何其他原因, 都会发出此消息.其目的是通知PNS断开连接以及断开的原因.
2.14. WAN-Error-Notify
WAN-Error-Notify消息是PAC发送到PNS的PPTP控制消息, 用于指示WAN错误条件 (在支持PPP的接口上发生的条件).此消息中的计数器是累积的.此消息仅应在发生错误时发送, 并且不应超过每60秒一次.当建立新呼叫时计数器被重置.
错误类型包括:
- CRC Errors (CRC错误)
- Framing Errors (成帧错误)
- Hardware Overruns (硬件溢出)
- Buffer Overruns (缓冲区溢出)
- Time-out Errors (超时错误)
- Alignment Errors (对齐错误)
2.15. Set-Link-Info
Set-Link-Info消息是PNS发送到PAC的PPTP控制消息, 用于设置PPP协商的选项.由于这些选项可以在呼叫生命周期的任何时间更改, 因此PAC必须能够动态更新其内部呼叫信息并在活动PPP会话上执行PPP协商.
关键字段包括:
- Peer's Call ID: PAC分配给此呼叫的呼叫ID值
- Send ACCM: 客户端应用于处理出站PPP数据包的发送ACCM值.在收到此消息之前, 客户端使用的默认值为0XFFFFFFFF
- Receive ACCM: 客户端应用于处理入站PPP数据包的接收ACCM值.在收到此消息之前, 客户端使用的默认值为0XFFFFFFFF
2.16. 通用错误代码 (General Error Codes)
通用错误代码适用于不特定于任何特定PPTP请求的错误类型, 而是适用于协议或消息格式错误.如果PPTP回复在其结果代码中指示发生一般错误, 则应检查通用错误值以确定错误是什么.当前定义的通用错误代码及其含义为:
- 0 (None) - 无一般错误 (No general error)
- 1 (Not-Connected) - 此PAC-PNS对尚不存在控制连接 (No control connection exists yet for this PAC-PNS pair)
- 2 (Bad-Format) - 长度错误或Magic Cookie值不正确 (Length is wrong or Magic Cookie value is incorrect)
- 3 (Bad-Value) - 字段值之一超出范围或保留字段非零 (One of the field values was out of range or reserved field was non-zero)
- 4 (No-Resource) - 现在资源不足无法处理此命令 (Insufficient resources to handle this command now)
- 5 (Bad-Call ID) - 在此上下文中呼叫ID无效 (The Call ID is invalid in this context)
- 6 (PAC-Error) - PAC中发生通用供应商特定错误 (A generic vendor-specific error occurred in the PAC)
3. 控制连接协议操作 (Control Connection Protocol Operation)
本节描述各种PPTP控制连接功能的操作以及用于支持它们的控制连接消息.控制连接的协议操作被简化, 因为TCP用于提供可靠的传输机制.消息的排序和重传在此级别不是问题.然而, TCP连接本身可能随时关闭, 并且必须提供适当的错误恢复机制来处理这种情况.
某些错误恢复过程对控制连接的所有状态都是通用的.如果预期的回复在60秒内未到达, 则关闭控制连接, 除非另有规定.应实施适当的日志记录, 以便轻松确定问题和关闭控制连接的原因.
应适当记录接收到无效或格式错误的控制连接消息, 并应关闭并重新启动控制连接以确保恢复到已知状态.
3.1. 控制连接状态 (Control Connection States)
控制连接依赖于标准TCP连接来提供其服务.PPTP控制连接协议在PNS和PAC之间没有区别, 但在发起方和接收方之间是可区分的.发起对等方是首先尝试TCP打开的一方.由于PAC或PNS都可能发起连接, 因此可能发生TCP冲突.有关此情况的描述, 请参见第3.1.3节.
3.1.1. 控制连接发起方 (Control Connection Originator) (可以是PAC或PNS)
TCP Open Indication
/Send Start Control
Connection Request +-----------------+
+------------------------------------>| wait_ctl_reply |
| +-----------------+
| Collision/See (4.1.3) Close TCP V V V Receive Start Ctl
| +-------------------------------+ | | Connection Reply
| | | | Version OK
^ V | V
+-----------------+ Receive Start Ctl | +-----------------+
| idle | Connection Reply | | established |
+-----------------+ Version Not OK | +-----------------+
^ | V Local Terminate
| Receive Stop Control | | /Send Stop
| Connection Request | | Control Request
| /Send Stop Control Reply V V
| Close TCP +-----------------+
+-------------------------------------| wait_stop_reply |
+-----------------+
idle (空闲)
控制连接发起方在空闲状态期间尝试打开到对等方的TCP连接.当TCP连接打开时, 发起方传输发送Start-Control-Connection-Request, 然后进入wait_ctl_reply状态.
wait_ctl_reply (等待控制回复)
发起方检查是否已从同一对等方请求了另一个TCP连接, 如果是, 则处理第3.1.3节中描述的冲突情况.
当收到Start-Control-Connection-Reply时, 检查其版本是否兼容.如果回复的版本低于请求中发送的版本, 则应使用较旧 (较低) 的版本, 前提是它受支持.如果回复的版本较早且受支持, 则发起方移至established状态.如果版本较早且不受支持, 则应当 (SHOULD) 向对等方发送Stop-Control-Connection-Request, 并且发起方移入wait_stop_reply状态.
established (已建立)
已建立的连接可以通过本地条件或接收到Stop-Control-Connection-Request来终止.在本地终止的情况下, 发起方必须 (MUST) 发送Stop-Control-Connection-Request并进入wait_stop_reply状态.
如果发起方收到Stop-Control-Connection-Request, 它应当 (SHOULD) 发送Stop-Control-Connection-Reply并关闭TCP连接, 确保最终的TCP信息已正确"推送".
wait_stop_reply (等待停止回复)
如果收到Stop-Control-Connection-Reply, 则应当 (SHOULD) 关闭TCP连接, 并且控制连接变为空闲.
3.1.2. 控制连接接收方 (Control connection Receiver) (可以是PAC或PNS)
Receive Start Control Connection Request
Version Not OK/Send Start Control Connection
Reply with Error
+--------+
| | Receive Control Connection Request Version OK
| | /Send Start Control Connection Reply
| | +----------------------------------------+
^ V ^ V
+-----------------+ Receive Start Ctl +-----------------+
| Idle | Connection Request | Established |
+-----------------+ /Send Stop Reply +-----------------+
^ ^ Close TCP V V Local Terminate
| +-------------------------------------+ | /Send Stop
| | Control Conn.
| V Request
| +-----------------+
+-------------------------------------| Wait-Stop-Reply |
Receive Stop Control +-----------------+
Connection Reply
/Close TCP
idle (空闲)
控制连接接收方等待端口1723上的TCP打开尝试.当被通知有打开的TCP连接时, 它应该准备接收PPTP消息.当收到Start-Control-Connection-Request时, 应检查其版本字段.如果版本早于接收方的版本并且接收方可以支持较早的版本, 则接收方应当 (SHOULD) 发送Start-Control-Connection-Reply.如果版本早于接收方的版本并且不能支持该版本, 则接收方应当 (SHOULD) 发送Start-Connection-Reply消息, 关闭TCP连接并保持在空闲状态.如果接收方的版本与对等方的版本相同或早于对等方的版本, 则接收方应当 (SHOULD) 发送带有接收方版本的Start-Control-Connection-Reply并进入established状态.
established (已建立)
已建立的连接可以通过本地条件或接收到Stop-Control-Connection-Request来终止.在本地终止的情况下, 接收方必须 (MUST) 发送Stop-Control-Connection-Request并进入wait_stop_reply状态.
如果接收方收到Stop-Control-Connection-Request, 它应当 (SHOULD) 发送Stop-Control-Connection-Reply并关闭TCP连接, 确保最终的TCP信息已正确"推送".
wait_stop_reply (等待停止回复)
如果收到Stop-Control-Connection-Reply, 则应当 (SHOULD) 关闭TCP连接, 并且控制连接变为空闲.
3.1.3. 启动控制连接发起请求冲突 (Start Control Connection Initiation Request Collision)
当PAC和PNS同时彼此发起控制连接时, 可能会发生冲突.当发起方处于wait_ctl_reply状态并收到另一个Start-Control-Connection-Request时, 检测到冲突.
当检测到冲突时, 冲突"获胜者"由有序比较两个对等方的IP地址确定.使用更高IP地址的对等方"获胜".获胜者继续作为发起方 (保持在wait_ctl_reply状态).失败方关闭其TCP连接, 并作为接收方等待获胜方的TCP Open.
3.1.4. 保活和计时器 (Keep Alives and Timers)
控制连接必须验证对等方的可达性.Echo-Request消息和Echo-Reply消息用于此目的.实现应当 (SHOULD) 定期向其对等方发送Echo-Request.如果发送方在合理的时间内未收到Echo-Reply, 它应当 (SHOULD) 向对等方发送另一个Echo-Request.如果合理数量的连续Echo-Requests (建议值为60秒和3次重试) 没有响应, 则控制连接应当 (SHOULD) 关闭, 隐式释放所有相关会话.
3.2. 呼叫状态 (Call States)
本节描述呼叫状态及其与控制连接协议操作的关系.
3.2.1. 时序考虑 (Timing considerations)
如果在1分钟内未发生状态转换 (除了处于空闲或已建立状态的连接), 则怀疑对等方之间的协议处理的完整性, 并且应当关闭并重新启动整个控制连接.每当启动控制连接时, 所有呼叫ID都在逻辑上被释放.这大概也有助于防止收费呼叫被"丢失"而永远不被清除.
不鼓励使用短计时器.
3.2.2. 呼叫ID值 (Call ID Values)
每个对等方为其请求或接受的每个用户会话分配一个呼叫ID值.此呼叫ID值对于它所属的PAC和PNS之间的隧道必须 (MUST) 是唯一的.到其他对等方的隧道可以使用相同的呼叫ID号, 因此隧道上的数据包的接收方需要将用户会话与特定隧道和呼叫ID关联.建议每个隧道的潜在呼叫ID值的数量至少是给定隧道上预期的最大呼叫数的两倍.
会话由三元组 (PAC, PNS, Call ID) 定义.
3.2.3. 呼入呼叫 (Incoming Calls)
当关联的电话线路响铃时, PAC生成Incoming-Call-Request消息.PAC选择呼叫ID和序列号, 并指示呼叫承载类型.调制解调器应始终指示模拟呼叫类型.ISDN呼叫应在使用非限制数字服务或速率适配时指示数字, 如果涉及数字调制解调器则指示模拟.拨号号码、被叫号码和子地址可能包含在消息中 (如果它们可从电话网络获得).
一旦PAC发送Incoming-Call-Request, 它就等待来自PNS的响应, 但不接听来自电话网络的呼叫.如果以下情况, PNS可能选择不接受呼叫:
- 没有可用资源来处理更多会话
- 拨号、拨入或子地址字段不表示授权用户
- 不授权或不支持承载服务
如果PNS选择接受呼叫, 它会响应一个Incoming-Call-Reply, 该回复还指示窗口大小 (见第4.2节).当PAC收到Outgoing-Call-Reply时, 它尝试连接呼叫, 假设呼叫方未挂机.来自PAC到PNS的最终呼叫连接消息指示PAC和PNS的呼叫状态都应进入established状态.
当拨入的客户端挂机时, 呼叫正常清除, PAC发送Call-Disconnect-Notify消息.如果PNS希望清除呼叫, 它发送Call-Clear-Request消息, 然后等待Call-Disconnect-Notify.
3.2.3.1. PAC呼入呼叫状态 (PAC Incoming Call States)
Ring/Send Incoming Call Request +-----------------+
+----------------------------------------->| wait_reply |
| +-----------------+
| Receive Incoming Call Reply V V V
| Not Accepting | | | Receive Incoming
| +--------------------------------+ | | Call Reply Accept-
| | +------------------------------+ | ing/Answer call;
| | | Abort/Send Call | Send Call
^ V V Disconnect Notify V Connected
+-----------------+ +-----------------+
| idle |<-----------------------------| established |
+-----------------+ Receive Clear Call Request +-----------------+
or telco call dropped
or local disconnect
/Send Call Disconnect Notify
idle (空闲): PAC在其电信接口之一上检测到呼入呼叫.通常这意味着模拟线路正在响铃或ISDN TE检测到传入的Q.931 SETUP消息.PAC发送Incoming-Call-Request消息并移至wait_reply状态.
wait_reply (等待回复): PAC接收指示不愿意接受呼叫 (一般错误或不接受) 的Incoming-Call-Reply消息, 并返回到空闲状态.如果回复消息指示接受呼叫, PAC发送Incoming-Call-Connected消息并进入established状态.
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)
Receive Incoming Call Request
/Send Incoming Call Reply +-----------------+
Not Accepting if Error | Wait-Connect |
+-----+ +-----------------+
| | Receive Incoming Call Req. ^ V V
| | /Send Incoming Call Reply OK | | | Receive Incoming
| | +--------------------------------+ | | Call Connect
^ V ^ V------------------------------+ V
+-----------------+ Receive Call Disconnect +-----------------+
| Idle | Notify +- | Established |
+-----------------+ | +-----------------+
^ ^ | V Local Terminate
| +----------------------------+ | /Send Call Clear
| Receive Call Disconnect | Request
| Notify V
| +-----------------+
+--------------------------------------| Wait-Disconnect |
Receive Call Disconnect +-----------------+
Notify
idle (空闲): 收到Incoming-Call-Request消息.如果请求不可接受, 则向PAC发送Incoming-Call-Reply, 并且PNS保持在空闲状态.如果Incoming-Call-Request消息可接受, 则发送Incoming-Call-Reply, 在结果代码中指示接受.会话移至wait_connect状态.
wait_connect (等待连接): 如果会话在PAC上连接, PAC向PNS发送incoming call connect消息, 然后移入established状态.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在电信接口上拨打呼叫.呼出呼叫只有两条消息: Outgoing-Call-Request和Outgoing-Call-Reply.PNS发送Outgoing-Call-Request, 指定拨号方电话号码和子地址以及速度和窗口参数.一旦PAC确定以下情况, PAC必须 (MUST) 使用Outgoing-Call-Reply消息响应Outgoing-Call-Request消息:
- 呼叫已成功连接
- 由于以下原因发生呼叫失败: 没有可用于拨出的接口、被叫方忙或无应答, 或在为拨号选择的接口上未检测到拨号音
3.2.4.1. PAC呼出呼叫状态 (PAC Outgoing Call States)
Receive Outgoing Call Request in Error
/Send Outgoing Call Reply with Error
|--------+
| | Receive Outgoing Call Request No Error
| | /Off Hook; Dial
| | +-----------------------------------------
^ V ^ V
+-----------------+ Incomplete Call +-----------------+
| idle | /Send Outgoing Call | wait_cs_ans |
+-----------------+ Reply with Error +-----------------+
^ ^ or Recv. Call Clear Req. V V Telco Answer
| | /Send Disconnect Notify| | /Send Outgoing
| +-------------------------------------+ | Call Reply.
| V
| +-----------------+
+-------------------------------------| established |
Receive Call Clear Request +-----------------+
or local terminate
or telco disconnect
/Hangup call and send
Call Disconnect Notify
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) 通过适当的机制释放电信呼叫, 并应当 (SHOULD BE) 向PNS发送Call-Disconnect-Notify消息.如果呼叫被客户端或电信接口断开, 则应当 (SHOULD) 向PNS发送Call-Disconnect-Notify消息.
3.2.4.2. PNS呼出呼叫状态 (PNS Outgoing Call States)
Open Indication Abort/Send
/Send Outgoing Call Call Clear
Request +-----------------+Request
+-------------------------------->| Wait-Reply |----------+
| +-----------------+ |
| Receive Outgoing Call Reply V V Receive Outgoing |
| with Error | | Call Reply |
| +-------------------------------+ | No Error |
^ V V |
+-----------------+ +-----------------+ |
| Idle |<-----------------------------| Established | |
+-----------------+ Receive Call Disconnect +-----------------+ |
^ Notify V Local Terminate |
| | /Send Call Clear |
| | Request |
| Receive Call Disconnect V |
| Notify +-----------------+ |
+---------------------------------| Wait-Disconnect |<---------+
+-----------------+
idle (空闲): 向PAC发送Outgoing-Call-Request消息, 会话移入wait_reply状态.
wait_reply (等待回复): 收到指示错误的Outgoing-Call-Reply.会话返回到空闲状态.没有活动的电信呼叫.如果Outgoing-Call-Reply没有指示错误, 则电信呼叫已连接, 会话移至established状态.
established (已建立): 如果收到Call-Disconnect-Notify, 则电信呼叫已因结果和原因代码中指示的原因而终止.会话返回到空闲状态.如果PNS选择终止会话, 它向PAC发送Call-Clear-Request, 然后进入wait_disconnect状态.
wait_disconnect (等待断开): 会话断开正在等待PAC确认.一旦PNS收到Call-Disconnect-Notify消息, 会话就进入空闲状态.
4. 隧道协议操作 (Tunnel Protocol Operation)
PPTP协议承载的用户数据是PPP数据包.PPP数据包在PAC和PNS之间承载, 封装在GRE数据包中, 而GRE数据包又通过IP承载.封装的PPP数据包本质上是没有任何媒体特定成帧元素的PPP数据包.不包括HDLC标志、位插入、控制字符或控制字符转义.不通过隧道发送CRC.在PAC和PNS之间的隧道上传输的IP数据包具有以下通用结构:
+--------------------------------+
| Media Header |
+--------------------------------+
| IP Header |
+--------------------------------+
| GRE Header |
+--------------------------------+
| PPP Packet |
+--------------------------------+
4.1. 增强的GRE头部 (Enhanced GRE header)
PPTP中使用的GRE头部在当前GRE协议规范 [1,2] 中指定的基础上进行了轻微增强.主要区别涉及新的确认号字段的定义, 用于确定特定GRE数据包或数据包集是否已到达隧道的远端.此确认功能不与任何用户数据包的重传结合使用.相反, 它用于确定为给定用户会话通过隧道传输用户数据包的速率.增强的GRE头部的格式如下:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|R|K|S|s|Recur|A| Flags | Ver | Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key (HW) Payload Length | Key (LW) Call ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C (位0) - Checksum Present (校验和存在): 设置为零 (0).
R (位1) - Routing Present (路由存在): 设置为零 (0).
K (位2) - Key Present (密钥存在): 设置为一 (1).
S (位3) - Sequence Number Present (序列号存在): 如果存在有效载荷 (数据) 数据包, 则设置为一 (1).如果不存在有效载荷 (GRE数据包仅为确认), 则设置为零 (0).
s (位4) - Strict source route present (严格源路由存在): 设置为零 (0).
Recur (位5-7) - Recursion control (递归控制): 设置为零 (0).
A (位8) - Acknowledgment sequence number present (确认序列号存在): 如果数据包包含用于确认先前传输的数据的确认号, 则设置为一 (1).
Flags (位9-12): 必须设置为零 (0).
Ver (位13-15): 必须包含1 (增强的GRE).
Protocol Type (协议类型): 设置为十六进制880B [8].
Key (密钥): 密钥字段的使用取决于实现.PPTP使用方式如下:
- Payload Length (有效载荷长度, 密钥的高2个八位字节): 有效载荷的大小, 不包括GRE头部
- Call ID (呼叫ID, 低2个八位字节): 包含此数据包所属会话的对等方呼叫ID
Sequence Number (序列号): 包含有效载荷的序列号.如果S位 (位3) 为一 (1), 则存在.
Acknowledgment Number (确认号): 包含发送对等方为此用户会话接收到的最高编号GRE数据包的序列号.如果A位 (位8) 为一 (1), 则存在.
有效载荷部分包含没有任何媒体特定成帧元素的PPP数据包.
涉及的序列号是每个数据包的序列号.每个用户会话的序列号在会话启动时设置为零.为给定用户会话发送的包含有效载荷 (并且将S位 (位3) 设置为一) 的每个数据包都被分配该会话的下一个连续序列号.
此协议允许确认与数据一起携带, 使整体协议更有效, 这反过来需要较少的数据包缓冲.
4.2. 滑动窗口协议 (Sliding Window Protocol)
PPTP数据路径上使用的滑动窗口协议用于数据交换的每一侧的流量控制.增强的GRE协议允许数据包确认搭载在数据包上.确认也可以与数据包分开发送.同样, 滑动窗口协议的主要目的是流量控制 - 隧道对等方不执行重传.
4.2.1. 初始窗口大小 (Initial Window Size)
尽管每一侧都已指示其接收窗口的最大大小, 但建议在开始传输数据时采取保守的方法.发送器上的初始窗口大小设置为接收器请求的最大大小的一半, 最小大小为一个数据包.当等待确认的数据包数等于当前窗口大小时, 发送器停止发送数据包.当接收器成功消化每个窗口时, 发送器上的窗口大小增加一个数据包, 直到达到最大值.此方法防止系统淹没已经拥塞的网络, 因为尚未建立历史记录.
4.2.2. 关闭窗口 (Closing the Window)
当数据包确实发生超时时, 发送方将传输窗口的大小调整为其失败时值的一半.分数向上舍入, 最小窗口大小为一.
4.2.3. 打开窗口 (Opening the Window)
每次成功传输一个窗口的数据包而没有超时, 传输窗口大小就增加一个数据包, 直到达到在呼叫连接时另一侧发送的最大窗口大小.如前所述, 超时后不进行重传.超时后, 传输从窗口从发生超时时传输窗口大小的一半开始恢复, 并且每次传输窗口填充数据包并且所有数据包都被确认而没有超时时向上调整一个.
4.2.4. 窗口溢出 (Window Overflow)
当接收方的窗口因传入数据包过多而溢出时, 多余的数据包将被丢弃.如果发送方和接收方正确遵循滑动窗口过程, 则不应出现这种情况.假设在发送侧, 数据包被缓冲以进行传输, 并且当传输缓冲区填满时, 不再从数据包源接受数据包.
4.2.5. 多包确认 (Multi-packet Acknowledgment)
PPTP滑动窗口协议的一个特性是它允许使用单个确认来确认多个数据包.序列号低于或等于确认号的所有未完成数据包都被视为已确认.超时计算使用传输被确认的最高序列号对应的数据包的时间来执行.
仅在收到确认时才执行自适应超时计算.当使用多包确认时, 自适应超时算法的开销减少.PAC不需要传输多包确认; 相反, 它可以在将每个数据包传递给PPP客户端时单独确认每个数据包.
4.3. 乱序数据包 (Out-of-sequence Packets)
偶尔数据包在复杂的互联网络上失去其排序.例如, 假设PNS向PAC发送数据包0到5.由于互联网络中的重路由, 数据包4在数据包3之前到达PAC.PAC确认数据包4, 并且可能假设数据包3丢失.此确认授予超过数据包4的窗口信用.
当PAC确实收到数据包3时, 它不得 (MUST not) 尝试将其传输到相应的PPP客户端.这样做可能会导致问题, 因为正确的PPP协议操作前提是按顺序接收数据包.PPP确实正确处理数据包的丢失, 但不处理重新排序, 因此PNS和PAC之间的乱序数据包必须 (MUST) 被静默丢弃, 或者它们可能被接收方重新排序.当数据包5进来时, 它被PAC确认, 因为它的序列号高于4, 这是PAC最后确认的最高数据包.具有重复序列号的数据包永远不应该发生, 因为PAC和PNS从不重传GRE数据包.健壮的实现将静默丢弃重复的GRE数据包, 如果它收到任何.
4.4. 确认超时 (Acknowledgment Time-Outs)
PPTP使用滑动窗口和超时来提供跨互联网络的用户会话流量控制, 并执行有效的数据缓冲, 以保持PAC-PNS数据通道满而不会导致接收缓冲区溢出.PPTP要求使用超时来从丢失的数据或确认数据包中恢复.确切的超时实现是特定于供应商的.建议实现自适应超时, 并为拥塞控制实施退避.这里提出的超时机制具有以下属性:
-
每个会话的独立超时 (Independent time-outs for each session): 设备 (PAC或PNS) 必须为每个活动会话维护和计算超时.
-
管理员可调整的最大超时 (An administrator-adjustable maximum time-out): MaxTimeOut, 每个设备唯一.
-
补偿不断变化的吞吐量的自适应超时机制 (An adaptive time-out mechanism that compensates for changing throughput): 为了减少数据包处理开销, 供应商可能选择不为每个接收到的确认重新计算自适应超时.这种开销减少的结果是超时不会对快速网络变化响应得那么快.
-
超时时的计时器退避以减少拥塞 (Timer backoff on time-out to reduce congestion): 退避的计时器值受可配置的最大超时值限制.每次发生确认超时时都会执行计时器退避.
一般来说, 此机制具有在超时时快速退避的理想行为, 并且在数据包被传递而没有超时时缓慢降低超时值.
一些定义:
-
Packet Processing Delay (数据包处理延迟, PPD): 每一侧处理其接收数据包滑动窗口中缓冲的最大数据量所需的时间量.PPD是在建立呼叫时PAC和PNS之间交换的值.对于PNS, 此数字应该很小.对于进行调制解调器连接的PAC, 此数字可能很大.
-
Sample (样本): 接收数据包的确认所产生的实际时间量.样本是测量的, 而不是计算的.
-
Round-Trip Time (往返时间, RTT): 为给定传输的数据包接收确认的估计往返时间.当网络链路是本地网络时, 此延迟将是最小的 (如果不是零).当网络链路是互联网时, 此延迟可能很大且变化很大.RTT是自适应的: 它将调整以包括PPD和任何移动的网络延迟, 这些延迟有助于数据包被传输和接收其确认之间的时间.
-
Adaptive Time-Out (自适应超时, ATO): 在确认被视为丢失之前必须经过的时间.超时后, 滑动窗口部分关闭, ATO退避.
数据包处理延迟 (PPD) 参数是在呼叫控制阶段交换的16位字, 表示十分之一秒 (64表示6.4秒).协议仅指定交换参数, 它不指定如何计算它.PPD值的计算方式取决于实现, 不需要是可变的 (允许静态超时).即使在实现中保持恒定, 也必须在呼叫连接序列中交换PPD.计算PPD的一种可能方式是:
PPD' = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / ConnectRate
PPD = PPD' + PACFudge
其中:
- Header是IP和GRE头部的总大小, 为36
- MTU是PAC和PNS之间互联网络链路的总体MTU
- WindowSize表示滑动窗口中的数据包数, 取决于实现
- 可以使用互联网络的延迟来选择足以保持当前会话管道满的窗口大小
- 常数8将八位字节转换为位 (假设ConnectRate以位每秒为单位)
- 如果ConnectRate以字节每秒为单位, 则省略8
- PACFudge不是必需的, 但可以用于考虑PAC的总体处理开销
PPD的值用于使用初始RTT[n-1]值为自适应算法提供种子.
4.4.1. 计算自适应确认超时 (Calculating Adaptive Acknowledgment Time-Out)
我们仍然必须决定允许多少时间让确认返回.如果超时设置得太高, 我们可能会不必要地长时间等待丢失的数据包.如果超时太短, 我们可能在确认到达之前就超时.确认超时也应该是合理的并响应不断变化的网络条件.
下面详细介绍的建议自适应算法基于TCP 1989实现, 并在 [11] 中解释.'n'表示此计算的迭代, 'n-1'指的是上次计算的值.
DIFF[n] = SAMPLE[n] - RTT[n-1]
DEV[n] = DEV[n-1] + (beta * (|DIFF[n]| - DEV[n-1]))
RTT[n] = RTT[n-1] + (alpha * DIFF[n])
ATO[n] = MAX (MinTimeOut, MIN (RTT[n] +
(chi * DEV[n]), MaxTimeOut))
其中:
- DIFF: 表示最后估计的往返时间与测量时间之间的误差.DIFF在每次迭代时计算.
- DEV: 是估计的平均偏差.这近似于标准偏差.DEV在每次迭代时计算并存储以供下次迭代使用.最初设置为0.
- RTT: 是平均数据包的估计往返时间.RTT在每次迭代时计算并存储以供下次迭代使用.最初设置为PPD.
- ATO: 是下一个传输的数据包的自适应超时.ATO在每次迭代时计算.通过MIN函数, 其值被限制为最大为配置的MaxTimeOut值.
- Alpha: 是平均值的增益, 通常为1/8 (0.125).
- Beta: 是偏差的增益, 通常为1/4 (0.250).
- Chi: 是超时的增益, 通常设置为4.
为了消除分数增益元素的除法操作, 可以缩放整个方程组.使用建议的增益常数, 它们应该按8缩放以消除所有除法.为简化计算, 所有增益值都保持为2的幂, 以便可以使用移位操作代替乘法或除法.
4.4.2. 拥塞控制: 调整超时 (Congestion Control: Adjusting for Time-Out)
本节描述在发生超时的情况下如何修改ATO的计算.当发生超时时, 超时值应快速向上调整.尽管当发生超时时不重传GRE数据包, 但超时应向最大限制调整.为了补偿移动的互联网络时间延迟, 必须采用策略在超时到期时增加超时 (请注意, 除了增加超时之外, 我们还在缩小窗口的大小, 如下一节所述).对于发生超时的间隔, 新的ATO计算为:
RTT[n] = delta * RTT[n-1]
DEV[n] = DEV[n-1]
ATO[n] = MAX (MinTimeOut, MIN (RTT[n] +
(chi * DEV[n]), MaxTimeOut))
在此ATO计算中, 仅计算两个既有助于ATO又存储用于下一次迭代的值.RTT由delta缩放, DEV未修改.DIFF不会向前携带, 在此场景中不使用.建议Delta (RTT的超时增益因子) 的值为2.
5. 安全性考虑 (Security Considerations)
通过隧道PPP连接传递的用户数据的安全性由PPP解决, 就像PPP对等方的认证一样.
由于PPTP控制通道消息既未经过认证也未经过完整性保护, 因此攻击者可能劫持底层TCP连接.也可能制造虚假的控制通道消息并在传输中修改真实消息而不被检测到.
形成隧道本身的GRE数据包未受到加密保护.由于PPP协商是通过隧道进行的, 因此攻击者可能窃听和修改这些协商.
除非PPP有效载荷数据受到加密保护, 否则它可以被捕获和读取或修改.
6. 作者地址 (Authors' Addresses)
Kory Hamzeh
Ascend Communications
1275 Harbor Bay Parkway
Alameda, CA 94502
EMail: [email protected]
Gurdeep Singh Pall
Microsoft Corporation
Redmond, WA
EMail: [email protected]
William Verthein
U.S. Robotics/3Com
Jeff Taarud
Copper Mountain Networks
W. Andrew Little
ECI Telematics
Glen Zorn
Microsoft Corporation
Redmond, WA
EMail: [email protected]
7. 参考文献 (References)
[1] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994.
[2] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE) over IPv4 Networks", RFC 1702, October 1994.
[3] Lloyd, B. and W. Simpson, "PPP Authentication Protocols", RFC 1334, October 1992.
[4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[5] Postel, J., "User Data Protocol", STD 6, RFC 768, August 1980.
[6] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. See also: http://www.iana.org/numbers.html
[7] Simpson, W., editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[8] Ethertype for PPP, Reserved with Xerox Corporation.
[9] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
[10] Blunk, L. and J Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.
[11] Stevens, R., "TCP/IP Illustrated, Volume 1", p. 300, Addison-Wesley, 1994.
[12] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
8. 完整版权声明 (Full Copyright Statement)
Copyright (C) The Internet Society (1999). All Rights Reserved.
本文档及其翻译可以被复制并提供给他人, 并且可以准备、复制、出版和分发对其进行评论或以其他方式解释它或协助其实施的衍生作品, 全部或部分, 没有任何限制, 前提是上述版权声明和本段包含在所有此类副本和衍生作品中.然而, 本文档本身不得以任何方式修改, 例如删除版权声明或对Internet Society或其他Internet组织的引用, 除非为了开发Internet标准的目的, 在这种情况下必须遵循Internet标准过程中定义的版权程序, 或者需要将其翻译成除英语之外的语言.
上述授予的有限许可是永久性的, 不会被Internet Society或其继承者或受让人撤销.
本文档和此处包含的信息按"原样"提供, INTERNET SOCIETY和INTERNET ENGINEERING TASK FORCE拒绝所有保证, 明示或暗示, 包括但不限于任何关于使用此处信息不会侵犯任何权利的保证或适销性或适用于特定目的的暗示保证.
致谢 (Acknowledgment)
RFC Editor功能的资金目前由Internet Society提供.