Network Working Group C. Pignataro
Request for Comments: 4349 M. Townsley
Category: Standards Track Cisco Systems
February 2006
Network Working Group C. Pignataro
Request for Comments: 4349 M. Townsley
Category: Standards Track Cisco Systems
February 2006
High-Level Data Link Control (HDLC) Frames over Layer 2 Tunneling Protocol, Version 3 (L2TPv3)
第2层隧道协议第3版（L2TPv3）上的高级数据链路控制（HDLC）帧
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 (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a protocol for tunneling a variety of data link protocols over IP networks. This document describes the specifics of how to tunnel High-Level Data Link Control (HDLC) frames over L2TPv3.
第2层隧道协议第3版（L2TPv3）定义了一种通过IP网络隧道传输各种数据链路协议的协议。本文档描述了如何在L2TPv3上传输高级数据链路控制（HDLC）帧的详细信息。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Abbreviations ..............................................2
1.2. Specification of Requirements ..............................3
2. Control Connection Establishment ................................3
3. HDLC Link Status Notification and Session Establishment .........3
3.1. L2TPv3 Session Establishment ...............................3
3.2. L2TPv3 Session Teardown ....................................5
3.3. L2TPv3 Session Maintenance .................................5
3.4. Use of Circuit Status AVP for HDLC .........................6
4. Encapsulation ...................................................6
4.1. Data Packet Encapsulation ..................................6
4.2. Data Packet Sequencing .....................................7
4.3. MTU Considerations .........................................7
5. Applicability Statement .........................................8
6. Security Considerations .........................................9
7. IANA Considerations .............................................9
7.1. Pseudowire Type ............................................9
7.2. Result Code AVP Values .....................................9
8. Acknowledgements ................................................9
9. References .....................................................10
9.1. Normative References ......................................10
9.2. Informative References ....................................10
1. Introduction ....................................................2
1.1. Abbreviations ..............................................2
1.2. Specification of Requirements ..............................3
2. Control Connection Establishment ................................3
3. HDLC Link Status Notification and Session Establishment .........3
3.1. L2TPv3 Session Establishment ...............................3
3.2. L2TPv3 Session Teardown ....................................5
3.3. L2TPv3 Session Maintenance .................................5
3.4. Use of Circuit Status AVP for HDLC .........................6
4. Encapsulation ...................................................6
4.1. Data Packet Encapsulation ..................................6
4.2. Data Packet Sequencing .....................................7
4.3. MTU Considerations .........................................7
5. Applicability Statement .........................................8
6. Security Considerations .........................................9
7. IANA Considerations .............................................9
7.1. Pseudowire Type ............................................9
7.2. Result Code AVP Values .....................................9
8. Acknowledgements ................................................9
9. References .....................................................10
9.1. Normative References ......................................10
9.2. Informative References ....................................10
[RFC3931] defines a base protocol for Layer 2 Tunneling over IP networks. This document defines the specifics necessary for tunneling HDLC Frames over L2TPv3. Such emulated circuits are referred to as HDLC Pseudowires (HDLCPWs).
[RFC3931]定义了IP网络上第2层隧道的基本协议。本文档定义了在L2TPv3上隧道HDLC帧所需的细节。这种仿真电路称为HDLC伪线（HDLCPW）。
Protocol specifics defined in this document for L2TPv3 HDLCPWs include those necessary for simple point-to-point (e.g., between two L2TPv3 nodes) frame encapsulation, and for simple interface up and interface down notifications.
本文档中为L2TPv3 HDLCPW定义的协议规范包括简单点到点（例如，两个L2TPv3节点之间）帧封装以及简单接口向上和接口向下通知所需的协议规范。
The reader is expected to be very familiar with the terminology and protocol constructs defined in [RFC3931].
读者应非常熟悉[RFC3931]中定义的术语和协议结构。
HDLC High-Level Data Link Control HDLCPW HDLC Pseudowire LAC L2TP Access Concentrator (see [RFC3931]) LCCE L2TP Control Connection Endpoint (see [RFC3931]) PW Pseudowire
HDLC高级数据链路控制HDLCPW HDLC伪线LAC L2TP访问集中器（参见[RFC3931]）LCCE L2TP控制连接端点（参见[RFC3931]）PW伪线
In this document, several words are used to signify the requirements of the specification. These words are often capitalized. 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 [RFC2119].
在本文件中，使用了几个词来表示规范的要求。这些词通常大写。本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
In order to tunnel an HDLC link over IP using L2TPv3, an L2TPv3 Control Connection MUST first be established as described in [RFC3931]. The L2TPv3 SCCRQ Control Message and corresponding SCCRP Control Message MUST include the HDLC Pseudowire Type of 0x0006 (see Section 7, "IANA Considerations"), in the Pseudowire Capabilities List as defined in 5.4.3 of [RFC3931]. This identifies the control connection as able to establish L2TP sessions to support HDLC Pseudowires (HDLCPWs).
为了使用L2TPv3通过IP隧道HDLC链路，必须首先按照[RFC3931]中的说明建立L2TPv3控制连接。L2TPv3 SCCRQ控制消息和相应的SCCRP控制消息必须包括[RFC3931]第5.4.3节中定义的伪线能力列表中的HDLC伪线类型0x0006（参见第7节“IANA注意事项”）。这将控制连接标识为能够建立L2TP会话以支持HDLC伪线（HDLCPW）。
An LCCE MUST be able to uniquely identify itself in the SCCRQ and SCCRP messages via a globally unique value. By default, this is advertised via the structured Router ID AVP [RFC3931], though the unstructured Hostname AVP [RFC3931] MAY be used to identify LCCEs as well.
LCCE必须能够通过全局唯一值在SCCRQ和SCCRP消息中唯一标识自己。默认情况下，这是通过结构化路由器ID AVP[RFC3931]公布的，尽管非结构化主机名AVP[RFC3931]也可用于标识LCCE。
This section specifies how the status of an HDLC interface is reported between two LCCEs, and the associated L2TP session creation and deletion that occurs.
本节指定如何在两个LCCE之间报告HDLC接口的状态，以及发生的相关L2TP会话创建和删除。
Associating an HDLC serial interface with a PW and its transition to "Ready" or "Up" results in the establishment of an L2TP session via the standard three-way handshake described in Section 3.4.1 of [RFC3931]. For purposes of this discussion, the action of locally associating an interface running HDLC with a PW by local configuration or otherwise is referred to as "provisioning" the HDLC interface. The transition of the interface to "ready" or "up" will be referred to as the interface becoming ACTIVE. The transition of the interface to "not-ready" or "down" will be referred to as the interface becoming INACTIVE.
将HDLC串行接口与PW关联，并将其转换为“就绪”或“向上”，通过[RFC3931]第3.4.1节所述的标准三向握手建立L2TP会话。出于本讨论的目的，通过本地配置或其他方式将运行HDLC的接口与PW本地关联的操作称为“设置”HDLC接口。将接口转换为“就绪”或“向上”将被称为接口变为活动状态。将接口转换为“未就绪”或“关闭”将被称为接口变为非活动状态。
An LCCE MAY initiate the session immediately upon association with an HDLC interface or wait until the interface becomes ACTIVE before attempting to establish an L2TP session. Waiting until the interface transitions to ACTIVE may be preferred, as it delays allocation of resources until absolutely necessary.
LCCE可在与HDLC接口关联后立即启动会话，或在尝试建立L2TP会话之前等待接口变为活动状态。等待接口转换为活动可能是首选，因为它会延迟资源分配，直到绝对必要。
The Pseudowire Type AVP defined in Section 5.4.4 of [RFC3931], Attribute Type 68, MUST be present in the ICRQ messages and MUST include the Pseudowire Type of 0x0006 for HDLCPWs.
[RFC3931]第5.4.4节中定义的伪线类型AVP属性类型68必须出现在ICRQ消息中，并且必须包括HDLCPWs的伪线类型0x0006。
The Circuit Status AVP (see Section 3.4) MUST be present in the ICRQ and ICRP messages and MAY be present in the SLI message for HDLCPWs.
电路状态AVP（见第3.4节）必须出现在ICRQ和ICRP消息中，并且可能出现在HDLCPWs的SLI消息中。
Following is an example of the L2TP messages exchanged for an HDLCPW that is initiated after an HDLC interface is provisioned and becomes ACTIVE.
以下是为HDLCPW交换的L2TP消息的示例，HDLCPW在HDLC接口设置并变为活动状态后启动。
LCCE (LAC) A LCCE (LAC) B
------------------ ------------------
HDLC Interface Provisioned
HDLC Interface Provisioned
HDLC Interface ACTIVE
LCCE (LAC) A LCCE (LAC) B
------------------ ------------------
HDLC Interface Provisioned
HDLC Interface Provisioned
HDLC Interface ACTIVE
ICRQ (status = 0x03) ---->
ICRQ (status = 0x03) ---->
HDLC Interface ACTIVE
HDLC接口活动
<---- ICRP (status = 0x03)
<---- ICRP (status = 0x03)
L2TP session established, OK to send data into tunnel
L2TP会话已建立，可以将数据发送到隧道中
ICCN ----->
L2TP session established,
OK to send data into tunnel
ICCN ----->
L2TP session established,
OK to send data into tunnel
In the example above, an ICRQ is sent after the interface is provisioned and becomes ACTIVE. The Circuit Status AVP indicates that this link is ACTIVE and New (0x03). The Remote End ID AVP [RFC3931] MUST be present in the ICRQ in order to identify the HDLC link (together with the identity of the LCCE itself as defined in Section 2) with which to associate the L2TP session. The Remote End ID AVP defined in [RFC3931] is of opaque form and variable length, though one MUST at a minimum support use of an unstructured four-octet value that is known to both LCCEs (either by direct configuration, or some other means). The exact method of how this value is configured, retrieved, discovered, or otherwise determined at each LCCE is outside the scope of this document.
在上面的示例中，ICRQ在接口被设置并变为活动状态后发送。电路状态AVP指示此链路处于活动状态且为新链路（0x03）。ICRQ中必须存在远程端ID AVP[RFC3931]，以便识别与L2TP会话相关联的HDLC链路（以及第2节中定义的LCCE本身的标识）。[RFC3931]中定义的远程端ID AVP为不透明形式且长度可变，但必须至少支持使用两个LCCE已知的非结构化四八位组值（通过直接配置或其他方式）。如何在每个LCCE配置、检索、发现或以其他方式确定此值的确切方法不在本文档的范围内。
As with the ICRQ, the ICRP is sent only after the associated HDLC interface transitions to ACTIVE as well. If LCCE B had not been provisioned for the interface identified in the ICRQ, a CDN would have been immediately returned indicating that the associated link was not provisioned or available at this LCCE. LCCE A SHOULD then exhibit a periodic retry mechanism. If so, the period and maximum number of retries MUST be configurable.
与ICRQ一样，ICRP仅在相关的HDLC接口转换为活动接口后发送。如果没有为ICRQ中标识的接口配置LCCE B，则会立即返回CDN，表明相关链路未在该LCCE配置或可用。然后，LCCE A应显示定期重试机制。如果是这样，则必须配置重试的周期和最大次数。
An Implementation MAY send an ICRQ or ICRP before an HDLC interface is ACTIVE, as long as the Circuit Status AVP reflects that the link is INACTIVE and an SLI is sent when the HDLC interface becomes ACTIVE (see Section 3.3).
只要电路状态AVP反映链路处于非活动状态，并且当HDLC接口变为活动状态时发送SLI，则实现可以在HDLC接口激活之前发送ICRQ或ICRP（参见第3.3节）。
The ICCN is the final stage in the session establishment, confirming the receipt of the ICRP with acceptable parameters to allow bidirectional traffic.
ICCN是会话建立的最后阶段，用可接受的参数确认收到ICRP，以允许双向通信。
In the event a link is removed (unprovisioned) at either LCCE, the associated L2TP session MUST be torn down via the CDN message defined in Section 3.4.3 of [RFC3931].
如果在任一LCCE上删除（未设置）链接，则必须通过[RFC3931]第3.4.3节中定义的CDN消息中断相关L2TP会话。
General Result Codes regarding L2TP session establishment are defined in [RFC3931]. Additional HDLC result codes are defined as follows:
[RFC3931]中定义了有关L2TP会话建立的一般结果代码。其他HDLC结果代码定义如下：
20 - HDLC Link was deleted permanently (no longer provisioned) 21 - HDLC Link has been INACTIVE for an extended period of time
20-HDLC链路被永久删除（不再配置）21-HDLC链路已长时间处于非活动状态
HDLCPWs over L2TP make use of the Set Link Info (SLI) control message defined in [RFC3931] to signal HDLC link status notifications between PEs. The SLI message is a single message that is sent over the L2TP control channel, signaling the interface state change.
L2TP上的HDLCPWs利用[RFC3931]中定义的Set Link Info（SLI）控制消息在PEs之间发送HDLC链路状态通知。SLI消息是通过L2TP控制信道发送的单个消息，表示接口状态更改。
The SLI message MUST be sent any time there is a status change of any values identified in the Circuit Status AVP. The only exceptions to this are the initial ICRQ, ICRP, and CDN messages, which establish and teardown the L2TP session itself. The SLI message may be sent from either PE at any time after the first ICRQ is sent (and perhaps before an ICRP is received, requiring the peer to perform a reverse Session ID lookup).
当电路状态AVP中标识的任何值发生状态变化时，必须发送SLI消息。唯一的例外是初始ICRQ、ICRP和CDN消息，这些消息建立和断开L2TP会话本身。SLI消息可以在发送第一个ICRQ之后（并且可能在接收到ICRP之前，要求对等方执行反向会话ID查找）的任何时间从任一PE发送。
All sessions established by a given control connection utilize the L2TP Hello facility defined in Section 4.4 of [RFC3931] for session keepalive. This gives all sessions basic dead peer and path detection between PEs.
由给定控制连接建立的所有会话都使用[RFC3931]第4.4节中定义的L2TP Hello功能来实现会话保持。这为所有会话提供了PEs之间的基本死点和路径检测。
HDLC reports Circuit Status with the Circuit Status AVP defined in [RFC3931], Attribute Type 71. For reference, this AVP is shown below:
HDLC使用[RFC3931]中定义的电路状态AVP报告电路状态，属性类型为71。该AVP如下所示，以供参考：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |N|A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |N|A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Value is a 16-bit mask with the two least significant bits defined and the remaining bits reserved for future use. Reserved bits MUST be set to 0 when sending, and ignored upon receipt.
该值是一个16位掩码，定义了两个最低有效位，其余位保留供将来使用。发送时保留位必须设置为0，接收时忽略。
The N (New) bit SHOULD be set to one (1) if the Circuit Status indication is for a new HDLC circuit; to zero (0) otherwise.
如果电路状态指示用于新的HDLC电路，则N（新）位应设置为一（1）；否则为零（0）。
The A (Active) bit indicates whether the HDLC interface is ACTIVE (1) or INACTIVE (0).
A（活动）位指示HDLC接口是活动（1）还是非活动（0）。
HDLCPWs use the default encapsulations defined in [RFC3931] for demultiplexing, sequencing, and flags. The HDLCPW Type over L2TP is intended to operate in an "interface to interface" or "port to port" fashion, passing all HDLC data and control PDUs over the PW. The HDLC PDU is stripped of flags and trailing FCS, bit/byte unstuffing is performed, and the remaining data, including the address, control, and protocol fields, is transported over the PW.
HDLCPW使用[RFC3931]中定义的默认封装进行解复用、排序和标志。L2TP上的HDLCPW类型旨在以“接口到接口”或“端口到端口”的方式运行，通过PW传递所有HDLC数据和控制PDU。HDLC PDU去除标志和尾随FCS，执行位/字节取消缓冲，剩余数据（包括地址、控制和协议字段）通过PW传输。
Since all packets are passed in a largely transparent manner over the HDLCPW, any protocol that has HDLC-like framing may utilize the HDLCPW mode, including PPP, Frame-Relay ("port to port" Frame-Relay transport), X.25 (LAPB), etc. In such cases, the negotiations and signaling of the specific protocols transported over the HDLCPW take place between the Remote Systems. A non-exhaustive list of examples and considerations of this transparent nature include:
由于所有分组在HDLCPW上以基本透明的方式传递，因此具有类似HDLC的帧的任何协议都可以利用HDLCPW模式，包括PPP、帧中继（“端口到端口”帧中继传输）、X.25（LAPB）等，通过HDLCPW传输的特定协议的协商和信令在远程系统之间进行。这种透明性质的示例和考虑事项的非详尽清单包括：
o When the HDLCPW transports Point-to-Point Protocol (PPP) traffic, PPP negotiations (Link Control Protocol, optional authentication, and Network Control Protocols) are performed between Remote Systems, and LCCEs do not participate in these negotiations.
o 当HDLCPW传输点对点协议（PPP）流量时，在远程系统之间执行PPP协商（链路控制协议、可选身份验证和网络控制协议），LCCE不参与这些协商。
o When the HDLCPW transports Frame-Relay traffic, PVC status management procedures (Local Management Interface) take place between Remote Systems, and LCCEs do not participate in LMI. Additionally, individual Frame-Relay virtual-circuits are not visible to the LCCEs, and the FECN, BECN, and DE bits are transported transparently.
o 当HDLCPW传输帧中继流量时，PVC状态管理程序（本地管理接口）在远程系统之间进行，LCCE不参与LMI。此外，单个帧中继虚拟电路对lcce不可见，并且FECN、BECN和DE比特是透明传输的。
o When the HDLCPW transports X.25 (LAPB) traffic, LCCEs do not function as either LAPB DCE or DTE devices.
o 当HDLCPW传输X.25（LAPB）通信量时，LCCE不能作为LAPB DCE或DTE设备工作。
On the other hand, exceptions include cases where direct access to the HDLC interface is required, or modes that operate on the flags, FCS, or bit/byte unstuffing that is performed before sending the HDLC PDU over the PW. An example of this is PPP ACCM negotiation.
另一方面，例外情况包括需要直接访问HDLC接口的情况，或在通过PW发送HDLC PDU之前对标志、FCS或位/字节取消缓冲进行操作的模式。PPP ACCM谈判就是一个例子。
Data Packet Sequencing MAY be enabled for HDLCPWs. The sequencing mechanisms described in Section 4.6.1 of [RFC3931] MUST be used for signaling sequencing support. HDLCPWs over L2TP MUST request the presence of the L2TPv3 Default L2-Specific Sublayer defined in Section 4.6 of [RFC3931] when sequencing is enabled, and MAY request its presence at all times.
可为HDLCPW启用数据包排序。[RFC3931]第4.6.1节中描述的排序机制必须用于信号排序支持。当启用排序时，L2TP上的HDLCPWs必须请求存在[RFC3931]第4.6节中定义的L2TPv3默认L2特定子层，并且可以随时请求其存在。
With L2TPv3 as the tunneling protocol, the packet resulting from the encapsulation is N bytes longer than the HDLC frame without the flags or FCS. The value of N depends on the following fields:
使用L2TPv3作为隧道协议，封装产生的数据包比不带标志或FCS的HDLC帧长N字节。N的值取决于以下字段：
L2TP Session Header: Flags, Ver, Res 4 octets (L2TPv3 over UDP only) Session ID 4 octets Cookie Size 0, 4, or 8 octets L2-Specific Sublayer 0 or 4 octets (i.e., using sequencing)
L2TP会话头：Flags、Ver、Res 4个八位字节（仅限UDP上的L2TPv3）会话ID 4个八位字节Cookie大小0、4或8个八位字节L2特定子层0或4个八位字节（即，使用排序）
Hence the range for N in octets is:
因此，八位字节中N的范围为：
N = 4-16, L2TPv3 data messages are over IP;
N = 16-28, L2TPv3 data messages are over UDP;
(N does not include the IP header.)
N = 4-16, L2TPv3 data messages are over IP;
N = 16-28, L2TPv3 data messages are over UDP;
(N does not include the IP header.)
The MTU and fragmentation implications resulting from this are discussed in Section 4.1.4 of [RFC3931].
[RFC3931]第4.1.4节讨论了由此产生的MTU和碎片影响。
HDLC Pseudowires support a "port to port" or "interface to interface" deployment model operating in a point-to-point fashion. In addition to the transport of HDLC frames, a natural application of HDLCPWs allows for the transport of any protocol using an HDLC-like framing.
HDLC伪线支持以点对点方式运行的“端口到端口”或“接口到接口”部署模型。除了HDLC帧的传输之外，HDLCPWs的自然应用允许使用类似HDLC的帧传输任何协议。
The HDLCPW emulation over a packet-switched network (PSN) has the following characteristics in relationship to the native service:
分组交换网络（PSN）上的HDLCPW仿真相对于本机服务具有以下特征：
o HDLC data and control fields are transported transparently (see Section 4.1). The specific negotiations and signaling of the protocol being transported are performed between Remote Systems transparently, and the LCCE does not participate in them.
o HDLC数据和控制字段的传输是透明的（见第4.1节）。正在传输的协议的特定协商和信令在远程系统之间透明地执行，并且LCCE不参与这些协商和信令。
o The trailing FCS (Frame Check Sequence) containing a CRC (Cyclic Redundancy Check) is stripped at the ingress LCCE and not transported over HDLCPWs. It is therefore regenerated at the egress LCCE (see Section 4.1). This means that the FCS may not accurately reflect errors on the end-to-end HDLC link. Errors or corruption introduced in the HDLCPW payload during encapsulation or transit across the packet-switched network may not be detected. This lack of integrity-check transparency may not be of concern if it is known that the inner payloads or upper protocols transported perform their own error and integrity checking. To allow for payload integrity-checking transparency on HDLCPWs using L2TP over IP or L2TP over UDP/IP, the L2TPv3 session can utilize IPSec as specified in Section 4.1.3 of [RFC3931].
o 包含CRC（循环冗余校验）的后续FCS（帧校验序列）在入口LCCE处剥离，而不是通过HDLCPWs传输。因此，它在出口LCCE处再生（见第4.1节）。这意味着FCS可能无法准确反映端到端HDLC链路上的错误。在封装或通过分组交换网络传输期间，可能无法检测到HDLCPW有效负载中引入的错误或损坏。如果已知内部有效负载或传输的上层协议执行其自身的错误和完整性检查，则完整性检查透明度的缺乏可能不值得关注。为了允许使用L2TP over IP或L2TP over UDP/IP在HDLCPW上进行有效负载完整性检查透明度，L2TPv3会话可以按照[RFC3931]第4.1.3节的规定使用IPSec。
o HDLC link status notification is provided using the Circuit Status AVP in the SLI message (see Section 3.4).
o HDLC链路状态通知使用SLI消息中的电路状态AVP提供（见第3.4节）。
o The length of the resulting L2TPv3 packet is longer than the encapsulated HDLC frame without flags and FCS (see Section 4.3), with resulting MTU and fragmentation implications discussed in Section 4.1.4 of [RFC3931].
o 产生的L2TPv3数据包的长度比不带标志和FCS的封装HDLC帧长（见第4.3节），产生的MTU和碎片影响在[RFC3931]第4.1.4节中讨论。
o The packet-switched network may reorder, duplicate, or silently drop packets. Sequencing may be enabled in the HDLCPW for some or all packets to detect lost, duplicate, or out-of-order packets on a per-session basis (see Section 4.2).
o 分组交换网络可以重新排序、复制或静默丢弃分组。可在HDLCPW中为部分或所有数据包启用排序，以在每个会话的基础上检测丢失、重复或无序数据包（见第4.2节）。
o The faithfulness of an HDLCPW may be increased by leveraging Quality of Service features of the LCCEs and the underlying PSN.
o HDLCPW的忠实性可以通过利用LCCE和基础PSN的服务质量特性来提高。
HDLC over L2TPv3 is subject to the security considerations defined in [RFC3931]. Beyond the considerations when carrying other data link types, there are no additional considerations specific to carrying HDLC.
L2TPv3上的HDLC应遵守[RFC3931]中定义的安全注意事项。除了承载其他数据链路类型时的注意事项外，没有特定于承载HDLC的其他注意事项。
The signaling mechanisms defined in this document rely upon the allocation of an HDLC Pseudowire Type (see Pseudowire Capabilities List as defined in 5.4.3 of [RFC3931] and L2TPv3 Pseudowire Types in 10.6 of [RFC3931]) by the IANA (number space created as part of publication of [RFC3931]). The HDLC Pseudowire Type is defined in Section 2 of this specification:
本文件中定义的信令机制取决于IANA（作为[RFC3931]出版物的一部分创建的数字空间）对HDLC伪线类型的分配（参见[RFC3931]第5.4.3节中定义的伪线能力列表和[RFC3931]第10.6节中定义的L2TPv3伪线类型）。HDLC伪线类型在本规范第2节中定义：
L2TPv3 Pseudowire Types
-----------------------
L2TPv3 Pseudowire Types
-----------------------
0x0006 - HDLC Pseudowire Type
0x0006-HDLC伪线类型
This number space is managed by IANA as described in section 2.3 of [BCP0068]. Two new L2TP Result Codes for the CDN message appear in Section 3.2. The following is a summary:
该数字空间由IANA管理，如[BCP0068]第2.3节所述。CDN消息的两个新L2TP结果代码出现在第3.2节中。以下是总结：
Result Code AVP (Attribute Type 1) Values
-----------------------------------------
Result Code AVP (Attribute Type 1) Values
-----------------------------------------
20 - HDLC Link was deleted permanently (no longer provisioned) 21 - HDLC Link has been INACTIVE for an extended period of time
20-HDLC链路被永久删除（不再配置）21-HDLC链路已长时间处于非活动状态
Thanks to Sudhir Rustogi and George Wilkie for valuable input. Maria Alice Dos Santos provided helpful review and comment. Many thanks to Mark Lewis for providing review and clarifying comments during IETF Last Call.
感谢Sudhir Rustogi和George Wilkie的宝贵意见。Maria Alice Dos Santos提供了有用的评论。非常感谢Mark Lewis在IETF最后一次通话中提供评论和澄清意见。
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC3931]Lau，J.，Townsley，M.，和I.Goyret，“第二层隧道协议-版本3（L2TPv3）”，RFC 39312005年3月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[BCP0068] Townsley, W., "Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update", BCP 68, RFC 3438, December 2002.
[BCP0068]汤斯利，W.“第二层隧道协议（L2TP）互联网分配号码管理局（IANA）注意事项更新”，BCP 68，RFC 3438，2002年12月。
Authors' Addresses
作者地址
Carlos Pignataro Cisco Systems 7025 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709
卡洛斯·皮格纳塔罗思科系统公司，地址：北卡罗来纳州三角研究公园Kit Creek路7025号邮政信箱14987，邮编：27709
EMail: cpignata@cisco.com
EMail: cpignata@cisco.com
W. Mark Townsley Cisco Systems 7025 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709
美国北卡罗来纳州三角研究公园14987号吉特克里克路邮政信箱7025号马克·汤斯利思科系统公司
EMail: mark@townsley.net
EMail: mark@townsley.net
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。