Network Working Group I. Goyret
Request for Comments: 3573 Lucent Technologies
Category: Standards Track July 2003
Network Working Group I. Goyret
Request for Comments: 3573 Lucent Technologies
Category: Standards Track July 2003
Signaling of Modem-On-Hold status in Layer 2 Tunneling Protocol (L2TP)
第2层隧道协议（L2TP）中调制解调器保持状态的信令
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
The Layer 2 Tunneling Protocol (L2TP) defines a mechanism for tunneling Point-to-Point Protocol (PPP) sessions. It is common for these PPP sessions to be established using modems connected over the public switched telephone network.
第二层隧道协议（L2TP）定义了隧道点对点协议（PPP）会话的机制。这些PPP会话通常使用通过公共交换电话网络连接的调制解调器建立。
One of the standards governing modem operation defines procedures that enable a client modem to put the call on hold and later, re-establish the modem link with minimal delay and without having to redial. While the modem call is on hold, the client phone line can be used to place or receive other calls.
管理调制解调器操作的一个标准定义了一些过程，这些过程使客户端调制解调器能够将呼叫挂起，然后以最小的延迟重新建立调制解调器链路，而无需重拨。当调制解调器呼叫处于保留状态时，客户端电话线可用于拨打或接听其他呼叫。
The L2TP base protocol does not provide any means to signal these events from the L2TP Access Controller (LAC), where the modem is physically connected, to the L2TP Network Server (LNS), where the PPP session is handled.
L2TP基本协议不提供从L2TP访问控制器（LAC）向L2TP网络服务器（LNS）发送这些事件信号的任何方法，L2TP访问控制器（LAC）物理连接调制解调器，L2TP网络服务器（LNS）处理PPP会话。
This document describes a method to let the LNS know when a client modem connected to a LAC has placed the call on hold.
本文档描述了一种让LNS知道连接到LAC的客户端调制解调器何时已将呼叫置于挂起状态的方法。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Specification of Requirements. . . . . . . . . . . . . . 3
1.2. Terminology. . . . . . . . . . . . . . . . . . . . . . . 3
2. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Typical Modem on Hold Usage Scenario . . . . . . . . . . 4
2.2. Capability Negotiation . . . . . . . . . . . . . . . . . 4
2.3. Modem On-Hold. . . . . . . . . . . . . . . . . . . . . . 5
2.4. Modem Online . . . . . . . . . . . . . . . . . . . . . . 5
3. New Control Messages . . . . . . . . . . . . . . . . . . . . . 5
3.1. Modem-Status (MDMST) . . . . . . . . . . . . . . . . . . 5
4. New Attribute Value Pairs. . . . . . . . . . . . . . . . . . . 6
4.1. Modem On-Hold Capable AVP. . . . . . . . . . . . . . . . 6
4.2. Modem On-Hold Status AVP . . . . . . . . . . . . . . . . 6
5. Sample LNS Actions . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 9
9. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 10
Appendix A: Vendor Specific Assignments. . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Specification of Requirements. . . . . . . . . . . . . . 3
1.2. Terminology. . . . . . . . . . . . . . . . . . . . . . . 3
2. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Typical Modem on Hold Usage Scenario . . . . . . . . . . 4
2.2. Capability Negotiation . . . . . . . . . . . . . . . . . 4
2.3. Modem On-Hold. . . . . . . . . . . . . . . . . . . . . . 5
2.4. Modem Online . . . . . . . . . . . . . . . . . . . . . . 5
3. New Control Messages . . . . . . . . . . . . . . . . . . . . . 5
3.1. Modem-Status (MDMST) . . . . . . . . . . . . . . . . . . 5
4. New Attribute Value Pairs. . . . . . . . . . . . . . . . . . . 6
4.1. Modem On-Hold Capable AVP. . . . . . . . . . . . . . . . 6
4.2. Modem On-Hold Status AVP . . . . . . . . . . . . . . . . 6
5. Sample LNS Actions . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 9
9. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 10
Appendix A: Vendor Specific Assignments. . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 13
The Layer 2 Tunneling Protocol (L2TP) [RFC2661] defines a general purpose mechanism for tunneling Point-to-Point Protocol (PPP) [STD51] sessions over various media. By design, the operation of L2TP is insulated from the details of the media from which the PPP session originated.
第二层隧道协议（L2TP）[RFC2661]定义了一种通用机制，用于在各种媒体上隧道点对点协议（PPP）[STD51]会话。根据设计，L2TP的操作与PPP会话起源的媒体的细节是隔离的。
It is common for PPP sessions to be established using modems connected over the public switched telephone network. The ITU-T Recommendation V.92 [V92] is one of the standards governing modem operation and it defines procedures that enable a client modem to put the call on hold and later, re-establish the modem link without having to redial. While the modem call is on hold, the client phone line can be used for another phone call.
PPP会话通常使用通过公共交换电话网络连接的调制解调器建立。ITU-T建议V.92[V92]是管理调制解调器操作的标准之一，它定义了一些程序，使客户机调制解调器能够在不重拨的情况下暂停呼叫，然后重新建立调制解调器链路。当调制解调器呼叫处于保留状态时，客户端电话线可用于另一个电话呼叫。
The L2TP base protocol does not provide any means to signal these events from the L2TP Access Controller (LAC), where the modem is physically connected, to the L2TP Network Server (LNS), where the PPP session is handled. It may be desirable for this information (which is available only on the LAC) to be provided to the LNS.
L2TP基本协议不提供从L2TP访问控制器（LAC）向L2TP网络服务器（LNS）发送这些事件信号的任何方法，L2TP访问控制器（LAC）物理连接调制解调器，L2TP网络服务器（LNS）处理PPP会话。可能需要将该信息（仅在LAC上可用）提供给LNS。
This document provides additional L2TP AVPs and control messages that may be used to communicate some modem information from the LAC to the LNS. However, it does not define what, if anything, the LNS should do with this information. A sample of the possible actions that an LNS may consider are listed in section 5.
本文档提供了额外的L2TP AVP和控制消息，可用于将一些调制解调器信息从LAC传输到LNS。但是，它没有定义LNS应该如何处理这些信息。LNS可以考虑的可能动作的示例在第5节中列出。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [BCP14].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[BCP14]中的说明进行解释。
Definition of terms used in this document may be found in the L2TP Protocol document [L2TP].
本文件中使用的术语定义见L2TP协议文件[L2TP]。
The typical dial in topology looks like this:
典型的拨入拓扑如下所示：
+-----+ { } +----------+ [ IP ]
| |-[M]-----{ PSTN }-----[SM] |.....[ network ]
+-----+ { } +----------+ [ ]
Remote NAS
System
+-----+ { } +----------+ [ IP ]
| |-[M]-----{ PSTN }-----[SM] |.....[ network ]
+-----+ { } +----------+ [ ]
Remote NAS
System
M is the client modem and may be an integral part of the Remote System. If this modem implements V.92, it can ask the server modem SM (a part of the NAS) whether the call can be placed on-hold for some period of time.
M是客户端调制解调器，可能是远程系统的组成部分。如果此调制解调器实现V.92，它可以询问服务器调制解调器SM（NAS的一部分）是否可以将呼叫保持一段时间。
If the server modem agrees, the client modem can signal the PSTN to place the call on-hold (usually, a flash hook). The user at the remote system can then use the same POTS line where the client modem is connected to make or receive another call.
如果服务器调制解调器同意，客户端调制解调器可以向PSTN发送信号，使呼叫保持（通常是闪存挂钩）。然后，远程系统的用户可以使用连接客户端调制解调器的同一POTS线路拨打或接听另一个电话。
In the above scenario, the server modem module can notify the rest of the NAS of these events via its usual signaling mechanism. The NAS layers can then act on this information as desired. See section 5. for a sample list of possible actions.
在上述场景中，服务器调制解调器模块可以通过其常用的信令机制将这些事件通知其余NAS。然后，NAS层可以根据需要对该信息进行操作。见第5节。获取可能操作的示例列表。
In the case of L2TP, this document looks at this particular topology:
在L2TP的情况下，本文档将介绍此特定拓扑：
+-----+ { } +-----+ [ packet ] +-----+ [ home ]
| |-[M]---{ PSTN }---[SM] |...[ network ]...| |...[ network ]
+-----+ { } +-----+ [ ] +-----+ [ ]
Remote LAC LNS
System
+-----+ { } +-----+ [ packet ] +-----+ [ home ]
| |-[M]---{ PSTN }---[SM] |...[ network ]...| |...[ network ]
+-----+ { } +-----+ [ ] +-----+ [ ]
Remote LAC LNS
System
If the LAC implements the functionality described here, it can signal to the LNS when the client modem has gone on-hold and when it comes back online.
如果LAC实现此处所述的功能，则当客户端调制解调器处于保留状态且恢复联机时，它可以向LNS发送信号。
This document does not define what, if anything, the LNS should do with this information. A sample of the possible actions that an LNS MAY consider are listed in section 5. However, the LNS MUST NOT stop processing otherwise valid data packets arriving from the LAC, regardless of the current state of the modem on-hold indications.
本文件未规定LNS应如何处理这些信息。LNS可以考虑的可能动作的示例在第5节中列出。但是，无论调制解调器保持指示的当前状态如何，LNS不得停止处理从LAC到达的其他有效数据包。
A user connects to his Internet service provider with a V.92-capable modem. He then starts downloading a big file which will take several minutes to complete.
用户使用支持V.92的调制解调器连接到其Internet服务提供商。然后他开始下载一个大文件，需要几分钟才能完成。
While the file is being downloaded, a friend calls him. If the user has call waiting enabled, his modem can let him know of the incoming call and he can choose to either pick up the incoming call or reject it. Let's say he chooses to pick up the phone to talk to his friend, for example because he recognized the caller's phone number.
文件下载时，一位朋友打电话给他。如果用户启用了呼叫等待功能，他的调制解调器可以让他知道来电，他可以选择接听来电或拒绝来电。比方说，他选择拿起电话与朋友通话，例如，因为他认出了来电者的电话号码。
Before the user picks up his phone, he tells his modem to go on hold and switch to the incoming call (usually signaled with a "flash-hook"). His modem will then notify the server modem (attached to the LAC) that it is about to go on hold. If the server modem agrees, the client performs a flash hook so the user can talk to his friend.
在用户拿起电话之前，他告诉他的调制解调器保持等待并切换到来电（通常通过“闪光挂钩”发出信号）。然后，他的调制解调器将通知服务器调制解调器（连接到LAC）它将要挂起。如果服务器调制解调器同意，客户端将执行一个flashhook，以便用户可以与他的朋友交谈。
After talking to his friend, the user let's his modem know that it can return to the original call (where the server modem has been patiently waiting). After another flash hook, the modems are connected again and the download can continue.
在与他的朋友交谈后，用户让他的调制解调器知道它可以返回到原始呼叫（服务器调制解调器一直耐心等待）。在另一个闪存挂钩之后，调制解调器再次连接，下载可以继续。
A LAC MUST NOT send a Modem Status (MDMST) control message to an LNS that has not indicated the capability of processing such control messages. This capability is indicated by adding a "Modem On-Hold Capable" AVP on the SCCRQ or SCCRP sent to the LAC when the tunnel is brought up.
LAC不得将调制解调器状态（MDMST）控制消息发送至未指示处理此类控制消息能力的LNS。当隧道启动时，通过在发送至LAC的SCCRQ或SCCRP上添加“调制解调器保持功能”AVP来指示此功能。
When the client modem requests the LAC to go on-hold, the LAC SHOULD send a MDMST control message to the LNS with the H (Hold) field set to 1 and the negotiated maximum on-hold time.
当客户端调制解调器请求LAC保持时，LAC应向LNS发送MDMST控制消息，H（保持）字段设置为1，协商的最大保持时间。
When the client modem returns back online after having gone on-hold, the LAC SHOULD send a MDMST control message to the LNS with the H (Hold) field set to 0. The LAC MUST send this message if it has previously sent a MDMST message with the H (Hold) field set to 1.
当客户端调制解调器在保持后恢复联机时，LAC应向LNS发送MDMST控制消息，H（保持）字段设置为0。如果LAC先前发送了H（保持）字段设置为1的MDMST消息，则必须发送此消息。
The following control messages MUST be sent with the M-bit in the Message Type AVP set to 0 to prevent interoperability issues.
发送以下控制消息时，必须将消息类型AVP中的M位设置为0，以防止互操作性问题。
Messages with unknown values in the Message Type AVP with the M-bit set to 0 should be ignored by compliant L2TP peers [RFC2661].
M位设置为0的消息类型AVP中具有未知值的消息应由兼容L2TP对等方忽略[RFC2661]。
The Modem-Status (MDMST) control message is used by the LAC to notify the LNS when the client modem on-hold status changes.
LAC使用调制解调器状态（MDMST）控制消息在客户端调制解调器保持状态更改时通知LNS。
The MDMST control message MUST NOT be sent to peers that have not included the "Modem On-Hold Capable" AVP in their Start-Control-Connection-Request (SCCRQ) or Start-Control-Connection-Reply (SCCRP) control messages.
MDMST控制消息不得发送给在其启动控制连接请求（SCCRQ）或启动控制连接回复（SCCRP）控制消息中未包含“支持保留的调制解调器”AVP的对等方。
Furthermore, the MDMST control message can only be sent after session establishment is successful (i.e., after the LAC has sent either an Incoming-Call-Connected (ICCN) or an Outgoing-Call-Connected (OCCN) control message), and before the session ends from the LAC's point of view (i.e., before the LAC has sent or received a Call-Disconnect-Notify (CDN) control message).
此外，MDMST控制消息只能在会话建立成功之后（即，在LAC发送了连接入局呼叫（ICCN）或连接出局呼叫（OCCN）的控制消息之后）并且在会话从LAC的角度结束之前（即，在LAC发送或接收到呼叫断开通知之前）发送（CDN）控制消息）。
Note that due to protocol race conditions, it is possible for a LAC to send a MDMST control message about the same time that the LNS is sending a CDN. An LNS MUST ignore MDMST control messages received after sending a CDN.
注意，由于协议竞争条件，LAC可能在LNS发送CDN的同时发送MDMST控制消息。LNS必须忽略发送CDN后收到的MDMST控制消息。
An LNS MUST ignore redundant modem status reports.
LNS必须忽略冗余调制解调器状态报告。
This control message is encoded as follows:
此控制消息的编码如下所示：
Vendor ID = 0 (IETF) Attribute Type = 17
供应商ID=0（IETF）属性类型=17
The following AVPs MUST be present in the MDMST control message:
MDMST控制消息中必须存在以下AVP：
Message Type Modem On-Hold Status
消息类型调制解调器保持状态
The M-bit on the Message Type AVP for this control message MUST be set to 0.
此控制消息的消息类型AVP上的M位必须设置为0。
The following sections contain a list of the new L2TP AVPs defined in this document.
以下部分包含本文档中定义的新L2TP AVP列表。
The Modem On-Hold Capable AVP, Attribute Type 53, indicates that the sender (an LNS) is capable of receiving MDMST control messages. This AVP MUST be included on the SCCRQ or SCCRP control messages to indicate that the sender implements this specification.
支持调制解调器保持的AVP属性类型53表示发送方（LNS）能够接收MDMST控制消息。此AVP必须包含在SCCRQ或SCCRP控制消息中，以表明发送方实施了此规范。
This AVP has no Attribute Value field.
此AVP没有属性值字段。
This AVP MAY be hidden (the H-bit on the AVP header MAY be 0 or 1). The M-bit for this AVP MUST be set to 0. The Length is 6.
该AVP可能被隐藏（AVP头上的H位可能为0或1）。此AVP的M位必须设置为0。长度是6。
The Modem On-Hold Status AVP, Attribute Type 54, indicates the current on-hold status of the client modem. This AVP MUST be present on the MDMST control message.
调制解调器保持状态AVP属性类型54表示客户端调制解调器的当前保持状态。此AVP必须出现在MDMST控制消息中。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|H| reserved |Timeout|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|H| reserved |Timeout|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Modem On-Hold Status AVP is a 16-bit quantity, containing two fields that indicate whether the client modem has placed the call on-hold and the maximum amount of time that the call is allowed to remain on-hold.
调制解调器挂起状态AVP是一个16位的量，包含两个字段，指示客户端调制解调器是否已将呼叫挂起，以及允许呼叫保持挂起的最长时间。
The H (Hold) field is a single bit that indicates whether the client modem has placed the call on-hold. If the H (Hold) field is 1, the client modem is on-hold. If the H (Hold) field is 0, the client modem is back online.
H（保持）字段是一个位，指示客户端调制解调器是否已将呼叫置于保持状态。如果H（保持）字段为1，则客户端调制解调器处于保持状态。如果H（保持）字段为0，则客户端调制解调器重新联机。
The Timeout field is a 4 bits quantity that indicates the negotiated maximum amount of time that the call can remain on-hold. It is valid only if the H (Hold) field is 1 and MUST be ignored if the H (Hold) field is 0. The values for the Timeout field are defined in [V92] and they are reproduced here for easy reference:
超时字段是一个4位的量，表示协商的呼叫可以保持等待的最大时间量。仅当H（保持）字段为1时有效，如果H（保持）字段为0，则必须忽略该字段。[V92]中定义了超时字段的值，为了便于参考，此处对这些值进行了复制：
Bits Decimal Meaning
---- ------- -------
0000 0 Reserved
0001 1 10 seconds
0010 2 20 seconds
0011 3 30 seconds
0100 4 40 seconds
0101 5 1 minute
0110 6 2 minutes
0111 7 3 minutes
1000 8 4 minutes
1001 9 6 minutes
1010 10 8 minutes
1011 11 12 minutes
1100 12 16 minutes
1101 13 No limit
1110 14 Reserved
1111 15 Reserved
Bits Decimal Meaning
---- ------- -------
0000 0 Reserved
0001 1 10 seconds
0010 2 20 seconds
0011 3 30 seconds
0100 4 40 seconds
0101 5 1 minute
0110 6 2 minutes
0111 7 3 minutes
1000 8 4 minutes
1001 9 6 minutes
1010 10 8 minutes
1011 11 12 minutes
1100 12 16 minutes
1101 13 No limit
1110 14 Reserved
1111 15 Reserved
Bits 1 through 11 are reserved. These bits MUST be set to 0 when sending this AVP and MUST be ignored on reception.
保留位1到11。发送此AVP时，这些位必须设置为0，并且在接收时必须忽略。
This AVP MAY be hidden (the H-bit on the AVP header MAY be 0 or 1). The M-bit for this AVP MUST be set to 0. The Length is 8.
该AVP可能被隐藏（AVP头上的H位可能为0或1）。此AVP的M位必须设置为0。长度是8。
The specific actions taken by an LNS upon receipt of a Modem On-Hold Status AVP are implementation dependent. This document does not mandate what, if anything, the LNS should do with this information.
LNS在接收到调制解调器保持状态AVP时采取的具体操作取决于实现。本文件未规定LNS应如何处理这些信息。
The choice of actions taken by the LNS may have an impact on higher layer protocols. For example, TCP connections and other connection-oriented applications may timeout or disconnect during the on-hold time. The impact that those choices may have on these or other protocols is not addressed by this document.
LNS采取的行动的选择可能会对高层协议产生影响。例如，TCP连接和其他面向连接的应用程序可能在保持时间内超时或断开连接。这些选择可能对这些协议或其他协议产生的影响，本文件未提及。
The following list is a sample of possible actions that an LNS implementation might consider. Note that some of these actions are not really alternatives, as some of the possibilities preclude others.
下面的列表是LNS实现可能考虑的可能动作的示例。请注意，其中一些行动并非真正的替代方案，因为有些可能性排除了其他可能性。
* Temporarily stop polling protocols such as LCP Echo Requests, Link Quality Monitoring (LQM), Multilink PPP (MP), etc. * Drop data packets directed to the now on-hold remote client. * Start a new accounting session, to account for the on-hold time. * Stop or hold accounting until the modem returns online again. * Start a separate time accounting for the time that the modem is on hold.
* 暂时停止轮询协议，如LCP回显请求、链路质量监控（LQM）、多链路PPP（MP）等。*将数据包直接丢弃到现在处于保留状态的远程客户端。*启动新的记帐会话，以说明保留时间。*停止或保持记帐，直到调制解调器再次联机。*启动一个单独的时间，说明调制解调器处于保留状态的时间。
Here are a few things that an LNS should probably NOT do:
以下是LNS不应该做的几件事：
* Buffer data packets directed to the now on-hold remote client. Reason: How many data packets should be buffered? What would be the impact on higher layer protocols such as TCP? What would be the impact caused by the delay introduced when the client returns online again?
* 缓冲区数据包定向到现在处于保留状态的远程客户端。原因：应该缓冲多少数据包？对更高层协议（如TCP）有什么影响？当客户再次在线时，延迟会造成什么影响？
* Answer TCP keepalives in lieu of the client. Reason: It may interfere with TCP's recovery once the client returns online.
* 代替客户回答TCP keepalives。原因：一旦客户端恢复联机，它可能会干扰TCP的恢复。
* Stop processing otherwise valid data packets from the client. Reason: There is a race condition between the notification of the modem returning online and the first packet from the client because they are delivered on independent channels. Dropping valid client packets may lead to a slower recovery after returning online due to the forced retries.
* 停止处理来自客户端的其他有效数据包。原因：调制解调器返回联机的通知与来自客户端的第一个数据包之间存在竞争条件，因为它们是在独立通道上传送的。由于强制重试，删除有效的客户端数据包可能会导致返回联机后恢复速度变慢。
This document requires one new L2TP "Message Type" number to be assigned by IANA:
本文件要求IANA分配一个新的L2TP“消息类型”编号：
17, Section 3.1., Modem Status
17，第3.1节，调制解调器状态
It also requires two new "AVP Attributes" to be assigned by IANA:
它还要求IANA分配两个新的“AVP属性”：
53, Section 4.1., Modem On-Hold Capable AVP 54, Section 4.2., Modem On-Hold Status AVP
53，第4.1节，支持调制解调器保持的AVP 54，第4.2节，调制解调器保持状态AVP
The Modem On-Hold Status AVP contains a set of reserved bits (bits 1 through 11) that are assigned by IANA through IETF Consensus [BCP26].
调制解调器保持状态AVP包含一组由IANA通过IETF协商一致[BCP26]分配的保留位（位1至11）。
The integrity and confidentiality of the method described in this document relies on the underlying L2TP security mechanisms. The new control message and AVPs are intended to indicate when a client modem has gone on-hold and cannot receive data. It does not define what, if anything, the LNS should do with this information. A sample of possible actions that an LNS may consider are listed in section 5.
本文档中描述的方法的完整性和机密性依赖于底层L2TP安全机制。新的控制消息和AVP用于指示客户机调制解调器何时处于保留状态，无法接收数据。它没有定义LNS应该如何处理这些信息。LNS可以考虑的可能动作的示例在第5节中列出。
It is believed that the defined extension does not provide information that would be useful to an attacker, and as such, it should not pose a threat to system security.
据信，定义的扩展不提供对攻击者有用的信息，因此，它不应对系统安全构成威胁。
If desired, the new AVPs MAY be hidden as described in section 4.3 of [RFC2661].
如果需要，可以按照[RFC2661]第4.3节的说明隐藏新的AVP。
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B. Peter, "Layer Two Tunneling Protocol (L2TP)", RFC 2661, August 1999.
[RFC2661]Townsley，W.，Valencia，A.，Rubens，A.，Pall，G.，Zorn，G.和B.Peter，“第二层隧道协议（L2TP）”，RFC 26611999年8月。
[BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[BCP14]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[BCP26]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[V92] ITU-T Recommendation V.92, "Enhancements to Recommendation V.90", November 2000
[V92]ITU-T建议V.92，“对建议V.90的改进”，2000年11月
[BCP9] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[BCP9]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[STD51] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[STD51]辛普森，W.“点对点协议（PPP）”，STD 51，RFC 1661994年7月。
Josh Bailey, Emmanuel Hislen and Marc Bongartz of Lucent Technologies provided invaluable help in reviewing this document and its implementation.
朗讯科技公司的Josh Bailey、Emmanuel Hislen和Marc Bongartz在审查本文件及其实施过程中提供了宝贵的帮助。
Mark Townsley of Cisco Systems provided helpful guidance.
思科系统公司的马克·汤斯利提供了有益的指导。
Thomas Narten of IBM Corporation provided invaluable insights and suggestions.
IBM公司的Thomas Narten提供了宝贵的见解和建议。
Appendix A: Vendor Specific Assignments
附录A：特定于供应商的任务
THIS SECTION IS NOT NORMATIVE
本节不规范
Early implementations of this specification used vendor-specific values for the new control message and AVPs. This appendix describes those initial vendor-specific assignments for historical reference only.
该规范的早期实现为新的控制消息和AVP使用了特定于供应商的值。本附录描述了最初的特定于供应商的任务，仅供历史参考。
The following table shows the vendor-specific assignments:
下表显示了特定于供应商的分配：
Vendor Attr Attr
ID Type Value Equivalent to
------ ---- ----- -------------
Control message:
Modem-Status 529 0 2 Section 3.1.
Vendor Attr Attr
ID Type Value Equivalent to
------ ---- ----- -------------
Control message:
Modem-Status 529 0 2 Section 3.1.
AVP: Modem On-Hold Capable 529 2 none Section 4.1. Modem On-Hold Status 529 3 [..] Section 4.2.
AVP：调制解调器保持功能529 2无第4.1节。调制解调器保持状态529 3[…]第4.2节。
Author's Address
作者地址
Ignacio Goyret Lucent Technologies 1801 Harbor Bay Parkway Alameda, CA 94502
加利福尼亚州阿拉米达港湾公园路1801号伊格纳西奥·戈雷特·朗讯科技公司，邮编94502
EMail: igoyret@lucent.com
EMail: igoyret@lucent.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。