Internet Engineering Task Force (IETF) S. Bryant, Ed.
Request for Comments: 6658 L. Martini
Category: Standards Track G. Swallow
ISSN: 2070-1721 Cisco Systems
A. Malis
Verizon Communications
July 2012
Internet Engineering Task Force (IETF) S. Bryant, Ed.
Request for Comments: 6658 L. Martini
Category: Standards Track G. Swallow
ISSN: 2070-1721 Cisco Systems
A. Malis
Verizon Communications
July 2012
Packet Pseudowire Encapsulation over an MPLS PSN
MPLS PSN上的数据包伪线封装
Abstract
摘要
This document describes a pseudowire mechanism that is used to transport a packet service over an MPLS PSN in the case where the client Label Switching Router (LSR) and the server Provider Edge equipments are co-resident in the same equipment. This pseudowire mechanism may be used to carry all of the required layer 2 and layer 3 protocols between the pair of client LSRs.
本文档描述了在客户机标签交换路由器（LSR）和服务器提供商边缘设备共同驻留在同一设备中的情况下，用于通过MPLS PSN传输分组服务的伪线机制。该伪线机制可用于在客户端lsr对之间承载所有所需的第2层和第3层协议。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6658.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6658.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Network Reference Model . . . . . . . . . . . . . . . . . . . 4
3. Client Network-Layer Model . . . . . . . . . . . . . . . . . . 5
4. Forwarding Model . . . . . . . . . . . . . . . . . . . . . . . 5
5. Packet PW Encapsulation . . . . . . . . . . . . . . . . . . . 7
6. Ethernet and IEEE 802.1 Functional Restrictions . . . . . . . 8
7. Congestion Considerations . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . . 9
Appendix A. Encapsulation Approaches Considered . . . . . . . . . 11
A.1. A Protocol Identifier in the Control Word . . . . . . . . 11
A.2. PID Label . . . . . . . . . . . . . . . . . . . . . . . . 12
A.3. Parallel PWs . . . . . . . . . . . . . . . . . . . . . . . 13
A.4. Virtual Ethernet . . . . . . . . . . . . . . . . . . . . . 13
A.5. Recommended Encapsulation . . . . . . . . . . . . . . . . 14
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Network Reference Model . . . . . . . . . . . . . . . . . . . 4
3. Client Network-Layer Model . . . . . . . . . . . . . . . . . . 5
4. Forwarding Model . . . . . . . . . . . . . . . . . . . . . . . 5
5. Packet PW Encapsulation . . . . . . . . . . . . . . . . . . . 7
6. Ethernet and IEEE 802.1 Functional Restrictions . . . . . . . 8
7. Congestion Considerations . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . . 9
Appendix A. Encapsulation Approaches Considered . . . . . . . . . 11
A.1. A Protocol Identifier in the Control Word . . . . . . . . 11
A.2. PID Label . . . . . . . . . . . . . . . . . . . . . . . . 12
A.3. Parallel PWs . . . . . . . . . . . . . . . . . . . . . . . 13
A.4. Virtual Ethernet . . . . . . . . . . . . . . . . . . . . . 13
A.5. Recommended Encapsulation . . . . . . . . . . . . . . . . 14
There is a need to provide a method of carrying a packet service over an MPLS PSN in a way that provides isolation between the two networks. The server MPLS network may be an MPLS network or a network conforming to the MPLS Transport Profile (MPLS-TP) [RFC5317]. The client may also be either an MPLS network or a network conforming to the MPLS-TP. Considerations regarding the use of an MPLS network as a server for an MPLS-TP network are outside the scope of this document.
需要提供一种通过MPLS PSN承载分组服务的方法，该方法在两个网络之间提供隔离。服务器MPLS网络可以是MPLS网络或符合MPLS传输配置文件（MPLS-TP）[RFC5317]的网络。客户端还可以是MPLS网络或符合MPLS-TP的网络。关于使用MPLS网络作为MPLS-TP网络的服务器的注意事项不在本文档的范围内。
Where the client equipment is connected to the server equipment via a physical interface, the same data-link type must be used to attach the clients to the Provider Edge (PE) equipments, and a pseudowire (PW) of the same type as the data-link must be used [RFC3985]. The reason that interworking between different physical and data-link attachment types is specifically disallowed in the pseudowire architecture is because this is a complex task and not a simple bit-mapping exercise. The interworking is not limited to the physical and data-link interfaces and the state-machines. It also requires a compatible approach to the formation of the adjacencies between attached client network equipment. As an example, the reader should consider the differences between router adjacency formation on a point-to-point link compared to a multipoint-to-multipoint interface (e.g., Ethernet).
如果客户端设备通过物理接口连接到服务器设备，则必须使用相同的数据链路类型将客户端连接到提供商边缘（PE）设备，并且必须使用与数据链路相同类型的伪线（PW）[RFC3985]。pseudowire体系结构中特别禁止不同物理和数据链路连接类型之间的互通，因为这是一项复杂的任务，而不是简单的位映射练习。互通不限于物理和数据链路接口以及状态机。它还需要一种兼容的方法来形成连接的客户端网络设备之间的邻接。作为一个例子，读者应该考虑点对点链路上的路由器邻接形成与多点到多点接口（例如，以太网）之间的差异。
A further consideration is that two adjacent MPLS Label Switching Routers (LSRs) do not simply exchange MPLS packets. They exchange IP packets for adjacency formation, control, routing, label exchange, management, and monitoring purposes. In addition, they may exchange data-link packets as part of routing (e.g., IS-IS Hellos and IS-IS Link State Packets) and for Operations, Administration, and Maintenance (OAM) purposes such as the Link-Layer Discovery Protocol [IEEE.802.1AB.2009]. Thus, the two clients require an attachment mechanism that can be used to multiplex a number of protocols. In addition, it is essential to the correct operation of the network layer that all of these protocols fate share.
进一步考虑的是，两个相邻的MPLS标签交换路由器（LSR）并不简单地交换MPLS数据包。它们交换IP数据包用于邻接形成、控制、路由、标签交换、管理和监视目的。此外，它们可以交换数据链路分组作为路由的一部分（例如，IS-IS Hellos和IS-IS链路状态分组），并用于操作、管理和维护（OAM）目的，例如链路层发现协议[IEEE.802.1AB.2009]。因此，这两个客户端需要一种连接机制，该机制可用于多路传输多个协议。此外，所有这些协议共享对网络层的正确操作至关重要。
Where the client LSR and server PE are co-located in the same equipment, the data-link layer can be simplified to a point-to-point Ethernet used to multiplex the various data-link types onto a pseudowire. This is the method described in this document.
当客户端LSR和服务器PE位于同一设备中时，数据链路层可以简化为用于将各种数据链路类型多路复用到伪线上的点对点以太网。这是本文档中描述的方法。
Appendix A provides information on alternative approaches to providing a packet PW that were considered by the PWE3 Working Group and the reasons for using the method defined in this specification.
附录A提供了PWE3工作组考虑的提供数据包PW的替代方法的信息，以及使用本规范中定义的方法的原因。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The network reference model for the packet pseudowire operating in an MPLS network is shown in Figure 1. This is an extension of Figure 3 "Pre-processing within the PWE3 Network Reference Model" from [RFC3985].
在MPLS网络中运行的分组伪线的网络参考模型如图1所示。这是[RFC3985]图3“PWE3网络参考模型内的预处理”的扩展。
PW PW
End Service End Service
| |
|<------- Pseudowire ------->|
| |
| Server |
| |<- PSN Tunnel ->| |
| V V |
------- +-----+-----+ +-----+-----+ -------
) | | |================| | | (
Client ) | MPLS| PE1 | PW1 | PE2 | MPLS| ( Client
MPLS PSN )+ LSR1+............................+ LSR2+( MPLS PSN
) | | | | | | (
) | | |================| | | (
------- +-----+-----+ +-----+-----+ --------
^ ^
| |
| |
|<---- Emulated Service----->|
| |
Virtual physical Virtual physical
termination termination
PW PW
End Service End Service
| |
|<------- Pseudowire ------->|
| |
| Server |
| |<- PSN Tunnel ->| |
| V V |
------- +-----+-----+ +-----+-----+ -------
) | | |================| | | (
Client ) | MPLS| PE1 | PW1 | PE2 | MPLS| ( Client
MPLS PSN )+ LSR1+............................+ LSR2+( MPLS PSN
) | | | | | | (
) | | |================| | | (
------- +-----+-----+ +-----+-----+ --------
^ ^
| |
| |
|<---- Emulated Service----->|
| |
Virtual physical Virtual physical
termination termination
Figure 1: Packet PW Network Reference Model
图1：包PW网络参考模型
In this model, the LSRs (LSR1 and LSR2) are part of the client MPLS PSN. The PEs (PE1 and PE2) are part of the server PSN that is to be used to provide connectivity between the client LSRs. The attachment circuit that is used to connect the MPLS LSRs to the PEs is a virtual interface within the equipment. A packet pseudowire is used to provide connectivity between these virtual interfaces. This packet pseudowire is used to transport all of the required layer 2 and layer 3 protocols between LSR1 and LSR2.
在此模型中，LSR（LSR1和LSR2）是客户端MPLS PSN的一部分。PEs（PE1和PE2）是服务器PSN的一部分，用于提供客户端LSR之间的连接。用于将MPLS LSR连接到PEs的连接电路是设备内的虚拟接口。数据包伪线用于提供这些虚拟接口之间的连接。此数据包伪线用于在LSR1和LSR2之间传输所有必需的第2层和第3层协议。
The packet PW appears as a single point-to-point link to the client layer. Network-layer adjacency formation and maintenance between the client equipments will follow the normal practice needed to support the required relationship in the client layer. The assignment of metrics for this point-to-point link is a matter for the client layer. In a hop-by-hop routing network, the metrics would normally be assigned by appropriate configuration of the embedded client network-layer equipment (e.g., the embedded client LSR). Where the client was using the packet PW as part of a traffic-engineered path, it is up to the operator of the client network to ensure that the server-layer operator provides the necessary service-level agreement.
数据包PW显示为到客户端层的单点对点链路。客户端设备之间的网络层邻接形成和维护将遵循支持客户端层所需关系所需的正常实践。此点到点链接的指标分配由客户端层负责。在逐跳路由网络中，通常通过嵌入式客户端网络层设备（例如，嵌入式客户端LSR）的适当配置来分配度量。当客户机使用数据包PW作为流量工程路径的一部分时，由客户机网络的运营商确保服务器层运营商提供必要的服务级别协议。
The packet PW forwarding model is illustrated in Figure 2. The forwarding operation can be likened to a virtual private network (VPN), in which a forwarding decision is first taken at the client layer, an encapsulation is applied, and then a second forwarding decision is taken at the server layer.
包PW转发模型如图2所示。转发操作可以类似于虚拟专用网（VPN），其中首先在客户端层做出转发决策，应用封装，然后在服务器层做出第二个转发决策。
+------------------------------------------------+
| |
| +--------+ +--------+ |
| | | Pkt +-----+ | | |
------+ +---------+ PW1 +--------+ +------
| | Client | AC +-----+ | Server | |
Client | | LSR | | LSR | | Server
Network | | | Pkt +-----+ | | | Network
------+ +---------+ PW2 +--------+ +------
| | | AC +-----+ | | |
| +--------+ +--------+ |
| |
+------------------------------------------------+
+------------------------------------------------+
| |
| +--------+ +--------+ |
| | | Pkt +-----+ | | |
------+ +---------+ PW1 +--------+ +------
| | Client | AC +-----+ | Server | |
Client | | LSR | | LSR | | Server
Network | | | Pkt +-----+ | | | Network
------+ +---------+ PW2 +--------+ +------
| | | AC +-----+ | | |
| +--------+ +--------+ |
| |
+------------------------------------------------+
Figure 2: Packet PW Forwarding Model
图2：包PW转发模型
A packet PW PE comprises three components: the client LSR, a PW processor, and a server LSR. Note that [RFC3985] does not formally indicate the presence of the server LSR because it does not concern itself with the server layer. However it is useful in this document to recognize that the server LSR exists.
分组PW-PE包括三个组件：客户端LSR、PW处理器和服务器LSR。请注意，[RFC3985]没有正式指示服务器LSR的存在，因为它与服务器层无关。但是，在本文档中，识别服务器LSR的存在非常有用。
It may be useful to first recall the operation of a layer 2 PW such as an Ethernet PW [RFC4448] within this model. The client LSR is not present, and packets arrive directly on the attachment circuit (AC) that is part of the client network. The PW function undertakes any
首先回顾该模型中的第2层PW（如以太网PW[RFC4448]）的操作可能很有用。客户端LSR不存在，数据包直接到达作为客户端网络一部分的连接电路（AC）。PW职能部门承担任何
header processing, if configured to do so; it then optionally pushes the PW control word (CW) and finally pushes the PW label. The PW function then passes the packet to the LSR function, which pushes the label needed to reach the egress PE and forwards the packet to the next hop in the server network. At the egress PE, the packet typically arrives with the PW label at the top of the stack; the packet is thus directed to the correct PW instance. The PW instance performs any required reconstruction using, if necessary, the CW, and the packet is sent directly to the attachment circuit.
标题处理，如果配置为这样做；然后它选择性地推送PW控制字（CW），最后推送PW标签。然后，PW函数将数据包传递给LSR函数，LSR函数推送到达出口PE所需的标签，并将数据包转发到服务器网络中的下一跳。在出口PE处，分组通常到达时，PW标签位于栈的顶部；因此，数据包被定向到正确的PW实例。PW实例在必要时使用CW执行任何所需的重构，并且包被直接发送到连接电路。
Now let us consider the case of client-layer MPLS traffic being carried over a packet PW. An LSR belonging to the client layer is embedded within the PE equipment. This is a type of native service processing element [RFC3985]. The client LSR determines the next hop in the client layer, and pushes the label needed by the next hop in the client layer. It then encapsulates the packet in an Ethernet header setting the Ethertype to MPLS, and the client LSR passes the packet to the correct PW instance. The PW instance then proceeds as defined for an Ethernet PW [RFC4448] by optionally pushing the control word, then pushing the PW label, and finally handing the packet to the server-layer LSR for delivery to the egress PE in the server layer.
现在让我们考虑客户端层MPLS流量在分组PW上传输的情况。属于客户端层的LSR嵌入在PE设备中。这是一种本机服务处理元素[RFC3985]。客户端LSR确定客户端层中的下一个跃点，并在客户端层中推送下一个跃点所需的标签。然后，它将数据包封装在以太网报头中，将Ethertype设置为MPLS，客户端LSR将数据包传递给正确的PW实例。然后，PW实例按照以太网PW[rfc448]的定义继续进行，可选地推送控制字，然后推送PW标签，最后将分组交给服务器层LSR，以便传递给服务器层中的出口PE。
At the egress PE in the server layer, the packet is first processed by the server LSR, which uses the PW label to pass the packet to the correct PW instance. This PW instance processes the packet as described in [RFC4448]. The resultant Ethernet encapsulated client packet is then passed to the egress client LSR, which then processes the packet in the normal manner.
在服务器层的出口PE处，包首先由服务器LSR处理，它使用PW标签将包传递到正确的PW实例。此PW实例按照[RFC4448]中所述处理数据包。生成的以太网封装客户端数据包随后被传递到出口客户端LSR，出口客户端LSR随后以正常方式处理该数据包。
Note that although the description above is written in terms of the behavior of an MPLS LSR, the processing model would be similar for an IP packet or any other protocol type.
注意，尽管上面的描述是根据MPLS LSR的行为编写的，但是对于IP分组或任何其他协议类型，处理模型将类似。
Note that the semantics of the PW between the client LSRs is a point-to-point link.
请注意，客户端LSR之间的PW语义是一个点对点链接。
The client network-layer packet encapsulation into a packet PW is shown in Figure 3.
客户机网络层数据包封装到数据包PW中如图3所示。
+-------------------------------+
| Client |
| Network-Layer |
| Packet | n octets
| |
+-------------------------------+
| |
| Ethernet | 14 octets
| Header |
| +---------------+
| |
+---------------+---------------+
| Optional Control Word | 4 octets
+-------------------------------+
| PW Label | 4 octets
+-------------------------------+
| Server MPLS Tunnel Label(s) | n*4 octets (4 octets per label)
+-------------------------------+
+-------------------------------+
| Client |
| Network-Layer |
| Packet | n octets
| |
+-------------------------------+
| |
| Ethernet | 14 octets
| Header |
| +---------------+
| |
+---------------+---------------+
| Optional Control Word | 4 octets
+-------------------------------+
| PW Label | 4 octets
+-------------------------------+
| Server MPLS Tunnel Label(s) | n*4 octets (4 octets per label)
+-------------------------------+
Figure 3: Packet PW Encapsulation
图3：包PW封装
This conforms to the PW protocols stack as defined in [RFC4448]. The protocol stack is unremarkable except to note that the stack does not retain 32-bit alignment between the virtual Ethernet header and the PW optional control word (or the PW label when the optional components are not present in the PW header). This loss of 32 bits of alignment is necessary to preserve backwards compatibility with the Ethernet PW design [RFC4448]
这符合[RFC4448]中定义的PW协议栈。协议栈不引人注目，但需要注意的是，协议栈没有在虚拟以太网报头和PW可选控制字（或PW报头中不存在可选组件时的PW标签）之间保持32位对齐。这种32位对齐的丢失对于保持与以太网PW设计的向后兼容性是必要的[RFC4448]
Ethernet Raw Mode (PW type 5) MUST be used for the packet PW.
以太网原始模式（PW类型5）必须用于数据包PW。
The PEs MAY use a local Ethernet address for the Ethernet header used to encapsulate the client network-layer packet or MAY use the special Ethernet addresses "PacketPWEthA" or "PacketPWEthB" as described below.
PEs可以使用用于封装客户端网络层分组的以太网报头的本地以太网地址，或者可以使用如下所述的特殊以太网地址“PacketPWEthA”或“PacketPWEthB”。
IANA has allocated two unicast Ethernet addresses [RFC5342] for use with this protocol, referred to as "PacketPWEthA" and "PacketPWEthB". Where [RFC4447] signaling is used to set up the PW, the LDP peers numerically compare their IP addresses. The LDP PE with the higher-value IP address will use PacketPWEthA, whilst the LDP peer with the lower-value IP address uses PacketPWEthB.
IANA分配了两个单播以太网地址[RFC5342]用于该协议，称为“PacketPWEthA”和“PacketPWEthB”。当[RFC4447]信令用于设置PW时，LDP对等方以数字方式比较其IP地址。具有较高值IP地址的LDP PE将使用PacketPWEthA，而具有较低值IP地址的LDP对等方将使用PacketPWEthB。
Where no signaling PW protocol is used, suitable Ethernet addresses MUST be configured at each PE.
如果未使用信令PW协议，则必须在每个PE处配置合适的以太网地址。
Although this PW represents a point-to-point connection, the use of a multicast destination address in the Ethernet encapsulation is REQUIRED by some client-layer protocols. Peers MUST be prepared to handle a multicast destination address in the Ethernet encapsulation.
尽管此PW表示点对点连接，但某些客户端层协议要求在以太网封装中使用多播目标地址。对等方必须准备好处理以太网封装中的多播目标地址。
The use of Ethernet as the encapsulation mechanism for traffic between the server LSRs is a convenience based on the widespread availability of existing hardware. In this application, there is no requirement for any Ethernet feature other than its protocol multiplexing capability. Thus, for example, a server LSR is not required to implement the Ethernet OAM.
基于现有硬件的广泛可用性，使用以太网作为服务器LSR之间流量的封装机制是一种方便。在此应用程序中，除了协议多路复用功能外，不需要任何以太网功能。因此，例如，实现以太网OAM不需要服务器LSR。
The use and applicability of VLANs, IEEE 802.1p, and IEEE 802.1Q tagging between PEs is not supported.
PEs之间不支持VLAN、IEEE 802.1p和IEEE 802.1Q标记的使用和适用性。
Point-to-multipoint and multipoint-to-multipoint operation of the virtual Ethernet is not supported.
不支持虚拟以太网的点对多点和多点对多点操作。
A packet pseudowire is normally used to carry IP, MPLS and their associated support protocols over an MPLS network. There are no congestion considerations beyond those that ordinarily apply to an IP or MPLS network. Where the packet protocol being carried is not IP or MPLS and the traffic volumes are greater than that ordinarily associated with the support protocols in an IP or MPLS network, the congestion considerations developed for PWs apply [RFC3985] [RFC5659].
包伪线通常用于通过MPLS网络承载IP、MPLS及其相关支持协议。除了通常应用于IP或MPLS网络之外，没有其他拥塞考虑。如果正在承载的分组协议不是IP或MPLS，并且通信量大于通常与IP或MPLS网络中的支持协议相关联的通信量，则为PWs制定的拥塞注意事项适用[RFC3985][RFC5659]。
The virtual Ethernet approach to packet PW introduces no new security risks. A more detailed discussion of pseudowire security is given in [RFC3985], [RFC4447], and [RFC3916].
包PW的虚拟以太网方法不会带来新的安全风险。[RFC3985]、[RFC4447]和[RFC3916]中对伪线安全性进行了更详细的讨论。
IANA has allocated two Ethernet unicast addresses from "IANA Unicast 48-bit MAC Addresses".
IANA已从“IANA单播48位MAC地址”中分配了两个以太网单播地址。
Address Usage Reference
------------------- ---------------- ---------
00-00-5E-00-52-00 PacketPWEthA [RFC6658]
00-00-5E-00-52-01 PacketPWEthB [RFC6658]
Address Usage Reference
------------------- ---------------- ---------
00-00-5E-00-52-00 PacketPWEthA [RFC6658]
00-00-5E-00-52-01 PacketPWEthB [RFC6658]
The authors acknowledge the contributions made to this document by Sami Boutros, Giles Herron, Siva Sivabalan, and David Ward.
作者感谢Sami Boutros、Giles Herron、Siva Sivabalan和David Ward对本文件的贡献。
[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月。
[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4447]Martini，L.，Rosen，E.，El Aawar，N.，Smith，T.，和G.Heron，“使用标签分发协议（LDP）的伪线设置和维护”，RFC 4447，2006年4月。
[RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006.
[RFC4448]Martini，L.，Rosen，E.，El Aawar，N.，和G.Heron，“通过MPLS网络传输以太网的封装方法”，RFC 4448，2006年4月。
[RFC5342] Eastlake, D., "IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters", BCP 141, RFC 5342, September 2008.
[RFC5342]Eastlake，D.，“IEEE802参数的IANA考虑因素和IETF协议使用”，BCP 141，RFC 5342，2008年9月。
[IEEE.802.1AB.2009] Institute of Electrical and Electronics Engineers, "IEEE Standard for Local and Metropolitan Area Networks -- Station and Media Access Control Connectivity Discovery", IEEE Standard 802.1AB, 2009.
[IEEE.802.1AB.2009]电气和电子工程师协会，“局域网和城域网IEEE标准——站点和媒体访问控制连接发现”，IEEE标准802.1AB，2009年。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[RFC3916] Xiao, X., McPherson, D., and P. Pate, "Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916, September 2004.
[RFC3916]Xiao，X.，McPherson，D.，和P.Pate，“伪线仿真边到边（PWE3）的要求”，RFC 39162004年9月。
[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月。
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006.
[RFC4385]Bryant，S.，Swallow，G.，Martini，L.，和D.McPherson，“用于MPLS PSN的伪线仿真边到边（PWE3）控制字”，RFC 43852006年2月。
[RFC5317] Bryant, S. and L. Andersson, "Joint Working Team (JWT) Report on MPLS Architectural Considerations for a Transport Profile", RFC 5317, February 2009.
[RFC5317]Bryant，S.和L.Andersson，“联合工作组（JWT）关于传输配置文件的MPLS体系结构考虑的报告”，RFC 53172009年2月。
[RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, October 2009.
[RFC5659]Bocci，M.和S.Bryant，“多段伪线边到边仿真的体系结构”，RFC 5659，2009年10月。
[RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010.
[RFC5921]Bocci，M.，Bryant，S.，Frost，D.，Levrau，L.，和L.Berger，“传输网络中MPLS的框架”，RFC 59212010年7月。
A number of approaches to the design of a packet pseudowire (PW) were investigated by the PWE3 Working Group and were discussed in IETF meetings and on the PWE3 list. This section describes the approaches that were analyzed and the technical issues that the authors took into consideration in arriving at the approach described in the main body of this document. This appendix is provided so that engineers considering alternative optimizations can have access to the rationale for the selection of the approach described in this document.
PWE3工作组对包伪线（PW）设计的许多方法进行了研究，并在IETF会议和PWE3列表中进行了讨论。本节描述了分析的方法以及作者在得出本文件主体部分所述方法时考虑的技术问题。提供本附录是为了使考虑替代优化的工程师能够了解本文件中所述方法选择的基本原理。
In a typical network, there are usually no more that four network-layer protocols that need to be supported: IPv4, IPv6, MPLS, and Connectionless Network Service (CLNS). However, any solution needs to be scalable to a larger number of protocols. The approaches considered in this appendix all satisfy this minimum requirement but vary in their ability to support larger numbers of network-layer protocols.
在一个典型的网络中，通常只需要支持四个网络层协议：IPv4、IPv6、MPLS和无连接网络服务（CLNS）。但是，任何解决方案都需要可扩展到更多协议。本附录中考虑的方法均满足此最低要求，但在支持大量网络层协议的能力方面有所不同。
Additionally, it is beneficial if the complete set of protocols carried over the network in support of a set of CE peers fate share. It is additionally beneficial if a single OAM session can be used to monitor the behavior of this complete set. During the investigation, various views were expressed as to where these benefits lay on the scale from absolutely required to "nice to have", but in the end, they were not a factor in reaching our conclusion.
此外，如果在网络上承载完整的协议集以支持一组CE对等点，则这是有益的。另外，如果可以使用单个OAM会话来监视此完整集合的行为，这将是非常有益的。在调查过程中，人们对这些好处从绝对必要到“很好拥有”的范围表达了各种观点，但最终，它们并不是我们得出结论的一个因素。
Four candidate approaches were analyzed:
分析了四种候选方法：
1. A protocol identifier (PID) in the PW control word (CW)
1. PW控制字（CW）中的协议标识符（PID）
2. A PID label
2. PID标签
3. Parallel PWs - one per protocol
3. 并行PWs-每个协议一个
4. Virtual Ethernet
4. 虚拟以太网
In this approach, a Protocol Identifier (PID) is included in the PW control word (CW) by appending it to the generic control word [RFC4385] to make a 6-byte CW (it was thought that this approach would include 2 reserved bytes to provide 32-bit alignment, but then this was optimized out). A variant of this is just to use a 2-byte PID without a control word.
在这种方法中，通过将协议标识符（PID）附加到通用控制字[RFC4385]以生成6字节的CW，将其包括在PW控制字（CW）中（人们认为这种方法将包括2个保留字节以提供32位对齐，但随后进行了优化）。这种方法的一种变体就是只使用2字节PID，而不使用控制字。
This is a simple approach and is basically a virtual PPP interface without the PPP control protocol. This has a smaller MTU than, for example, a virtual Ethernet would need; however, in forwarding terms, it is not as simple as the PID label or multiple PW approaches described next and may not be deployable on a number of existing hardware platforms.
这是一种简单的方法，基本上是一个没有PPP控制协议的虚拟PPP接口。这具有比例如虚拟以太网所需的更小的MTU；然而，在转发方面，它不像下面描述的PID标签或多PW方法那样简单，并且可能无法部署在许多现有硬件平台上。
In this approach, the PID is indicated by including a label after the PW label that indicates the protocol type, as shown in Figure 4.
在这种方法中，PID通过在PW标签之后包含一个标签来表示，PW标签指示协议类型，如图4所示。
+-------------------------------+
| Client |
| Network-Layer |
| Packet | n octets
| |
+-------------------------------+
| Optional Control Word | 4 octets
+-------------------------------+
| PID Label (S=1) | 4 octets
+-------------------------------+
| PW Label | 4 octets
+-------------------------------+
| Server MPLS Tunnel Label(s) | n*4 octets (four octets per label)
+-------------------------------+
+-------------------------------+
| Client |
| Network-Layer |
| Packet | n octets
| |
+-------------------------------+
| Optional Control Word | 4 octets
+-------------------------------+
| PID Label (S=1) | 4 octets
+-------------------------------+
| PW Label | 4 octets
+-------------------------------+
| Server MPLS Tunnel Label(s) | n*4 octets (four octets per label)
+-------------------------------+
Figure 4: Encapsulation of a Pseudowire with a Pseudowire Load-Balancing Label
图4：使用伪线负载平衡标签封装伪线
In the PID label approach, a new Label Distribution Protocol (LDP) Forwarding Equivalence Class (FEC) element is used to signal the mapping between protocol type and the PID label. This approach complies with [RFC3031].
在PID标签方法中，使用一个新的标签分发协议（LDP）转发等价类（FEC）元素来表示协议类型和PID标签之间的映射。该方法符合[RFC3031]。
A similar approach to PID label is described in Section 3.4.5 of [RFC5921]. In this case, when the client is a network-layer packet service such as IP or MPLS, a service label and demultiplexer label (which may be combined) are used to provide the necessary identifications needed to carry this traffic over an LSP.
[RFC5921]第3.4.5节描述了PID标签的类似方法。在这种情况下，当客户端是诸如IP或MPLS的网络层分组服务时，服务标签和解复用器标签（可以组合）用于提供通过LSP承载该业务所需的必要标识。
The authors surveyed the hardware designs produced by a number of companies across the industry and concluded that whilst the approach complies with the MPLS architecture, it may conflict with a number of designers' interpretations of the existing MPLS architecture. This led to concerns that the approach may result in unexpected difficulties in the future. Specifically, there was an assumption in many designs that a forwarding decision should be made on the basis
作者调查了行业内多家公司的硬件设计，得出结论认为，虽然该方法符合MPLS体系结构，但可能与许多设计师对现有MPLS体系结构的解释相冲突。这导致了人们的担忧，即该方法可能会在未来造成意想不到的困难。具体地说，在许多设计中都有一个假设，即转发决策应基于
of a single label. Whilst the approach is attractive, it cannot be supported by many commodity chip sets, and this would require new hardware, which would increase the cost of deployment and delay the introduction of a packet PW service.
一个单一的标签。虽然这种方法很有吸引力，但它不能由许多商品芯片组支持，这将需要新的硬件，这将增加部署成本并延迟分组PW服务的引入。
In this approach, one PW is constructed for each protocol type that must be carried between the PEs. Thus, a complete packet PW would consist of a bundle of PWs. This model would be very simple and efficient from a forwarding point of view. The number of parallel PWs required would normally be relatively small. In a typical network, there are usually no more that four network-layer protocols that need to be supported: IPv4, IPv6, MPLS, and CLNS. However, any solution needs to be scalable to a larger number of protocols.
在这种方法中，为PEs之间必须携带的每种协议类型构造一个PW。因此，一个完整的包PW将由一束PW组成。从转发的角度来看，该模型将非常简单和高效。所需的并联PW数量通常相对较少。在一个典型的网络中，通常只需要支持四个网络层协议：IPv4、IPv6、MPLS和CLN。但是，任何解决方案都需要可扩展到更多协议。
There are a number of serious downsides with this approach:
这种方法有许多严重的缺点：
1. From an operational point of view, the lack of fate sharing between the protocol types can lead to complex faults that are difficult to diagnose.
1. 从操作角度来看，协议类型之间缺乏命运共享可能导致难以诊断的复杂故障。
2. There is an undesirable trade-off in the OAM related to the first point. We would have to run an OAM on each PW and bind them together, which leads to significant protocol and software complexity and does not scale well. Alternatively, we would need to run a single OAM session on one of the PWs as a proxy for the others and then diagnose any more complex failures on a case-by-case basis. To some extent, the issue of fate sharing between protocols in the bundle (for example, the assumed fate sharing between CLNS and IP in IS-IS) can be mitigated through the use of Bidirectional Forwarding Detection (BFD).
2. 在与第一点相关的OAM中存在一个不可取的权衡。我们必须在每个PW上运行一个OAM并将它们绑定在一起，这会导致协议和软件的复杂性，并且不能很好地扩展。或者，我们需要在其中一个PW上运行单个OAM会话作为其他PW的代理，然后根据具体情况诊断任何更复杂的故障。在某种程度上，捆绑包中协议之间的命运共享问题（例如，IS-IS中CLN和IP之间假定的命运共享）可以通过使用双向转发检测（BFD）来缓解。
3. The need to configure, manage, and synchronize the behavior of a group of PWs as if they were a single PW leads to an increase in control-plane complexity.
3. 需要将一组PW的行为配置、管理和同步，就像它们是单个PW一样，这会导致控制平面复杂性的增加。
The Parallel PW mechanism is therefore an approach that simplifies the forwarding plane, but only at a cost of a considerable increase in other aspects of the design, in particular, operation of the PW.
因此，并行PW机制是一种简化转发平面的方法，但其代价是在设计的其他方面，特别是PW的操作方面显著增加。
Using a virtual Ethernet to provide a packet PW would require PEs to include a virtual (internal) Ethernet interface and then to use an Ethernet PW [RFC4448] to carry the user traffic. This is conceptually simple and can be implemented today without any further standards action, although there are a number of applicability
使用虚拟以太网提供数据包PW需要PEs包括虚拟（内部）以太网接口，然后使用以太网PW[RFC4448]承载用户流量。这在概念上很简单，今天可以实现，而无需任何进一步的标准操作，尽管有许多适用性
considerations that it are useful to bring to the attention of the community.
有助于引起社会注意的考虑因素。
Conceptually, this is a simple approach, and some deployed equipments can already do this. However, the requirement to run a complete Ethernet adjacency led us to conclude that there was a need to identify a simpler approach. The packets encapsulated in an Ethernet header have a larger MTU than the other approaches, although this is not considered to be an issue on the networks needing to carry packet PWs.
从概念上讲，这是一种简单的方法，一些部署的设备已经可以做到这一点。然而，运行完整以太网邻接的要求使我们得出结论，需要确定一种更简单的方法。封装在以太网报头中的数据包具有比其他方法更大的MTU，尽管这在需要携带数据包PW的网络上不被认为是一个问题。
The virtual Ethernet mechanism was the first approach that the authors considered, before the merits of the other approaches appeared to make them more attractive. As we shall see below, however, the other approaches were not without issues, and it appears that the virtual Ethernet is the preferred approach to providing a packet PW.
在其他方法的优点使其更具吸引力之前，虚拟以太网机制是作者考虑的第一种方法。然而，正如我们将在下文中看到的，其他方法并非没有问题，而且虚拟以太网似乎是提供分组PW的首选方法。
The operational complexity and the breaking of fate-sharing assumptions associated with the parallel PW approach would suggest that this is not an approach that should be further pursued.
与并行PW方法相关的操作复杂性和命运共享假设的打破表明，这不是一种应进一步采用的方法。
The PID label approach gives rise to the concerns that it will break implicit behavioral and label-stack size assumptions in many implementations. Whilst those assumptions may be addressed with new hardware, this would delay the introduction of the technology to the point where it is unlikely to gain acceptance in competition with an approach that needs no new protocol design and is already supportable on many existing hardware platforms.
PID标签方法引起了人们的担忧，即在许多实现中，它会打破隐含的行为和标签堆栈大小假设。虽然这些假设可以通过新硬件解决，但这将推迟技术的引入，使其不太可能在与无需新协议设计且在许多现有硬件平台上已经可支持的方法的竞争中获得认可。
The PID in the CW leads to the most compact protocol stack, is simple, and requires minimal protocol work. However, it is a new forwarding design and, apart from the issue of the larger packet header and the simpler adjacency formation, offers no advantage over the virtual Ethernet.
CW中的PID导致最紧凑的协议栈，非常简单，并且需要最少的协议工作。然而，它是一种新的转发设计，除了更大的数据包报头和更简单的邻接形成问题之外，与虚拟以太网相比没有任何优势。
The above considerations bring us back to the virtual Ethernet, which is a well-known protocol stack with a well-known (internal) client interface. It is already implemented in many hardware platforms and is therefore readily deployable. After considering a number of initially promising alternatives, the authors conclude that the simplicity and existing hardware make the virtual Ethernet approach to the packet PW the most attractive solution.
上述考虑因素将我们带回虚拟以太网，它是一个众所周知的协议栈，具有众所周知的（内部）客户端接口。它已经在许多硬件平台上实现，因此易于部署。在考虑了许多最初有希望的替代方案后，作者得出结论，简单性和现有硬件使包PW的虚拟以太网方法成为最有吸引力的解决方案。
Authors' Addresses
作者地址
Stewart Bryant (editor) Cisco Systems 250, Longwater, Green Park, Reading, Berks RG2 6GB UK
Stewart Bryant（编辑）思科系统250，朗沃特，格林公园，雷丁，伯克斯RG2 6GB英国
EMail: stbryant@cisco.com
EMail: stbryant@cisco.com
Luca Martini Cisco Systems 9155 East Nichols Avenue, Suite 400 Englewood, CO 80112 USA
Luca Martini Cisco Systems美国科罗拉多州恩格尔伍德东尼科尔斯大道9155号400室，邮编：80112
EMail: lmartini@cisco.com
EMail: lmartini@cisco.com
George Swallow Cisco Systems 1414 Massachusetts Ave Boxborough, MA 01719 USA
美国马萨诸塞州博克斯伯勒马萨诸塞大道1414号乔治·斯沃诺思科系统公司01719
EMail: swallow@cisco.com
EMail: swallow@cisco.com
Andrew G. Malis Verizon Communications 60 Sylvan Rd. Waltham, MA 02451 USA
Andrew G.Malis Verizon Communications美国马萨诸塞州沃尔瑟姆西尔文路60号，邮编02451
EMail: andrew.g.malis@verizon.com
EMail: andrew.g.malis@verizon.com