Network Working Group W. Luo
Request for Comments: 4667 Cisco Systems, Inc.
Category: Standards Track September 2006
Network Working Group W. Luo
Request for Comments: 4667 Cisco Systems, Inc.
Category: Standards Track September 2006
Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP)
第2层隧道协议（L2TP）的第2层虚拟专用网络（L2VPN）扩展
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 (L2TP) provides a standard method for setting up and managing L2TP sessions to tunnel a variety of L2 protocols. One of the reference models supported by L2TP describes the use of an L2TP session to connect two Layer 2 circuits attached to a pair of peering L2TP Access Concentrators (LACs), which is a basic form of Layer 2 Virtual Private Network (L2VPN). This document defines the protocol extensions for L2TP to set up different types of L2VPNs in a unified fashion.
第二层隧道协议（L2TP）为设置和管理L2TP会话以隧道各种L2协议提供了一种标准方法。L2TP支持的一个参考模型描述了使用L2TP会话连接两个连接到对等L2TP访问集中器（LAC）的第2层电路，这是第2层虚拟专用网（L2VPN）的基本形式。本文档定义了L2TP的协议扩展，以统一方式设置不同类型的L2VPN。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Specification of Requirements ..............................2
2. Network Reference Model .........................................2
3. Forwarder Identifier ............................................3
4. Protocol Components .............................................4
4.1. Control Messages ...........................................4
4.2. Existing AVPs for L2VPN ....................................4
4.3. New AVPs for L2VPN .........................................5
4.4. AVP Interoperability .......................................7
5. Signaling Procedures ............................................7
5.1. Overview ...................................................7
5.2. Pseudowire Tie Detection ...................................8
5.3. Generic Algorithm ..........................................9
6. IANA Considerations ............................................12
1. Introduction ....................................................2
1.1. Specification of Requirements ..............................2
2. Network Reference Model .........................................2
3. Forwarder Identifier ............................................3
4. Protocol Components .............................................4
4.1. Control Messages ...........................................4
4.2. Existing AVPs for L2VPN ....................................4
4.3. New AVPs for L2VPN .........................................5
4.4. AVP Interoperability .......................................7
5. Signaling Procedures ............................................7
5.1. Overview ...................................................7
5.2. Pseudowire Tie Detection ...................................8
5.3. Generic Algorithm ..........................................9
6. IANA Considerations ............................................12
7. Security Considerations ........................................12
8. Acknowledgement ................................................13
9. References .....................................................13
9.1. Normative References ......................................13
9.2. Informative References ....................................13
7. Security Considerations ........................................12
8. Acknowledgement ................................................13
9. References .....................................................13
9.1. Normative References ......................................13
9.2. Informative References ....................................13
[RFC3931] defines a dynamic tunneling mechanism to carry multiple Layer 2 protocols besides Point-to-Point Protocol (PPP), the only protocol supported in [RFC2661], over a packet-based network. The baseline protocol supports various types of applications, which have been highlighted in the different Layer 2 Tunneling Protocol (L2TP) reference models in [RFC3931]. An L2TP Access Concentrator (LAC) is an L2TP Control Connection Endpoint (LCCE) that cross-connects attachment circuits and L2TP sessions. Layer 2 Virtual Private Network (L2VPN) applications are typically in the scope of the LAC-LAC reference model.
[RFC3931]定义了一种动态隧道机制，用于在基于分组的网络上承载除点对点协议（PPP）（RFC2661中唯一支持的协议）之外的多个第2层协议。基线协议支持各种类型的应用程序，这些应用程序在[RFC3931]中的不同第2层隧道协议（L2TP）参考模型中得到了强调。L2TP访问集中器（LAC）是交叉连接连接连接电路和L2TP会话的L2TP控制连接端点（LCCE）。第2层虚拟专用网络（L2VPN）应用程序通常在LAC-LAC参考模型的范围内。
This document discusses the commonalities and differences among L2VPN applications with respect to using L2TPv3 as the signaling protocol. In this document, the acronym "L2TP" refers to L2TPv3 or L2TP in general.
本文档讨论了L2VPN应用程序在使用L2TPv3作为信令协议方面的共性和差异。在本文件中，缩写词“L2TP”通常指L2TPv3或L2TP。
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 the LAC-LAC reference model, a LAC serves as a cross-connect between attachment circuits and L2TP sessions. Each L2TP session acts as an emulated circuit, also known as pseudowire. A pseudowire is used to bind two "forwarders" together. For different L2VPN applications, different types of forwarders are defined.
在LAC-LAC参考模型中，LAC充当连接电路和L2TP会话之间的交叉连接。每个L2TP会话充当模拟电路，也称为伪线。伪线用于将两个“转发器”绑定在一起。对于不同的L2VPN应用，定义了不同类型的转发器。
In the L2VPN framework [L2VPNFW], a LAC is a Provider Edge (PE) device. LAC and PE are interchangeable terms in the context of this document. Remote systems in the LAC-LAC reference model are Customer Edge (CE) devices.
在L2VPN框架[L2VPNFW]中，LAC是提供商边缘（PE）设备。在本文件中，LAC和PE是可互换的术语。LAC-LAC参考模型中的远程系统是客户边缘（CE）设备。
+----+ L2 +----+ +----+ L2 +----+
| CE |------| PE |....[core network]....| PE |------| CE |
+----+ +----+ +----+ +----+
+----+ L2 +----+ +----+ L2 +----+
| CE |------| PE |....[core network]....| PE |------| CE |
+----+ +----+ +----+ +----+
|<- emulated service ->|
|<----------------- L2 service -------------->|
|<- emulated service ->|
|<----------------- L2 service -------------->|
L2VPN Network Reference Model
L2VPN网络参考模型
In a simple cross-connect application, an attachment circuit is a forwarder directly bound to a pseudowire. It is a one-to-one mapping. Traffic received from the attachment circuit on a local PE is forwarded to the remote PE through the pseudowire. When the remote PE receives traffic from the pseudowire, it forwards the traffic to the corresponding attachment circuit on its end. The forwarding decision is based on the attachment circuit or pseudowire demultiplexing identifier.
在简单的交叉连接应用中，连接电路是直接绑定到伪导线的转发器。这是一对一的映射。从本地PE上的连接电路接收的通信量通过伪线转发到远程PE。当远程PE从伪线接收通信量时，它将通信量转发到其端部的相应连接电路。转发决策基于连接电路或伪线解复用标识符。
With Virtual Private LAN Service (VPLS), a Virtual Switching Instance (VSI) is a forwarder connected to one or more attachment circuits and pseudowires. A single pseudowire is used to connect a pair of VSIs on two peering PEs. Traffic received from an attachment circuit or a pseudowire is first forwarded to the corresponding VSI based on the attachment circuit or pseudowire demultiplexing identifier. The VSI performs additional lookup to determine where to further forward the traffic.
使用虚拟专用LAN服务（VPLS），虚拟交换实例（VSI）是连接到一个或多个连接电路和伪线的转发器。单个伪线用于连接两个对等PE上的一对VSI。从连接电路或伪线接收的业务首先基于连接电路或伪线解复用标识符转发到相应的VSI。VSI执行额外的查找以确定进一步转发流量的位置。
With Virtual Private Wire Service (VPWS), attachment circuits are grouped into "colored pools". Each pool is a forwarder and is connected through a network of point-to-point cross-connects. The data forwarding perspective is identical to the cross-connect application. However, constructing colored pools involves more complicated signaling procedures.
使用虚拟专用线路服务（VPWS），连接线路被分组到“彩色池”中。每个池都是一个转发器，通过点对点交叉连接网络连接。数据转发透视图与交叉连接应用程序相同。然而，构建彩色池涉及更复杂的信号传递过程。
A forwarder identifier is assigned to each forwarder on a given PE and is unique in the context of the PE. It is defined as the concatenation of an Attachment Group Identifier (AGI) and an Attachment Individual Identifier (AII), denoted as <AGI, AII>. The AGI is used to group a set of forwarders together for signaling purposes. An AII is used to distinguish forwarders within a group. AII can be unique on a per-platform or per-group basis.
转发器标识符分配给给定PE上的每个转发器，并且在PE上下文中是唯一的。它被定义为附件组标识符（AGI）和附件个人标识符（AII）的串联，表示为<AGI，AII>。AGI用于将一组转发器组合在一起，以便发送信号。AII用于区分集团内的货运代理。在每个平台或每个组的基础上，所有信息都可以是唯一的。
As far as the signaling procedures are concerned, a forwarder identifier is an arbitrary string of bytes. It is up to implementations to decide the values for AGI and AII.
就信令过程而言，转发器标识符是任意字节串。AGI和AII的值由实现决定。
When connecting two forwarders together, both MUST have the same AGI as part of their forwarder identifiers. The AII of the source forwarder is known as the Source AII (SAII), and the AII of the target forwarder is known as the Target AII (TAII). Therefore, the source forwarder and target forwarder can be denoted as <AGI, SAII> and <AGI, TAII>, respectively.
将两个转发器连接在一起时，两个转发器必须具有相同的AGI作为其转发器标识符的一部分。源转发器的AII称为源AII（SAII），目标转发器的AII称为目标AII（TAII）。因此，源转发器和目标转发器可分别表示为<AGI，SAII>和<AGI，TAII>。
L2TP defines two sets of session management procedures: incoming call and outgoing call. Even though it is entirely possible to use the outgoing call procedures for signaling L2VPNs, the incoming call procedures have some advantages in terms of the relevance of the semantics. [PWE3L2TP] gives more details on why the incoming call procedures are more appropriate for setting up pseudowires.
L2TP定义了两组会话管理过程：传入呼叫和传出呼叫。尽管完全可以使用呼出呼叫过程为L2VPN发信号，但呼入呼叫过程在语义相关性方面具有一些优势。[PWE3L2TP]提供了关于为什么传入呼叫过程更适合设置伪线的更多详细信息。
The signaling procedures for L2VPNs described in the following sections are based on the Control Connection Management and the Incoming Call procedures, defined in Sections 3.3 and 3.4.1 of [RFC3931], respectively. L2TP control message types are defined in Section 3.1 of [RFC3931]. This document references the following L2TP control messages:
以下章节中描述的L2VPN信令程序分别基于[RFC3931]第3.3节和第3.4.1节中定义的控制连接管理和传入呼叫程序。L2TP控制消息类型在[RFC3931]第3.1节中定义。本文档引用了以下L2TP控制消息：
Start-Control-Connection-Request (SCCRQ) Start-Control-Connection-Reply (SCCRP) Incoming-Call-Request (ICRQ) Incoming-Call-Reply (ICRP) Incoming-Call-Connected (ICCN) Set-Link-Info (SLI)
启动控制连接请求（SCCRQ）启动控制连接应答（SCCRP）来电请求（ICRQ）来电应答（ICRP）已连接来电（ICCN）设置链路信息（SLI）
The following Attribute Value Pairs (AVPs), defined in Sections 5.4.3, 5.4.4, and 5.4.5 of [RFC3931], are used for signaling L2VPNs.
[RFC3931]第5.4.3节、第5.4.4节和第5.4.5节中定义的以下属性值对（AVP）用于发送L2VPN信号。
Router ID
路由器标识
The Router ID sent in SCCRQ and SCCRP during control connection setup establishes the unique identity of each PE.
在控制连接设置期间，在SCCRQ和SCCRP中发送的路由器ID建立每个PE的唯一标识。
Pseudowire Capabilities List
伪线能力列表
The Pseudowire Capabilities List sent in the SCCRQ and SCCRP indicates the pseudowire types supported by the sending PE. It merely serves as an advertisement to the receiving PE. Its content should not affect the control connection setup.
SCCRQ和SCCRP中发送的伪线能力列表指示发送PE支持的伪线类型。它只是作为一个广告的接收PE。其内容不应影响控件连接设置。
Before a local PE initiates a session of a particular pseudowire type to a remote PE, it MUST examine whether the remote PE has advertised this pseudowire type in this AVP and SHOULD NOT attempt to initiate the session if the intended pseudowire type is not supported by the remote PE.
在本地PE向远程PE发起特定伪线类型的会话之前，必须检查远程PE是否在此AVP中播发了此伪线类型，如果远程PE不支持预期的伪线类型，则不应尝试发起会话。
Pseudowire Type
假丝型
The Pseudowire Type sent in ICRQ signals the intended pseudowire type to the receiving PE. The receiving PE checks it against its local pseudowire capabilities list. If it finds a match, it responds with an ICRP without a Pseudowire Type AVP, which implicitly acknowledges its acceptance of the intended pseudowire. If it does not find a match, it MUST respond with a Call-Disconnect-Notify (CDN), with an "unsupported pseudowire type" result code.
ICRQ中发送的伪线类型向接收PE发送预期伪线类型的信号。接收PE根据其本地伪线功能列表对其进行检查。如果找到匹配项，它将使用ICRP进行响应，而不使用伪线类型AVP，该类型AVP隐式承认其接受预期的伪线。如果未找到匹配项，则必须使用呼叫断开通知（CDN）和“不支持的伪线类型”结果代码进行响应。
L2-Specific Sublayer
L2特异性亚层
The L2-Specific Sublayer can be sent in ICRQ, ICRP, and ICCN. If the receiving PE supports the specified L2-Specific Sublayer, it MUST include the identified L2-Specific Sublayer in its data packets sent to the sending PE. Otherwise, it MUST reject the connection by sending a CDN to the sending PE.
L2特定子层可以在ICRQ、ICRP和ICCN中发送。如果接收PE支持指定的L2特定子层，则它必须在发送给发送PE的数据包中包含标识的L2特定子层。否则，它必须通过向发送PE发送CDN来拒绝连接。
Circuit Status
电路状态
The Circuit Status is sent in both ICRQ and ICRP to inform the receiving PE about the circuit status on the sending PE. It can also be sent in ICCN and SLI to update the status.
在ICRQ和ICRP中发送电路状态，以通知接收PE发送PE上的电路状态。它也可以通过ICCN和SLI发送，以更新状态。
Remote End Identifier
远程端标识符
The TAII value is encoded in the Remote End ID AVP and sent in ICRQ along with the optional AGI to instruct the receiving PE to bind the proposed pseudowire to the forwarder that matches the specified forwarder identifier.
TAII值在远端ID AVP中编码，并与可选AGI一起在ICRQ中发送，以指示接收PE将建议的伪线绑定到与指定转发器标识符匹配的转发器。
Attachment Group Identifier
附件组标识符
The AGI AVP, Attribute Type 89, is an identifier used to associate a forwarder to a logical group. The AGI AVP is used in conjunction with the Local End ID AVP and Remote End ID AVP, which encode the SAII and TAII, respectively, to identify a specific forwarder. When the AGI AVP is omitted in the control messages or contains a zero-length value, the forwarders are considered to use
AGI AVP属性类型89是用于将转发器与逻辑组关联的标识符。AGI AVP与本地端ID AVP和远程端ID AVP一起使用，分别对SAII和TAII进行编码，以识别特定的转发器。当AGI AVP在控制消息中被省略或包含零长度值时，转发器被视为使用
the default AGI. Note that there is only one designated default AGI value for all forwarders.
默认AGI。请注意，所有转发器只有一个指定的默认AGI值。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 89 | AGI (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 89 | AGI (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The AGI field is a variable-length field. This AVP MAY be present in ICRQ.
AGI字段是一个可变长度字段。该AVP可能存在于ICRQ中。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The hiding of AVP attribute values is defined in Section 5.3 of [RFC3931]. The M bit for this AVP SHOULD be set to 0. The Length (before hiding) of this AVP is 6 octets plus the length of the AGI field.
该AVP可能被隐藏（H位可能为0或1）。[RFC3931]第5.3节定义了AVP属性值的隐藏。此AVP的M位应设置为0。此AVP的长度（隐藏前）为6个八位字节加上AGI字段的长度。
Local End ID
本地端ID
The Local End ID AVP, Attribute Type 90, encodes the SAII value. The SAII may also be used in conjunction with the TAII to detect pseudowire ties. When it is omitted in the control messages, it is assumed that it has the same value as the TAII.
本地端ID AVP属性类型90对SAII值进行编码。SAII还可与TAII一起用于检测假导线扎带。当它在控制消息中被省略时，假定它与TAII具有相同的值。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 90 | SAII (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 90 | SAII (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The SAII field is a variable-length field. This AVP MAY be present in ICRQ.
SAII字段是一个可变长度字段。该AVP可能存在于ICRQ中。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to 0. The Length (before hiding) of this AVP is 6 octets plus the length of the SAII field.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位应设置为0。此AVP的长度（隐藏前）为6个八位字节加上SAII字段的长度。
Interface Maximum Transmission Unit
接口最大传输单元
The Interface Maximum Transmission Unit (MTU) AVP, Attribute Type
接口最大传输单元（MTU）AVP，属性类型
91, indicates the MTU in octets of a packet that can be sent out from the CE-facing interface. The MTU values of a given pseudowire, if advertised in both directions, MUST be identical. If they do not match, the pseudowire SHOULD NOT be established. When this AVP is omitted in the control messages in either direction, it is assumed that the remote PE has the same interface MTU as the local PE for the pseudowire being signaled.
91，表示可从面向CE的接口发送的数据包的MTU（以八位字节为单位）。如果在两个方向上公布，则给定伪导线的MTU值必须相同。如果它们不匹配，则不应建立伪导线。当在任一方向的控制消息中省略该AVP时，假定远程PE具有与被发信号的伪线的本地PE相同的接口MTU。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 91 | Interface MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 91 | Interface MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Interface MTU field is a 2-octet integer value. This AVP MAY be present in ICRQ and ICRP. When a PE receives an Interface MTU AVP with an MTU value different from its own, it MAY respond with a CDN with a new result code indicating the disconnect cause.
接口MTU字段是2个八位整数。该AVP可能存在于ICRQ和ICRP中。当PE接收到MTU值与其自身不同的接口MTU AVP时，它可能会使用CDN响应，并使用新的结果代码指示断开原因。
23 - Mismatching interface MTU
23-不匹配接口MTU
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to 0. The Length (before hiding) of this AVP is 8 octets.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位应设置为0。此AVP的长度（隐藏前）为8个八位字节。
To ensure interoperability, the mandatory (M) bit settings of the existing AVPs used in L2VPN applications should be the same as those specified in [RFC3931]. The generic M-bit processing is described in Section 5.2 of [RFC3931]. Setting the M-bit of the new AVPs to 1 will impair interoperability.
为确保互操作性，L2VPN应用程序中使用的现有AVP的强制（M）位设置应与[RFC3931]中规定的相同。[RFC3931]第5.2节描述了通用M位处理。将新AVP的M位设置为1将损害互操作性。
Assume that a PE assigns a forwarder identifier to one of its local forwarders and that it knows it needs to set up a pseudowire to a remote forwarder on a remote PE that has a certain Forwarder ID. This knowledge can be obtained either through manual configuration or some auto-discovery procedure.
假设一个PE将一个转发器标识符分配给它的一个本地转发器，并且它知道它需要在具有特定转发器ID的远程PE上设置一个到远程转发器的伪线。可以通过手动配置或一些自动发现过程来获取此知识。
Before establishing the intended pseudowire, each pair of peering PEs
在建立预期的伪线之前，每对对等PE
exchanges control connection messages to establish a control connection. Each advertises its supported pseudowire types, as defined in [PWE3IANA], in the Pseudowire Capabilities List AVP.
交换控制连接消息以建立控制连接。每个都在伪线能力列表AVP中公布其支持的伪线类型，如[PWE3IANA]中所定义。
After the control connection is established, the local PE examines whether the remote PE supports the pseudowire type it intends to set up. Only if the remote PE supports the intended pseudowire type should it initiate a pseudowire connection request.
建立控制连接后，本地PE检查远程PE是否支持它打算设置的伪线类型。仅当远程PE支持预期的伪线类型时，才应启动伪线连接请求。
When the local PE receives an ICRQ for a pseudowire connection, it examines the forwarder identifiers encoded in the AGI, SAII, and TAII in order to determine the following:
当本地PE收到用于伪接线的ICRQ时，它检查AGI、SAII和TAII中编码的转发器标识符，以确定以下内容：
- Whether it has a local forwarder with the forwarder identifier value specified in the ICRQ.
- 是否有具有ICRQ中指定的转发器标识符值的本地转发器。
- Whether the remote forwarder with the forwarder identifier specified in the ICRQ is allowed to connect with this local forwarder.
- 是否允许具有ICRQ中指定的转发器标识符的远程转发器连接到此本地转发器。
If both conditions are met, it sends an ICRP to the remote PE to accept the connection request. If either of the two conditions fails, it sends a CDN to the remote PE to reject the connection request.
如果两个条件都满足，它将向远程PE发送ICRP以接受连接请求。如果两个条件中的任何一个失败，它将向远程PE发送CDN以拒绝连接请求。
The local PE can optionally include a result code in the CDN to indicate the disconnect cause. The possible result codes are
本地PE可以选择在CDN中包含结果代码，以指示断开原因。可能的结果代码如下所示
24 - Attempt to connect to non-existent forwarder 25 - Attempt to connect to unauthorized forwarder
24-尝试连接到不存在的转发器25-尝试连接到未经授权的转发器
Conceivably in the network reference models, as either PE may initiate a pseudowire to another PE at any time, the PEs could end up initiating a pseudowire to each other simultaneously. In order to avoid setting up duplicated pseudowires between two forwarders, each PE must be able to independently detect such a pseudowire tie. The following procedures need to be followed to detect a tie:
可以想象，在网络参考模型中，由于任意一个PE可以在任何时候发起到另一个PE的伪线，因此这些PE最终可以同时发起到彼此的伪线。为了避免在两个转发器之间设置重复的伪线，每个PE必须能够独立检测此类伪线接头。检测领带需要遵循以下程序：
If both TAII and SAII are present in the ICRQ, the receiving PE compares the TAII and SAII against the SAII and TAII previously sent to the sending PE. If the received TAII matches the sent SAII and the received SAII matches the sent TAII, a tie is detected.
如果ICRQ中同时存在TAII和SAII，则接收PE将TAII和SAII与之前发送给发送PE的SAII和TAII进行比较。如果接收到的TAII与发送的SAII匹配，并且接收到的SAII与发送的TAII匹配，则检测到平局。
If only the TAII is present in the ICRQ, the SAII is assumed to have the same value as the TAII. The receiving PE compares the received TAII with the SAII that it previously sent to the sending PE. If the
如果ICRQ中仅存在TAII，则假定SAII与TAII具有相同的值。接收PE将接收到的TAII与之前发送给发送PE的SAII进行比较。如果
SAII in that ICRQ is also omitted, then the value encoded in the sent TAII is used for comparison. If they match, a tie is detected.
SAII，因为ICRQ也被省略，所以发送的TAII中编码的值用于比较。如果它们匹配，则检测到平局。
If the AGI is present, it is first prepended to the TAII and SAII values before the tie detection occurs.
如果存在AGI，则在tie检测发生之前，首先将其预先设置为TAII和SAII值。
Once a tie is discovered, the PE uses the standard L2TP tie breaking procedure, as described in Section 5.4.4 of [RFC3931], to disconnect the duplicated pseudowire.
一旦发现接头，PE使用标准L2TP接头断开程序（如[RFC3931]第5.4.4节所述）断开复制假导线。
The following uses a generic algorithm to illustrate the protocol interactions when constructing an L2VPN using L2TP signaling.
以下使用通用算法来说明使用L2TP信令构建L2VPN时的协议交互。
Each PE first forms a list, SOURCE_FORWARDERS, consisting of all local forwarders of a given VPN. Then it puts all local forwarders that need to be interconnected and all remote forwarders of the same VPN into another list, TARGET_FORWARDERS. The formation of the network topology depends on the content in the SOURCE_FORWARDERS and TARGET_FORWARDERS lists. These two lists can be constructed by manual configuration or some auto-discovery procedure.
每个PE首先形成一个列表，即SOURCE_转发器，由给定VPN的所有本地转发器组成。然后，它将所有需要互连的本地转发器和同一VPN的所有远程转发器放入另一个列表中，即TARGET_转发器。网络拓扑的形成取决于源转发器和目标转发器列表中的内容。这两个列表可以通过手动配置或某些自动发现过程构建。
The algorithm is used to set up a full mesh of interconnections between SOURCE_FORWARDERS and TARGET_FORWARDERS. An L2VPN is formed when the algorithm is finished in every participating PE of this L2VPN.
该算法用于在源_转发器和目标_转发器之间建立完整的互连网格。当算法在该L2VPN的每个参与PE中完成时，形成L2VPN。
1. Pick the next forwarder, from SOURCE_FORWARDERS. If no forwarder is available for processing, the processing is complete.
1. 从SOURCE_FORWARDERS中选择下一个转发器。如果没有可供处理的转发器，则处理完成。
2. Pick the next forwarder, from TARGET_FORWARDERS. If no forwarder is available for processing, go back to step 1.
2. 从目标货运代理中选择下一个货运代理。如果没有可用于处理的转发器，请返回步骤1。
3. If the two forwarders are associated with different Router IDs, a pseudowire must be established between them. Proceed to step 6.
3. 如果两个转发器与不同的路由器ID相关联，则必须在它们之间建立伪线。继续执行步骤6。
4. Compare the <AGI, AII> values of the two forwarders. If they match, the source and target forwarders are the same, so no more action is necessary. Go back to step 2.
4. 比较两个转发器的<AGI，AII>值。如果它们匹配，则源转发器和目标转发器是相同的，因此无需执行更多操作。返回到步骤2。
5. As the source and target forwarders both reside on the local PE, no pseudowire is needed. The PE simply creates a local cross-connect between the two forwarders. Go back to step 2.
5. 由于源和目标转发器都位于本地PE上，因此不需要伪线。PE只是在两个转发器之间创建一个本地交叉连接。返回到步骤2。
6. As the source and target forwarders reside on different PEs,
6. 由于源和目标转发器位于不同的PE上，
a pseudowire must be established between them. The PE first examines whether the source forwarder has already established a pseudowire to the target forwarder. If so, go back to step 2.
必须在它们之间建立伪线。PE首先检查源转发器是否已建立到目标转发器的伪线。如果是，请返回步骤2。
7. If no pseudowire is already established between the source and target forwarders, the local PE obtains the address of the remote PE and establishes a control connection to the remote PE if one does not already exist.
7. 如果源转发器和目标转发器之间尚未建立伪线，则本地PE将获取远程PE的地址，并在不存在伪线的情况下建立到远程PE的控制连接。
8. The local PE sends an ICRQ to the remote PE. The AGI, TAII, and SAII values are encoded in the AGI AVP, the Remote End ID AVP, and the Local End ID AVP, respectively.
8. 本地PE向远程PE发送ICRQ。AGI、TAII和SAII值分别编码在AGI AVP、远程端ID AVP和本地端ID AVP中。
9. If the local PE receives a response corresponding to the ICRQ it just sent, proceed to step 10. Otherwise, if the local PE receives an ICRQ from the same remote PE, proceed to step 11.
9. 如果本地PE接收到与其刚发送的ICRQ相对应的响应，则转至步骤10。否则，如果本地PE从同一远程PE接收到ICRQ，则转至步骤11。
10. The local PE receives a response from the remote PE. If it is a CDN, go back to step 2. If it's an ICRP, the local PE binds the source forwarder to the pseudowire and sends an ICCN to the remote PE. Go back to step 2.
10. 本地PE接收来自远程PE的响应。如果是CDN，请返回步骤2。如果是ICRP，本地PE将源转发器绑定到伪线，并向远程PE发送ICCN。返回到步骤2。
11. If the local PE receives an ICRQ from the same remote PE, it needs to perform session tie detection, as described in Section 5.2. If a session tie is detected, the PE performs tie breaking.
11. 如果本地PE收到来自同一远程PE的ICRQ，则需要执行会话连接检测，如第5.2节所述。如果检测到会话连接，PE将执行连接断开。
12. If the local PE loses the tie breaker, it sends a CDN with the result code that indicates that the disconnection is due to losing the tie breaker. Proceed to step 14.
12. 如果本地PE失去了连接断路器，它将发送一个CDN，其结果代码指示断开是由于失去连接断路器造成的。转至步骤14。
13. If the local PE wins the tie breaker, it ignores the remote PE's ICRQ, but acknowledges receipt of the control message and continues waiting for the response from the remote PE. Go to step 10.
13. 如果本地PE赢得平局，它将忽略远程PE的ICRQ，但确认收到控制消息，并继续等待远程PE的响应。转至步骤10。
14. The local PE determines whether it should accept the connection request, as described in Section 5.1. If it accepts the ICRQ, it sends an ICRP to the remote PE.
14. 本地PE决定是否应接受连接请求，如第5.1节所述。如果接受ICRQ，则向远程PE发送ICRP。
15. The local PE receives a response from the remote PE. If it is a CDN, go back to step 2. If it is an ICCN, the local PE binds the source forwarder to the pseudowire, go back to step 2.
15. 本地PE接收来自远程PE的响应。如果是CDN，请返回步骤2。如果是ICCN，则本地PE将源转发器绑定到伪线，返回步骤2。
The following diagram illustrates the above procedure:
下图说明了上述步骤：
---------> Pick Next
| Source Forwarder
| |
| |
| v N
| Found Source Forwarder? ----------> End
| |
| Y |
| v
| Pick Next <--------------------------------
| Target Forwarder |
| | |
| | |
| N v |
-------- Found Target Forwarder? |
| |
Y | |
v Y Y |
Same Router ID? ------> Same Forwarder ID? ------|
| | |
N | N | |
| v |
| Create Local -------|
v Cross-connect |
Pseudowire Already Y |
Established Between -------------------------------|
Source and Target? |
| |
N | |
v |
Local Initiates Pseudowire |
Connection Request to Remote |
| |
| |
v |
-------> Local Wait for Message |
| ----- from Remote -------------- |
| | | |
| | | |
| v v |
| Local Receives Pseudowire Local Receives Pseudowire |
| Connection Request Connection Response |
| from Remote from Remote |
| | | |
| | | |
| v v N |
| Perform Pseudowire Connection Accepted? --------|
| Tie Detection | |
---------> Pick Next
| Source Forwarder
| |
| |
| v N
| Found Source Forwarder? ----------> End
| |
| Y |
| v
| Pick Next <--------------------------------
| Target Forwarder |
| | |
| | |
| N v |
-------- Found Target Forwarder? |
| |
Y | |
v Y Y |
Same Router ID? ------> Same Forwarder ID? ------|
| | |
N | N | |
| v |
| Create Local -------|
v Cross-connect |
Pseudowire Already Y |
Established Between -------------------------------|
Source and Target? |
| |
N | |
v |
Local Initiates Pseudowire |
Connection Request to Remote |
| |
| |
v |
-------> Local Wait for Message |
| ----- from Remote -------------- |
| | | |
| | | |
| v v |
| Local Receives Pseudowire Local Receives Pseudowire |
| Connection Request Connection Response |
| from Remote from Remote |
| | | |
| | | |
| v v N |
| Perform Pseudowire Connection Accepted? --------|
| Tie Detection | |
| | Y | |
| | v |
| | Local Binds Source ---------|
| | Forwarder to Pseudowire |
| | |
| v N N |
| Tie Detected? -----> Accept Remote -----> Reject ------|
| | Connection Request? Remote Request |
| Y | ^ | |
| v | | Y |
| Perform Tie Breaking | ------> Local Binds ----
| | | Source Forwarder
| | | to Pseudowire
| v N |
| Won Tie Breaking? ------> Disconnect
| | Local Connection
| Y |
| v
------ Ignore Remote
Connection Request
| | Y | |
| | v |
| | Local Binds Source ---------|
| | Forwarder to Pseudowire |
| | |
| v N N |
| Tie Detected? -----> Accept Remote -----> Reject ------|
| | Connection Request? Remote Request |
| Y | ^ | |
| v | | Y |
| Perform Tie Breaking | ------> Local Binds ----
| | | Source Forwarder
| | | to Pseudowire
| v N |
| Won Tie Breaking? ------> Disconnect
| | Local Connection
| Y |
| v
------ Ignore Remote
Connection Request
The IANA registry procedure in this document follows that in Section 10 of [RFC3931]. The IANA has assigned the following new values for existing registries managed by IANA.
本文件中的IANA注册程序遵循[RFC3931]第10节。IANA为IANA管理的现有注册中心分配了以下新值。
This document defines three new L2TP control message Attribute Value Pairs (AVPs) that have been assigned by the IANA. These are described in Section 4.3 and are summarized below:
本文档定义了IANA分配的三个新L2TP控制消息属性值对（AVP）。第4.3节对此进行了描述，总结如下：
89 - Attachment Group Identifier 90 - Local End Identifier 91 - Interface Maximum Transmission Unit
89-附件组标识符90-本地端标识符91-接口最大传输单元
Sections 4.3 and 5.1 define three new result codes for the CDN message that have been assigned by the IANA:
第4.3节和第5.1节为IANA分配的CDN消息定义了三个新的结果代码：
23 - Mismatching interface MTU 24 - Attempt to connect to non-existent forwarder 25 - Attempt to connect to unauthorized forwarder
23-接口MTU 24不匹配-尝试连接到不存在的转发器25-尝试连接到未经授权的转发器
This specification does not introduce any additional security considerations beyond those discussed in [RFC3931] and [L2VPNFW].
除[RFC3931]和[L2VPNFW]中讨论的安全注意事项外，本规范未引入任何其他安全注意事项。
The author would like to thank Mark Townsley and Carlos Pignataro for their valuable input.
作者要感谢马克·汤斯利和卡洛斯·皮格纳塔罗的宝贵意见。
[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月。
[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月。
[PWE3IANA] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[PWE3IANA]Martini，L.，“伪线边到边仿真（PWE3）的IANA分配”，BCP 116，RFC 4446，2006年4月。
[L2VPNFW] Andersson L., Ed. and E. Rosen, Ed., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006.
[L2VPNFW]Andersson L.，Ed.和E.Rosen，Ed.，“第二层虚拟专用网络（L2VPN）框架”，RFC 4664，2006年9月。
[PWE3L2TP] W. Townsley, "Pseudowires and L2TPv3", Work in Progress.
[PWE3L2TP]W.Townsley，“伪导线和L2TPv3”，正在进行中。
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
[RFC2661]汤斯利，W.，瓦伦西亚，A.，鲁本斯，A.，帕尔，G.，佐恩，G.，和B.帕尔特，“第二层隧道协议“L2TP”，RFC 26611999年8月。
Author's Address
作者地址
Wei Luo Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
韦洛思科系统有限公司，加利福尼亚州圣何塞市西塔斯曼大道170号，邮编95134
EMail: luo@cisco.com
EMail: luo@cisco.com
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）提供。