Network Working Group R. Aggarwal, Ed.
Request for Comments: 4719 Juniper Networks
Category: Standards Track M. Townsley, Ed.
M. Dos Santos, Ed.
Cisco Systems
November 2006
Network Working Group R. Aggarwal, Ed.
Request for Comments: 4719 Juniper Networks
Category: Standards Track M. Townsley, Ed.
M. Dos Santos, Ed.
Cisco Systems
November 2006
Transport of Ethernet Frames over Layer 2 Tunneling Protocol Version 3 (L2TPv3)
通过第2层隧道协议版本3（L2TPv3）传输以太网帧
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 IETF Trust (2006).
版权所有（C）IETF信托基金（2006年）。
Abstract
摘要
This document describes the transport of Ethernet frames over the Layer 2 Tunneling Protocol, Version 3 (L2TPv3). This includes the transport of Ethernet port-to-port frames as well as the transport of Ethernet VLAN frames. The mechanism described in this document can be used in the creation of Pseudowires to transport Ethernet frames over an IP network.
本文档描述了通过第2层隧道协议版本3（L2TPv3）传输以太网帧。这包括以太网端口到端口帧的传输以及以太网VLAN帧的传输。本文档中描述的机制可用于创建通过IP网络传输以太网帧的伪线。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Specification of Requirements ..............................2
1.2. Abbreviations ..............................................3
1.3. L2TPv3 Control Message Types ...............................3
1.4. Requirements ...............................................3
2. PW Establishment ................................................4
2.1. LCCE-LCCE Control Connection Establishment .................4
2.2. PW Session Establishment ...................................4
2.3. PW Session Monitoring ......................................6
3. Packet Processing ...............................................7
3.1. Encapsulation .............................................7
3.2. Sequencing ................................................7
3.3. MTU Handling ..............................................7
4. Applicability Statement .........................................8
5. Congestion Control .............................................10
6. Security Considerations ........................................10
7. IANA Considerations ............................................11
8. Contributors ...................................................11
9. Acknowledgements ...............................................11
10. References ....................................................12
10.1. Normative References .....................................12
10.2. Informative References ...................................12
1. Introduction ....................................................2
1.1. Specification of Requirements ..............................2
1.2. Abbreviations ..............................................3
1.3. L2TPv3 Control Message Types ...............................3
1.4. Requirements ...............................................3
2. PW Establishment ................................................4
2.1. LCCE-LCCE Control Connection Establishment .................4
2.2. PW Session Establishment ...................................4
2.3. PW Session Monitoring ......................................6
3. Packet Processing ...............................................7
3.1. Encapsulation .............................................7
3.2. Sequencing ................................................7
3.3. MTU Handling ..............................................7
4. Applicability Statement .........................................8
5. Congestion Control .............................................10
6. Security Considerations ........................................10
7. IANA Considerations ............................................11
8. Contributors ...................................................11
9. Acknowledgements ...............................................11
10. References ....................................................12
10.1. Normative References .....................................12
10.2. Informative References ...................................12
The Layer 2 Tunneling Protocol, Version 3 (L2TPv3) can be used as a control protocol and for data encapsulation to set up Pseudowires (PWs) for transporting layer 2 Packet Data Units across an IP network [RFC3931]. This document describes the transport of Ethernet frames over L2TPv3 including the PW establishment and data encapsulation.
第2层隧道协议版本3（L2TPv3）可用作控制协议和数据封装，以建立伪线（PW），用于在IP网络上传输第2层分组数据单元[RFC3931]。本文档描述了L2TPv3上以太网帧的传输，包括PW建立和数据封装。
The term "Ethernet" in this document is used with the intention to include all such protocols that are reasonably similar in their packet format to IEEE 802.3 [802.3], including variants or extensions that may or may not necessarily be sanctioned by the IEEE (including such frames as jumbo frames, etc.). The term "VLAN" in this document is used with the intention to include all virtual LAN tagging protocols such as IEEE 802.1Q [802.1Q], 802.1ad [802.1ad], etc.
本文件中的术语“以太网”旨在包括在数据包格式上合理类似于IEEE 802.3[802.3]的所有此类协议，包括IEEE可能批准或不一定批准的变体或扩展（包括巨型帧等）。本文档中的术语“VLAN”旨在包括所有虚拟LAN标记协议，如IEEE 802.1Q[802.1Q]、802.1ad[802.1ad]等。
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]中所述进行解释。
AC Attachment Circuit (see [RFC3985]) CE Customer Edge (Typically also the L2TPv3 Remote System) LCCE L2TP Control Connection Endpoint (see [RFC3931]) NSP Native Service Processing (see [RFC3985]) PE Provider Edge (Typically also the LCCE) (see [RFC3985]) PSN Packet Switched Network (see [RFC3985]) PW Pseudowire (see [RFC3985]) PWE3 Pseudowire Emulation Edge to Edge (Working Group)
AC连接电路（参见[RFC3985]）CE客户边缘（通常也是L2TPv3远程系统）LCCE L2TP控制连接端点（参见[RFC3931]）NSP本机服务处理（参见[RFC3985]）PE提供商边缘（通常也是LCCE）（参见[RFC3985]）PSN分组交换网络（参见[RFC3985]）PW伪线（参见[RFC3985]）PWE3伪线仿真边到边（工作组）
Relevant L2TPv3 control message types (see [RFC3931]) are listed for reference.
列出了相关L2TPv3控制消息类型（参见[RFC3931]），以供参考。
SCCRQ L2TPv3 Start-Control-Connection-Request control message SCCRP L2TPv3 Start-Control-Connection-Reply control message SCCCN L2TPv3 Start-Control-Connection-Connected control message StopCCN L2TPv3 Stop-Control-Connection-Notification control message ICRQ L2TPv3 Incoming-Call-Request control message ICRP L2TPv3 Incoming-Call-Reply control message ICCN L2TPv3 Incoming-Call-Connected control message OCRQ L2TPv3 Outgoing-Call-Request control message OCRP L2TPv3 Outgoing-Call-Reply control message OCCN L2TPv3 Outgoing-Call-Connected control message CDN L2TPv3 Call-Disconnect-Notify control message SLI L2TPv3 Set-Link-Info control message
SCCRQ L2TPv3启动控制连接请求控制消息SCCRP L2TPv3启动控制连接回复控制消息SCCCN L2TPv3启动控制连接控制消息STOPCN L2TPv3停止控制连接通知控制消息ICRQ L2TPv3来电请求控制消息ICRP L2TPv3来电回复控制消息ICCN L2TPv3呼入呼叫连接控制消息OCRQ L2TPv3呼出呼叫请求控制消息OCRP L2TPv3呼出呼叫应答控制消息OCCN L2TPv3呼出呼叫连接控制消息CDN L2TPv3呼叫断开通知控制消息SLI L2TPv3设置链路信息控制消息
An Ethernet PW emulates a single Ethernet link between exactly two endpoints. The following figure depicts the PW termination relative to the NSP and PSN tunnel within an LCCE [RFC3985]. The Ethernet interface may be connected to one or more Remote Systems (an L2TPv3 Remote System is referred to as Customer Edge (CE) in this and associated PWE3 documents). The LCCE may or may not be a PE.
以太网PW模拟两个端点之间的单个以太网链路。下图描述了相对于LCCE内NSP和PSN隧道的PW终端[RFC3985]。以太网接口可以连接到一个或多个远程系统（L2TPv3远程系统在本文件和相关PWE3文件中称为客户边缘（CE））。LCCE可能是也可能不是PE。
+---------------------------------------+
| LCCE |
+-+ +-----+ +------+ +------+ +-+
|P| | | |PW ter| | PSN | |P|
Ethernet <==>|h|<=>| NSP |<=>|minati|<=>|Tunnel|<=>|h|<==> PSN
Interface |y| | | |on | | | |y|
+-+ +-----+ +------+ +------+ +-+
| |
+---------------------------------------+
Figure 1: PW termination
+---------------------------------------+
| LCCE |
+-+ +-----+ +------+ +------+ +-+
|P| | | |PW ter| | PSN | |P|
Ethernet <==>|h|<=>| NSP |<=>|minati|<=>|Tunnel|<=>|h|<==> PSN
Interface |y| | | |on | | | |y|
+-+ +-----+ +------+ +------+ +-+
| |
+---------------------------------------+
Figure 1: PW termination
The PW termination point receives untagged (also referred to as 'raw') or tagged Ethernet frames and delivers them unaltered to the PW termination point on the remote LCCE. Hence, it can provide untagged or tagged Ethernet link emulation service.
PW终端点接收未标记（也称为“raw”）或标记的以太网帧，并将其原封不动地传送到远程LCCE上的PW终端点。因此，它可以提供未标记或标记的以太网链路仿真服务。
The "NSP" function includes packet processing needed to translate the Ethernet frames that arrive at the CE-LCCE interface to/from the Ethernet frames that are applied to the PW termination point. Such functions may include stripping, overwriting, or adding VLAN tags. The NSP functionality can be used in conjunction with local provisioning to provide heterogeneous services where the CE-LCCE encapsulations at the two ends may be different.
“NSP”功能包括将到达CE-LCCE接口的以太网帧转换为应用于PW端点的以太网帧所需的数据包处理。此类功能可能包括剥离、覆盖或添加VLAN标记。NSP功能可与本地供应结合使用，以提供两端CE-LCCE封装可能不同的异构服务。
The physical layer between the CE and LCCE, and any adaptation (NSP) functions between it and the PW termination, are outside of the scope of PWE3 and are not defined here.
CE和LCCE之间的物理层及其与PW终端之间的任何适配（NSP）功能不在PWE3的范围内，此处未定义。
With L2TPv3 as the tunneling protocol, Ethernet PWs are L2TPv3 sessions. An L2TP Control Connection has to be set up first between the two LCCEs. Individual PWs can then be established as L2TP sessions.
使用L2TPv3作为隧道协议，以太网PW是L2TPv3会话。必须首先在两个LCCE之间建立L2TP控制连接。然后可以将单个PW建立为L2TP会话。
The two LCCEs that wish to set up Ethernet PWs MUST establish an L2TP Control Connection first as described in [RFC3931]. Hence, an Ethernet PW Type must be included in the Pseudowire Capabilities List as defined in [RFC3931]. The type of PW can be either "Ethernet port" or "Ethernet VLAN". This indicates that the Control Connection can support the establishment of Ethernet PWs. Note that there are two Ethernet PW Types required. For connecting an Ethernet port to another Ethernet port, the PW Type MUST be "Ethernet port"; for connecting an Ethernet VLAN to another Ethernet VLAN, the PW Type MUST be "Ethernet VLAN".
如[RFC3931]所述，希望建立以太网PWs的两个LCCE必须首先建立L2TP控制连接。因此，以太网PW类型必须包括在[RFC3931]中定义的伪线能力列表中。PW的类型可以是“以太网端口”或“以太网VLAN”。这表明控制连接可以支持以太网PWs的建立。注意，需要两种以太网PW类型。将一个以太网端口连接到另一个以太网端口时，PW类型必须为“以太网端口”；要将以太网VLAN连接到另一个以太网VLAN，PW类型必须为“以太网VLAN”。
The provisioning of an Ethernet port or Ethernet VLAN and its association with a PW triggers the establishment of an L2TP session via the standard Incoming Call three-way handshake described in Section 3.4.1 of [RFC3931].
以太网端口或以太网VLAN的供应及其与PW的关联通过[RFC3931]第3.4.1节所述的标准传入呼叫三方握手触发L2TP会话的建立。
Note that an L2TP Outgoing Call is essentially a method of controlling the originating point of a Switched Virtual Circuit (SVC), allowing it to be established from any reachable L2TP-enabled device able to perform outgoing calls. The Outgoing Call model and its corresponding OCRQ, OCRP, and OCCN control messages are mainly used within the dial arena with L2TPv2 today and has not been found applicable for PW applications yet.
请注意，L2TP呼出呼叫本质上是一种控制交换虚拟电路（SVC）的起始点的方法，允许从能够执行呼出呼叫的任何可到达L2TP启用设备建立它。传出呼叫模型及其相应的OCRQ、OCRP和OCCN控制消息目前主要用于L2TPv2拨号竞技场，尚未发现适用于PW应用程序。
The following are the signaling elements needed for the Ethernet PW establishment:
以下是以太网PW建立所需的信令元素：
a) Pseudowire Type: The type of a Pseudowire can be either "Ethernet port" or "Ethernet VLAN". Each LCCE signals its Pseudowire type in the Pseudowire Type AVP [RFC3931]. The assigned values for "Ethernet port" and "Ethernet VLAN" Pseudowire types are captured in the "IANA Considerations" of this document. The Pseudowire Type AVP MUST be present in the ICRQ.
a) 伪线类型：伪线的类型可以是“以太网端口”或“以太网VLAN”。每个LCCE在伪线类型AVP[RFC3931]中发送其伪线类型的信号。本文档中捕获的“以太网”和“虚拟局域网”端口的值均为“以太网”类型。ICRQ中必须存在伪线型AVP。
b) Pseudowire ID: Each PW is associated with a Pseudowire ID. The two LCCEs of a PW have the same Pseudowire ID for it. The Remote End Identifier AVP [RFC3931] is used to convey the Pseudowire ID. The Remote End Identifier AVP MUST be present in the ICRQ in order for the remote LCCE to determine the PW to associate the L2TP session with. An implementation MUST support a Remote End Identifier of four octets known to both LCCEs either by manual configuration or some other means. Additional Remote End Identifier formats that MAY be supported are outside the scope of this document.
b) 伪线ID：每个PW与一个伪线ID关联。PW的两个LCCE具有相同的伪线ID。远程端标识符AVP[RFC3931]用于传输伪线ID。远程端标识符AVP必须存在于ICRQ中，以便远程LCCE确定与L2TP会话关联的PW。一个实现必须通过手动配置或其他方式支持两个LCCE已知的四个八位字节的远程终端标识符。可能支持的其他远程端标识符格式不在本文档范围内。
c) The Circuit Status AVP [RFC3931] MUST be included in ICRQ and ICRP to indicate the circuit status of the Ethernet port or Ethernet VLAN. For ICRQ and ICRP, the Circuit Status AVP MUST indicate that the circuit status is for a new circuit (refer to N bit in Section 2.3.3). An implementation MAY send an ICRQ or ICRP before an Ethernet interface is ACTIVE, as long as the Circuit Status AVP (refer to A bit in Section 2.3.3) in the ICRQ or ICRP reflects the correct status of the Ethernet port or Ethernet VLAN link. A subsequent circuit status change of the Ethernet port or Ethernet VLAN MUST be conveyed in the Circuit Status AVP in ICCN or SLI control messages. For ICCN and SLI (refer to Section 2.3.2), the Circuit Status AVP MUST indicate that the circuit status is for an existing circuit (refer to N bit in Section 2.3.3) and reflect the current status of the link (refer to A bit in Section 2.3.3).
c) ICRQ和ICRP中必须包含电路状态AVP[RFC3931]，以指示以太网端口或以太网VLAN的电路状态。对于ICRQ和ICRP，电路状态AVP必须表明电路状态为新电路（参考第2.3.3节中的N位）。只要ICRQ或ICRP中的电路状态AVP（参考第2.3.3节中的一个位）反映了以太网端口或以太网VLAN链路的正确状态，实施可以在以太网接口激活之前发送ICRQ或ICRP。以太网端口或以太网VLAN的后续电路状态更改必须在ICCN或SLI控制消息中的电路状态AVP中传送。对于ICCN和SLI（参考第2.3.2节），电路状态AVP必须表明电路状态是针对现有电路的（参考第2.3.3节中的N位），并反映链路的当前状态（参考第2.3.3节中的位）。
The working status of a PW is reflected by the state of the L2TPv3 session. If the corresponding L2TPv3 session is down, the PW associated with it MUST be shut down. The Control Connection keep-alive mechanism of L2TPv3 can serve as a link status monitoring mechanism for the set of PWs associated with a Control Connection.
PW的工作状态由L2TPv3会话的状态反映。如果相应的L2TPv3会话已关闭，则必须关闭与其关联的PW。L2TPv3的控制连接保持活动机制可以用作与控制连接相关联的一组PW的链路状态监视机制。
In addition to the Control Connection keep-alive mechanism of L2TPv3, Ethernet PW over L2TP makes use of the Set-Link-Info (SLI) control message defined in [RFC3931]. The SLI message is used to signal Ethernet link status notifications between LCCEs. This can be useful to indicate Ethernet interface state changes without bringing down the L2TP session. Note that change in the Ethernet interface state will trigger an SLI message for each PW associated with that Ethernet interface. This may be one Ethernet port PW or more than one Ethernet VLAN PW. The SLI message MUST be sent any time there is a status change of any values identified in the Circuit Status AVP. The only exception to this is the initial ICRQ, ICRP, and CDN messages that establish and tear down the L2TP session itself. The SLI message may be sent from either LCCE 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).
除了L2TPv3的控制连接保持活动机制外，L2TP上的以太网PW还利用了[RFC3931]中定义的Set Link Info（SLI）控制消息。SLI消息用于向LCCE之间的以太网链路状态通知发送信号。这在指示以太网接口状态更改时非常有用，而不会关闭L2TP会话。请注意，以太网接口状态的更改将触发与该以太网接口相关的每个PW的SLI消息。这可能是一个以太网端口PW或多个以太网VLAN PW。当电路状态AVP中标识的任何值发生状态变化时，必须发送SLI消息。唯一的例外是初始ICRQ、ICRP和CDN消息，它们建立并中断L2TP会话本身。SLI消息可以在发送第一个ICRQ之后（可能在接收ICRP之前，需要对等方执行反向会话ID查找）的任何时间从任一LCCE发送。
Ethernet PW reports circuit status with the Circuit Status AVP defined in [RFC3931]. For reference, this AVP is shown below:
Ethernet PW使用[RFC3931]中定义的电路状态AVP报告电路状态。该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 A (Active) bit indicates whether the Ethernet interface is ACTIVE (1) or INACTIVE (0).
A（活动）位指示以太网接口是活动（1）还是非活动（0）。
The N (New) bit indicates whether the circuit status is for a new (1) Ethernet circuit or an existing (0) Ethernet circuit.
N（新）位表示电路状态是新（1）以太网电路还是现有（0）以太网电路。
The encapsulation described in this section refers to the functionality performed by the PW termination point depicted in Figure 1, unless otherwise indicated.
除非另有说明，否则本节中描述的封装是指图1中所示的PW端点执行的功能。
The entire Ethernet frame, without the preamble or frame check sequence (FCS), is encapsulated in L2TPv3 and is sent as a single packet by the ingress LCCE. This is done regardless of whether or not a VLAN tag is present in the Ethernet frame. For Ethernet port-to-port mode, the remote LCCE simply decapsulates the L2TP payload and sends it out on the appropriate interface without modifying the Ethernet header. For Ethernet VLAN-to-VLAN mode, the remote LCCE MAY rewrite the VLAN tag. As described in Section 1, the VLAN tag modification is an NSP function.
没有前导码或帧检查序列（FCS）的整个以太网帧封装在L2TPv3中，并由入口LCCE作为单个数据包发送。无论以太网帧中是否存在VLAN标记，都会执行此操作。对于以太网端口到端口模式，远程LCCE只需解除L2TP有效负载的封装，并将其发送到适当的接口上，而无需修改以太网报头。对于以太网VLAN到VLAN模式，远程LCCE可以重写VLAN标记。如第1节所述，VLAN标记修改是一项NSP功能。
The Ethernet PW over L2TP is homogeneous with respect to packet encapsulation, i.e., both ends of the PW are either untagged or tagged. The Ethernet PW can still be used to provide heterogeneous services using NSP functionality at the ingress and/or egress LCCE. The definition of such NSP functionality is outside the scope of this document.
L2TP上的以太网PW在数据包封装方面是同质的，即PW的两端不是未标记就是已标记。以太网PW仍可用于在入口和/或出口LCCE处使用NSP功能提供异构服务。此类NSP功能的定义不在本文件范围内。
The maximum length of the Ethernet frame carried as the PW payload is irrelevant as far as the PW is concerned. If anything, that value would only be relevant when quantifying the faithfulness of the emulation.
就PW而言，作为PW有效负载承载的以太网帧的最大长度是无关的。如果有什么区别的话，那么这个值只有在量化仿真的忠实性时才相关。
Data packet sequencing MAY be enabled for Ethernet PWs. The sequencing mechanisms described in [RFC3931] MUST be used for signaling sequencing support.
可为以太网PWs启用数据包排序。[RFC3931]中描述的排序机制必须用于信号排序支持。
With L2TPv3 as the tunneling protocol, the IP packet resulting from the encapsulation is M + N bytes longer than the Ethernet frame without the preamble or FCS. Here M is the length of the IP header along with associated options and extension headers, and the value of N depends on the following fields:
使用L2TPv3作为隧道协议，封装产生的IP数据包比没有前导码或FCS的以太网帧长M+N字节。这里M是IP头的长度以及相关的选项和扩展头，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 = 4-16, for L2TPv3 data messages over IP;
N = 16-28, for L2TPv3 data messages over UDP;
(N does not include the IP header).
Hence the range for N in octets is:
N = 4-16, for L2TPv3 data messages over IP;
N = 16-28, for L2TPv3 data messages over UDP;
(N does not include the IP header).
Fragmentation in the PSN can occur when using Ethernet over L2TP, unless proper configuration and management of MTU sizes are in place between the Customer Edge (CE) router and Provider Edge (PE) router, and across the PSN. This is not specific only to Ethernet over L2TPv3, and the base L2TPv3 specification [RFC3931] provides general recommendations with respect to fragmentation and reassembly in Section 4.1.4. "PWE3 Fragmentation and Reassembly" [RFC4623] expounds on this topic, including a fragmentation and reassembly mechanism within L2TP itself in the event that no other option is available. Implementations MUST follow these guidelines with respect to fragmentation and reassembly.
在L2TP上使用以太网时，PSN中可能会出现碎片，除非在客户边缘（CE）路由器和提供商边缘（PE）路由器之间以及整个PSN中适当配置和管理MTU大小。这不仅适用于L2TPv3上的以太网，基本L2TPv3规范[RFC3931]在第4.1.4节中提供了有关碎片和重新组装的一般建议。“PWE3碎片和重组”[RFC4623]阐述了这一主题，包括在没有其他选项可用的情况下L2TP内部的碎片和重组机制。在碎片化和重组方面，实现必须遵循这些准则。
The Ethernet PW emulation allows a service provider to offer a "port-to-port"-based Ethernet service across an IP Packet Switched Network (PSN), while the Ethernet VLAN PW emulation allows an "VLAN-to-VLAN"-based Ethernet service across an IP Packet Switched Network (PSN).
以太网PW仿真允许服务提供商跨IP分组交换网络（PSN）提供基于“端口到端口”的以太网服务，而以太网VLAN PW仿真允许跨IP分组交换网络（PSN）提供基于“VLAN到VLAN”的以太网服务。
The Ethernet or Ethernet VLAN PW emulation has the following characteristics in relationship to the respective native service:
以太网或以太网VLAN PW仿真相对于各自的本机服务具有以下特征：
o Ethernet PW connects two Ethernet port ACs, and Ethernet VLAN PW connects two Ethernet VLAN ACs, which both support bi-directional transport of variable-length Ethernet frames. The ingress LCCE strips the preamble and FCS from the Ethernet frame and transports the frame in its entirety across the PW. This is done regardless of the presence of the VLAN tag in the frame. The egress LCCE receives the Ethernet frame from the PW and regenerates the preamble and FCS before forwarding the frame to the attached Remote System (see Section 3.1). Since FCS is not being transported across either Ethernet or Ethernet VLAN PWs, payload integrity transparency may be lost. To achieve payload integrity transparency on Ethernet or Ethernet VLAN PWs 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 以太网PW连接两个以太网端口ACs，以太网VLAN PW连接两个以太网VLAN ACs，两者都支持可变长度以太网帧的双向传输。入口LCCE从以太网帧中剥离前导码和FCS，并通过PW整体传输帧。无论帧中是否存在VLAN标记，都会执行此操作。出口LCCE从PW接收以太网帧，并在将帧转发至连接的远程系统之前重新生成前导码和FCS（见第3.1节）。由于FCS未通过以太网或以太网VLAN PWs传输，因此有效负载完整性透明度可能会丢失。为了使用L2TP over IP或L2TP over UDP/IP在以太网或以太网VLAN PWs上实现有效负载完整性透明，L2TPv3会话可以按照[RFC3931]第4.1.3节的规定使用IPsec。
o While architecturally [RFC3985] outside the scope of the L2TPv3 PW itself, if VLAN tags are present, the NSP may rewrite VLAN tags on ingress or egress from the PW (see Section 3.1).
o 虽然体系结构[RFC3985]超出L2TPv3 PW本身的范围，但如果存在VLAN标记，NSP可以在PW的入口或出口重写VLAN标记（参见第3.1节）。
o The Ethernet or Ethernet VLAN PW only supports homogeneous Ethernet frame type across the PW; both ends of the PW must be either tagged or untagged. Heterogeneous frame type support achieved with NSP functionality is outside the scope of this document (see Section 3.1).
o 以太网或以太网VLAN PW仅支持PW上的同构以太网帧类型；PW的两端必须标记或未标记。使用NSP功能实现的异构帧类型支持不在本文件范围内（见第3.1节）。
o Ethernet port or Ethernet VLAN status notification is provided using the Circuit Status AVP in the SLI message (see Sections 2.3.2 and 2.3.3). Loss of connectivity between LCCEs can be detected by the L2TPv3 keep-alive mechanism (see Section 2.3.1 of this document and Section 4.4 of [RFC3931]). The LCCE can convey these indications back to its attached Remote System.
o 使用SLI消息中的电路状态AVP提供以太网端口或以太网VLAN状态通知（见第2.3.2和2.3.3节）。L2TPv3保持活动机制可检测LCCE之间的连接丢失（见本文件第2.3.1节和[RFC3931]第4.4节）。LCCE可将这些指示传回其连接的远程系统。
o The maximum frame size that can be supported is limited by the PSN MTU minus the L2TPv3 header size, unless fragmentation and reassembly is used (see Section 3.3 of this document and Section 4.1.4 of [RFC3931]).
o 可支持的最大帧大小受PSN MTU减去L2TPv3报头大小的限制，除非使用分段和重新组装（见本文件第3.3节和[RFC3931]第4.1.4节）。
o The Packet Switched Network may reorder, duplicate, or silently drop packets. Sequencing may be enabled in the Ethernet or Ethernet VLAN PW for some or all packets to detect lost, duplicate, or out-of-order packets on a per-session basis (see Section 3.2).
o 分组交换网络可以重新排序、复制或静默丢弃分组。可在Ethernet或Ethernet VLAN PW中为部分或所有数据包启用排序，以在每个会话的基础上检测丢失、重复或无序数据包（见第3.2节）。
o The faithfulness of an Ethernet or Ethernet VLAN PW may be increased by leveraging Quality-of-Service (QoS) features of the LCCEs and the underlying PSN. For example, for Ethernet 802.1Q [802.1Q] VLAN transport, the ingress LCCE MAY consider the user priority field (i.e., 802.1p) of the VLAN tag for traffic classification and QoS treatments, such as determining the Differentiated Services (DS) field [RFC2474] of the encapsulating IP header. Similarly, the egress LCCE MAY consider the DS field of the encapsulating IP header when rewriting the user priority field of the VLAN tag or queuing the Ethernet frame before forwarding the frame to the Remote System. The mapping between the user priority field and the IP header DS field as well as the Quality-of-Service model deployed are application specific and are outside the scope of this document.
o 以太网或以太网VLAN PW的忠实性可以通过利用lcce和底层PSN的服务质量（QoS）特性来提高。例如，对于以太网802.1q[802.1q] VLAN传输，入口LCCE可以考虑VLAN标签的用户优先级字段（即802.1p）用于业务分类和QoS处理，例如确定封装IP报头的区分服务（DS）字段[RFC2474]。类似地，出口LCCE可以考虑重写VLAN标签的用户优先级字段或在将帧转发到远程系统之前排队以太网帧时封装IP报头的DS字段。用户优先级字段和IP头DS字段之间的映射以及部署的服务质量模型是特定于应用程序的，不在本文档的范围内。
As explained in [RFC3985], the PSN carrying the PW may be subject to congestion, with congestion characteristics depending on PSN type, network architecture, configuration, and loading. During congestion, the PSN may exhibit packet loss that will impact the service carried by the Ethernet or Ethernet VLAN PW. In addition, since Ethernet or Ethernet VLAN PWs carry a variety of services across the PSN, including but not restricted to TCP/IP, they may or may not behave in a TCP-friendly manner prescribed by [RFC2914] and thus consume more than their fair share.
如[RFC3985]中所述，承载PW的PSN可能会发生拥塞，其拥塞特性取决于PSN类型、网络架构、配置和负载。在拥塞期间，PSN可能会出现分组丢失，这将影响以太网或以太网VLAN PW承载的服务。此外，由于以太网或以太网VLAN PW在整个PSN中承载各种服务，包括但不限于TCP/IP，因此它们可能以[RFC2914]规定的TCP友好方式运行，也可能不以[RFC2914]规定的方式运行，因此消耗的服务超过其公平份额。
Whenever possible, Ethernet or Ethernet VLAN PWs should be run over traffic-engineered PSNs providing bandwidth allocation and admission control mechanisms. IntServ-enabled domains providing the Guaranteed Service (GS) or DiffServ-enabled domains using EF (expedited forwarding) are examples of traffic-engineered PSNs. Such PSNs will minimize loss and delay while providing some degree of isolation of the Ethernet or Ethernet VLAN PW's effects from neighboring streams.
只要可能，以太网或以太网VLAN PWs应在提供带宽分配和准入控制机制的流量工程PSN上运行。提供保证服务（GS）的支持IntServ的域或使用EF（加速转发）的支持DiffServ的域是流量工程PSN的示例。这样的PSN将最小化损失和延迟，同时提供以太网或以太网VLAN PW与相邻流的某种程度的隔离。
LCCEs SHOULD monitor for congestion (by using explicit congestion notification or by measuring packet loss) in order to ensure that the service using the Ethernet or Ethernet VLAN PW may be maintained. When severe congestion is detected (for example, when enabling sequencing and detecting that the packet loss is higher than a threshold), the Ethernet or Ethernet VLAN PW SHOULD be halted by tearing down the L2TP session via a CDN message. The PW may be restarted by manual intervention or by automatic means after an appropriate waiting time. Note that the thresholds and time periods for shutdown and possible automatic recovery need to be carefully configured. This is necessary to avoid loss of service due to temporary congestion and to prevent oscillation between the congested and halted states.
LCCE应监控拥塞（通过使用显式拥塞通知或测量数据包丢失），以确保使用以太网或以太网VLAN PW的服务可以得到维护。当检测到严重拥塞时（例如，当启用排序并检测到数据包丢失高于阈值时），应通过CDN消息中断L2TP会话来停止以太网或以太网VLAN PW。经过适当的等待时间后，可通过手动干预或自动方式重新启动PW。请注意，需要仔细配置关机和可能的自动恢复的阈值和时间段。这对于避免由于临时拥塞而导致的服务损失以及防止拥塞和停止状态之间的振荡是必要的。
This specification offers no congestion control and is not TCP friendly [TFRC]. Future works for PW congestion control (being studied by the PWE3 Working Group) will provide congestion control for all PW types including Ethernet and Ethernet VLAN PWs.
此规范不提供拥塞控制，并且不支持TCP[TFRC]。PW拥塞控制的未来工作（由PWE3工作组研究）将为所有PW类型提供拥塞控制，包括以太网和以太网VLAN PW。
Ethernet over L2TPv3 is subject to all of the general security considerations outlined in [RFC3931].
L2TPv3上的以太网应遵守[RFC3931]中概述的所有一般安全注意事项。
The signaling mechanisms defined in this document rely upon the following Ethernet Pseudowire Types (see Pseudowire Capabilities List as defined in 5.4.3 of [RFC3931] and L2TPv3 Pseudowire Types in 10.6 of [RFC3931]), which were allocated by the IANA (number space created as part of publication of [RFC3931]):
本文件中定义的信令机制依赖于IANA分配的以下以太网伪线类型（参见[RFC3931]第5.4.3节中定义的伪线能力列表和[RFC3931]第10.6节中定义的L2TPv3伪线类型）（作为[RFC3931]发布的一部分创建的数字空间）：
Pseudowire Types
----------------
0x0004 Ethernet VLAN Pseudowire Type
0x0005 Ethernet Pseudowire Type
Pseudowire Types
----------------
0x0004 Ethernet VLAN Pseudowire Type
0x0005 Ethernet Pseudowire Type
The following is the complete list of contributors to this document.
以下是本文档的完整贡献者列表。
Rahul Aggarwal Juniper Networks
Rahul Aggarwal Juniper网络
Xipeng Xiao Riverstone Networks
西鹏小河通网络
W. Mark Townsley Stewart Bryant Maria Alice Dos Santos Cisco Systems
W.马克·汤斯利·斯图尔特·布莱恩特·玛丽亚·爱丽丝·多斯桑托斯思科系统公司
Cheng-Yin Lee Alcatel
李正银阿尔卡特
Tissa Senevirathne Consultant
Tissa Senevirathne顾问公司
Mitsuru Higashiyama Anritsu Corporation
东山安立株式会社
This RFC evolved from the document, "Ethernet Pseudo Wire Emulation Edge-to-Edge". We would like to thank its authors, T.So, X.Xiao, L. Anderson, C. Flores, N. Tingle, S. Khandekar, D. Zelig and G. Heron for their contribution. We would also like to thank S. Nanji, the author of "Ethernet Service for Layer Two Tunneling Protocol", for writing the first Ethernet over L2TP document.
此RFC是从文档“以太网伪线仿真边缘到边缘”演变而来的。我们要感谢其作者T.苏、X.肖、L.安德森、C.弗洛雷斯、N.廷格尔、S.坎德卡尔、D.泽利格和G.赫隆的贡献。我们还要感谢《第二层隧道协议的以太网服务》的作者S.Nanji，他编写了第一篇L2TP上的以太网文档。
Thanks to Carlos Pignataro for providing a thorough review and helpful input.
感谢Carlos Pignataro提供的全面审查和有用的意见。
[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月。
[RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to-Edge (PWE3) Fragmentation and Reassembly", RFC 4623, August 2006.
[RFC4623]Malis，A.和M.Townsley，“伪线仿真边到边（PWE3）碎片化和重组”，RFC 46232006年8月。
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985]Bryant，S.和P.Pate，“伪线仿真边到边（PWE3）架构”，RFC 39852005年3月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]Floyd，S.，“拥塞控制原则”，BCP 41，RFC 2914，2000年9月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[802.3] IEEE, "IEEE std 802.3 -2005/Cor 1-2006 IEEE Standard for Information Technology - Telecommuincations and Information Exchange Between Systems - Local and Metropolitan Area Networks", IEEE Std 802.3-2005/Cor 1-2006 (Corrigendum to IEEE Std 802.3-2005)
[802.3]IEEE，“IEEE标准802.3-2005/Cor 1-2006 IEEE信息技术标准-系统间远程通信和信息交换-局域网和城域网”，IEEE标准802.3-2005/Cor 1-2006（IEEE标准802.3-2005勘误表）
[802.1Q] IEEE, "IEEE standard for local and metropolitan area networks virtual bridged local area networks", IEEE Std 802.1Q-2005 (Incorporates IEEE Std 802.1Q1998, IEEE Std 802.1u-2001, IEEE Std 802.1v-2001, and IEEE Std 802.1s-2002)
[802.1Q]IEEE，“局域网和城域网的IEEE标准虚拟桥接局域网”，IEEE标准802.1Q-2005（包括IEEE标准802.1Q1998、IEEE标准802.1u-2001、IEEE标准802.1v-2001和IEEE标准802.1s-2002）
[802.1ad] IEEE, "IEEE Std 802.1ad - 2005 IEEE Standard for Local and metropolitan area networks - virtual Bridged Local Area Networks, Amendment 4: Provider Bridges", IEEE Std 802.1ad-2005 (Amendment to IEEE Std 8021Q-2005)
[802.1ad]IEEE，“IEEE标准802.1ad-2005 IEEE局域网和城域网标准-虚拟桥接局域网，修改件4：提供商网桥”，IEEE标准802.1ad-2005（对IEEE标准8021Q-2005的修改）
[TFRC] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 3448, January 2003.
[TFRC]Handley，M.，Floyd，S.，Padhye，J.，和J.Widmer，“TCP友好速率控制（TFRC）：协议规范”，RFC 3448，2003年1月。
Author Information
作者信息
Rahul Aggarwal Juniper Networks 1194 North Mathilda Avenue Sunnyvale, CA 94089
加利福尼亚州桑尼维尔北马蒂尔达大道1194号Rahul Aggarwal Juniper Networks，邮编94089
EMail: rahul@juniper.net
EMail: rahul@juniper.net
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
Maria Alice Dos Santos Cisco Systems 170 W Tasman Dr San Jose, CA 95134
Maria Alice Dos Santos Cisco Systems 170 W Tasman Dr San Jose，加利福尼亚州95134
EMail: mariados@cisco.com
EMail: mariados@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2006).
版权所有（C）IETF信托基金（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, THE IETF TRUST, 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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 currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。