Internet Engineering Task Force (IETF) S. Sivabalan
Request for Comments: 7769 S. Boutros
Category: Standards Track Cisco Systems, Inc.
ISSN: 2070-1721 H. Shah
Ciena Corp.
S. Aldrin
Google Inc.
M. Venkatesan
Comcast
February 2016
Internet Engineering Task Force (IETF) S. Sivabalan
Request for Comments: 7769 S. Boutros
Category: Standards Track Cisco Systems, Inc.
ISSN: 2070-1721 H. Shah
Ciena Corp.
S. Aldrin
Google Inc.
M. Venkatesan
Comcast
February 2016
Media Access Control (MAC) Address Withdrawal over Static Pseudowire
静态伪线上的媒体访问控制（MAC）地址提取
Abstract
摘要
This document specifies a mechanism to signal Media Access Control (MAC) address withdrawal notification using a pseudowire (PW) Associated Channel (ACH). Such notification is useful when statically provisioned PWs are deployed in a Virtual Private LAN Service (VPLS) or Hierarchical Virtual Private LAN Service (H-VPLS) environment.
本文档指定了一种使用伪线（PW）关联通道（ACH）向媒体访问控制（MAC）地址撤回通知发送信号的机制。当静态配置的PW部署在虚拟专用LAN服务（VPLS）或分层虚拟专用LAN服务（H-VPLS）环境中时，此类通知非常有用。
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/rfc7769.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7769.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. MAC Withdraw OAM Message . . . . . . . . . . . . . . . . . . 4
4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Operation of Sender . . . . . . . . . . . . . . . . . . . 6
4.2. Operation of Receiver . . . . . . . . . . . . . . . . . . 7
5. Security Consideration . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6.1. MPLS G-Ach Type . . . . . . . . . . . . . . . . . . . . . 8
6.2. Sequence Number TLV . . . . . . . . . . . . . . . . . . . 8
7. Normative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. MAC Withdraw OAM Message . . . . . . . . . . . . . . . . . . 4
4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Operation of Sender . . . . . . . . . . . . . . . . . . . 6
4.2. Operation of Receiver . . . . . . . . . . . . . . . . . . 7
5. Security Consideration . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6.1. MPLS G-Ach Type . . . . . . . . . . . . . . . . . . . . . 8
6.2. Sequence Number TLV . . . . . . . . . . . . . . . . . . . 8
7. Normative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
An LDP-based MAC address withdrawal mechanism is specified in [RFC4762] to remove dynamically learned MAC addresses when the source of those addresses can no longer forward traffic. This is accomplished by sending an LDP Address Withdraw Message with a MAC List TLV containing the MAC addresses to be removed from all other Provider Edge nodes over the LDP sessions. [RFC7361] describes an optimized MAC withdrawal mechanism that can be used to remove only the set of MAC addresses that need to be relearned in H-VPLS networks. [RFC7361] also describes optimized MAC withdrawal operations in PBB-VPLS networks.
[RFC4762]中规定了一种基于LDP的MAC地址提取机制，用于在动态学习的MAC地址的来源不再能够转发流量时删除这些地址。这是通过发送LDP地址撤回消息来实现的，该消息具有MAC列表TLV，其中包含要通过LDP会话从所有其他提供商边缘节点移除的MAC地址。[RFC7361]描述了一种优化的MAC撤销机制，可用于仅删除H-VPLS网络中需要重新学习的MAC地址集。[RFC7361]还描述了PBB-VPLS网络中优化的MAC撤回操作。
A PW can be signaled via the LDP or can be statically provisioned. In the case of a static PW, an LDP-based MAC withdrawal mechanism cannot be used. This is analogous to the problem and solution described in [RFC6478] where a PW OAM (Operations, Administration, and Maintenance) message has been introduced to carry the PW status TLV using the in-band PW Associated Channel. In this document, we use a PW OAM message to withdraw MAC address(es) learned via a static PW.
PW可以通过LDP发信号，或者可以静态地配置。在静态PW的情况下，不能使用基于LDP的MAC撤回机制。这类似于[RFC6478]中描述的问题和解决方案，其中引入了PW OAM（操作、管理和维护）消息，以使用带内PW相关信道承载PW状态TLV。在本文档中，我们使用PW OAM消息提取通过静态PW获取的MAC地址。
Thus, MAC withdraw signaling for static PW reuses the following concepts:
因此，用于静态PW的MAC撤回信令重用了以下概念：
- in-band signaling mechanisms used by static PW status signaling and
- 静态PW状态信令使用的带内信令机制和
- MAC withdrawal mechanisms described by [RFC4762] and [RFC7361].
- [RFC4762]和[RFC7361]描述的MAC撤回机制。
MAC withdraw signaling is a best effort scheme. It is an attempt to optimize network convergence by reducing blackholes caused by PW failover for protected PWs. The protocol defined in this document addresses possible loss of the MAC withdraw signal due to network congestion, but does not guarantee delivery, as is the case for the LDP-based MAC withdraw signaling. In the event that MAC withdraw signaling does not reach the intended target, the fallback to MAC re-learning due to bi-directional traffic or as a last resort aging out of MAC addresses in the absence of frames from the sources, will resume the traffic via new PW path. Such fallbacks would cause temporary blackouts but does not render a network permanently unusable.
MAC撤回信令是一种尽力而为的方案。它试图通过减少受保护PW的PW故障切换造成的黑洞来优化网络融合。本文件中定义的协议解决了由于网络拥塞可能导致的MAC撤回信号丢失，但不保证传输，基于LDP的MAC撤回信号就是这样。如果MAC撤销信令未达到预期目标，则由于双向通信量或作为在没有来自源的帧的情况下老化MAC地址的最后手段，MAC重新学习的回退将通过新的PW路径恢复通信量。此类回退将导致临时停电，但不会使网络永久不可用。
The following terminology is used in this document:
本文件使用以下术语：
ACK: Acknowledgement for MAC withdraw message
ACK：MAC撤回消息的确认
LDP: Label Distribution Protocol
标签分发协议
MAC: Media Access Control
媒体访问控制
MPLS: Multiprotocol Label Switching
多协议标签交换
PW: Pseudowire
伪线
PW OAM: PW Operations, Administration, and Maintenance
PW OAM：PW操作、管理和维护
TLV: Type, Length, and Value
TLV：类型、长度和值
VPLS: Virtual Private LAN Services
虚拟专用局域网服务
In addition, 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]中所述进行解释。
LDP provides reliable packet transport for control plackets for dynamic PWs. This can be contrasted with static PWs that rely on retransmission and acknowledgments (ACKs) for reliable OAM packet delivery as described in [RFC6478]. The proposed solution for MAC withdrawal over a static PW also relies on retransmissions and ACKs. However, an ACK is mandatory. A given MAC withdrawal notification is sent as a PW OAM message, and the sender retransmits the message a configured number of times in the absence of an ACK response for the sequence-numbered message. The receiver removes the MAC address(es) for a given sequence-number MAC withdraw signaling message and sends the ACK response. The receipt of the same or lower sequence-number message is responded to with an ACK but does not cause removal of MAC addresses. A new TLV to carry the sequence number has been defined.
LDP为动态PWs的控制标签提供可靠的数据包传输。这可以与静态PWs形成对比，静态PWs依赖于重传和确认（ACKs），以实现[RFC6478]中所述的可靠OAM数据包交付。在静态PW上提出的MAC撤回解决方案还依赖于重传和ack。但是，ACK是强制性的。给定的MAC撤回通知作为PW OAM消息发送，并且发送方在序列号消息没有ACK响应的情况下重新传输消息配置的次数。接收器移除给定序列号MAC撤销信令消息的MAC地址，并发送ACK响应。接收到相同或更低序列号的消息时，将使用ACK进行响应，但不会导致删除MAC地址。定义了一个携带序列号的新TLV。
The format of the MAC address withdraw OAM message is shown in Figure 1. The MAC withdraw PW OAM message follows the same guidelines used in [RFC6478], whereby the first 4 bytes of the OAM message header are followed by a message-specific field and a set of TLVs relevant for the message. Since the MAC withdrawal PW OAM message is not refreshed forever, a MAC address withdraw OAM message MUST contain a "Sequence Number TLV"; otherwise, the entire message is dropped. It
MAC地址撤回OAM消息的格式如图1所示。MAC撤回PW OAM消息遵循[RFC6478]中使用的相同准则，即OAM消息头的前4个字节后面跟着一个消息特定字段和一组与消息相关的TLV。由于MAC撤回PW OAM消息不会永远刷新，因此MAC地址撤回OAM消息必须包含“序列号TLV”；否则，将删除整个消息。信息技术
MAY contain the MAC Flush Parameter TLV defined in [RFC7361] when static PWs are deployed in H-VPLS and PBB-VPLS scenarios. The first 2 bits of the sequence-number TLV are reserved and MUST be set to 0 on transmit and ignored on receipt.
当在H-VPLS和PBB-VPLS场景中部署静态PWs时，可能包含[RFC7361]中定义的MAC刷新参数TLV。序列号TLV的前2位是保留的，传输时必须设置为0，接收时忽略。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | MAC Withdraw OAM Msg (0x28) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | TLV Length |A|R| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Res| Sequence No. TLV (0x1) | Sequence Number TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MAC List TLV |
~ MAC Flush Parameter TLV (optional) ~
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | MAC Withdraw OAM Msg (0x28) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | TLV Length |A|R| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Res| Sequence No. TLV (0x1) | Sequence Number TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MAC List TLV |
~ MAC Flush Parameter TLV (optional) ~
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: MAC Address Withdraw PW OAM Packet Format
图1:MAC地址提取PW OAM数据包格式
In this section, the MAC List TLV and MAC Flush Parameter TLV are collectively referred to as "MAC TLV(s)". The definition and processing rules of the MAC List TLV are described by [RFC4762], and the corresponding rules of the MAC Flush Parameter TLV are governed by [RFC7361].
在本节中，MAC列表TLV和MAC刷新参数TLV统称为“MAC TLV”。MAC列表TLV的定义和处理规则由[RFC4762]描述，MAC刷新参数TLV的相应规则由[RFC7361]管理。
"TLV Length" is the total length of all TLVs in the message, and "Sequence Number TLV Length" is the length of the Sequence Number field.
“TLV长度”是消息中所有TLV的总长度，“序列号TLV长度”是序列号字段的长度。
A single bit (called "A-bit") is set by a receiver to acknowledge receipt and processing of a MAC Address Withdraw OAM Message. In the acknowledge message, with the A-bit set, the MAC TLVs are excluded.
接收器设置单个位（称为“A位”），以确认接收和处理MAC地址撤销OAM消息。在确认消息中，设置了A位后，MAC TLV被排除。
A single bit (called "R-bit") is set to indicate if the sender is requesting reset of the sequence numbers. The sender sets this bit when the pseudowire is restarted and has no local record of previous send and expected receive sequence numbers.
设置单个位（称为“R位”）以指示发送方是否请求重置序列号。发送方在伪线重新启动时设置此位，并且没有以前发送和预期接收序列号的本地记录。
The Sequence Number TLV MUST be the first TLV in the message.
序列号TLV必须是消息中的第一个TLV。
The lack of a reliable transport protocol for the in-band OAM necessitates a presence of sequencing and acknowledgement scheme so that the receiver can recognize newer message from retransmitted older messages. [RFC4385] describes the details of sequence-number handling, which includes overflow detection for a Sequence Number field size of 16 bits. This document leverages the same scheme with the two exemptions:
由于带内OAM缺乏可靠的传输协议，因此必须存在排序和确认方案，以便接收机能够从重新传输的旧消息中识别新消息。[RFC4385]描述了序列号处理的细节，其中包括16位序列号字段大小的溢出检测。本文件利用了相同的方案和两项豁免：
- the Sequence Number field is of size 32 bits.
- 序列号字段的大小为32位。
- overflow detection is simplified such that a sequence number that exceeds 2,147,483,647 (0x7FFFFFFF) is considered an overflow and reset to 1.
- 溢出检测被简化，因此超过2147483647（0x7FFFFFFF）的序列号被视为溢出并重置为1。
This section describes how the initial MAC Withdraw OAM Messages are sent and retransmitted, as well as how the messages are processed and retransmitted messages are identified.
本节描述如何发送和重新传输初始MAC-draw-OAM消息，以及如何处理消息和识别重新传输的消息。
Each PW is associated with a counter to keep track of the sequence number of the transmitted MAC withdrawal messages. Whenever a node sends a new set of MAC TLVs, it increments the transmitted sequence-number counter and includes the new sequence number in the message. The transmit sequence number is initialized to 1 at the onset, after the wrap and after the sequence number reset request receipt. Hence the transmit sequence number is set to 2 in the first MAC withdraw message sent after the sequence number is initialized to 1.
每个PW与计数器相关联，以跟踪发送的MAC撤回消息的序列号。每当节点发送一组新的MAC tlv时，它都会增加发送的序列号计数器，并在消息中包含新的序列号。传输序列号在开始时、包装后和序列号重置请求接收后初始化为1。因此，在序列号被初始化为1之后发送的第一个MAC收回消息中，发送序列号被设置为2。
The sender expects an ACK from the receiver within a time interval we call "Retransmit Time", which can be either a default (1 second) or a configured value. If the ACK does not arrive within the Retransmit Time, the sender retransmits the message with the same sequence number as the original message. The retransmission MUST cease when an ACK is received. In order to avoid continuous retransmissions in the absence of acknowledgements, a method of suppressing retransmissions MUST be implemented. A simple and well-used approach is to cease retransmission after a small number of transmissions. In the absence of an ACK response, a one second retransmission with two retries is RECOMMENDED. However, both the interval and the number of retries are a local matter that present no interworking issues; thus, the operator MAY configure different values. Alternatively, an increasing backoff delay with a larger number of retries MAY be implemented to improve scaling issues. Whilst there are no interworking issues with any of these methods, the implementer must be mindful to not introduce network congestion and must take into
发送方希望在我们称为“重传时间”的时间间隔内收到接收方的ACK，该时间间隔可以是默认值（1秒）或配置值。如果ACK没有在重新传输时间内到达，发送方将使用与原始消息相同的序列号重新传输消息。当接收到ACK时，必须停止重新传输。为了避免在没有确认的情况下连续重传，必须实施抑制重传的方法。一种简单且常用的方法是在少量传输后停止重新传输。在没有ACK响应的情况下，建议进行1秒的重新传输，并重试两次。但是，重试的间隔和次数都是局部问题，不存在互通问题；因此，操作员可以配置不同的值。或者，可以实现具有更多重试次数的增加退避延迟，以改善缩放问题。虽然这些方法中的任何一种都不存在互通问题，但实施者必须注意不要引入网络拥塞，并且必须考虑
account the decaying value of the delayed MAC withdraw signaling against possible relearning due to bidirectional traffic or MAC timeout.
考虑延迟MAC撤销信令的衰减值，以防止由于双向通信量或MAC超时而可能的重新学习。
During the period of retransmission, if a need to send a new MAC withdraw message with updated sequence number arises, then retransmission of the older unacknowledged withdraw message MUST be suspended and retransmit time for the new sequence number MUST be initiated. In essence, a sender engages in retransmission logic only for the most recently sent withdraw message for a given PW.
在重新传输期间，如果需要发送具有更新序列号的新MAC撤回消息，则必须暂停对旧的未确认撤回消息的重新传输，并且必须启动新序列号的重新传输时间。本质上，发送方只对给定PW最近发送的撤销消息进行重传逻辑。
In the event that a pseudowire is deleted and re-added or the router is restarted with configuration, the local node may lose information about the previously sent sequence number. This becomes problematic for the remote peer as it will continue to ignore the received MAC withdraw messages with lower sequence numbers. In such cases, it is desirable to reset the sequence numbers at both ends of the pseudowire. The reset R-bit is set in the first MAC withdraw to notify the remote peer to reset the send and receive sequence numbers. The R-bit must be cleared in subsequent MAC withdraw messages after the acknowledgement is received.
如果删除并重新添加伪线，或者重新启动路由器进行配置，则本地节点可能会丢失有关先前发送的序列号的信息。这对于远程对等方来说是有问题的，因为它将继续忽略接收到的序列号较低的MAC-draw消息。在这种情况下，需要重置伪线两端的序列号。在第一个MAC撤回中设置重置R位，以通知远程对等方重置发送和接收序列号。在收到确认后，必须在随后的MAC撤销消息中清除R位。
Each PW is associated with a register to keep track of the expected sequence number of the MAC withdrawal message and is initialized to 1. Whenever a MAC withdrawal message is received, and if the sequence number on the message is greater than the value in the register, the MAC addresses contained in the MAC TLVs are removed, and the register is updated with the received sequence number. The receiver sends an ACK whose sequence number is the same as that in the received message.
每个PW与寄存器相关联，以跟踪MAC撤回消息的预期序列号，并初始化为1。每当接收到MAC撤销消息时，如果消息上的序列号大于寄存器中的值，则删除MAC TLV中包含的MAC地址，并使用接收到的序列号更新寄存器。接收器发送一个序列号与接收到的消息中的序列号相同的ACK。
If the sequence number in the received message is smaller than or equal to the value in the register, the MAC TLVs are not processed. However, an ACK with the received sequence number MUST be sent as a response. The receiver processes the ACK message as an acknowledgement for all the MAC withdraw messages sent up to the sequence number present in the ACK message and terminates retransmission.
如果接收到的消息中的序列号小于或等于寄存器中的值，则不处理MAC TLV。但是，带有接收序列号的ACK必须作为响应发送。接收机处理ACK消息作为对发送到ACK消息中存在的序列号的所有MAC撤回消息的确认，并终止重传。
The handling of the sequence number is described in Section 3.
第3节描述了序列号的处理。
A MAC withdraw message with the R-bit set MUST be processed by resetting the send and receive sequence number first. The rest of MAC withdraw message processing is performed as described above. The acknowledgement is sent with the R-bit cleared.
必须首先通过重置发送和接收序列号来处理设置了R位的MAC撤销消息。MAC收回消息处理的其余部分如上所述执行。发送确认时清除R位。
The security measures described in [RFC4447], [RFC5085], and [RFC6073] are adequate for the proposed mechanism.
[RFC4447]、[RFC5085]和[RFC6073]中描述的安全措施适用于提议的机制。
IANA has assigned a new channel type (0x0028) from the "MPLS Generalized Associated Channel (G-ACh) Types (including Pseudowire Associated Channel Types)" registry. The description of the new channel type is "MAC Withdraw OAM Message".
IANA已从“MPLS通用关联通道（G-ACh）类型（包括伪线关联通道类型）”注册表中分配了新通道类型（0x0028）。新信道类型的描述是“MAC撤回OAM消息”。
IANA has assigned a new TLV Type (0x0001) from the existing LDP "TLV Type Name Space" registry. The description for the new TLV Type is "Sequence Number TLV".
IANA已从现有LDP“TLV类型名称空间”注册表中分配了新的TLV类型（0x0001）。新TLV类型的描述为“序列号TLV”。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[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, DOI 10.17487/RFC4385, February 2006, <http://www.rfc-editor.org/info/rfc4385>.
[RFC4385]Bryant，S.，Swallow，G.，Martini，L.，和D.McPherson，“用于MPLS PSN的伪线仿真边到边（PWE3）控制字”，RFC 4385，DOI 10.17487/RFC4385，2006年2月<http://www.rfc-editor.org/info/rfc4385>.
[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, DOI 10.17487/RFC4447, April 2006, <http://www.rfc-editor.org/info/rfc4447>.
[RFC4447]Martini，L.，Ed.，Rosen，E.，El Aawar，N.，Smith，T.，和G.Heron，“使用标签分发协议（LDP）的伪线设置和维护”，RFC 4447，DOI 10.17487/RFC4447，2006年4月<http://www.rfc-editor.org/info/rfc4447>.
[RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, <http://www.rfc-editor.org/info/rfc4762>.
[RFC4762]Lasserre，M.，Ed.，和V.Kompella，Ed.，“使用标签分发协议（LDP）信令的虚拟专用LAN服务（VPLS）”，RFC 4762，DOI 10.17487/RFC4762，2007年1月<http://www.rfc-editor.org/info/rfc4762>.
[RFC5085] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, December 2007, <http://www.rfc-editor.org/info/rfc5085>.
[RFC5085]Nadeau，T.，Ed.，和C.Pignataro，Ed.，“伪线虚拟电路连接验证（VCCV）：伪线的控制通道”，RFC 5085，DOI 10.17487/RFC5085，2007年12月<http://www.rfc-editor.org/info/rfc5085>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. Aissaoui, "Segmented Pseudowire", RFC 6073, DOI 10.17487/RFC6073, January 2011, <http://www.rfc-editor.org/info/rfc6073>.
[RFC6073]Martini，L.，Metz，C.，Nadeau，T.，Bocci，M.和M.Aissaoui，“分段伪线”，RFC 6073，DOI 10.17487/RFC6073，2011年1月<http://www.rfc-editor.org/info/rfc6073>.
[RFC6478] Martini, L., Swallow, G., Heron, G., and M. Bocci, "Pseudowire Status for Static Pseudowires", RFC 6478, DOI 10.17487/RFC6478, May 2012, <http://www.rfc-editor.org/info/rfc6478>.
[RFC6478]Martini，L.，Swallow，G.，Heron，G.，和M.Bocci，“静态伪线的伪线状态”，RFC 6478，DOI 10.17487/RFC6478，2012年5月<http://www.rfc-editor.org/info/rfc6478>.
[RFC7361] Dutta, P., Balus, F., Stokes, O., Calvignac, G., and D. Fedyk, "LDP Extensions for Optimized MAC Address Withdrawal in a Hierarchical Virtual Private LAN Service (H-VPLS)", RFC 7361, DOI 10.17487/RFC7361, September 2014, <http://www.rfc-editor.org/info/rfc7361>.
[RFC7361]Dutta，P.，Balus，F.，Stokes，O.，Calvignac，G.，和D.Fedyk，“分层虚拟专用LAN服务（H-VPLS）中优化MAC地址提取的LDP扩展”，RFC 7361，DOI 10.17487/RFC7361，2014年9月<http://www.rfc-editor.org/info/rfc7361>.
Authors' Addresses
作者地址
Siva Sivabalan Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario K2K 3E8 Canada
Siva Sivabalan思科系统公司，加拿大安大略省卡纳塔创新大道2000号K2K 3E8
Email: msiva@cisco.com
Email: msiva@cisco.com
Sami Boutros Cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA 95134 United States
Sami Boutros Cisco Systems，Inc.美国加利福尼亚州圣何塞市西塔斯曼博士170号，邮编95134
Email: sboutros@cisco.com
Email: sboutros@cisco.com
Himanshu Shah Ciena Corp. 3939 North First Street San Jose, CA 95134 United States
Himanshu Shah Ciena公司，美国加利福尼亚州圣何塞北第一街3939号，邮编95134
Email: hshah@ciena.com
Email: hshah@ciena.com
Sam Aldrin Google Inc.
山姆·奥尔德林谷歌公司。
Email: aldrin.ietf@gmail.com
Email: aldrin.ietf@gmail.com
Mannan Venkatesan Comcast 1800 Bishops Gate Blvd Mount Laurel, NJ 08075 United States
Mannan Venkatesan Comcast美国新泽西州劳雷尔山主教门大道1800号，邮编：08075
Email: mannan_venkatesan@cable.comcast.com
Email: mannan_venkatesan@cable.comcast.com