Internet Engineering Task Force (IETF) C. Villamizar, Ed.
Request for Comments: 7325 OCCNC
Category: Informational K. Kompella
ISSN: 2070-1721 Juniper Networks
S. Amante
Apple Inc.
A. Malis
Huawei
C. Pignataro
Cisco
August 2014
Internet Engineering Task Force (IETF) C. Villamizar, Ed.
Request for Comments: 7325 OCCNC
Category: Informational K. Kompella
ISSN: 2070-1721 Juniper Networks
S. Amante
Apple Inc.
A. Malis
Huawei
C. Pignataro
Cisco
August 2014
MPLS Forwarding Compliance and Performance Requirements
MPLS转发遵从性和性能要求
Abstract
摘要
This document provides guidelines for implementers regarding MPLS forwarding and a basis for evaluations of forwarding implementations. Guidelines cover many aspects of MPLS forwarding. Topics are highlighted where implementers might otherwise overlook practical requirements that are unstated or underemphasized, or that are optional for conformance to RFCs but often considered mandatory by providers.
本文档为实施者提供了有关MPLS转发的指南，并为转发实施的评估提供了基础。指南涵盖了MPLS转发的许多方面。突出强调了实施者可能忽略未说明或强调不足的实际需求，或者是符合RFC的可选需求，但通常被提供者视为强制性需求的主题。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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/rfc7325.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7325.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束
(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.
(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction and Document Scope . . . . . . . . . . . . . . . 4
1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Use of Requirements Language . . . . . . . . . . . . . . 8
1.3. Apparent Misconceptions . . . . . . . . . . . . . . . . . 9
1.4. Target Audience . . . . . . . . . . . . . . . . . . . . . 10
2. Forwarding Issues . . . . . . . . . . . . . . . . . . . . . . 11
2.1. Forwarding Basics . . . . . . . . . . . . . . . . . . . . 11
2.1.1. MPLS Special-Purpose Labels . . . . . . . . . . . . . 12
2.1.2. MPLS Differentiated Services . . . . . . . . . . . . 13
2.1.3. Time Synchronization . . . . . . . . . . . . . . . . 14
2.1.4. Uses of Multiple Label Stack Entries . . . . . . . . 14
2.1.5. MPLS Link Bundling . . . . . . . . . . . . . . . . . 15
2.1.6. MPLS Hierarchy . . . . . . . . . . . . . . . . . . . 16
2.1.7. MPLS Fast Reroute (FRR) . . . . . . . . . . . . . . . 16
2.1.8. Pseudowire Encapsulation . . . . . . . . . . . . . . 17
2.1.8.1. Pseudowire Sequence Number . . . . . . . . . . . 17
2.1.9. Layer 2 and Layer 3 VPN . . . . . . . . . . . . . . . 19
2.2. MPLS Multicast . . . . . . . . . . . . . . . . . . . . . 20
2.3. Packet Rates . . . . . . . . . . . . . . . . . . . . . . 21
2.4. MPLS Multipath Techniques . . . . . . . . . . . . . . . . 23
2.4.1. Pseudowire Control Word . . . . . . . . . . . . . . . 24
2.4.2. Large Microflows . . . . . . . . . . . . . . . . . . 24
2.4.3. Pseudowire Flow Label . . . . . . . . . . . . . . . . 25
2.4.4. MPLS Entropy Label . . . . . . . . . . . . . . . . . 25
2.4.5. Fields Used for Multipath Load Balance . . . . . . . 25
2.4.5.1. MPLS Fields in Multipath . . . . . . . . . . . . 26
2.4.5.2. IP Fields in Multipath . . . . . . . . . . . . . 27
2.4.5.3. Fields Used in Flow Label . . . . . . . . . . . . 29
2.4.5.4. Fields Used in Entropy Label . . . . . . . . . . 29
2.5. MPLS-TP and UHP . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction and Document Scope . . . . . . . . . . . . . . . 4
1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Use of Requirements Language . . . . . . . . . . . . . . 8
1.3. Apparent Misconceptions . . . . . . . . . . . . . . . . . 9
1.4. Target Audience . . . . . . . . . . . . . . . . . . . . . 10
2. Forwarding Issues . . . . . . . . . . . . . . . . . . . . . . 11
2.1. Forwarding Basics . . . . . . . . . . . . . . . . . . . . 11
2.1.1. MPLS Special-Purpose Labels . . . . . . . . . . . . . 12
2.1.2. MPLS Differentiated Services . . . . . . . . . . . . 13
2.1.3. Time Synchronization . . . . . . . . . . . . . . . . 14
2.1.4. Uses of Multiple Label Stack Entries . . . . . . . . 14
2.1.5. MPLS Link Bundling . . . . . . . . . . . . . . . . . 15
2.1.6. MPLS Hierarchy . . . . . . . . . . . . . . . . . . . 16
2.1.7. MPLS Fast Reroute (FRR) . . . . . . . . . . . . . . . 16
2.1.8. Pseudowire Encapsulation . . . . . . . . . . . . . . 17
2.1.8.1. Pseudowire Sequence Number . . . . . . . . . . . 17
2.1.9. Layer 2 and Layer 3 VPN . . . . . . . . . . . . . . . 19
2.2. MPLS Multicast . . . . . . . . . . . . . . . . . . . . . 20
2.3. Packet Rates . . . . . . . . . . . . . . . . . . . . . . 21
2.4. MPLS Multipath Techniques . . . . . . . . . . . . . . . . 23
2.4.1. Pseudowire Control Word . . . . . . . . . . . . . . . 24
2.4.2. Large Microflows . . . . . . . . . . . . . . . . . . 24
2.4.3. Pseudowire Flow Label . . . . . . . . . . . . . . . . 25
2.4.4. MPLS Entropy Label . . . . . . . . . . . . . . . . . 25
2.4.5. Fields Used for Multipath Load Balance . . . . . . . 25
2.4.5.1. MPLS Fields in Multipath . . . . . . . . . . . . 26
2.4.5.2. IP Fields in Multipath . . . . . . . . . . . . . 27
2.4.5.3. Fields Used in Flow Label . . . . . . . . . . . . 29
2.4.5.4. Fields Used in Entropy Label . . . . . . . . . . 29
2.5. MPLS-TP and UHP . . . . . . . . . . . . . . . . . . . . . 30
2.6. Local Delivery of Packets . . . . . . . . . . . . . . . . 30
2.6.1. DoS Protection . . . . . . . . . . . . . . . . . . . 31
2.6.2. MPLS OAM . . . . . . . . . . . . . . . . . . . . . . 33
2.6.3. Pseudowire OAM . . . . . . . . . . . . . . . . . . . 34
2.6.4. MPLS-TP OAM . . . . . . . . . . . . . . . . . . . . . 34
2.6.5. MPLS OAM and Layer 2 OAM Interworking . . . . . . . . 35
2.6.6. Extent of OAM Support by Hardware . . . . . . . . . . 36
2.6.7. Support for IPFIX in Hardware . . . . . . . . . . . . 37
2.7. Number and Size of Flows . . . . . . . . . . . . . . . . 37
3. Questions for Suppliers . . . . . . . . . . . . . . . . . . . 38
3.1. Basic Compliance . . . . . . . . . . . . . . . . . . . . 38
3.2. Basic Performance . . . . . . . . . . . . . . . . . . . . 40
3.3. Multipath Capabilities and Performance . . . . . . . . . 41
3.4. Pseudowire Capabilities and Performance . . . . . . . . . 41
3.5. Entropy Label Support and Performance . . . . . . . . . . 42
3.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . 42
3.7. OAM Capabilities and Performance . . . . . . . . . . . . 42
4. Forwarding Compliance and Performance Testing . . . . . . . . 43
4.1. Basic Compliance . . . . . . . . . . . . . . . . . . . . 43
4.2. Basic Performance . . . . . . . . . . . . . . . . . . . . 44
4.3. Multipath Capabilities and Performance . . . . . . . . . 45
4.4. Pseudowire Capabilities and Performance . . . . . . . . . 46
4.5. Entropy Label Support and Performance . . . . . . . . . . 46
4.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . 47
4.7. OAM Capabilities and Performance . . . . . . . . . . . . 47
5. Security Considerations . . . . . . . . . . . . . . . . . . . 48
6. Organization of References Section . . . . . . . . . . . . . 50
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.1. Normative References . . . . . . . . . . . . . . . . . . 50
7.2. Informative References . . . . . . . . . . . . . . . . . 53
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 59
2.6. Local Delivery of Packets . . . . . . . . . . . . . . . . 30
2.6.1. DoS Protection . . . . . . . . . . . . . . . . . . . 31
2.6.2. MPLS OAM . . . . . . . . . . . . . . . . . . . . . . 33
2.6.3. Pseudowire OAM . . . . . . . . . . . . . . . . . . . 34
2.6.4. MPLS-TP OAM . . . . . . . . . . . . . . . . . . . . . 34
2.6.5. MPLS OAM and Layer 2 OAM Interworking . . . . . . . . 35
2.6.6. Extent of OAM Support by Hardware . . . . . . . . . . 36
2.6.7. Support for IPFIX in Hardware . . . . . . . . . . . . 37
2.7. Number and Size of Flows . . . . . . . . . . . . . . . . 37
3. Questions for Suppliers . . . . . . . . . . . . . . . . . . . 38
3.1. Basic Compliance . . . . . . . . . . . . . . . . . . . . 38
3.2. Basic Performance . . . . . . . . . . . . . . . . . . . . 40
3.3. Multipath Capabilities and Performance . . . . . . . . . 41
3.4. Pseudowire Capabilities and Performance . . . . . . . . . 41
3.5. Entropy Label Support and Performance . . . . . . . . . . 42
3.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . 42
3.7. OAM Capabilities and Performance . . . . . . . . . . . . 42
4. Forwarding Compliance and Performance Testing . . . . . . . . 43
4.1. Basic Compliance . . . . . . . . . . . . . . . . . . . . 43
4.2. Basic Performance . . . . . . . . . . . . . . . . . . . . 44
4.3. Multipath Capabilities and Performance . . . . . . . . . 45
4.4. Pseudowire Capabilities and Performance . . . . . . . . . 46
4.5. Entropy Label Support and Performance . . . . . . . . . . 46
4.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . 47
4.7. OAM Capabilities and Performance . . . . . . . . . . . . 47
5. Security Considerations . . . . . . . . . . . . . . . . . . . 48
6. Organization of References Section . . . . . . . . . . . . . 50
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.1. Normative References . . . . . . . . . . . . . . . . . . 50
7.2. Informative References . . . . . . . . . . . . . . . . . 53
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 59
The initial purpose of this document was to address concerns raised on the MPLS WG mailing list about shortcomings in implementations of MPLS forwarding. Documenting existing misconceptions and potential pitfalls might potentially avoid repeating past mistakes. The document has grown to address a broad set of forwarding requirements.
本文档的最初目的是解决在MPLS WG邮件列表中提出的有关MPLS转发实现中的缺陷的问题。记录现有的误解和潜在的陷阱可能会避免重复过去的错误。该文件已发展到满足一系列广泛的转发要求。
The focus of this document is MPLS forwarding, base pseudowire forwarding, and MPLS Operations, Administration, and Maintenance (OAM). The use of pseudowire Control Word and the use of pseudowire Sequence Number are discussed. Specific pseudowire Attachment Circuit (AC) and Native Service Processing (NSP) are out of scope. Specific pseudowire applications, such as various forms of Virtual Private Network (VPN), are out of scope.
本文档的重点是MPLS转发、基本伪线转发以及MPLS操作、管理和维护（OAM）。讨论了伪线控制字的使用和伪线序列号的使用。特定的伪线连接电路（AC）和本机服务处理（NSP）超出范围。特定的伪线应用程序，如各种形式的虚拟专用网（VPN），超出了范围。
MPLS support for multipath techniques is considered essential by many service providers and is useful for other high-capacity networks. In order to obtain sufficient entropy from MPLS, traffic service providers and others find it essential for the MPLS implementation to interpret the MPLS payload as IPv4 or IPv6 based on the contents of the first nibble of payload. The use of IP addresses, the IP protocol field, and UDP and TCP port number fields in multipath load balancing are considered within scope. The use of any other IP protocol fields, such as tunneling protocols carried within IP, are out of scope.
对多路径技术的MPLS支持被许多服务提供商认为是必不可少的，并且对于其他高容量网络非常有用。为了从MPLS获得足够的熵，流量服务提供商和其他人发现MPLS实现必须基于负载的第一个半字节的内容将MPLS负载解释为IPv4或IPv6。在多路径负载平衡中，IP地址、IP协议字段以及UDP和TCP端口号字段的使用在范围内。任何其他IP协议字段的使用，例如IP中携带的隧道协议，都超出了范围。
Implementation details are a local matter and are out of scope. Most interfaces today operate at 1 Gb/s or greater. It is assumed that all forwarding operations are implemented in specialized forwarding hardware rather than on a general-purpose processor. This is often referred to as "fast path" and "slow path" processing. Some recommendations are made regarding implementing control or management-plane functionality in specialized hardware or with limited assistance from specialized hardware. This advice is based on expected control or management protocol loads and on the need for denial of service (DoS) protection.
实施细节是本地事务，超出范围。目前，大多数接口的运行速度为1 Gb/s或更高。假设所有转发操作都在专用转发硬件中实现，而不是在通用处理器上实现。这通常被称为“快速路径”和“慢速路径”处理。针对在专用硬件中实现控制或管理平面功能或在专用硬件的有限协助下实现控制或管理平面功能，提出了一些建议。此建议基于预期的控制或管理协议负载以及拒绝服务（DoS）保护的需要。
The following abbreviations are used.
使用以下缩写。
AC Attachment Circuit ([RFC3985])
交流连接电路（[RFC3985]）
ACH Associated Channel Header (pseudowires)
ACH相关信道头（伪线）
ACK Acknowledgement (TCP flag and type of TCP packet)
ACK确认（TCP标志和TCP数据包类型）
AIS Alarm Indication Signal (MPLS-TP OAM)
AIS报警指示信号（MPLS-TP OAM）
ATM Asynchronous Transfer Mode (legacy switched circuits)
ATM异步传输模式（传统交换电路）
BFD Bidirectional Forwarding Detection
双向转发检测
BGP Border Gateway Protocol
边界网关协议
CC-CV Continuity Check and Connectivity Verification
CC-CV连续性检查和连通性验证
CE Customer Edge ([RFC4364])
CE客户边缘（[RFC4364]）
CPU Central Processing Unit (computer or microprocessor)
中央处理器（计算机或微处理器）
CT Class Type ([RFC4124])
CT类类型（[RFC4124]）
CW Control Word ([RFC4385])
连续波控制字（[RFC4385]）
DCCP Datagram Congestion Control Protocol
数据报拥塞控制协议
DDoS Distributed Denial of Service
分布式拒绝服务
DM Delay Measurement (MPLS-TP OAM)
DM延迟测量（MPLS-TP OAM）
DSCP Differentiated Services Code Point ([RFC2474])
DSCP区分服务代码点（[RFC2474]）
DWDM Dense Wave Division Multiplexing
密集波分复用
DoS Denial of Service
拒绝服务
E-LSP Explicitly TC-encoded-PSC LSP ([RFC5462])
E-LSP显式TC编码的PSC LSP（[RFC5462]）
EBGP External BGP
外部BGP
ECMP Equal-Cost Multipath
等成本多路径
ECN Explicit Congestion Notification ([RFC3168] and [RFC5129])
ECN显式拥塞通知（[RFC3168]和[RFC5129]）
EL Entropy Label ([RFC6790])
EL熵标签（[RFC6790]）
ELI Entropy Label Indicator ([RFC6790])
ELI熵标签指示器（[RFC6790]）
EXP Experimental (field in MPLS renamed to "TC" in [RFC5462])
EXP实验（MPLS中的字段在[RFC5462]中重命名为“TC”）
FEC Forwarding Equivalence Classes ([RFC3031]); also Forward Error Correction in other context
FEC转发等价类（[RFC3031]）；也可以在其他上下文中转发错误更正
FR Frame Relay (legacy switched circuits)
帧中继（传统交换电路）
FRR Fast Reroute ([RFC4090])
FRR快速重路由（[RFC4090]）
G-ACh Generic Associated Channel ([RFC5586])
G-ACh通用关联信道（[RFC5586]）
GAL Generic Associated Channel Label ([RFC5586])
GAL通用关联通道标签（[RFC5586]）
GFP Generic Framing Procedure (used in OTN)
GFP通用成帧程序（用于OTN）
GMPLS Generalized MPLS ([RFC3471])
GMPLS通用MPLS（[RFC3471]）
GTSM Generalized TTL Security Mechanism ([RFC5082])
GTSM通用TTL安全机制（[RFC5082]）
Gb/s Gigabits per second (billion bits per second)
Gb/s千兆位/秒（十亿位/秒）
IANA Internet Assigned Numbers Authority
IANA互联网分配号码管理局
ILM Incoming Label Map ([RFC3031])
ILM传入标签映射（[RFC3031]）
IP Internet Protocol
网际协议
IPVPN Internet Protocol VPN
互联网协议
IPv4 Internet Protocol version 4
IPv4互联网协议版本4
IPv6 Internet Protocol version 6
IPv6互联网协议版本6
L-LSP Label-Only-Inferred-PSC LSP ([RFC3270])
仅L-LSP标签推断的PSC LSP（[RFC3270]）
L2VPN Layer 2 VPN
L2VPN第二层VPN
LDP Label Distribution Protocol ([RFC5036])
LDP标签分发协议（[RFC5036]）
LER Label Edge Router ([RFC3031])
标签边缘路由器（[RFC3031]）
LM Loss Measurement (MPLS-TP OAM)
LM损耗测量（MPLS-TP OAM）
LSP Label Switched Path ([RFC3031])
LSP标签交换路径（[RFC3031]）
LSR Label Switching Router ([RFC3031])
LSR标签交换路由器（[RFC3031]）
MP2MP Multipoint to Multipoint
MP2MP多点对多点
MPLS Multiprotocol Label Switching ([RFC3031])
MPLS多协议标签交换（[RFC3031]）
MPLS-TP MPLS Transport Profile ([RFC5317])
MPLS-TP MPLS传输配置文件（[RFC5317]）
Mb/s Megabits per second (million bits per second)
Mb/s兆位/秒（百万位/秒）
NSP Native Service Processing ([RFC3985])
NSP本机服务处理（[RFC3985]）
NTP Network Time Protocol
网络时间协议
OAM Operations, Administration, and Maintenance ([RFC6291])
OAM操作、管理和维护（[RFC6291]）
OOB Out-of-band (not carried within a data channel)
带外OOB（不在数据通道内传输）
OTN Optical Transport Network
光传送网
P Provider router ([RFC4364])
P提供程序路由器（[RFC4364]）
P2MP Point to Multipoint
点对多点
PE Provider Edge router ([RFC4364])
PE提供程序边缘路由器（[RFC4364]）
PHB Per-Hop Behavior ([RFC2475])
PHB每跳行为（[RFC2475]）
PHP Penultimate Hop Popping ([RFC3443])
PHP倒数第二跳弹出（[RFC3443]）
POS PPP over SONET
SONET上的POS PPP
PSC This abbreviation has multiple interpretations.
PSC此缩写有多种解释。
1. Packet Switch Capable ([RFC3471]
1. 支持分组交换（[RFC3471]
2. PHB Scheduling Class ([RFC3270])
2. PHB调度类（[RFC3270]）
3. Protection State Coordination ([RFC6378])
3. 保护状态协调（[RFC6378]）
PTP Precision Time Protocol
精确时间协议
PW Pseudowire
伪线
QoS Quality of Service
服务质量
RA Router Alert ([RFC3032])
RA路由器警报（[RFC3032]）
RDI Remote Defect Indication (MPLS-TP OAM)
RDI远程缺陷指示（MPLS-TP OAM）
RSVP-TE RSVP Traffic Engineering
RSVP-TE RSVP交通工程
RTP Real-time Transport Protocol
实时传输协议
SCTP Stream Control Transmission Protocol
流控制传输协议
SDH Synchronous Data Hierarchy (European SONET, a form of TDM)
SDH同步数据体系（欧洲SONET，TDM的一种形式）
SONET Synchronous Optical Network (US SDH, a form of TDM)
SONET同步光网络（US SDH，TDM的一种形式）
T-LDP Targeted LDP (LDP sessions over more than one hop)
T-LDP目标LDP（超过一跳的LDP会话）
TC Traffic Class ([RFC5462])
TC流量等级（[RFC5462]）
TCP Transmission Control Protocol
TCP传输控制协议
TDM Time-Division Multiplexing (legacy encapsulations)
时分多路复用（传统封装）
TOS Type of Service (see [RFC2474])
TOS服务类型（参见[RFC2474]）
TTL Time-to-live (a field in IP and MPLS headers)
TTL生存时间（IP和MPLS标头中的字段）
UDP User Datagram Protocol
UDP用户数据报协议
UHP Ultimate Hop Popping (opposite of PHP)
UHP终极跳跃弹出（与PHP相反）
VCCV Virtual Circuit Connectivity Verification ([RFC5085])
VCCV虚拟电路连接验证（[RFC5085]）
VLAN Virtual Local Area Network (Ethernet)
VLAN虚拟局域网（以太网）
VOQ Virtual Output Queuing (switch fabric design)
VOQ虚拟输出队列（交换机结构设计）
VPN Virtual Private Network
虚拟私有网
WG Working Group
工作组
This document is Informational. The uppercase [RFC2119] key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are used in this document in the following cases.
本文件仅供参考。大写[RFC2119]关键字“必须”、“不得”、“应该”、“不应该”和“可能”在本文件中用于以下情况。
1. RFC 2119 keywords are used where requirements stated in this document are called for in referenced RFCs. In most cases, the RFC containing the requirement is cited within the statement using an RFC 2119 keyword.
1. RFC 2119关键字用于参考RFC中要求本文件中所述要求的地方。在大多数情况下，包含要求的RFC在声明中使用RFC 2119关键字引用。
2. RFC 2119 keywords are used where explicitly noted that the keywords indicate that operator experiences indicate a requirement, but there are no existing RFC requirements.
2. RFC 2119关键字用于明确指出关键字表示操作员经验表示要求，但不存在现有RFC要求的情况。
Advice provided by this document may be ignored by implementations. Similarly, implementations not claiming conformance to specific RFCs may ignore the requirements of those RFCs. In both cases, implementers should consider the risk of doing so.
本文档提供的建议可能会被实现忽略。类似地，未声明符合特定RFC的实现可能会忽略这些RFC的要求。在这两种情况下，实施者都应该考虑这样做的风险。
In early generations of forwarding silicon (which might now be behind us), there apparently were some misconceptions about MPLS. The following statements provide clarifications.
在转发硅的早期时代（现在可能已经落后于我们），显然对MPLS有一些误解。以下声明作了澄清。
1. There are practical reasons to have more than one or two labels in an MPLS label stack. Under some circumstances, the label stack can become quite deep. See Section 2.1.
1. MPLS标签堆栈中有一个或两个以上标签的实际原因。在某些情况下，标签堆栈可能变得相当深。见第2.1节。
2. The label stack MUST be considered to be arbitrarily deep. Section 3.27.4 ("Hierarchy: LSP Tunnels within LSPs") of RFC 3031 states "The label stack mechanism allows LSP tunneling to nest to any depth" [RFC3031]. If a bottom of the label stack cannot be found, but sufficient number of labels exist to forward, an LSR MUST forward the packet. An LSR MUST NOT assume the packet is malformed unless the end of packet is found before the bottom of the stack. See Section 2.1.
2. 必须将标签堆栈视为任意深度。RFC 3031第3.27.4节（“层次结构：LSP中的LSP隧道”）规定“标签堆栈机制允许LSP隧道嵌套到任何深度”[RFC3031]。如果找不到标签堆栈的底部，但存在足够数量的标签进行转发，则LSR必须转发数据包。LSR不得假设数据包格式不正确，除非在堆栈底部之前找到数据包的结尾。见第2.1节。
3. In networks where deep label stacks are encountered, they are not rare. Full packet rate performance is required regardless of label stack depth, except where multiple pop operations are required. See Section 2.1.
3. 在遇到深标签堆栈的网络中，它们并不罕见。除非需要多个pop操作，否则无论标签堆栈深度如何，都需要全包速率性能。见第2.1节。
4. Research has shown that long bursts of short packets with 40-byte or 44-byte IP payload sizes in these bursts are quite common. This is due to TCP ACK compression [ACK-compression]. The following two sub-bullets constitute advice that reflects very common nonnegotiable requirements of providers. Implementers may ignore this advice but should consider the risk of doing so.
4. 研究表明，具有40字节或44字节IP有效负载大小的短数据包的长突发在这些突发中非常常见。这是由于TCP ACK压缩[ACK压缩]。以下两个子项目符号构成了反映提供者非常常见的不可协商要求的建议。实施者可能忽略这个建议，但应该考虑这样做的风险。
A. A forwarding engine SHOULD, if practical, be able to sustain an arbitrarily long sequence of small packets arriving at full interface rate.
A.如果可行，转发引擎应该能够支持以全接口速率到达的任意长序列的小数据包。
B. If indefinitely sustained full packet rate for small packets is not practical, a forwarding engine MUST be able to buffer a long sequence of small packets inbound to the on-chip decision engine and sustain full interface rate for some reasonable average packet rate. Absent this small on-chip buffering, QoS-agnostic packet drops can occur.
B.如果无限期地维持小包的全包速率是不可行的，则转发引擎必须能够缓冲进入片上决策引擎的长序列小包，并维持某个合理平均包速率的全接口速率。如果没有这种小型片上缓冲，可能会发生与QoS无关的数据包丢失。
See Section 2.3.
见第2.3节。
5. The implementations and system designs MUST support pseudowire Control Word (CW) if MPLS-TP is supported or if ACH [RFC5586] is being used on a pseudowire. The implementation and system designs SHOULD support pseudowire CW even if MPLS-TP and ACH
5. 如果支持MPLS-TP或ACH[RFC5586]正在伪线上使用，则实现和系统设计必须支持伪线控制字（CW）。实现和系统设计应支持伪线CW，即使MPLS-TP和ACH
[RFC5586] are not used, using instead CW and VCCV Type 1 [RFC5085] to allow the use of multipath in the underlying network topology without impacting the PW traffic. [RFC7079] does note that there are still some deployments where the CW is not always used. It also notes that many service providers do enable the CW. See Section 2.4.1 for more discussion on why deployments SHOULD enable the pseudowire CW.
不使用[RFC5586]，而是使用CW和VCCV类型1[RFC5085]来允许在基础网络拓扑中使用多路径，而不会影响PW通信量。[RFC7079]注意到，仍有一些部署并不总是使用CW。它还指出，许多服务提供商确实启用了CW。有关部署为何应启用伪线CW的更多讨论，请参见第2.4.1节。
The following statements provide clarification regarding more recent requirements that are often missed.
以下声明对最近经常遗漏的要求进行了澄清。
1. The implementer and system designer SHOULD support adding a pseudowire Flow Label [RFC6391]. Deployments MAY enable this feature for appropriate pseudowire types. See Section 2.4.3.
1. 实现者和系统设计者应该支持添加伪线流标签[RFC6391]。部署可能会为适当的伪导线类型启用此功能。见第2.4.3节。
2. The implementer and system designer SHOULD support adding an MPLS Entropy Label [RFC6790]. Deployments MAY enable this feature. See Section 2.4.4.
2. 实现者和系统设计者应该支持添加MPLS熵标签[RFC6790]。部署可能会启用此功能。见第2.4.4节。
Non-IETF definitions of MPLS exist, and these should not be used as normative texts in place of the relevant IETF RFCs. [RFC5704] documents incompatibilities between the IETF definition of MPLS and one such alternative MPLS definition, which led to significant issues in the resulting non-IETF specification.
存在MPLS的非IETF定义，这些定义不应作为规范性文本代替相关的IETF RFC。[RFC5704]记录了MPLS的IETF定义与一个此类替代MPLS定义之间的不兼容，这导致了产生的非IETF规范中的重大问题。
This document is intended for multiple audiences: implementer (implementing MPLS forwarding in silicon or in software); systems designer (putting together a MPLS forwarding systems); deployer (running an MPLS network). These guidelines are intended to serve the following purposes:
本文档面向多个受众：实施者（在硅或软件中实施MPLS转发）；系统设计师（组装MPLS转发系统）；部署器（运行MPLS网络）。本指南旨在达到以下目的：
1. Explain what to do and what not to do when a deep label stack is encountered. (audience: implementer)
1. 解释遇到深标签堆栈时应执行的操作和不应执行的操作。（受众：实施者）
2. Highlight pitfalls to look for when implementing an MPLS forwarding chip. (audience: implementer)
2. 强调在实施MPLS转发芯片时要寻找的陷阱。（受众：实施者）
3. Provide a checklist of features and performance specifications to request. (audience: systems designer, deployer)
3. 根据要求提供功能和性能规格清单。（受众：系统设计师、部署人员）
4. Provide a set of tests to perform. (audience: systems designer, deployer).
4. 提供一组要执行的测试。（受众：系统设计师、部署人员）。
The implementer, systems designer, and deployer have a transitive supplier-customer relationship. It is in the best interest of the supplier to review their product against their customer's checklist and secondary customer's checklist if applicable.
实施者、系统设计者和部署者具有可传递的供应商-客户关系。供应商根据其客户的检查表和第二客户的检查表（如适用）审查其产品符合其最大利益。
This document identifies and explains many details and potential pitfalls of MPLS forwarding. It is likely that the identified set of potential pitfalls will later prove to be an incomplete set.
本文档确定并解释了MPLS转发的许多细节和潜在缺陷。确定的一组潜在陷阱很可能在以后被证明是不完整的。
A brief review of forwarding issues is provided in the subsections that follow. This section provides some background on why some of these requirements exist. The questions to ask of suppliers is covered in Section 3. Some guidelines for testing are provided in Section 4.
下文各小节简要回顾了转发问题。本节提供了一些背景知识，说明为什么存在这些需求。第3节介绍了向供应商提出的问题。第4节提供了一些测试指南。
Basic MPLS architecture and MPLS encapsulation, and therefore packet forwarding, are defined in [RFC3031] and [RFC3032]. RFC 3031 and RFC 3032 are somewhat LDP centric. RSVP-TE supports traffic engineering (TE) and fast reroute, features that LDP lacks. The base document for MPLS RSVP-TE is [RFC3209].
[RFC3031]和[RFC3032]中定义了基本MPLS体系结构和MPLS封装，并因此定义了数据包转发。RFC 3031和RFC 3032在某种程度上以LDP为中心。RSVP-TE支持流量工程（TE）和快速重路由，这是LDP所缺乏的特性。MPLS RSVP-TE的基本文档为[RFC3209]。
A few RFCs update RFC 3032. Those with impact on forwarding include the following.
一些RFC更新了RFC 3032。影响转发的因素包括以下几点。
1. TTL processing is clarified in [RFC3443].
1. TTL处理在[RFC3443]中进行了说明。
2. The use of MPLS Explicit NULL is modified in [RFC4182].
2. [RFC4182]中修改了MPLS显式NULL的使用。
3. Differentiated Services is supported by [RFC3270] and [RFC4124]. The "EXP" field is renamed to "Traffic Class" in [RFC5462], removing any misconception that it was available for experimentation or could be ignored.
3. [RFC3270]和[RFC4124]支持区分服务。[RFC5462]中的“EXP”字段被重命名为“Traffic Class”，消除了任何关于该字段可用于实验或可忽略的误解。
4. ECN is supported by [RFC5129].
4. [RFC5129]支持ECN。
5. The MPLS G-ACh and GAL are defined in [RFC5586].
5. MPLS G-ACh和GAL在[RFC5586]中定义。
6. [RFC5332] redefines the two data link layer codepoints for MPLS packets.
6. [RFC5332]重新定义MPLS数据包的两个数据链路层代码点。
Tunneling encapsulations carrying MPLS, such as MPLS in IP [RFC4023], MPLS in GRE [RFC4023], MPLS in L2TPv3 [RFC4817], or MPLS in UDP [MPLS-IN-UDP], are out of scope.
承载MPLS的隧道封装（如IP[RFC4023]中的MPLS、GRE[RFC4023]中的MPLS、L2TPv3[RFC4817]中的MPLS或UDP[MPLS-in-UDP]中的MPLS）超出范围。
Other RFCs have implications to MPLS Forwarding and do not update RFC 3032 or RFC 3209, including:
其他RFC对MPLS转发有影响，不更新RFC 3032或RFC 3209，包括：
1. The pseudowire (PW) Associated Channel Header (ACH) is defined by [RFC5085] and was later generalized by the MPLS G-ACh [RFC5586].
1. 伪线（PW）相关信道报头（ACH）由[RFC5085]定义，随后由MPLS G-ACH[RFC5586]推广。
2. The Entropy Label Indicator (ELI) and Entropy Label (EL) are defined by [RFC6790].
2. 熵标签指示器（ELI）和熵标签（EL）由[RFC6790]定义。
A few RFCs update RFC 3209. Those that are listed as updating RFC 3209 generally impact only RSVP-TE signaling. Forwarding is modified by major extensions built upon RFC 3209.
一些RFC更新了RFC3209。被列为更新RFC 3209的那些通常只影响RSVP-TE信令。转发由基于RFC3209的主要扩展修改。
RFCs that impact forwarding are discussed in the following subsections.
影响转发的RFC将在以下小节中讨论。
[RFC3032] specifies that label values 0-15 are special-purpose labels with special meanings. [RFC7274] renamed these from the term "reserved labels" used in [RFC3032] to "special-purpose labels". Three values of NULL label are defined (two of which are later updated by [RFC4182]) and a Router Alert Label is defined. The original intent was that special-purpose labels, except the NULL labels, could be sent to the routing engine CPU rather than be processed in forwarding hardware. Hardware support is required by new RFCs such as those defining Entropy Label and OAM processed as a result of receiving a GAL. For new special-purpose labels, some accommodation is needed for LSRs that will send the labels to a general-purpose CPU or other highly programmable hardware. For example, ELI will only be sent to LSRs that have signaled support for [RFC6790], and a high OAM packet rate must be negotiated among endpoints.
[RFC3032]指定标签值0-15是具有特殊含义的专用标签。[RFC7274]将[RFC3032]中使用的术语“保留标签”重命名为“专用标签”。定义了空标签的三个值（其中两个值稍后由[RFC4182]更新），并定义了路由器警报标签。最初的意图是，除了空标签之外，特殊用途的标签可以发送到路由引擎CPU，而不是在转发硬件中处理。新的RFC需要硬件支持，例如定义熵标签和接收GAL后处理的OAM的RFC。对于新的专用标签，需要为LSR提供一些便利，LSR将标签发送到通用CPU或其他高度可编程的硬件。例如，ELI将只发送到表示支持[RFC6790]的LSR，并且必须在端点之间协商高OAM数据包速率。
[RFC3429] reserves a label for ITU-T Y.1711; however, Y.1711 does not work with multipath and its use is strongly discouraged.
[RFC3429]为ITU-T Y.1711保留一个标签；但是，Y.1711不适用于多路径，因此强烈建议不要使用它。
The current list of special-purpose labels can be found on the "Multiprotocol Label Switching Architecture (MPLS) Label Values" registry reachable at IANA's pages at <http://www.iana.org>.
当前的专用标签列表可在“多协议标签交换体系结构（MPLS）标签值”注册表中找到，可在IANA的网页上访问<http://www.iana.org>.
[RFC7274] introduces an IANA "Extended Special-Purpose MPLS Label Values" registry and makes use of the "extension" label, label 15, to indicate that the next label is an extended special-purpose label and requires special handling. The range of only 16 values for special-purpose labels allows a table to be used. The range of extended special-purpose labels with 20 bits available for use may have to be handled in some other way in the unlikely event that in the future
[RFC7274]引入了IANA“扩展专用MPLS标签值”注册表，并利用“扩展”标签标签15指示下一个标签是扩展专用标签，需要特殊处理。对于特殊用途标签，只有16个值的范围允许使用表格。可供使用的20位扩展特殊用途标签的范围可能必须以其他方式处理，以防将来出现这种情况
the range of currently reserved values 256-1048575 is used. If only the Standards Action range, 16-239, and the Experimental range, 240-255, are used, then a table of 256 entries can be used.
使用当前保留值256-1048575的范围。如果仅使用标准操作范围16-239和实验范围240-255，则可以使用包含256个条目的表格。
Unknown special-purpose labels and unknown extended special-purpose labels are handled the same. When an unknown special-purpose label is encountered or a special purpose label not directly handled in forwarding hardware is encountered, the packet should be sent to a general-purpose CPU by default. If this capability is supported, there must be an option to either drop or rate limit such packets based on the value of each special-purpose label.
未知专用标签和未知扩展专用标签的处理方式相同。当遇到未知的专用标签或遇到转发硬件中未直接处理的专用标签时，默认情况下，数据包应发送到通用CPU。如果支持此功能，则必须有一个选项，可以根据每个专用标签的值丢弃或限制此类数据包的速率。
[RFC2474] deprecates the IP Type of Service (TOS) and IP Precedence (Prec) fields and replaces them with the Differentiated Services Field more commonly known as the Differentiated Services Code Point (DSCP) field. [RFC2475] defines the Differentiated Services architecture, which in other forums, is often called a Quality of Service (QoS) architecture.
[RFC2474]不推荐IP服务类型（TOS）和IP优先级（Prec）字段，并将其替换为差异化服务字段（通常称为差异化服务代码点（DSCP）字段）。[RFC2475]定义了区分服务体系结构，在其他论坛中，该体系结构通常被称为服务质量（QoS）体系结构。
MPLS uses the Traffic Class (TC) field to support Differentiated Services [RFC5462]. There are two primary documents describing how DSCP is mapped into TC.
MPLS使用流量类别（TC）字段来支持区分服务[RFC5462]。有两个主要文档描述了DSCP如何映射到TC。
1. [RFC3270] defines E-LSP and L-LSP. E-LSP uses a static mapping of DSCP into TC. L-LSP uses a per-LSP mapping of DSCP into TC, with one PHB Scheduling Class (PSC) per L-LSP. Each PSC can use multiple Per-Hop Behavior (PHB) values. For example, the Assured Forwarding service defines three PSCs, each with three PHB [RFC2597].
1. [RFC3270]定义了E-LSP和L-LSP。E-LSP使用DSCP到TC的静态映射。L-LSP使用DSCP到TC的每LSP映射，每个L-LSP有一个PHB调度类（PSC）。每个PSC可以使用多个每跳行为（PHB）值。例如，保证转发服务定义了三个PSC，每个PSC有三个PHB[RFC2597]。
2. [RFC4124] defines assignment of a class-type (CT) to an LSP, where a per-CT static mapping of TC to PHB is used. [RFC4124] provides a means to support up to eight E-LSP-like mappings of DSCP to TC.
2. [RFC4124]定义类类型（CT）到LSP的分配，其中使用TC到PHB的每CT静态映射。[RFC4124]提供了一种支持多达八个DSCP到TC的E-LSP类映射的方法。
To meet Differentiated Services requirements specified in [RFC3270], the following forwarding requirements must be met. An ingress LER MUST be able to select an LSP and then apply a per-LSP map of DSCP into TC. A midpoint LSR MUST be able to apply a per-LSP map of TC to PHB. The number of mappings supported will be far less than the number of LSPs supported.
为了满足[RFC3270]中规定的差异化服务要求，必须满足以下转发要求。入口LER必须能够选择LSP，然后将DSCP的每LSP映射应用到TC中。中点LSR必须能够将TC的每LSP映射应用于PHB。支持的映射数将远远少于支持的LSP数。
To meet Differentiated Services requirements specified in [RFC4124], the following forwarding requirements must be met. An ingress LER MUST be able to select an LSP and then apply a per-LSP map of DSCP into TC. A midpoint LSR MUST be able to map LSP number to Class Type
为了满足[RFC4124]中规定的差异化服务要求，必须满足以下转发要求。入口LER必须能够选择LSP，然后将DSCP的每LSP映射应用到TC中。中点LSR必须能够将LSP编号映射到类类型
(CT), then use a per-CT map to map TC to PHB. Since there are only eight allowed values of CT, only eight maps of TC to PHB need to be supported. The LSP label can be used directly to find the TC-to-PHB mapping, as is needed to support L-LSPs as defined by [RFC3270].
（CT），然后使用每CT图将TC映射到PHB。因为只有八个允许的CT值，所以只需要支持八个TC到PHB的映射。LSP标签可直接用于查找TC到PHB的映射，这是支持[RFC3270]定义的L-LSP所需的。
While support for [RFC4124] and not [RFC3270] would allow support for only eight mappings of TC to PHB, it is common to support both and simply state a limit on the number of unique TC-to-PHB mappings that can be supported.
虽然对[RFC4124]和[RFC3270]的支持只允许支持八个TC到PHB的映射，但通常都支持这两个映射，并且仅对可支持的唯一TC到PHB映射的数量进行限制。
PTP or NTP may be carried over MPLS [TIMING-OVER-MPLS]. Generally, NTP will be carried within IP, and IP will be carried in MPLS [RFC5905]. Both PTP and NTP benefit from accurate timestamping of incoming packets and the ability to insert accurate timestamps in outgoing packets. PTP correction that occurs when forwarding requires updating a timestamp compensation field based on the difference between packet arrival at an LSR and packet transmit time at that same LSR.
PTP或NTP可以通过MPLS[通过MPLS的定时]携带。通常，NTP将在IP中传输，IP将在MPLS中传输[RFC5905]。PTP和NTP都受益于传入数据包的准确时间戳以及在传出数据包中插入准确时间戳的能力。当转发需要基于在LSR处的分组到达和在同一LSR处的分组发送时间之间的差来更新时间戳补偿字段时发生的PTP校正。
Since the label stack depth may vary, hardware should allow a timestamp to be placed in an outgoing packet at any specified byte position. It may be necessary to modify Layer 2 checksums or frame check sequences after insertion. PTP and NTP timestamp formats differ in such a way as to require different implementations of the timestamp correction. If NTP or PTP is carried over UDP/IP or UDP/IP/MPLS, the UDP checksum will also have to be updated.
由于标签堆栈深度可能不同，硬件应允许在任何指定字节位置的传出数据包中放置时间戳。插入后，可能需要修改第2层校验和或帧校验序列。PTP和NTP时间戳格式的不同之处在于需要时间戳校正的不同实现。如果NTP或PTP通过UDP/IP或UDP/IP/MPLS传输，则还必须更新UDP校验和。
Accurate time synchronization, in addition to being generally useful, is required for MPLS-TP Delay Measurement (DM) OAM. See Section 2.6.4.
MPLS-TP延迟测量（DM）OAM除了通常有用外，还需要精确的时间同步。见第2.6.4节。
MPLS deployments in the early part of the prior decade (circa 2000) tended to support either LDP or RSVP-TE. LDP was favored by some for its ability to scale to a very large number of PE devices at the edge of the network, without adding deployment complexity. RSVP-TE was favored, generally in the network core, where traffic engineering and/or fast reroute were considered important.
上一个十年早期（大约2000年）的MPLS部署倾向于支持LDP或RSVP-TE。LDP因其能够扩展到网络边缘的大量PE设备，而不增加部署复杂性而受到一些人的青睐。RSVP-TE受到青睐，通常在网络核心，流量工程和/或快速重路由被认为是重要的。
Both LDP and RSVP-TE are used simultaneously within major service provider networks using a technique known as "LDP over RSVP-TE Tunneling". This technique allows service providers to carry LDP tunnels inside RSVP-TE tunnels. This makes it possible to take advantage of the traffic engineering and fast reroute on more expensive intercity and intercontinental transport paths. The
LDP和RSVP-TE都使用一种称为“LDP over RSVP-TE隧道”的技术在主要服务提供商网络中同时使用。该技术允许服务提供商在RSVP-TE隧道内承载LDP隧道。这使得在更昂贵的城际和洲际运输路径上利用交通工程和快速改道成为可能。这个
ingress RSVP-TE PE places many LDP tunnels on a single RSVP-TE LSP and carries it to the egress RSVP-TE PE. The LDP PEs are situated further from the core, for example, within a metro network. LDP over RSVP-TE tunneling requires a minimum of two MPLS labels: one each for LDP and RSVP-TE.
入口RSVP-TE PE在单个RSVP-TE LSP上放置多个LDP隧道，并将其输送至出口RSVP-TE PE。LDP-PEs位于远离核心的位置，例如，在城域网内。RSVP-TE隧道上的LDP至少需要两个MPLS标签：LDP和RSVP-TE各一个。
The use of MPLS FRR [RFC4090] might add one more label to MPLS traffic but only when FRR protection is in use (active). If LDP over RSVP-TE is in use, and FRR protection is in use, then at least three MPLS labels are present on the label stack on the links through which the Bypass LSP traverses. FRR is covered in Section 2.1.7.
MPLS FRR[RFC4090]的使用可能会为MPLS流量添加一个以上的标签，但仅当FRR保护正在使用时（活动）。如果使用RSVP-TE上的LDP，并且使用FRR保护，则旁路LSP通过的链路上的标签堆栈上至少存在三个MPLS标签。FRR见第2.1.7节。
LDP L2VPN, LDP IPVPN, BGP L2VPN, and BGP IPVPN added support for VPN services that are deployed by the vast majority of service providers. These VPN services added yet another label, bringing the label stack depth (when FRR is active) to four.
LDP L2VPN、LDP IPVPN、BGP L2VPN和BGP IPVPN增加了对绝大多数服务提供商部署的VPN服务的支持。这些VPN服务又添加了一个标签，使标签堆栈深度（当FRR处于活动状态时）增加到四个。
Pseudowires and VPN are discussed in further detail in Sections 2.1.8 and 2.1.9.
第2.1.8节和第2.1.9节将进一步详细讨论伪线和VPN。
MPLS hierarchy as described in [RFC4206] and updated by [RFC7074] can in principle add at least one additional label. MPLS hierarchy is discussed in Section 2.1.6.
[RFC4206]中描述并由[RFC7074]更新的MPLS层次结构原则上可以添加至少一个附加标签。第2.1.6节讨论了MPLS层次结构。
Other features such as Entropy Label (discussed in Section 2.4.4) and Flow Label (discussed in Section 2.4.3) can add additional labels to the label stack.
熵标签（在第2.4.4节中讨论）和流量标签（在第2.4.3节中讨论）等其他功能可以向标签堆栈添加其他标签。
Although theoretical scenarios can easily result in eight or more labels, such cases are rare if they occur at all today. For the purpose of forwarding, only the top label needs to be examined if PHP is used, and a few more if UHP is used (see Section 2.5). For deep label stacks, quite a few labels may have to be examined for the purpose of load balancing across parallel links (see Section 2.4); however, this depth can be bounded by a provider through use of Entropy Label.
虽然理论上的情况很容易导致八个或更多的标签，但如果它们今天发生的话，这种情况是罕见的。为了转发，如果使用PHP，只需检查顶部标签，如果使用UHP，则需要检查更多标签（参见第2.5节）。对于深标签堆栈，为了在并行链路之间实现负载平衡，可能需要检查相当多的标签（见第2.4节）；然而，这个深度可以由提供者通过使用熵标签来限定。
Other creative uses of MPLS within the IETF, such as the use of MPLS label stack in source routing, may result in label stacks that are considerably deeper than those encountered today.
IETF中MPLS的其他创造性使用，例如在源路由中使用MPLS标签堆栈，可能导致标签堆栈比今天遇到的标签堆栈要深得多。
MPLS Link Bundling was the first RFC to address the need for multiple parallel links between nodes [RFC4201]. MPLS Link Bundling is notable in that it tried not to change MPLS forwarding, except in
MPLS链路捆绑是第一个解决节点间多个并行链路需求的RFC[RFC4201]。MPLS链路绑定值得注意的是，它试图不改变MPLS转发，除非在
specifying the "all-ones" component link. MPLS Link Bundling is seldom if ever deployed. Instead, multipath techniques described in Section 2.4 are used.
指定“所有一个”组件链接。MPLS链路绑定很少部署。相反，使用第2.4节中描述的多路径技术。
MPLS hierarchy is defined in [RFC4206] and updated by [RFC7074]. Although RFC 4206 is considered part of GMPLS, the Packet Switching Capable (PSC) portion of the MPLS hierarchy is applicable to MPLS and may be supported in an otherwise GMPLS-free implementation. The MPLS PSC hierarchy remains the most likely means of providing further scaling in an RSVP-TE MPLS network, particularly where the network is designed to provide RSVP-TE connectivity to the edges. This is the case for envisioned MPLS-TP networks. The use of the MPLS PSC hierarchy can add at least one additional label to a label stack, though it is likely that only one layer of PSC will be used in the near future.
MPLS层次结构在[RFC4206]中定义，并由[RFC7074]更新。尽管RFC 4206被认为是GMPLS的一部分，但是MPLS层次结构的分组交换能力（PSC）部分适用于MPLS，并且可以在不使用GMPLS的其他实现中得到支持。MPLS PSC层次结构仍然是在RSVP-TE MPLS网络中提供进一步扩展的最有可能的方法，特别是在网络设计为提供到边缘的RSVP-TE连接的情况下。设想中的MPLS-TP网络就是这样。使用MPLS PSC层次结构可以向标签堆栈添加至少一个附加标签，尽管在不久的将来可能只使用一层PSC。
Fast reroute is defined by [RFC4090]. Two significantly different methods are defined in RFC 4090: the "One-to-One Backup" method, which uses the "Detour LSP", and the "Facility Backup", which uses a "bypass tunnel". These are commonly referred to as the detour and bypass methods, respectively.
快速重路由由[RFC4090]定义。RFC 4090中定义了两种截然不同的方法：使用“绕道LSP”的“一对一备份”方法和使用“旁路隧道”的“设施备份”。这些方法通常分别称为迂回法和旁路法。
The detour method makes use of a presignaled LSP. Hardware assistance may be needed for detour FRR in order to accomplish local repair of a large number of LSPs within the target of tens of milliseconds. For each affected LSP, a swap operation must be reprogrammed or otherwise switched over. The use of detour FRR doubles the number of LSPs terminating at any given hop and will increase the number of LSPs within a network by a factor dependent on the average detour path length.
迂回法使用预先标记的LSP。绕行FRR可能需要硬件协助，以便在数十毫秒的目标时间内完成大量LSP的本地修复。对于每个受影响的LSP，必须重新编程或以其他方式切换交换操作。使用迂回FRR将使在任何给定跳数处终止的LSP数量加倍，并将使网络内的LSP数量增加一个取决于平均迂回路径长度的系数。
The bypass method makes use of a tunnel that is unused when no fault exists but may carry many LSPs when a local repair is required. There is no presignaling indicating which working LSP will be diverted into any specific bypass LSP. If interface label space is used, the bypass LSP MUST extend one hop beyond the merge point, except if the merge point is the egress and PHP is used. If the bypass LSPs are not extended in this way, then the merge LSR (egress LSR of the bypass LSP) MUST use platform label space (as defined in [RFC3031]) so that an LSP working path on any given interface can be backed up using a bypass LSP terminating on any other interface. Hardware assistance may be needed to accomplish local repair of a large number of LSPs within the target of tens of milliseconds. For each affected LSP a swap operation must be reprogrammed or otherwise
旁路方法利用了在不存在故障时未使用的隧道，但在需要局部维修时可能携带许多LSP。没有指示哪个工作LSP将分流到任何特定旁路LSP的预信号。如果使用接口标签空间，则旁路LSP必须在合并点之外扩展一个跃点，除非合并点是出口并且使用PHP。如果旁路LSP未以这种方式扩展，则合并LSR（旁路LSP的出口LSR）必须使用平台标签空间（如[RFC3031]中所定义），以便使用终止于任何其他接口的旁路LSP备份任何给定接口上的LSP工作路径。在数十毫秒的目标时间内完成大量LSP的本地修复可能需要硬件协助。对于每个受影响的LSP，必须重新编程或以其他方式进行交换操作
switched over with an additional push of the bypass LSP label. The use of platform label space impacts the size of the LSR ILM for an LSR with a very large number of interfaces.
通过额外按下旁路LSP标签切换。对于具有大量接口的LSR，平台标签空间的使用会影响LSR ILM的大小。
IP/LDP Fast Reroute (IP/LDP FRR) [RFC5714] is also applicable in MPLS networks. ECMP and Loop-Free Alternates (LFAs) [RFC5286] are well-established IP/LDP FRR techniques and were the first methods to be widely deployed. Work on IP/LDP FRR is ongoing within the IETF RTGWG. Two topics actively discussed in RTGWG are microloops and partial coverage of the established techniques in some network topologies. [RFC5715] covers the topic of IP/LDP Fast Reroute microloops and microloop prevention. RTGWG has developed additional IP/LDP FRR techniques to handle coverage concerns. RTGWG is extending LFA through the use of remote LFA [REMOTE-LFA]. Other techniques that require new forwarding paths to be established are also under consideration, including the IPFRR "not-via" technique defined in [RFC6981] and maximally redundant trees (MRT) [MRT]. ECMP, LFA (but not remote LFA), and MRT swap the top label to an alternate MPLS label. The other methods operate in a similar manner to the facility backup described in RFC 4090 and push an additional label. IP/LDP FRR methods that push more than one label have been suggested but are in early discussion.
IP/LDP快速重路由（IP/LDP FRR）[RFC5714]也适用于MPLS网络。ECMP和无环替代（LFA）[RFC5286]是成熟的IP/LDP FRR技术，是最先被广泛部署的方法。IETF RTGWG正在进行IP/LDP FRR的工作。RTGWG中积极讨论的两个主题是微环和某些网络拓扑中已建立技术的部分覆盖。[RFC5715]涵盖了IP/LDP快速重路由微环和微环预防的主题。RTGWG开发了额外的IP/LDP FRR技术来处理覆盖问题。RTGWG通过使用远程LFA[remote-LFA]扩展LFA。其他需要建立新转发路径的技术也在考虑之中，包括[RFC6981]中定义的IPFRR“非通过”技术和最大冗余树（MRT）[MRT]。ECMP、LFA（但不是远程LFA）和MRT将顶部标签交换为备用MPLS标签。其他方法的操作方式与RFC 4090中描述的设施备份类似，并添加一个附加标签。已经提出了推送多个标签的IP/LDP FRR方法，但仍在早期讨论中。
The pseudowire (PW) architecture is defined in [RFC3985]. A pseudowire, when carried over MPLS, adds one or more additional label entries to the MPLS label stack. A PW Control Word is defined in [RFC4385] with motivation for defining the Control Word in [RFC4928]. The PW Associated Channel defined in [RFC4385] is used for OAM in [RFC5085]. The PW Flow Label is defined in [RFC6391] and is discussed further in this document in Section 2.4.3.
[RFC3985]中定义了伪线（PW）体系结构。通过MPLS传输的伪线将一个或多个附加标签项添加到MPLS标签堆栈中。[RFC4385]中定义了PW控制字，其动机是在[RFC4928]中定义控制字。[RFC4385]中定义的PW相关信道用于[RFC5085]中的OAM。PW流量标签在[RFC6391]中定义，并在本文件第2.4.3节中进一步讨论。
There are numerous pseudowire encapsulations, supporting emulation of services such as Frame Relay, ATM, Ethernet, TDM, and SONET/SDH over packet switched networks (PSNs) using IP or MPLS.
有许多伪线封装，支持通过使用IP或MPLS的分组交换网络（PSN）模拟帧中继、ATM、以太网、TDM和SONET/SDH等服务。
The pseudowire encapsulation is out of scope for this document. Pseudowire impact on MPLS forwarding at the midpoint LSR is within scope. The impact on ingress MPLS push and egress MPLS UHP pop are within scope. While pseudowire encapsulation is out of scope, some advice is given on Sequence Number support.
伪导线封装超出了本文档的范围。伪线对中点LSR处MPLS转发的影响在范围内。对入口MPLS推送和出口MPLS UHP pop的影响在范围之内。虽然伪线封装超出了范围，但在序列号支持方面给出了一些建议。
Pseudowire (PW) Sequence Number support is most important for PW payload types with a high expectation of lossless and/or in-order delivery. Identifying lost PW packets and the exact amount of lost
伪线（PW）序列号支持对于PW有效负载类型最为重要，该类型具有较高的无损和/或顺序交付期望。识别丢失的PW数据包和丢失的确切数量
payload is critical for PW services that maintain bit timing, such as Time Division Multiplexing (TDM) services since these services MUST compensate lost payload on a bit-for-bit basis.
有效载荷对于维持位定时的PW服务至关重要，例如时分复用（TDM）服务，因为这些服务必须以位对位的方式补偿丢失的有效载荷。
With PW services that maintain bit timing, packets that have been received out of order also MUST be identified and MAY be either reordered or dropped. Resequencing requires, in addition to sequence numbering, a "reorder buffer" in the egress PE, and the ability to reorder is limited by the depth of this buffer. The down side of maintaining a large reorder buffer is added end-to-end service delay.
对于保持位定时的PW服务，还必须识别无序接收的数据包，并且可以重新排序或丢弃。除序列编号外，重新排序还需要出口PE中的“重新排序缓冲区”，并且重新排序的能力受到该缓冲区深度的限制。维护大的重新排序缓冲区的缺点是增加了端到端服务延迟。
For PW services that maintain bit timing or any other service where jitter must be bounded, a jitter buffer is always necessary. The jitter buffer is needed regardless of whether reordering is done. In order to be effective, a reorder buffer must often be larger than a jitter buffer needs to be, thus creating a tradeoff between reducing loss and minimizing delay.
对于维持位定时的PW服务或抖动必须有界的任何其他服务，抖动缓冲区总是必要的。无论是否重新排序，都需要抖动缓冲区。为了有效，重排序缓冲区通常必须大于抖动缓冲区所需的大小，从而在减少损失和最小化延迟之间进行权衡。
PW services that are not timing critical bit streams in nature are cell oriented or frame oriented. Though resequencing support may be beneficial to PW cell- and frame-oriented payloads such as ATM, FR, and Ethernet, this support is desirable but not required. Requirements to handle out-of-order packets at all vary among services and deployments. For example, for Ethernet PW, occasional (very rare) reordering is usually acceptable. If the Ethernet PW is carrying MPLS-TP, then this reordering may be acceptable.
本质上不是定时关键比特流的PW服务是面向单元或面向帧的。尽管重排支持可能有利于PW信元和面向帧的有效负载，如ATM、FR和以太网，但这种支持是可取的，但不是必需的。处理无序数据包的要求因服务和部署而异。例如，对于以太网PW，偶尔（非常罕见）重新排序通常是可以接受的。如果以太网PW承载MPLS-TP，则可以接受这种重新排序。
Reducing jitter is best done by an end-system, given that the tradeoff of loss vs. delay varies among services. For example, with interactive real-time services, low delay is preferred, while with non-interactive (one-way) real-time services, low loss is preferred. The same end-site may be receiving both types of traffic. Regardless of this, bounded jitter is sometimes a requirement for specific deployments.
减少抖动最好由终端系统来完成，因为损失与延迟之间的权衡因服务而异。例如，对于交互式实时服务，首选低延迟，而对于非交互式（单向）实时服务，首选低损耗。同一终端站点可能接收两种类型的流量。尽管如此，特定部署有时需要有界抖动。
Packet reordering should be rare except in a small number of circumstances, most of which are due to network design or equipment design errors:
除了少数情况外，数据包重新排序应该很少，其中大多数情况是由于网络设计或设备设计错误：
1. The most common case is where reordering is rare, occurring only when a network or equipment fault forces traffic on a new path with different delay. The packet loss that accompanies a network or equipment fault is generally more disruptive than any reordering that may occur.
1. 最常见的情况是很少发生重新排序，仅当网络或设备故障迫使流量以不同延迟在新路径上时才会发生。伴随网络或设备故障的数据包丢失通常比可能发生的任何重新排序更具破坏性。
2. A path change can be caused by reasons other than a network or equipment fault, such as an administrative routing change. This may result in packet reordering but generally without any packet loss.
2. 路径更改可能由网络或设备故障以外的原因引起，例如管理路由更改。这可能导致数据包重新排序，但通常不会造成任何数据包丢失。
3. If the edge is not using pseudowire Control Word (CW) and the core is using multipath, reordering will be far more common. If this is occurring, using CW on the edge will solve the problem. Without CW, resequencing is not possible since the Sequence Number is contained in the CW.
3. 如果边缘不使用伪线控制字（CW），而核心使用多路径，则重新排序将更为常见。如果出现这种情况，在边缘使用CW将解决问题。如果没有CW，则无法重新排序，因为序列号包含在CW中。
4. Another avoidable case is where some core equipment has multipath and for some reason insists on periodically installing a new random number as the multipath hash seed. If supporting MPLS-TP, equipment MUST provide a means to disable periodic hash reseeding, and deployments MUST disable periodic hash reseeding. Operator experience dictates that even if not supporting MPLS-TP, equipment SHOULD provide a means to disable periodic hash reseeding, and deployments SHOULD disable periodic hash reseeding.
4. 另一个可以避免的情况是，一些核心设备具有多路径，并且出于某种原因坚持定期安装一个新的随机数作为多路径散列种子。如果支持MPLS-TP，则设备必须提供禁用定期散列重播的方法，部署必须禁用定期散列重播。运营商的经验表明，即使不支持MPLS-TP，设备也应提供一种禁用定期散列重播的方法，部署应禁用定期散列重播。
In provider networks that use multipath techniques and that may occasionally rebalance traffic or that may change PW paths occasionally for other reasons, reordering may be far more common than loss. Where reordering is more common than loss, resequencing packets is beneficial, rather than dropping packets at egress when out-of-order arrival occurs. Resequencing is most important for PW payload types with a high expectation of lossless delivery since in such cases out-of-order delivery within the network results in PW loss.
在使用多路径技术的提供商网络中，偶尔会重新平衡流量，或者偶尔会因为其他原因改变PW路径，重新排序可能比丢失更常见。在重排序比丢失更常见的情况下，重排序数据包是有益的，而不是在出现无序到达时在出口丢弃数据包。重新排序对于PW有效负载类型最为重要，因为在这种情况下，网络内的无序交付会导致PW丢失，因此对无损交付的期望很高。
Layer 2 VPN [RFC4664] and Layer 3 VPN [RFC4110] add one or more label entry to the MPLS label stack. VPN encapsulations are out of scope for this document. Their impact on forwarding at the midpoint LSR are within scope.
第2层VPN[RFC4664]和第3层VPN[RFC4110]向MPLS标签堆栈添加一个或多个标签条目。VPN封装超出了本文档的范围。它们对中点LSR转发的影响在范围之内。
Any of these services may be used on an ingress and egress that are MPLS Entropy Label enabled (see Section 2.4.4 for discussion of Entropy Label); this would add an additional two labels to the MPLS label stack. The need to provide a useful Entropy Label value impacts the requirements of the VPN ingress LER but is out of scope for this document.
这些服务中的任何一项都可以在启用MPLS熵标签的入口和出口上使用（熵标签的讨论见第2.4.4节）；这将向MPLS标签堆栈添加另外两个标签。需要提供有用的熵标签值会影响VPN入口LER的要求，但不在本文档的范围内。
MPLS Multicast encapsulation is clarified in [RFC5332]. MPLS Multicast may be signaled using RSVP-TE [RFC4875] or LDP [RFC6388].
[RFC5332]中阐明了MPLS多播封装。MPLS多播可以使用RSVP-TE[RFC4875]或LDP[RFC6388]发信号。
[RFC4875] defines a root-initiated RSVP-TE LSP setup rather than the leaf-initiated join used in IP multicast. [RFC6388] defines a leaf-initiated LDP setup. Both [RFC4875] and [RFC6388] define point-to-multipoint (P2MP) LSP setup. [RFC6388] also defined multipoint-to-multipoint (MP2MP) LSP setup.
[RFC4875]定义根启动的RSVP-TE LSP设置，而不是IP多播中使用的叶启动的连接。[RFC6388]定义叶启动的LDP设置。[RFC4875]和[RFC6388]都定义了点对多点（P2MP）LSP设置。[RFC6388]还定义了多点对多点（MP2MP）LSP设置。
The P2MP LSPs have a single source. An LSR may be a leaf node, an intermediate node, or a "bud" node. A bud serves as both a leaf and intermediate. At a leaf, an MPLS pop is performed. The payload may be an IP multicast packet that requires further replication. At an intermediate node, an MPLS swap operation is performed. The bud requires that both a pop operation and a swap operation be performed for the same incoming packet.
P2MP LSP只有一个源。LSR可以是叶节点、中间节点或“芽”节点。芽既是叶子又是中间物。在叶上，执行MPLS pop。有效载荷可以是需要进一步复制的IP多播分组。在中间节点，执行MPLS交换操作。bud要求对同一传入数据包执行pop操作和交换操作。
One strategy to support P2MP functionality is to pop at the LSR interface serving as ingress to the P2MP traffic and then optionally push labels at each LSR interface serving as egress to the P2MP traffic at that same LSR. A given LSR egress chip may support multiple egress interfaces, each of which requires a copy, but each with a different set of added labels and Layer 2 encapsulation. Some physical interfaces may have multiple sub-interfaces (such as Ethernet VLAN or channelized interfaces), each requiring a copy.
支持P2MP功能的一种策略是在作为P2MP流量入口的LSR接口处弹出，然后在作为同一LSR的P2MP流量出口的每个LSR接口处选择性地推送标签。给定的LSR出口芯片可以支持多个出口接口，每个出口接口都需要一个副本，但每个出口都有一组不同的附加标签和第2层封装。一些物理接口可能有多个子接口（如以太网VLAN或信道化接口），每个子接口都需要一个副本。
If packet replication is performed at LSR ingress, then the ingress interface performance may suffer. If the packet replication is performed within a LSR switching fabric and at LSR egress, congestion of egress interfaces cannot make use of backpressure to ingress interfaces using techniques such as virtual output queuing (VOQ). If buffering is primarily supported at egress, then the need for backpressure is minimized. There may be no good solution for high volumes of multicast traffic if VOQ is used.
如果在LSR入口执行数据包复制，则入口接口性能可能会受到影响。如果分组复制在LSR交换结构内和LSR出口处执行，则出口接口的拥塞不能利用诸如虚拟输出队列（VOQ）等技术对入口接口的背压。如果缓冲主要是在出口处支持的，那么背压的需要就最小化了。如果使用VOQ，可能没有解决大量多播流量的好方法。
Careful consideration should be given to the performance characteristics of high-fanout multicast for equipment that is intended to be used in such a role.
应仔细考虑拟用于此类角色的设备的高扇出多播的性能特征。
MP2MP LSPs differ in that any branch may provide an input, including a leaf. Packets must be replicated onto all other branches. This forwarding is often implemented as multiple P2MP forwarding trees, one for each potential input interface at a given LSR.
MP2MP LSP的不同之处在于，任何分支都可以提供输入，包括叶。数据包必须复制到所有其他分支上。这种转发通常被实现为多个P2MP转发树，一个用于给定LSR的每个潜在输入接口。
While average packet size of Internet traffic may be large, long sequences of small packets have both been predicted in theory and observed in practice. Traffic compression and TCP ACK compression can conspire to create long sequences of packets of 40-44 bytes in payload length. If carried over Ethernet, the 64-byte minimum payload applies, yielding a packet rate of approximately 150 Mpps (million packets per second) for the duration of the burst on a nominal 100 Gb/s link. The peak rate for other encapsulations can be as high as 250 Mpps (for example, when IP or MPLS is encapsulated using GFP over OTN ODU4).
虽然互联网流量的平均数据包大小可能很大，但理论上和实践中都预测到了小数据包的长序列。流量压缩和TCP ACK压缩可以共同创建有效负载长度为40-44字节的长数据包序列。如果通过以太网传输，则应用64字节的最小有效负载，在标称100 Gb/s链路上的突发持续时间内，产生约150 Mpps（百万数据包/秒）的数据包速率。其他封装的峰值速率可高达250 Mpps（例如，当使用OTN ODU4上的GFP封装IP或MPLS时）。
It is possible that the packet rates achieved by a specific implementation are acceptable for a minimum payload size, such as a 64-byte (64B) payload for Ethernet, but the achieved rate declines to an unacceptable level for other packet sizes, such as a 65B payload. There are other packet rates of interest besides TCP ACK. For example, a TCP ACK carried over an Ethernet PW over MPLS over Ethernet may occupy 82B or 82B plus an increment of 4B if additional MPLS labels are present.
对于最小有效负载大小（例如以太网的64字节（64B）有效负载），通过特定实现实现的分组速率可能是可接受的，但是对于其他分组大小（例如65B有效负载），实现的速率下降到不可接受的水平。除了TCP ACK，还有其他数据包利率。例如，如果存在额外的MPLS标签，则通过以太网PW通过MPLS通过以太网携带的TCP ACK可能占用82B或82B加上4B的增量。
A graph of packet rate vs. packet size often displays a sawtooth. The sawtooth is commonly due to a memory bottleneck and memory widths, sometimes an internal cache, but often a very wide external buffer memory interface. In some cases, it may be due to a fabric transfer width. A fine packing, rounding up to the nearest 8B or 16B will result in a fine sawtooth with small degradation for 65B, and even less for 82B packets. A coarse packing, rounding up to 64B can yield a sharper drop in performance for 65B packets, or perhaps more important, a larger drop for 82B packets.
数据包速率与数据包大小的关系图通常显示为锯齿形。锯齿波通常是由于内存瓶颈和内存宽度造成的，有时是内部缓存，但通常是非常宽的外部缓冲内存接口。在某些情况下，这可能是由于织物转移宽度造成的。精细的包装，四舍五入到最接近的8B或16B，将导致65B的锯齿状小劣化，82B包的锯齿状劣化甚至更小。粗包装，四舍五入到64B可以使65B数据包的性能下降更大，或者更重要的是，82B数据包的性能下降更大。
The loss of some TCP ACK packets are not the primary concern when such a burst occurs. When a burst occurs, any other packets, regardless of packet length and packet QoS are dropped once on-chip input buffers prior to the decision engine are exceeded. Buffers in front of the packet decision engine are often very small or nonexistent (less than one packet of buffer) causing significant QoS-agnostic packet drop.
发生这种突发时，一些TCP ACK数据包的丢失不是主要问题。当突发发生时，一旦超过决策引擎之前的片上输入缓冲区，则丢弃任何其他数据包，无论数据包长度和数据包QoS如何。数据包决策引擎前面的缓冲区通常非常小或不存在（少于一个缓冲区数据包），从而导致严重的QoS不可知数据包丢失。
Internet service providers and content providers at one time specified full rate forwarding with 40-byte payload packets as a requirement. Today, this requirement often can be waived if the provider can be convinced that when long sequences of short packets occur no packets will be dropped.
互联网服务提供商和内容提供商一次性指定全速率转发，要求使用40字节有效负载数据包。今天，如果提供者确信当短数据包的长序列出现时，不会丢弃任何数据包，则通常可以放弃这一要求。
Many equipment suppliers have pointed out that the extra cost in designing hardware capable of processing the minimum size packets at full line rate is significant for very-high-speed interfaces. If hardware is not capable of processing the minimum size packets at full line rate, then that hardware MUST be capable of handling large bursts of small packets, a condition that is often observed. This level of performance is necessary to meet Differentiated Services [RFC2475] requirements; without it, packets are lost prior to inspection of the IP DSCP field [RFC2474] or MPLS TC field [RFC5462].
许多设备供应商已经指出，对于非常高速的接口，设计能够以全线路速率处理最小大小数据包的硬件的额外成本是非常重要的。如果硬件不能以全行速率处理最小大小的数据包，那么该硬件必须能够处理小数据包的大突发，这是经常观察到的情况。此性能级别是满足差异化服务[RFC2475]要求所必需的；没有它，数据包在检查IP DSCP字段[RFC2474]或MPLS TC字段[RFC5462]之前丢失。
With adequate on-chip buffers before the packet decision engine, an LSR can absorb a long sequence of short packets. Even if the output is slowed to the point where light congestion occurs, the packets, having cleared the decision process, can make use of larger VOQ or output side buffers and be dealt with according to configured QoS treatment, rather than dropped completely at random.
在包决策引擎之前有足够的片上缓冲区，LSR可以吸收长序列的短包。即使输出速度减慢到出现轻微拥塞的程度，在清除了决策过程后，数据包也可以使用较大的VOQ或输出端缓冲区，并根据配置的QoS处理进行处理，而不是完全随机丢弃。
The buffering before the packet decision engine should be arranged such that 1) it can hold a relatively large number of small packets, 2) it can hold a small number of large packets, and 3) it can hold a mix of packets of different sizes.
分组决策引擎之前的缓冲应安排为1）它可以容纳相对大量的小分组，2）它可以容纳少量的大分组，以及3）它可以容纳不同大小的分组的混合。
These on-chip buffers need not contribute significant delay since they are only used when the packet decision engine is unable to keep up, not in response to congestion, plus these buffers are quite small. For example, an on-chip buffer capable of handling 4K packets of 64 bytes in length, or 256KB, corresponds to 200 microseconds on a 10 Gb/s link and 20 microseconds on a 100 Gb/s link. If the packet decision engine is capable of handling packets at 90% of the full rate for small packets, then the maximum added delay is 20 microseconds and 2 microseconds, respectively, and this delay only applies if a 4K burst of short packets occurs. When no burst of short packets was being processed, no delay is added. These buffers are only needed on high-speed interfaces where it is difficult to process small packets at full line rate.
这些片上缓冲区不需要造成显著的延迟，因为它们仅在数据包决策引擎无法跟上时使用，而不是响应拥塞，加上这些缓冲区非常小。例如，能够处理长度为64字节（256KB）的4K数据包的片上缓冲区在10 Gb/s链路上对应200微秒，在100 Gb/s链路上对应20微秒。如果数据包决策引擎能够以小数据包的90%全速率处理数据包，则最大附加延迟分别为20微秒和2微秒，并且该延迟仅适用于4K短数据包突发。当未处理短数据包突发时，不会增加延迟。这些缓冲区仅在高速接口上需要，在高速接口上很难以全行速率处理小数据包。
Packet rate requirements apply regardless of which network tier the equipment is deployed in. Whether deployed in the network core or near the network edges, one of the two conditions MUST be met if Differentiated Services requirements are to be met:
无论设备部署在哪个网络层，数据包速率要求都适用。无论是部署在网络核心还是网络边缘附近，如果要满足区分服务要求，必须满足以下两个条件之一：
1. Packets must be processed at full line rate with minimum-sized packets. -OR-
1. 必须使用最小大小的数据包以全行速率处理数据包-或-
2. Packets must be processed at a rate well under generally accepted average packet sizes, with sufficient buffering prior to the packet decision engine to accommodate long bursts of small packets.
2. 数据包必须以低于普遍接受的平均数据包大小的速率进行处理，在数据包决策引擎之前有足够的缓冲以适应小数据包的长突发。
In any large provider, service providers, and content providers, hash-based multipath techniques are used in the core and in the edge. In many of these providers, hash-based multipath is also used in the larger metro networks.
在任何大型提供商、服务提供商和内容提供商中，核心和边缘都使用基于哈希的多路径技术。在许多这样的提供商中，基于散列的多路径也用于较大的城域网。
For good reason, the Differentiated Services requirements dictate that packets within a common microflow SHOULD NOT be reordered [RFC2474]. Service providers generally impose stronger requirements, commonly requiring that packets within a microflow MUST NOT be reordered except in rare circumstances such as load balancing across multiple links, path change for load balancing, or path change for other reason.
出于充分的理由，区分服务要求规定公共微流中的数据包不应重新排序[RFC2474]。服务提供商通常会提出更高的要求，通常要求微流中的数据包不得重新排序，除非在极少数情况下，如跨多个链路的负载平衡、负载平衡的路径更改或其他原因的路径更改。
The most common multipath techniques are ECMP applied at the IP forwarding level, Ethernet Link Aggregation Group (LAG) with inspection of the IP payload, and multipath on links carrying both IP and MPLS, where the IP header is inspected below the MPLS label stack. In most core networks, the vast majority of traffic is MPLS encapsulated.
最常见的多路径技术是在IP转发级别应用的ECMP、检查IP有效负载的以太网链路聚合组（LAG）以及承载IP和MPLS的链路上的多路径，其中在MPLS标签堆栈下方检查IP报头。在大多数核心网络中，绝大多数流量都是MPLS封装的。
In order to support an adequately balanced load distribution across multiple links, IP header information must be used. Common practice today is to reinspect the IP headers at each LSR and use the label stack and IP header information in a hash performed at each LSR. Further details are provided in Section 2.4.5.
为了支持跨多个链路的充分平衡负载分布，必须使用IP报头信息。目前的常见做法是在每个LSR处重新检查IP头，并在每个LSR处执行的哈希中使用标签堆栈和IP头信息。更多详情见第2.4.5节。
The use of this technique is so ubiquitous in provider networks that lack of support for multipath makes any product unsuitable for use in large core networks. This will continue to be the case in the near future, even as deployment of the MPLS Entropy Label begins to relax the core LSR multipath performance requirements given the existing deployed base of edge equipment without the ability to add an Entropy Label.
这种技术的使用在提供商网络中非常普遍，缺乏对多路径的支持使得任何产品都不适合在大型核心网络中使用。即使在MPLS熵标签的部署开始放松核心LSR多径性能要求的情况下，这种情况在不久的将来仍将继续存在，因为现有部署的边缘设备基础无法添加熵标签。
A generation of edge equipment supporting the ability to add an MPLS Entropy Label is needed before the performance requirements for core LSRs can be relaxed. However, it is likely that two generations of deployment in the future will allow core LSRs to support full packet rate only when a relatively small number of MPLS labels need to be inspected before hashing. For now, don't count on it.
在放宽核心LSR的性能要求之前，需要一代支持添加MPLS熵标签的边缘设备。然而，未来的两代部署可能仅在散列之前需要检查相对较少数量的MPLS标签时，才允许核心LSR支持全包速率。现在，不要指望它。
Common practice today is to reinspect the packet at each LSR and use information from the packet combined with a hash seed that is selected by each LSR. Where Flow Labels or Entropy Labels are used, a hash seed must be used when creating these labels.
今天的常见实践是在每个LSR处重新检查分组，并使用来自分组的信息与每个LSR选择的散列种子相结合。如果使用流标签或熵标签，则在创建这些标签时必须使用哈希种子。
Within the core of a network, some form of multipath is almost certain to be used. Multipath techniques deployed today are likely to be looking beneath the label stack for an opportunity to hash on IP addresses.
在网络的核心内，几乎肯定会使用某种形式的多路径。今天部署的多路径技术可能会在标签堆栈下面寻找对IP地址进行散列的机会。
A pseudowire encapsulated at a network edge must have a means to prevent reordering within the core if the pseudowire will be crossing a network core, or any part of a network topology where multipath is used (see [RFC4385] and [RFC4928]).
如果封装在网络边缘的伪线将穿过网络核心或使用多路径的网络拓扑的任何部分（请参见[RFC4385]和[RFC4928]），则封装在网络边缘的伪线必须具有防止核心内重新排序的方法。
Not supporting the ability to encapsulate a pseudowire with a Control Word may lock a product out from consideration. A pseudowire capability without Control Word support might be sufficient for applications that are strictly both intra-metro and low bandwidth. However, a provider with other applications will very likely not tolerate having equipment that can only support a subset of their pseudowire needs.
不支持使用控制字封装伪线的功能可能会将产品排除在考虑之外。没有控制字支持的伪线功能对于严格意义上的城域内和低带宽应用程序可能就足够了。但是，具有其他应用程序的提供商很可能不会容忍设备只能支持其伪线需求的一部分。
Where multipath makes use of a simple hash and simple load balance such as modulo or other fixed allocation (see Section 2.4), there can be the presence of large microflows that each consume 10% of the capacity of a component link of a potentially congested composite link. One such microflow can upset the traffic balance, and more than one can reduce the effective capacity of the entire composite link by more than 10%.
如果多路径利用简单散列和简单负载平衡，如模或其他固定分配（见第2.4节），则可能存在大微流，每个微流消耗潜在拥塞复合链路的组件链路容量的10%。一个这样的微流会破坏流量平衡，而不止一个微流会使整个复合链路的有效容量降低10%以上。
When even a very small number of large microflows are present, there is a significant probability that more than one of these large microflows could fall on the same component link. If the traffic contribution from large microflows is small, the probability for three or more large microflows on the same component link drops significantly. Therefore, in a network where a significant number of parallel 10 Gb/s links exists, even a 1 Gb/s pseudowire or other large microflow that could not otherwise be subdivided into smaller flows should carry a Flow Label or Entropy Label if possible.
即使存在极少量的大型微流，这些大型微流中有一个以上可能落在同一组分链路上的可能性也很大。如果来自大微流的流量贡献很小，则在同一组件链路上出现三个或更多大微流的概率会显著降低。因此，在存在大量并行10 Gb/s链路的网络中，如果可能，即使1 Gb/s伪线或其他无法细分为较小流的大型微流也应带有流标签或熵标签。
Active management of the hash space to better accommodate large microflows has been implemented and deployed in the past; however, such techniques are out of scope for this document.
过去已经实施并部署了哈希空间的主动管理，以更好地容纳大型微流；但是，此类技术不在本文档的范围内。
Unlike a pseudowire Control Word, a pseudowire Flow Label [RFC6391] is required only for pseudowires that have a relatively large capacity. There are many cases where a pseudowire Flow Label makes sense. Any service such as a VPN that carries IP traffic within a pseudowire can make use of a pseudowire Flow Label.
与伪导线控制字不同，只有容量相对较大的伪导线才需要伪导线流标签[RFC6391]。在许多情况下，伪导线流标签是有意义的。任何服务，例如在伪线内承载IP流量的VPN，都可以使用伪线流标签。
Any pseudowire carried over MPLS that makes use of the pseudowire Control Word and does not carry a Flow Label is in effect a single microflow (in the terms defined in [RFC2475]) and may result in the types of problems described in Section 2.4.2.
使用伪线控制字且不携带流标签的MPLS上携带的任何伪线实际上是单个微流（按照[RFC2475]中定义的术语），可能导致第2.4.2节中描述的问题类型。
The MPLS Entropy Label simplifies flow group identification [RFC6790] at midpoint LSRs. Prior to the MPLS Entropy Label, midpoint LSRs needed to inspect the entire label stack and often the IP headers to provide an adequate distribution of traffic when using multipath techniques (see Section 2.4.5). With the use of the MPLS Entropy Label, a hash can be performed closer to network edges, placed in the label stack, and used by midpoint LSRs without fully reinspecting the label stack and inspecting the payload.
MPLS熵标签简化了中点LSR处的流组标识[RFC6790]。在使用MPLS熵标签之前，中点LSR需要检查整个标签堆栈，通常是IP报头，以便在使用多路径技术时提供足够的流量分布（参见第2.4.5节）。通过使用MPLS熵标签，可以在更靠近网络边缘的位置执行哈希，将其放置在标签堆栈中，并由中点LSR使用，而无需完全重新检查标签堆栈和检查有效负载。
The MPLS Entropy Label is capable of avoiding full label stack and payload inspection within the core where performance levels are most difficult to achieve (see Section 2.3). The label stack inspection can be terminated as soon as the first Entropy Label is encountered, which is generally after a small number of labels are inspected.
MPLS熵标签能够避免核心内性能水平最难达到的全标签堆栈和有效负载检查（见第2.3节）。一旦遇到第一个熵标签，标签堆叠检查就可以终止，这通常是在检查少量标签之后。
In order to provide these benefits in the core, an LSR closer to the edge must be capable of adding an Entropy Label. This support may not be required in the access tier, the tier closest to the customer, but is likely to be required in the edge or the border to the network core. An LSR peering with external networks will also need to be able to add an Entropy Label on incoming traffic.
为了在核心中提供这些好处，靠近边缘的LSR必须能够添加熵标签。在访问层（离客户最近的层）中可能不需要此支持，但在网络核心的边缘或边界中可能需要此支持。与外部网络的LSR对等还需要能够在传入流量上添加熵标签。
The most common multipath techniques are based on a hash over a set of fields. Regardless of whether a hash is used or some other method is used, there is a limited set of fields that can safely be used for multipath.
最常见的多路径技术基于一组字段上的散列。无论是使用散列还是使用其他方法，都有一组有限的字段可以安全地用于多路径。
If the "outer" or "first" layer of encapsulation is MPLS, then label stack entries are used in the hash. Within a finite amount of time (and for small packets arriving at high speed, that time can be quite limited), only a finite number of label entries can be inspected. Pipelined or parallel architectures improve this, but the limit is still finite.
如果封装的“外部”或“第一”层是MPLS，则在哈希中使用标签堆栈项。在有限的时间内（对于高速到达的小数据包，时间可能非常有限），只能检查有限数量的标签条目。流水线或并行架构改进了这一点，但限制仍然是有限的。
The following guidelines are provided for use of MPLS fields in multipath load balancing.
为在多路径负载平衡中使用MPLS字段提供了以下指南。
1. Only the 20-bit label field SHOULD be used. The TTL field SHOULD NOT be used. The S bit MUST NOT be used. The TC field (formerly EXP) MUST NOT be used. See text following this list for reasons.
1. 只能使用20位标签字段。不应使用TTL字段。不得使用S位。不得使用TC字段（以前称为EXP）。有关原因，请参阅此列表后面的文本。
2. If an ELI label is found, then if the LSR supports Entropy Labels, the EL label field in the next label entry (the EL) SHOULD be used, label entries below that label SHOULD NOT be used, and the MPLS payload SHOULD NOT be used. See below this list for reasons.
2. 如果找到ELI标签，则如果LSR支持熵标签，则应使用下一标签条目（EL）中的EL标签字段，不应使用该标签下方的标签条目，并且不应使用MPLS有效负载。有关原因，请参见下面的列表。
3. Special-purpose labels (label values 0-15) MUST NOT be used. Extended special-purpose labels (any label following label 15) MUST NOT be used. In particular, GAL and RA MUST NOT be used so that OAM traffic follows the same path as payload packets with the same label stack.
3. 不得使用特殊用途标签（标签值0-15）。不得使用扩展专用标签（标签15后的任何标签）。特别是，不能使用GAL和RA，以使OAM通信遵循与具有相同标签堆栈的有效负载数据包相同的路径。
4. If a new special-purpose label or extended special-purpose label is defined that requires special load-balance processing, then, as is the case for the ELI label, a special action may be needed rather than skipping the special-purpose label or extended special-purpose label.
4. 如果定义了需要特殊负载平衡处理的新专用标签或扩展专用标签，则与ELI标签一样，可能需要采取特殊措施，而不是跳过专用标签或扩展专用标签。
5. The most entropy is generally found in the label stack entries near the bottom of the label stack (innermost label, closest to S=1 bit). If the entire label stack cannot be used (or entire stack up to an EL), then it is better to use as many labels as possible closest to the bottom of stack.
5. 最大熵通常出现在标签堆栈底部附近的标签堆栈条目中（最里面的标签，最接近S=1位）。如果无法使用整个标签堆栈（或整个堆栈直至EL），则最好使用尽可能多的最靠近堆栈底部的标签。
6. If no ELI is encountered, and the first nibble of payload contains a 4 (IPv4) or 6 (IPv6), an implementation SHOULD support the ability to interpret the payload as IPv4 or IPv6 and extract and use appropriate fields from the IP headers. This feature is considered a nonnegotiable requirement by many service providers. If supported, there MUST be a way to disable it (if, for example, PW without CW are used). This ability to disable this feature is considered a nonnegotiable requirement by many service providers.
6. 如果未遇到ELI，并且负载的第一个半字节包含4（IPv4）或6（IPv6），则实现应支持将负载解释为IPv4或IPv6，并从IP头中提取和使用适当的字段。许多服务提供商认为此功能是不可协商的要求。如果支持，必须有一种方法来禁用它（例如，如果使用不带CW的PW）。许多服务提供商认为禁用此功能的能力是不可协商的要求。
Therefore, an implementation has a very strong incentive to support both options.
因此，实施具有支持这两种方案的强烈动机。
7. A label that is popped at egress (UHP pop) SHOULD NOT be used. A label that is popped at the penultimate hop (PHP pop) SHOULD be used.
7. 不应使用在出口处弹出的标签（UHP pop）。应该使用倒数第二个跃点处弹出的标签（PHP pop）。
Apparently, some chips have made use of the TC (formerly EXP) bits as a source of entropy. This is very harmful since it will reorder Assured Forwarding (AF) traffic [RFC2597] when a subset does not conform to the configured rates and is remarked but not dropped at a prior LSR. Traffic that uses MPLS ECN [RFC5129] can also be reordered if TC is used for entropy. Therefore, as stated in the guidelines above, the TC field (formerly EXP) MUST NOT be used in multipath load balancing as it violates Differentiated Services Ordered Aggregate (OA) requirements in these two instances.
显然，一些芯片利用了TC（以前是EXP）位作为熵源。这是非常有害的，因为当子集不符合配置的速率并且在先前的LSR中被注意到但没有丢弃时，它将重新排序保证转发（AF）通信量[RFC2597]。如果TC用于熵，则使用MPLS ECN[RFC5129]的流量也可以重新排序。因此，如上指南所述，TC字段（以前称为EXP）不得用于多路径负载平衡，因为它在这两种情况下违反了区分服务有序聚合（OA）要求。
Use of the MPLS label entry S bit would result in putting OAM traffic on a different path if the addition of a GAL at the bottom of stack removed the S bit from the prior label.
如果在堆栈底部添加GAL，则使用MPLS标签条目S位将导致将OAM通信置于不同的路径上，从而从先前的标签中移除S位。
If an ELI label is found, then if the LSR supports Entropy Labels, the EL label field in the next label entry (the EL) SHOULD be used, and the search for additional entropy within the packet SHOULD be terminated. Failure to terminate the search will impact client MPLS-TP LSPs carried within server MPLS LSPs. A network operator has the option to use administrative attributes as a means to identify LSRs that do not terminate the entropy search at the first EL. Administrative attributes are defined in [RFC3209]. Some configuration is required to support this.
如果找到ELI标签，则如果LSR支持熵标签，则应使用下一个标签条目（EL）中的EL标签字段，并且应终止对数据包内附加熵的搜索。未能终止搜索将影响服务器MPLS LSP中携带的客户端MPLS-TP LSP。网络运营商可以选择使用管理属性作为识别在第一个EL时不终止熵搜索的LSR的方法。管理属性在[RFC3209]中定义。需要一些配置来支持这一点。
If the label removed by a PHP pop is not used, then for any PW for which CW is used, there is no basis for multipath load split. In some networks, it is infeasible to put all PW traffic on one component link. Any PW that does not use CW will be improperly split, regardless of whether the label removed by a PHP pop is used. Therefore, the PHP pop label SHOULD be used as recommended above.
如果没有使用PHP pop移除的标签，那么对于使用CW的任何PW，没有多路径负载分割的基础。在某些网络中，将所有PW流量放在一个组件链路上是不可行的。任何不使用CW的PW都将被不正确地分割，无论是否使用PHP pop移除的标签。因此，应按照上述建议使用PHP pop标签。
Inspecting the IP payload provides the most entropy in provider networks. The practice of looking past the bottom of stack label for an IP payload is well accepted and documented in [RFC4928] and in other RFCs.
检查IP有效负载在提供商网络中提供了最大的熵。在[RFC4928]和其他RFC中，通过堆栈底部标签查看IP有效负载的做法已被广泛接受并记录在案。
Where IP is mentioned in the document, both IPv4 and IPv6 apply. All LSRs MUST fully support IPv6.
文件中提到IP时，IPv4和IPv6均适用。所有LSR必须完全支持IPv6。
When information in the IP header is used, the following guidelines apply:
当使用IP报头中的信息时，以下准则适用：
1. Both the IP source address and IP destination address SHOULD be used. There MAY be an option to reverse the order of these addresses, improving the ability to provide symmetric paths in some cases. Many service providers require that both addresses be used.
1. 应同时使用IP源地址和IP目标地址。可以选择反转这些地址的顺序，从而在某些情况下提高提供对称路径的能力。许多服务提供商要求使用这两个地址。
2. Implementations SHOULD allow inspection of the IP protocol field and use of the UDP or TCP port numbers. For many service providers, this feature is considered mandatory, particularly for enterprise, data center, or edge equipment. If this feature is provided, it SHOULD be possible to disable use of TCP and UDP ports. Many service providers consider it a nonnegotiable requirement that use of UDP and TCP ports can be disabled. Therefore, there is a strong incentive for implementations to provide both options.
2. 实现应该允许检查IP协议字段和使用UDP或TCP端口号。对于许多服务提供商，此功能被认为是强制性的，尤其是对于企业、数据中心或边缘设备。如果提供了此功能，则应该可以禁用TCP和UDP端口的使用。许多服务提供商认为，禁用UDP和TCP端口是不可协商的要求。因此，有一种强烈的动机促使实现提供这两种选择。
3. Equipment suppliers MUST NOT make assumptions that because the IP version field is equal to 4 (an IPv4 packet) that the IP protocol will either be TCP (IP protocol 6) or UDP (IP protocol 17) and blindly fetch the data at the offset where the TCP or UDP ports would be found. With IPv6, TCP and UDP port numbers are not at fixed offsets. With IPv4 packets carrying IP options, TCP and UDP port numbers are not at fixed offsets.
3. 设备供应商不得假设由于IP版本字段等于4（IPv4数据包），因此IP协议将是TCP（IP协议6）或UDP（IP协议17），并盲目获取TCP或UDP端口所在偏移量处的数据。在IPv6中，TCP和UDP端口号不是固定偏移量。对于携带IP选项的IPv4数据包，TCP和UDP端口号不是固定偏移量。
4. The IPv6 header flow field SHOULD be used. This is the explicit purpose of the IPv6 flow field; however, observed flow fields rarely contain a non-zero value. Some uses of the flow field have been defined, such as [RFC6438]. In the absence of MPLS encapsulation, the IPv6 flow field can serve a role equivalent to the Entropy Label.
4. 应使用IPv6标头流字段。这是IPv6流场的明确目的；然而，观测到的流场很少包含非零值。已经定义了流场的一些用途，如[RFC6438]。在没有MPLS封装的情况下，IPv6流场可以起到相当于熵标签的作用。
5. Support for other protocols that share a common Layer 4 header such as RTP [RFC3550], UDP-Lite [RFC3828], SCTP [RFC4960], and DCCP [RFC4340] SHOULD be provided, particularly for edge or access equipment where additional entropy may be needed. Equipment SHOULD also use RTP, UDP-lite, SCTP, and DCCP headers when creating an Entropy Label.
5. 应提供对共享公共第4层报头的其他协议的支持，例如RTP[RFC3550]、UDP Lite[RFC3828]、SCTP[RFC4960]和DCCP[RFC4340]，特别是对于可能需要额外熵的边缘或接入设备。创建熵标签时，设备还应使用RTP、UDP lite、SCTP和DCCP头。
6. The following IP header fields should not or must not be used:
6. 不应或不得使用以下IP标头字段：
A. Similar to avoiding TC in MPLS, the IP DSCP, and ECN bits MUST NOT be used.
A.与在MPLS中避免TC类似，不得使用IP DSCP和ECN位。
B. The IPv4 TTL or IPv6 Hop Count SHOULD NOT be used.
B.不应使用IPv4 TTL或IPv6跃点计数。
C. Note that the IP TOS field was deprecated. ([RFC0791] was updated by [RFC2474].) No part of the IP DSCP field can be used (formerly IP PREC and IP TOS bits).
请注意，IP TOS字段已弃用。（[RFC0791]已由[RFC2474]更新。）不能使用IP DSCP字段的任何部分（以前是IP PREC和IP TOS位）。
7. Some IP encapsulations support tunneling, such as IP-in-IP, GRE, L2TPv3, and IPsec. These provide a greater source of entropy that some provider networks carrying large amounts of tunneled traffic may need, for example, as used in [RFC5640] for GRE and L2TPv3. The use of tunneling header information is out of scope for this document.
7. 一些IP封装支持隧道，例如IP中的IP、GRE、L2TPv3和IPsec。这些提供了一些承载大量隧道流量的提供商网络可能需要的更大的熵源，例如，在[RFC5640]中用于GRE和L2TPv3。隧道标题信息的使用超出了本文档的范围。
This document makes the following recommendations. These recommendations are not required to claim compliance to any existing RFC; therefore, implementers are free to ignore them, but due to service provider requirements should consider the risk of doing so. The use of IP addresses MUST be supported, and TCP and UDP ports (conditional on the protocol field and properly located) MUST be supported. The ability to disable use of UDP and TCP ports MUST be available.
本文件提出以下建议。这些建议无需声明符合任何现有RFC；因此，实现者可以自由地忽略它们，但是由于服务提供者的要求应该考虑这样做的风险。必须支持使用IP地址，并且必须支持TCP和UDP端口（以协议字段为条件并正确定位）。必须具备禁用UDP和TCP端口的功能。
Though potentially very useful in some networks, it is uncommon to support using payloads of tunneling protocols carried over IP. Though the use of tunneling protocol header information is out of scope for this document, it is not discouraged.
虽然在某些网络中可能非常有用，但支持使用通过IP承载的隧道协议的有效负载是不常见的。尽管隧道协议头信息的使用超出了本文档的范围，但不鼓励这样做。
The ingress to a pseudowire (PW) can extract information from the payload being encapsulated to create a Flow Label. [RFC6391] references IP carried in Ethernet as an example. The Native Service Processing (NSP) function defined in [RFC3985] differs with pseudowire type. It is in the NSP function where information for a specific type of PW can be extracted for use in a Flow Label. Determining which fields to use for any given PW NSP is out of scope for this document.
进入伪线（PW）可以从封装的有效负载中提取信息，以创建流标签。[RFC6391]以以太网中承载的IP为例。[RFC3985]中定义的本机服务处理（NSP）功能与伪线类型不同。在NSP功能中，可以提取特定类型PW的信息，以便在流量标签中使用。确定用于任何给定PW NSP的字段超出了本文档的范围。
An Entropy Label is added at the ingress to an LSP. The payload being encapsulated is most often MPLS, a PW, or IP. The payload type is identified by the Layer 2 encapsulation (Ethernet, GFP, POS, etc.).
在LSP入口添加熵标签。被封装的有效负载通常是MPLS、PW或IP。有效负载类型由第2层封装（以太网、GFP、POS等）标识。
If the payload is MPLS, then the information used to create an Entropy Label is the same information used for local load balancing (see Section 2.4.5.1). This information MUST be extracted for use in generating an Entropy Label even if the LSR local egress interface is not a multipath.
如果有效负载是MPLS，则用于创建熵标签的信息与用于本地负载平衡的信息相同（参见第2.4.5.1节）。即使LSR本地出口接口不是多路径，也必须提取该信息以用于生成熵标签。
Of the non-MPLS payload types, only payloads that are forwarded are of interest. For example, payloads using the Address Resolution Protocol (ARP) are not forwarded, and payloads using the Connectionless-mode Network Protocol (CLNP), which is used only for IS-IS, are not forwarded.
在非MPLS有效负载类型中，只有转发的有效负载才是感兴趣的。例如，不转发使用地址解析协议（ARP）的有效载荷，不转发使用仅用于is-is的无连接模式网络协议（CLNP）的有效载荷。
The non-MPLS payload types of greatest interest are IPv4 and IPv6. The guidelines in Section 2.4.5.2 apply to fields used to create an Entropy Label.
最受关注的非MPLS有效负载类型是IPv4和IPv6。第2.4.5.2节中的指南适用于用于创建熵标签的字段。
The IP tunneling protocols mentioned in Section 2.4.5.2 may be more applicable to generation of an Entropy Label at the edge or access where deep packet inspection is practical due to lower interface speeds than in the core where deep packet inspection may be impractical.
第2.4.5.2节中提到的IP隧道协议可能更适用于在边缘或接入点生成熵标签，其中深度数据包检查由于接口速度较低而可行，而在核心中深度数据包检查可能不可行。
MPLS-TP introduces forwarding demands that will be extremely difficult to meet in a core network. Most troublesome is the requirement for Ultimate Hop Popping (UHP), the opposite of Penultimate Hop Popping (PHP). Using UHP opens the possibility of one or more MPLS pop operations plus an MPLS swap operation for each packet. The potential for multiple lookups and multiple counter instances per packet exists.
MPLS-TP引入了在核心网络中极难满足的转发需求。最麻烦的是对终极跳跃弹出（UHP）的要求，它与倒数第二跳跃弹出（PHP）相反。使用UHP可以为每个数据包提供一个或多个MPLS pop操作以及一个MPLS交换操作。每个数据包可能存在多个查找和多个计数器实例。
As networks grow and tunneling of LDP LSPs into RSVP-TE LSPs is used, and/or RSVP-TE hierarchy is used, the requirement to perform one or more MPLS pop operations plus an MPLS swap operation (and possibly a push or two) increases. If MPLS-TP LM (link monitoring) OAM is enabled at each layer, then a packet and byte count MUST be maintained for each pop and swap operation so as to offer OAM for each layer.
随着网络的增长，使用LDP LSP到RSVP-TE LSP的隧道，和/或使用RSVP-TE层次结构，执行一个或多个MPLS pop操作加上一个MPLS交换操作（以及可能的推送或推送）的要求增加。如果在每一层启用MPLS-TP LM（链路监控）OAM，则必须为每个pop和交换操作维护数据包和字节计数，以便为每一层提供OAM。
There are a number of situations in which packets are destined to a local address or where a return packet must be generated. There is a need to mitigate the potential for outage as a result of either attacks on network infrastructure, or in some cases unintentional misconfiguration resulting in processor overload. Some hardware assistance is needed for all traffic destined to the general-purpose CPU that is used in processing of the MPLS control protocol or the network management protocol and in most cases to other general-purpose CPUs residing on an LSR. This is due to the ease of overwhelming such a processor with traffic arriving on LSR high-speed interfaces, whether the traffic is malicious or not.
在许多情况下，数据包被发送到本地地址，或者必须生成返回数据包。需要降低由于网络基础设施受到攻击或在某些情况下导致处理器过载的无意错误配置而导致停机的可能性。对于发往通用CPU（用于处理MPLS控制协议或网络管理协议）的所有流量，以及在大多数情况下发往驻留在LSR上的其他通用CPU的所有流量，都需要一些硬件协助。这是因为无论流量是否为恶意流量，LSR高速接口上的流量都很容易压倒这样的处理器。
Denial of service (DoS) protection is an area requiring hardware support that is often overlooked or inadequately considered. Hardware assists are also needed for OAM, particularly the more demanding MPLS-TP OAM.
拒绝服务（DoS）保护是一个需要硬件支持的领域，经常被忽视或考虑不足。OAM也需要硬件协助，特别是要求更高的MPLS-TP OAM。
Modern equipment supports a number of control-plane and management-plane protocols. Generally, no single means of protecting network equipment from DoS attacks is sufficient, particularly for high-speed interfaces. This problem is not specific to MPLS but is a topic that cannot be ignored when implementing or evaluating MPLS implementations.
现代设备支持许多控制平面和管理平面协议。一般来说，保护网络设备免受DoS攻击的单一方法是不够的，特别是对于高速接口。这个问题不是MPLS特有的，但在实施或评估MPLS实施时，它是一个不容忽视的主题。
Two types of protections are often cited as the primary means of protecting against attacks of all kinds.
两种类型的保护通常被认为是抵御各种攻击的主要手段。
Isolated Control/Management Traffic Control and management traffic can be carried out-of-band (OOB), meaning not intermixed with payload. For MPLS, use of G-ACh and GAL to carry control and management traffic provides a means of isolation from potentially malicious payloads. Used alone, the compromise of a single node, including a small computer at a network operations center, could compromise an entire network. Implementations that send all G-ACh/GAL traffic directly to a routing engine CPU are subject to DoS attack as a result of such a compromise.
隔离控制/管理流量控制和管理流量可在带外（OOB）执行，这意味着不与有效负载混合。对于MPLS，使用G-ACh和GAL承载控制和管理流量提供了一种与潜在恶意有效负载隔离的方法。单独使用时，单个节点（包括网络运营中心的一台小型计算机）的损坏可能会损坏整个网络。将所有G-ACh/GAL通信量直接发送到路由引擎CPU的实现会由于这种妥协而受到DoS攻击。
Cryptographic Authentication Cryptographic authentication can very effectively prevent malicious injection of control or management traffic. Cryptographic authentication can in some circumstances be subject to DoS attack by overwhelming the capacity of the decryption with a high volume of malicious traffic. For very-low-speed interfaces, cryptographic authentication can be performed by the general-purpose CPU used as a routing engine. For all other cases, cryptographic hardware may be needed. For very-high-speed interfaces, even cryptographic hardware can be overwhelmed.
加密身份验证加密身份验证可以非常有效地防止恶意注入控制或管理流量。在某些情况下，加密身份验证可能会受到DoS攻击，其方法是使用大量恶意流量来压倒解密能力。对于非常低速的接口，加密身份验证可以由用作路由引擎的通用CPU执行。对于所有其他情况，可能需要加密硬件。对于非常高速的接口，即使是加密硬件也可能无法承受。
Some control and management protocols are often carried with payload traffic. This is commonly the case with BGP, T-LDP, and SNMP. It is often the case with RSVP-TE. Even when carried over G-ACh/GAL, additional measures can reduce the potential for a minor breach to be leveraged to a full network attack.
一些控制和管理协议通常与有效负载流量一起携带。BGP、T-LDP和SNMP通常都是这种情况。RSVP-TE通常就是这种情况。即使在通过G-ACh/GAL进行攻击时，额外的措施也可以降低利用轻微漏洞进行全面网络攻击的可能性。
Some of the additional protections are supported by hardware packet filtering.
硬件包过滤支持一些附加保护。
GTSM [RFC5082] defines a mechanism that uses the IPv4 TTL or IPv6 Hop Limit fields to ensure control traffic that can only originate from an immediate neighbor is not forged and is not originating from a distant source. GTSM can be applied to many control protocols that are routable, for example, LDP [RFC6720].
GTSM[RFC5082]定义了一种机制，该机制使用IPv4 TTL或IPv6跃点限制字段来确保只能来自近邻的控制流量不被伪造，也不来自远程源。GTSM可以应用于许多可路由的控制协议，例如LDP[RFC6720]。
IP Filtering At the very minimum, packet filtering plus classification and use of multiple queues supporting rate limiting is needed for traffic that could potentially be sent to a general-purpose CPU used as a routing engine. The first level of filtering only allows connections to be initiated from specific IP prefixes to specific destination ports and then preferably passes traffic directly to a cryptographic engine and/or rate limits. The second level of filtering passes connected traffic, such as TCP connections having received at least one authenticated SYN or having been locally initiated. The second level of filtering only passes traffic to specific address and port pairs to be checked for cryptographic authentication.
IP过滤对于可能发送到用作路由引擎的通用CPU的流量，至少需要包过滤加上支持速率限制的多个队列的分类和使用。第一级过滤仅允许从特定IP前缀启动到特定目的地端口的连接，然后优选地将流量直接传递到加密引擎和/或速率限制。第二级过滤传递连接的流量，例如已接收至少一个已验证SYN或已在本地启动的TCP连接。第二级过滤仅将通信量传递到要检查加密身份验证的特定地址和端口对。
The cryptographic authentication is generally the last resort in DoS attack mitigation. If a packet must be first sent to a general-purpose CPU, then sent to a cryptographic engine, a DoS attack is possible on high-speed interfaces. Only where hardware can fully process a cryptographic authentication without intervention from a general-purpose CPU (to find the authentication field and to identify the portion of packet to run the cryptographic algorithm over) is cryptographic authentication beneficial in protecting against DoS attacks.
密码认证通常是DoS攻击缓解的最后手段。如果必须先将数据包发送到通用CPU，然后再发送到加密引擎，则高速接口上可能存在DoS攻击。只有在硬件能够完全处理加密身份验证而无需通用CPU干预的情况下（查找身份验证字段并识别要运行加密算法的数据包部分），加密身份验证才有利于防止DoS攻击。
For chips supporting multiple 100 Gb/s interfaces, only a very large number of parallel cryptographic engines can provide the processing capacity to handle a large-scale DoS or distributed DoS (DDoS) attack. For many forwarding chips, this much processing power requires significant chip real estate and power, and therefore reduces system space and power density. For this reason, cryptographic authentication is not considered a viable first line of defense.
对于支持多个100 Gb/s接口的芯片，只有大量并行加密引擎能够提供处理大规模DoS或分布式DoS（DDoS）攻击的处理能力。对于许多转发芯片，如此高的处理能力需要大量的芯片空间和功率，因此降低了系统空间和功率密度。因此，加密身份验证不被视为可行的第一道防线。
For some networks, the first line of defense is some means of supporting OOB control and management traffic. In the past, this OOB channel might make use of overhead bits in SONET or OTN or a dedicated DWDM wavelength. G-ACh and GAL provide an alternative OOB mechanism that is independent of underlying layers. In other networks, including most IP/MPLS networks, perimeter filtering serves a similar purpose, though it is less effective without extreme vigilance.
对于某些网络，第一道防线是支持OOB控制和管理流量的一些手段。在过去，这种OOB信道可能利用SONET或OTN中的开销比特或专用DWDM波长。G-ACh和GAL提供了一种独立于底层的可选OOB机制。在其他网络（包括大多数IP/MPLS网络）中，周界过滤也有类似的用途，但如果没有高度警惕，则效果较差。
A second line of defense is filtering, including GTSM. For protocols such as EBGP, GTSM and other filtering are often the first line of defense. Cryptographic authentication is usually the last line of defense and insufficient by itself to mitigate DoS or DDoS attacks.
第二道防线是过滤，包括GTSM。对于EBGP等协议，GTSM和其他过滤通常是第一道防线。加密身份验证通常是最后一道防线，其本身不足以抵御DoS或DDoS攻击。
[RFC4377] defines requirements for MPLS OAM that predate MPLS-TP.
[RFC4379] defines what is commonly referred to as LSP Ping and LSP
Traceroute. [RFC4379] is updated by [RFC6424], which supports MPLS
tunnels and stitched LSP and P2MP LSP. [RFC4379] is updated by
[RFC6425], which supports P2MP LSP. [RFC4379] is updated by
[RFC6426] to support MPLS-TP connectivity verification (CV) and route
tracing.
[RFC4377] defines requirements for MPLS OAM that predate MPLS-TP.
[RFC4379] defines what is commonly referred to as LSP Ping and LSP
Traceroute. [RFC4379] is updated by [RFC6424], which supports MPLS
tunnels and stitched LSP and P2MP LSP. [RFC4379] is updated by
[RFC6425], which supports P2MP LSP. [RFC4379] is updated by
[RFC6426] to support MPLS-TP connectivity verification (CV) and route
tracing.
[RFC4950] extends the ICMP format to support TTL expiration that may occur when using IP Traceroute within an MPLS tunnel. The ICMP message generation can be implemented in forwarding hardware, but if the ICMP packets are sent to a general-purpose CPU, this packet flow must be rate limited to avoid a potential DoS attack.
[RFC4950]扩展了ICMP格式，以支持在MPLS隧道内使用IP跟踪路由时可能出现的TTL过期。ICMP消息生成可以在转发硬件中实现，但如果ICMP数据包被发送到通用CPU，则必须对数据包流进行速率限制，以避免潜在的DoS攻击。
[RFC5880] defines Bidirectional Forwarding Detection (BFD), a protocol intended to detect faults in the bidirectional path between two forwarding engines. [RFC5884] and [RFC5885] define BFD for MPLS. BFD can provide failure detection on any kind of path between systems, including direct physical links, virtual circuits, tunnels, MPLS Label Switched Paths (LSPs), multihop routed paths, and unidirectional links as long as there is some return path.
[RFC5880]定义了双向转发检测（BFD），该协议旨在检测两个转发引擎之间的双向路径中的故障。[RFC5884]和[RFC5885]定义MPLS的BFD。BFD可以在系统之间的任何类型的路径上提供故障检测，包括直接物理链路、虚拟电路、隧道、MPLS标签交换路径（LSP）、多跳路由路径和单向链路，只要存在一些返回路径。
The processing requirements for BFD are less than for LSP Ping, making BFD somewhat better suited for relatively high-rate proactive monitoring. BFD does not verify that the data plane matches the control plane, where LSP Ping does. LSP Ping is somewhat better suited for on-demand monitoring including relatively low-rate periodic verification of the data plane and as a diagnostic tool.
BFD的处理要求低于LSP Ping，这使得BFD在某种程度上更适合于相对高速率的主动监控。BFD不会验证数据平面是否与控制平面匹配，而LSP Ping会验证。LSP Ping在某种程度上更适合于按需监控，包括数据平面的相对低速率定期验证，以及作为诊断工具。
Hardware assistance is often provided for BFD response where BFD setup or parameter change is not involved and may be necessary for relatively high-rate proactive monitoring. If both BFD and LSP Ping are recognized in filtering prior to passing traffic to a general-purpose CPU, appropriate DoS protection can be applied (see Section 2.6.1). Failure to recognize BFD and LSP Ping and at least to rate limit creates the potential for misconfiguration to cause outages rather than cause errors in the misconfigured OAM.
在不涉及BFD设置或参数更改的情况下，通常会为BFD响应提供硬件帮助，这对于相对高速率的主动监测可能是必要的。如果在将流量传递给通用CPU之前，在过滤过程中识别出BFD和LSP Ping，则可以应用适当的DoS保护（参见第2.6.1节）。未能识别BFD和LSP Ping，并且至少未达到速率限制，可能会导致错误配置，从而导致停机，而不是在错误配置的OAM中导致错误。
Pseudowire OAM makes use of the control channel provided by Virtual Circuit Connectivity Verification (VCCV) [RFC5085]. VCCV makes use of the pseudowire Control Word. BFD support over VCCV is defined by [RFC5885]. [RFC5885] is updated by [RFC6478] in support of static pseudowires. [RFC4379] is updated by [RFC6829] to support LSP Ping for Pseudowire FEC advertised over IPv6.
伪线OAM利用虚拟电路连接验证（VCCV）[RFC5085]提供的控制通道。VCCV使用伪线控制字。VCCV上的BFD支持由[RFC5885]定义。[RFC5885]由[RFC6478]更新，以支持静态伪线。[RFC4379]由[RFC6829]更新，以支持通过IPv6播发的伪线FEC的LSP Ping。
G-ACh/GAL (defined in [RFC5586]) is the preferred MPLS-TP OAM control channel and applies to any MPLS-TP endpoints, including pseudowire. See Section 2.6.4 for an overview of MPLS-TP OAM.
G-ACh/GAL（在[RFC5586]中定义）是首选MPLS-TP OAM控制信道，适用于任何MPLS-TP端点，包括伪线。有关MPLS-TP OAM的概述，请参见第2.6.4节。
[RFC6669] summarizes the MPLS-TP OAM toolset, the set of protocols supporting the MPLS-TP OAM requirements specified in [RFC5860] and supported by the MPLS-TP OAM framework defined in [RFC6371].
[RFC6669]总结了MPLS-TP OAM工具集，该工具集支持[RFC5860]中规定的MPLS-TP OAM要求，并由[RFC6371]中定义的MPLS-TP OAM框架支持。
The MPLS-TP OAM toolset includes:
MPLS-TP OAM工具集包括：
CC-CV [RFC6428] defines BFD extensions to support proactive Continuity Check and Connectivity Verification (CC-CV) applications. [RFC6426] provides LSP Ping extensions that are used to implement on-demand connectivity verification.
CC-CV[RFC6428]定义了BFD扩展，以支持主动连续性检查和连接验证（CC-CV）应用。[RFC6426]提供用于实现按需连接验证的LSP Ping扩展。
RDI Remote Defect Indication (RDI) is triggered by failure of proactive CC-CV, which is BFD based. For fast RDI, RDI SHOULD be initiated and handled by hardware if BFD is handled in forwarding hardware. [RFC6428] provides an extension for BFD that includes the RDI in the BFD format and a specification of how this indication is to be used.
RDI远程缺陷指示（RDI）由基于BFD的主动CC-CV故障触发。对于快速RDI，如果在转发硬件中处理BFD，则RDI应由硬件启动和处理。[RFC6428]提供BFD扩展，包括BFD格式的RDI以及如何使用该指示的规范。
Route Tracing [RFC6426] specifies that the LSP Ping enhancements for MPLS-TP on-demand connectivity verification include information on the use of LSP Ping for route tracing of an MPLS-TP path.
路由跟踪[RFC6426]指定用于MPLS-TP按需连接验证的LSP Ping增强包括有关使用LSP Ping进行MPLS-TP路径路由跟踪的信息。
Alarm Reporting [RFC6427] describes the details of a new protocol supporting Alarm Indication Signal (AIS), Link Down Indication (LDI), and fault management. Failure to support this functionality in forwarding hardware can potentially result in failure to meet protection recovery time requirements; therefore, support of this functionality is strongly recommended.
报警报告[RFC6427]描述了支持报警指示信号（AIS）、链路中断指示（LDI）和故障管理的新协议的详细信息。转发硬件中不支持此功能可能导致无法满足保护恢复时间要求；因此，强烈建议支持此功能。
Lock Instruct Lock instruct is initiated on demand and therefore need not be implemented in forwarding hardware. [RFC6435] defines a lock instruct protocol.
锁指令锁指令是按需启动的，因此无需在转发硬件中实现。[RFC6435]定义了一个锁指令协议。
Lock Reporting [RFC6427] covers lock reporting. Lock reporting need not be implemented in forwarding hardware.
锁报告[RFC6427]包括锁报告。锁定报告不需要在转发硬件中实现。
Diagnostic [RFC6435] defines protocol support for loopback. Loopback initiation is on demand and therefore need not be implemented in forwarding hardware. Loopback of packet traffic SHOULD be implemented in forwarding hardware on high-speed interfaces.
诊断[RFC6435]定义了对环回的协议支持。环回启动是按需启动的，因此无需在转发硬件中实现。包流量的环回应该在高速接口上的转发硬件中实现。
Packet Loss and Delay Measurement [RFC6374] and [RFC6375] define a protocol and profile for Packet Loss Measurement (LM) and Delay Measurement (DM). LM requires a very accurate capture and insertion of packet and byte counters when a packet is transmitted and capture of packet and byte counters when a packet is received. This capture and insertion MUST be implemented in forwarding hardware for LM OAM if high accuracy is needed. DM requires very accurate capture and insertion of a timestamp on transmission and capture of timestamp when a packet is received. This timestamp capture and insertion MUST be implemented in forwarding hardware for DM OAM if high accuracy is needed.
分组丢失和延迟测量[RFC6374]和[RFC6375]定义了分组丢失测量（LM）和延迟测量（DM）的协议和配置文件。LM要求在传输数据包时非常准确地捕获和插入数据包和字节计数器，在接收数据包时捕获数据包和字节计数器。如果需要高精度，则必须在LM OAM的转发硬件中实现此捕获和插入。DM要求在传输时非常准确地捕获和插入时间戳，并在接收到数据包时捕获时间戳。如果需要高精度，则必须在DM OAM的转发硬件中实现时间戳捕获和插入。
See Section 2.6.2 for discussion of hardware support necessary for BFD and LSP Ping.
有关BFD和LSP Ping所需的硬件支持的讨论，请参见第2.6.2节。
CC-CV and alarm reporting is tied to protection and therefore SHOULD be supported in forwarding hardware in order to provide protection for a large number of affected LSPs within target response intervals. When using MPLS-TP, since CC-CV is supported by BFD, providing hardware assistance for BFD processing helps ensure that protection recovery time requirements can be met even for faults affecting a large number of LSPs.
CC-CV和报警报告与保护相关，因此应在转发硬件中得到支持，以便在目标响应间隔内为大量受影响的LSP提供保护。在使用MPLS-TP时，由于BFD支持CC-CV，因此为BFD处理提供硬件帮助有助于确保即使是影响大量LSP的故障也能满足保护恢复时间要求。
MPLS-TP Protection State Coordination (PSC) is defined by [RFC6378] and updated by [RFC7324], which corrects some errors in [RFC6378].
MPLS-TP保护状态协调（PSC）由[RFC6378]定义，并由[RFC7324]更新，这修正了[RFC6378]中的一些错误。
[RFC6670] provides the reasons for selecting a single MPLS-TP OAM solution and examines the consequences were ITU-T to develop a second OAM solution that is based on Ethernet encodings and mechanisms.
[RFC6670]提供了选择单个MPLS-TP OAM解决方案的原因，并分析了ITU-T开发基于以太网编码和机制的第二个OAM解决方案的后果。
[RFC6310] and [RFC7023] specify the mapping of defect states between many types of hardware Attachment Circuits (ACs) and associated pseudowires (PWs). This functionality SHOULD be supported in forwarding hardware.
[RFC6310]和[RFC7023]指定了多种类型的硬件连接电路（ACs）和相关伪线（PW）之间的缺陷状态映射。转发硬件中应支持此功能。
It is beneficial if an MPLS OAM implementation can interwork with the underlying server layer and provide a means to interwork with a client layer. For example, [RFC6427] specifies an inter-layer propagation of AIS and LDI from MPLS server layer to client MPLS layers. Where the server layer uses a Layer 2 mechanism, such as Ethernet, PPP over SONET/SDH, or GFP over OTN, interwork among layers is also beneficial. For high-speed interfaces, supporting this interworking in forwarding hardware helps ensure that protection based on this interworking can meet recovery time requirements even for faults affecting a large number of LSPs.
如果MPLS OAM实现可以与底层服务器层交互，并提供与客户机层交互的方法，这将是有益的。例如，[RFC6427]指定AIS和LDI从MPLS服务器层到客户端MPLS层的层间传播。当服务器层使用第2层机制时，例如以太网、SONET/SDH上的PPP或OTN上的GFP，层间的互通也是有益的。对于高速接口，在转发硬件中支持这种互通有助于确保基于这种互通的保护能够满足恢复时间要求，即使是对于影响大量LSP的故障。
Where certain requirements must be met, such as relatively high CC-CV rates and a large number of interfaces, or strict protection recovery time requirements and a moderate number of affected LSPs, some OAM functionality must be supported by forwarding hardware. In other cases, such as highly accurate LM and DM OAM or strict protection recovery time requirements with a large number of affected LSPs, OAM functionality must be entirely implemented in forwarding hardware.
如果必须满足某些要求，如较高的CC-CV速率和大量接口，或严格的保护恢复时间要求和中等数量的受影响LSP，则转发硬件必须支持某些OAM功能。在其他情况下，例如高度精确的LM和DM OAM，或者对大量受影响的LSP有严格的保护恢复时间要求，OAM功能必须完全在转发硬件中实现。
Where possible, implementation in forwarding hardware should be in programmable hardware such that if standards are later changed or extended these changes are likely to be accommodated with hardware reprogramming rather than replacement.
在可能的情况下，转发硬件中的实现应在可编程硬件中实现，这样，如果以后更改或扩展了标准，则这些更改很可能通过硬件重新编程而不是更换来适应。
For some functionality, there is a strong case for an implementation in dedicated forwarding hardware. Examples include packet and byte counters needed for LM OAM as well as needed for management protocols. Similarly, the capture and insertion of packet and byte counts or timestamps needed for transmitted LM or DM or time synchronization packets MUST be implemented in forwarding hardware if high accuracy is required.
对于某些功能，在专用转发硬件中实现是很有必要的。示例包括LM OAM以及管理协议所需的数据包和字节计数器。类似地，如果需要高精度，则必须在转发硬件中实现传输的LM或DM或时间同步数据包所需的数据包和字节计数或时间戳的捕获和插入。
For some functions, there is a strong case to provide limited support in forwarding hardware, but an external general-purpose processor may be used if performance criteria can be met. For example, origination of RDI triggered by CC-CV, response to RDI, and Protection State Coordination (PSC) functionality may be supported by hardware, but expansion to a large number of client LSPs and transmission of AIS or RDI to the client LSPs may occur in a general-purpose processor. Some forwarding hardware supports one or more on-chip general-purpose processors that may be well suited for such a role. [RFC7324], being
对于某些功能，在转发硬件方面提供有限支持是很有必要的，但如果能够满足性能标准，则可以使用外部通用处理器。例如，由CC-CV触发的RDI的发起、对RDI的响应和保护状态协调（PSC）功能可能由硬件支持，但扩展到大量客户端LSP以及将AIS或RDI传输到客户端LSP可能在通用处理器中发生。一些转发硬件支持一个或多个片上通用处理器，这些处理器可能非常适合这种角色。[RFC7324]，被
a very recent document that affects a protection state machine that requires hardware support, underscores the importance of having a degree of programmability in forwarding hardware.
一份影响需要硬件支持的保护状态机的最新文档强调了在转发硬件时具有一定程度的可编程性的重要性。
The customer (system supplier or provider) should not dictate design, but should independently validate target functionality and performance. However, it is not uncommon for service providers and system implementers to insist on reviewing design details (under a non-disclosure agreement) due to past experiences with suppliers and to reject suppliers who are unwilling to provide details.
客户（系统供应商或提供商）不应指定设计，但应独立验证目标功能和性能。然而，服务提供商和系统实施者由于过去与供应商的经验而坚持审查设计细节（根据保密协议），并拒绝不愿提供细节的供应商，这种情况并不少见。
The IPFIX architecture is defined by [RFC5470]. IPFIX supports per-flow statistics. IPFIX information elements (IEs) are defined in [RFC7012] and include IEs for MPLS.
IPFIX体系结构由[RFC5470]定义。IPFIX支持每流统计。[RFC7012]中定义了IPFIX信息元素，包括MPLS的信息元素。
The forwarding chips used in core routers are not optimized for high-touch applications like IPFIX. Often, support for IPFIX in core routers is limited to optional IPFIX metering, which involves a 1-in-N packet sampling, limited filtering support, and redirection to either an internal CPU or an external interface. The CPU or device at the other end of the external interface then implements the full IPFIX filtering and IPFIX collector functionality.
核心路由器中使用的转发芯片未针对IPFIX等高接触应用进行优化。通常，核心路由器中对IPFIX的支持仅限于可选的IPFIX计量，这涉及1/N数据包采样、有限的过滤支持以及重定向到内部CPU或外部接口。然后，外部接口另一端的CPU或设备实现完整的IPFIX过滤和IPFIX收集器功能。
LSRs that are intended to be deployed further from the core may support lower-capacity interfaces but support higher-touch applications on the forwarding hardware and may provide dedicated hardware to support a greater subset of IPFIX functionality before handing off to a general-purpose CPU. In some cases, far from the core the entire IPFIX functionality up to and including the collector may be implemented in hardware and firmware in the forwarding silicon. It is also worth noting that at lower speeds a general-purpose CPU may become adequate to implement IPFIX, particularly if metering is used.
拟部署在远离核心的地方的LSR可支持较低容量接口，但支持转发硬件上的更高触摸应用，并可提供专用硬件，以在移交给通用CPU之前支持更大的IPFIX功能子集。在某些情况下，在远离核心的情况下，整个IPFIX功能（包括收集器）可以在转发硅中的硬件和固件中实现。还值得注意的是，在较低的速度下，通用CPU可能足以实现IPFIX，特别是在使用计量的情况下。
Service provider networks may carry up to hundreds of millions of flows on 10 Gb/s links. Most flows are very short lived, many under a second. A subset of the flows are low capacity and somewhat long lived. When Internet traffic dominates capacity, a very small subset of flows are high capacity and/or very long lived.
服务提供商网络可能在10 Gb/s链路上承载数亿个流量。大多数流的寿命都很短，很多不到一秒钟。流量的一个子集是低容量的，并且有点长寿命。当互联网流量主导容量时，流量的一小部分是高容量和/或非常长寿命的。
Two types of limitations with regard to number and size of flows have been observed.
已观察到关于流量数量和大小的两种类型的限制。
1. Some hardware cannot handle some high-capacity flows because of internal paths that are limited, such as per-packet backplane paths or paths internal or external to chips such as buffer memory paths. Such designs can handle aggregates of smaller flows. Some hardware with acknowledged limitations has been successfully deployed but may be increasingly problematic if the capacity of large microflows in deployed networks continues to grow.
1. 某些硬件无法处理某些高容量流，因为内部路径受到限制，例如每包背板路径或芯片内部或外部路径，例如缓冲存储器路径。这种设计可以处理较小流量的集合。一些具有公认局限性的硬件已成功部署，但如果部署网络中的大型微流容量继续增长，问题可能会越来越严重。
2. Some hardware approaches cannot handle a large number of flows, or a large number of large flows, due to attempting to count per flow, rather than deal with aggregates of flows. Hash techniques scale with regard to number of flows due to a fixed hash size with many flows falling into the same hash bucket. Techniques that identify individual flows have been implemented but have never successfully deployed for Internet traffic.
2. 一些硬件方法无法处理大量流，或大量大型流，因为它们试图对每个流进行计数，而不是处理流的聚合。由于固定的散列大小，许多流落在同一个散列桶中，因此散列技术根据流的数量进行缩放。识别单个流的技术已经实现，但从未成功地部署到Internet流量中。
The following questions should be asked of a supplier. These questions are grouped into broad categories and are intended to be open-ended questions to the supplier. The tests in Section 4 are intended to verify whether the supplier disclosed any compliance or performance limitations completely and accurately.
应向供应商提出以下问题。这些问题分为大类，旨在向供应商提出开放式问题。第4节中的测试旨在验证供应商是否完整准确地披露了任何合规性或性能限制。
Q#1 Can the implementation forward packets with an arbitrarily large stack depth? What limitations exist, and under what circumstances do further limitations come into play (such as high packet rate or specific features enabled or specific types of packet processing)? See Section 2.1.
Q#1实现能否转发具有任意大堆栈深度的数据包？存在哪些限制，在什么情况下会出现进一步的限制（例如高数据包速率或启用特定功能或特定类型的数据包处理）？见第2.1节。
Q#2 Is the entire set of basic MPLS functionality described in Section 2.1 supported?
问题2：是否支持第2.1节中描述的整套基本MPLS功能？
Q#3 Is the set of MPLS special-purpose labels handled correctly and with adequate performance? Are extended special-purpose labels handled correctly and with adequate performance? See Section 2.1.1.
问题3：MPLS专用标签集是否处理正确且性能充足？扩展专用标签是否正确处理且性能良好？见第2.1.1节。
Q#4 Are mappings of label value and TC to PHB handled correctly, including L-LSP mappings (RFC 3270) and CT mappings (RFC 4124) to PHB? See Section 2.1.2.
问题4：标签值和TC到PHB的映射是否正确处理，包括L-LSP映射（RFC 3270）和CT映射（RFC 4124）到PHB？见第2.1.2节。
Q#5 Is time synchronization adequately supported in forwarding hardware?
问题5：转发硬件是否充分支持时间同步？
A. Are both PTP and NTP formats supported?
A.是否同时支持PTP和NTP格式？
B. Is the accuracy of timestamp insertion and incoming stamping sufficient?
B.时间戳插入和传入戳记的准确性是否足够？
See Section 2.1.3.
见第2.1.3节。
Q#6 Is link bundling supported?
问题6：是否支持链接绑定？
A. Can an LSP be pinned to specific components?
A.LSP是否可以固定到特定组件？
B. Is the "all-ones" component link supported?
B.是否支持“全一”组件链接？
See Section 2.1.5.
见第2.1.5节。
Q#7 Is MPLS hierarchy supported?
问题7是否支持MPLS层次结构？
A. Are both PHP and UHP supported? What limitations exist on the number of pop operations with UHP?
A.PHP和UHP都支持吗？超高压pop操作的数量存在哪些限制？
B. Are the pipe, short-pipe, and uniform models supported? Are TTL and TC values updated correctly at egress where applicable?
B.是否支持管道、短管和统一模型？出口处的TTL和TC值是否正确更新（如适用）？
See Section 2.1.6 regarding MPLS hierarchy. See [RFC3443] regarding PHP, UHP, and pipe, short-pipe, and uniform models.
有关MPLS层次结构，请参见第2.1.6节。关于PHP、UHP以及管道、短管和统一模型，请参见[RFC3443]。
Q#8 Is FRR supported?
问题8：是否支持FRR？
A. Are both "One-to-One Backup" and "Facility Backup" supported?
A.是否同时支持“一对一备份”和“设施备份”？
B. What forms of IP/LDP FRR are supported?
B.支持何种形式的IP/LDP FRR？
C. How quickly does protection recovery occur?
C.保护恢复的速度有多快？
D. Does protection recovery speed increase when a fault affects a large number of protected LSPs? And if so, by how much?
D.当故障影响大量受保护的LSP时，保护恢复速度是否会增加？如果是的话，增加多少？
See Section 2.1.7.
见第2.1.7节。
Q#9 Are pseudowire Sequence Numbers handled correctly? See Section 2.1.8.1.
Q#9伪线序列号处理是否正确？见第2.1.8.1节。
Q#10 Is VPN LER functionality handled correctly and without performance issues? See Section 2.1.9.
问题10：VPN LER功能是否正确处理且没有性能问题？见第2.1.9节。
Q#11 Is MPLS multicast (P2MP and MP2MP) handled correctly?
问题11：MPLS多播（P2MP和MP2MP）处理是否正确？
A. Are packets dropped on uncongested outputs if some outputs are congested?
A.如果某些输出拥挤，是否在未拥挤的输出上丢弃数据包？
B. Is performance limited in high-fanout situations?
B.高扇出情况下的性能是否受到限制？
See Section 2.2.
见第2.2节。
Q#12 Can very small packets be forwarded at full line rate on all interfaces indefinitely? What limitations exist? And under what circumstances do further limitations come into play (such as specific features enabled or specific types of packet processing)?
Q#12非常小的数据包能否在所有接口上以全线路速率无限期地转发？存在哪些限制？在什么情况下会出现进一步的限制（例如启用特定功能或特定类型的数据包处理）？
Q#13 Customers must decide whether to relax the prior requirement and to what extent. If the answer to the prior question indicates that limitations exist, then:
Q#13客户必须决定是否放宽先前的要求以及放宽到何种程度。如果前面问题的答案表明存在限制，则：
A. What is the smallest packet size where full line rate forwarding can be supported?
A.支持全线路速率转发的最小数据包大小是多少？
B. What is the longest burst of full-rate small packets that can be supported?
B.可支持的最长全速率小包突发是什么？
Specify circumstances (such as specific features enabled or specific types of packet processing) that often impact these rates and burst sizes.
指定经常影响这些速率和突发大小的情况（例如启用的特定功能或特定类型的数据包处理）。
Q#14 How many pop operations can be supported along with a swap operation at full line rate while maintaining per-LSP packet and byte counts for each pop and swap? This requirement is particularly relevant for MPLS-TP.
Q#14在保持每个pop和交换的每个LSP数据包和字节计数的同时，一个交换操作可以支持多少pop操作？这一要求与MPLS-TP特别相关。
Q#15 How many label push operations can be supported. While this limitation is rarely an issue, it applies to both PHP and UHP, unlike the pop limit that applies to UHP.
问题15：可以支持多少标签推送操作。虽然这一限制很少成为问题，但它适用于PHP和UHP，与适用于UHP的pop限制不同。
Q#16 For a worst case where all packets arrive on one LSP, what is the counter overflow time? Are any means provided to avoid polling all counters at short intervals? This applies to both MPLS and MPLS-TP.
问题16对于所有数据包都到达一个LSP的最坏情况，计数器溢出时间是多少？是否提供了避免短时间轮询所有计数器的方法？这适用于MPLS和MPLS-TP。
Multipath capabilities and performance do not apply to MPLS-TP, but they apply to MPLS and apply if MPLS-TP is carried in MPLS.
多路径能力和性能不适用于MPLS-TP，但它们适用于MPLS，并且在MPLS中承载MPLS-TP时也适用。
Q#17 How are large microflows accommodated? Is there active management of the hash space mapping to output ports? See Section 2.4.2.
问题17：如何容纳大型微流？是否有到输出端口的哈希空间映射的活动管理？见第2.4.2节。
Q#18 How many MPLS labels can be included in a hash based on the MPLS label stack?
Q#18基于MPLS标签堆栈的散列中可以包含多少个MPLS标签？
Q#19 Is packet rate performance decreased beyond some number of labels?
Q#19超过一定数量的标签后，包速率性能是否会下降？
Q#20 Can the IP header and payload information below the MPLS stack be used in the hash? If so, which IP fields, payload types, and payload fields are supported?
Q#20 MPLS堆栈下的IP头和有效负载信息能否用于哈希？如果是，支持哪些IP字段、有效负载类型和有效负载字段？
Q#21 At what maximum MPLS label stack depth can Bottom of Stack and an IP header appear without impacting packet rate performance?
Q#21在不影响数据包速率性能的情况下，MPLS标签堆栈的最大深度是多少？
Q#22 Are special-purpose labels excluded from the label stack hash? Are extended special-purpose labels excluded from the label stack hash? See Section 2.4.5.1.
Q#22特殊用途标签是否从标签堆栈哈希中排除？扩展专用标签是否从标签堆栈哈希中排除？见第2.4.5.1节。
Q#23 How is multipath performance affected by high-capacity flows, an extremely large number of flows, or very short-lived flows? See Section 2.7.
Q#23高容量流、大量流或非常短的流对多路径性能有何影响？见第2.7节。
Q#24 Is the pseudowire Control Word supported?
Q#24是否支持伪线控制字？
Q#25 What is the maximum rate of pseudowire encapsulation and decapsulation? Apply the same questions as in Section 3.2 ("Basic Performance") for any packet-based pseudowire, such as IP VPN or Ethernet.
Q#25伪导线封装和去封装的最大速率是多少？对任何基于数据包的伪线（如IP VPN或以太网）应用与第3.2节（“基本性能”）中相同的问题。
Q#26 Does inclusion of a pseudowire Control Word impact performance?
问题26：包含伪线控制字是否会影响性能？
Q#27 Are Flow Labels supported?
问题27：是否支持流标签？
Q#28 If so, what fields are hashed on for the Flow Label for different types of pseudowires?
Q#28如果是，对于不同类型的伪导线，流标签的散列字段是什么？
Q#29 Does inclusion of a Flow Label impact performance?
问题29：包含流标签是否会影响性能？
Q#30 Can an Entropy Label be added when acting as an ingress LER, and can it be removed when acting as an egress LER?
Q#30作为入口LER时是否可以添加熵标签，作为出口LER时是否可以删除熵标签？
Q#31 If an Entropy Label can be added, what fields are hashed on for the Entropy Label?
Q#31如果可以添加熵标签，熵标签的散列字段是什么？
Q#32 Does adding or removing an Entropy Label impact packet rate performance?
Q#32添加或删除熵标签是否会影响数据包速率性能？
Q#33 Can an Entropy Label be detected in the label stack, used in the hash, and properly terminate the search for further information to hash on?
Q#33是否可以在标签堆栈中检测熵标签并在哈希中使用，并正确终止对要哈希的进一步信息的搜索？
Q#34 Does using an Entropy Label have any negative impact on performance? It should have no impact or a positive impact.
Q#34使用熵标签对性能有负面影响吗？它应该没有影响或产生积极影响。
Q#35 For each control- and management-plane protocol in use, what measures are taken to provide DoS attack hardening?
Q#35对于使用中的每个控制和管理平面协议，采取了哪些措施来加强DoS攻击？
Q#36 Have DoS attack tests been performed?
Q#36是否进行了DoS攻击测试？
Q#37 Can compromise of an internal computer on a management subnet be leveraged for any form of attack including DoS attack?
Q#37管理子网上的内部计算机的安全漏洞是否可以用于任何形式的攻击，包括DoS攻击？
Q#38 What OAM proactive and on-demand mechanisms are supported?
问题38支持哪些OAM主动式和按需机制？
Q#39 What performance limits exist under high proactive monitoring rates?
Q#39在高主动监控率下存在哪些性能限制？
Q#40 Can excessively high proactive monitoring rates impact control-plane performance or cause control-plane instability?
Q#40过高的主动监控率是否会影响控制机性能或导致控制机不稳定？
Q#41 Ask the prior questions for each of the following.
Q#41针对以下每一个问题，询问之前的问题。
A. MPLS OAM
A.MPLS OAM
B. Pseudowire OAM
B.伪线OAM
C. MPLS-TP OAM
C.MPLS-TP OAM
D. Layer 2 OAM Interworking
D.第2层OAM互通
See Section 2.6.
见第2.6节。
Packet rate performance of equipment supporting a large number of 10 Gb/s or 100 Gb/s links is not possible using desktop computers or workstations. The use of high-end workstations as a source of test traffic was barely viable 20 years ago but is no longer at all viable. Though custom microcode has been used on specialized router forwarding cards to serve the purpose of generating test traffic and measuring it, for the most part, performance testing will require specialized test equipment. There are multiple sources of suitable equipment.
支持大量10 Gb/s或100 Gb/s链路的设备的数据包速率性能不可能使用台式计算机或工作站。使用高端工作站作为测试流量的来源在20年前几乎不可行，但现在根本不可行。尽管专用路由器转发卡上已使用自定义微码来生成测试流量并对其进行测量，但在大多数情况下，性能测试将需要专用测试设备。合适的设备有多种来源。
The set of tests listed here do not correspond one-to-one to the set of questions in Section 3. The same categorization is used, and these tests largely serve to validate answers provided to the prior questions. They can also provide answers where a supplier is unwilling to disclose compliance or performance.
此处列出的测试集与第3节中的问题集不一一对应。使用相同的分类，这些测试主要用于验证前面问题的答案。如果供应商不愿意披露合规性或绩效，他们也可以提供答案。
Performance testing is the domain of the IETF Benchmark Methodology Working Group (BMWG). Below are brief descriptions of conformance and performance tests. Some very basic tests, specified in [RFC5695], partially cover only the basic performance test T#3.
性能测试是IETF基准方法工作组（BMWG）的领域。以下是一致性和性能测试的简要说明。[RFC5695]中规定的一些非常基本的测试仅部分涵盖基本性能测试T#3。
The following tests should be performed by the systems designer or deployer; or, if it is not practical for the potential customer to perform the tests directly, they may be performed by the supplier on their behalf. These tests are grouped into broad categories.
以下测试应由系统设计师或部署人员执行；或者，如果潜在客户无法直接执行测试，则供应商可代表其执行测试。这些测试分为大类。
The tests in Section 4.1 should be repeated under various conditions to retest basic performance when critical capabilities are enabled. Complete repetition of the performance tests enabling each capability and combinations of capabilities would be very time intensive; therefore, a reduced set of performance tests can be used to gauge the impact of enabling specific capabilities.
应在各种条件下重复第4.1节中的测试，以在启用关键功能时重新测试基本性能。完全重复性能测试，以实现每种能力和能力组合，将非常耗时；因此，可以使用一组简化的性能测试来衡量启用特定功能的影响。
T#1 Test forwarding at a high rate for packets with varying number of label entries. While packets with more than a dozen label entries are unlikely to be used in any practical scenario today, it is useful to know if limitations exists.
T#1测试具有不同标签条目的数据包的高速转发。虽然现在在任何实际场景中都不太可能使用带有十几个标签条目的数据包，但了解是否存在限制是很有用的。
T#2 For each of the questions listed under "Basic Compliance" in Section 3, verify the claimed compliance. For any functionality considered critical to a deployment, the applicable performance using each capability under load should be verified in addition to basic compliance.
T#2对于第3节“基本合规性”下列出的每个问题，验证声称的合规性。对于被认为对部署至关重要的任何功能，除了基本符合性之外，还应验证在负载下使用每个功能的适用性能。
T#3 Test packet forwarding at full line rate with small packets. See [RFC5695]. The most likely case to fail is the smallest packet size. Also, test with packet sizes in 4-byte increments ranging from payload sizes of 40 to 128 bytes.
T#3使用小数据包以全线路速率测试数据包转发。参见[RFC5695]。最有可能失败的情况是最小的数据包大小。此外，以4字节增量使用数据包大小进行测试，有效负载大小从40字节到128字节不等。
T#4 If the prior tests did not succeed for all packet sizes, then perform the following tests.
T#4如果之前的测试没有在所有数据包大小下成功，则执行以下测试。
A. Increase the packet size by 4 bytes until a size is found that can be forwarded at full rate.
A.将数据包大小增加4个字节，直到找到可以全速转发的大小。
B. Inject bursts of consecutive small packets into a stream of larger packets. Allow some time for recovery between bursts. Increase the number of packets in the burst until packets are dropped.
B.将连续小包的突发注入到较大包的流中。在两次爆发之间留出一些时间进行恢复。增加突发中的数据包数量，直到数据包被丢弃。
T#5 Send test traffic where a swap operation is required. Also set up multiple LSPs carried over other LSPs where the device under test (DUT) is the egress of these LSPs. Create test packets such that the swap operation is performed after pop operations, increasing the number of pop operations until forwarding of small packets at full line rate can no longer be supported. Also, check to see how many pop operations can be supported before the full set of counters can no longer be maintained. This requirement is particularly relevant for MPLS-TP.
T#5在需要交换操作的地方发送测试流量。还应设置多个LSP，这些LSP由其他LSP承载，其中被测设备（DUT）是这些LSP的出口。创建测试数据包，以便在pop操作之后执行交换操作，增加pop操作的数量，直到不再支持以全线路速率转发小数据包。此外，请检查在无法再维护全套计数器之前可以支持多少pop操作。这一要求与MPLS-TP特别相关。
T#6 Send all traffic on one LSP and see if the counters become inaccurate. Often, counters on silicon are much smaller than the 64-bit packet and byte counters in various IETF MIBs. System developers should consider what counter polling rate is necessary to maintain accurate counters and whether those polling rates are practical. Relevant MIBs for MPLS are discussed in [RFC4221] and [RFC6639].
T#6在一个LSP上发送所有流量，并查看计数器是否变得不准确。通常，硅上的计数器比各种IETF MIB中的64位数据包和字节计数器小得多。系统开发人员应该考虑什么是反投票率，以保持精确的计数器和这些轮询率是否实用。[RFC4221]和[RFC6639]中讨论了MPLS的相关MIB。
T#7 [RFC6894] provides a good basis for MPLS FRR testing. Similar testing should be performed to determine restoration times; however, this testing is far more difficult to perform due to the need for a simulated test topology that is capable of simulating the signaling used in restoration. The simulated topology should be comparable with the target deployment in the
T#7[RFC6894]为MPLS FRR测试提供了良好的基础。应进行类似测试，以确定恢复时间；然而，由于需要能够模拟恢复中使用的信令的模拟测试拓扑，因此该测试更难执行。模拟的拓扑应与中的目标部署相比较
number of nodes and links and in resource usage flooding and setup delays. Some commercial test equipment can support this type of testing.
节点和链接的数量以及资源使用泛滥和设置延迟。一些商业测试设备可以支持这种类型的测试。
Multipath capabilities do not apply to MPLS-TP but apply to MPLS and apply if MPLS-TP is carried in MPLS.
多路径功能不适用于MPLS-TP，但适用于MPLS，如果MPLS中携带了MPLS-TP，则适用。
T#8 Send traffic at a rate well exceeding the capacity of a single multipath component link, and where entropy exists only below the top of stack. If only the top label is used, this test will fail immediately.
T#8发送流量的速率远远超过单个多径分量链路的容量，并且熵仅存在于堆栈顶部以下。如果只使用顶部标签，该测试将立即失败。
T#9 Move the labels with entropy down in the stack until either the full forwarding rate can no longer be supported or most or all packets try to use the same component link.
T#9在堆栈中向下移动带有熵的标签，直到不再支持完全转发速率，或者大部分或所有数据包尝试使用相同的组件链接。
T#10 Repeat the two tests above with the entropy contained in IP headers or IP payload fields below the label stack rather than in the label stack. Test with the set of IP headers or IP payload fields considered relevant to the deployment or to the target market.
T#10使用标签堆栈下方而非标签堆栈中的IP头或IP有效负载字段中包含的熵重复上述两个测试。使用与部署或目标市场相关的一组IP头或IP有效负载字段进行测试。
T#11 Determine whether traffic that contains a pseudowire Control Word is interpreted as IP traffic. Information in the payload MUST NOT be used in the load balancing if the first nibble of the packet is not 4 or 6 (IPv4 or IPv6).
T#11确定是否将包含伪线控制字的通信量解释为IP通信量。如果数据包的第一个半字节不是4或6（IPv4或IPv6），则负载中的信息不得用于负载平衡。
T#12 Determine whether special-purpose labels and extended special-purpose labels are excluded from the label stack hash. They MUST be excluded.
T#12确定是否从标签堆栈哈希中排除专用标签和扩展专用标签。它们必须被排除在外。
T#13 Perform testing in the presence of combinations of:
T#13在以下组合存在的情况下进行测试：
A. Very large microflows.
A.非常大的微流。
B. Relatively short-lived high-capacity flows.
B.相对短期的高容量流量。
C. Extremely large numbers of flows.
C.流量非常大。
D. Very short-lived small flows.
D.非常短暂的小流量。
T#14 Ensure that pseudowire can be set up with a pseudowire label and pseudowire Control Word added at ingress and the pseudowire label and pseudowire Control Word removed at egress.
T#14确保可以设置伪线，在入口添加伪线标签和伪线控制字，在出口删除伪线标签和伪线控制字。
T#15 For pseudowire that contains variable-length payload packets, repeat performance tests listed under "Basic Performance" for pseudowire ingress and egress functions.
T#15对于包含可变长度有效负载数据包的伪线，对伪线入口和出口功能重复“基本性能”下列出的性能测试。
T#16 Repeat pseudowire performance tests with and without a pseudowire Control Word.
T#16使用和不使用伪线控制字重复伪线性能测试。
T#17 Determine whether pseudowire can be set up with a pseudowire label, Flow Label, and pseudowire Control Word added at ingress and the pseudowire label, Flow Label, and pseudowire Control Word removed at egress.
T#17确定是否可以通过在入口添加伪线标签、流标签和伪线控制字以及在出口移除伪线标签、流标签和伪线控制字来设置伪线。
T#18 Determine which payload fields are used to create the Flow Label and whether the set of fields and algorithm provide sufficient entropy for load balancing.
T#18确定哪些有效负载字段用于创建流标签，以及字段集和算法是否为负载平衡提供足够的熵。
T#19 Repeat pseudowire performance tests with Flow Labels included.
T#19包括流量标签的重复伪线性能测试。
T#20 Determine whether Entropy Labels can be added at ingress and removed at egress.
T#20确定熵标签是否可以在入口添加，在出口移除。
T#21 Determine which fields are used to create an Entropy Label. Labels further down in the stack, including Entropy Labels further down and IP headers or IP payload fields where applicable, should be used. Determine whether the set of fields and algorithm provide sufficient entropy for load balancing.
T#21确定用于创建熵标签的字段。应使用堆栈中较低的标签，包括较低的熵标签和IP头或IP有效负载字段（如适用）。确定字段集和算法是否为负载平衡提供足够的熵。
T#22 Repeat performance tests under "Basic Performance" when Entropy Labels are used, where ingress or egress is the device under test (DUT).
T#22使用熵标签时，在“基本性能”下重复性能测试，其中入口或出口是被测设备（DUT）。
T#23 Determine whether an ELI is detected when acting as a midpoint LSR and whether the search for further information on which to base the load balancing is used. Information below the Entropy Label SHOULD NOT be used.
T#23确定当充当中点LSR时是否检测到ELI，以及是否使用搜索作为负载平衡基础的进一步信息。不应使用熵标签下方的信息。
T#24 Ensure that the Entropy Label indicator and Entropy Label (ELI and EL) are removed from the label stack during UHP and PHP operations.
T#24确保在UHP和PHP操作期间从标签堆栈中移除熵标签指示器和熵标签（ELI和EL）。
T#25 Ensure that operations on the TC field when adding and removing Entropy Label are correctly carried out. If TC is changed during a swap operation, the ability to transfer that change MUST be provided. The ability to suppress the transfer of TC MUST also be provided. See the pipe, short-pipe, and uniform models in [RFC3443].
T#25确保在添加和删除熵标签时正确执行TC字段上的操作。如果在交换操作期间TC发生变化，则必须提供转移该变化的能力。还必须提供抑制TC转移的能力。参见[RFC3443]中的管道、短管和均匀模型。
T#26 Repeat performance tests for a midpoint LSR with Entropy Labels found at various label stack depths.
T#26对中点LSR重复性能测试，在不同的标签堆栈深度发现熵标签。
T#27 Actively attack LSRs under high protocol churn load and determine control-plane performance impact or successful DoS under test conditions. Specifically, test for the following.
T#27在高协议搅动负载下主动攻击LSR，并在测试条件下确定控制平面性能影响或成功拒绝服务。具体来说，测试以下各项。
A. TCP SYN attack against control-plane and management-plane protocols using TCP, including CLI access (typically SSH-protected login), NETCONF, etc.
A.使用TCP攻击控制平面和管理平面协议的TCP SYN攻击，包括CLI访问（通常是SSH保护的登录）、NETCONF等。
B. High traffic volume attack against control-plane and management-plane protocols not using TCP.
B.针对不使用TCP的控制平面和管理平面协议的高流量攻击。
C. Attacks that can be performed from a compromised management subnet computer, but not one with authentication keys.
C.可以从受损的管理子网计算机执行的攻击，但不能从具有身份验证密钥的计算机执行。
D. Attacks that can be performed from a compromised peer within the control plane (internal domain and external domain). Assume that keys that are per peering and keys that are per router ID, rather than network-wide keys, are in use.
D.可从控制平面（内部域和外部域）内的受损对等方执行的攻击。假设正在使用每个对等的密钥和每个路由器ID的密钥，而不是网络范围的密钥。
See Section 2.6.1.
见第2.6.1节。
T#28 Determine maximum sustainable rates of BFD traffic. If BFD requires CPU intervention, determine both maximum rates and CPU loading when multiple interfaces are active.
T#28确定BFD流量的最大可持续速率。如果BFD需要CPU干预，则确定多个接口处于活动状态时的最大速率和CPU负载。
T#29 Verify LSP Ping and LSP Traceroute capability.
T#29验证LSP Ping和LSP跟踪路由能力。
T#30 Determine maximum rates of MPLS-TP CC-CV traffic. If CC-CV requires CPU intervention, determine both maximum rates and CPU loading when multiple interfaces are active.
T#30确定MPLS-TP CC-CV流量的最大速率。如果CC-CV需要CPU干预，则确定多个接口处于活动状态时的最大速率和CPU负载。
T#31 Determine MPLS-TP DM precision.
T#31确定MPLS-TP DM精度。
T#32 Determine MPLS-TP LM accuracy.
T#32确定MPLS-TP LM精度。
T#33 Verify MPLS-TP AIS/RDI and Protection State Coordination (PSC) functionality, protection speed, and AIS/RDI notification speed when a large number of Maintenance Entities (MEs) must be notified with AIS/RDI.
T#33当大量维修实体（MEs）必须通过AIS/RDI通知时，验证MPLS-TP AIS/RDI和保护状态协调（PSC）功能、保护速度和AIS/RDI通知速度。
This document reviews forwarding behavior specified elsewhere and points out compliance and performance requirements. As such, it introduces no new security requirements or concerns.
本文档回顾了其他地方指定的转发行为，并指出了合规性和性能要求。因此，它没有引入新的安全要求或问题。
Discussion of hardware support and other equipment hardening against DoS attack can be found in Section 2.6.1. Section 3.6 provides a list of questions regarding DoS to be asked of suppliers. Section 4.6 suggests types of testing that can provide some assurance of the effectiveness of a supplier's claims about DoS hardening.
第2.6.1节讨论了硬件支持和其他针对DoS攻击的设备加固。第3.6节提供了一份关于向供应商提出的DoS的问题清单。第4.6节提出了一些测试类型，这些测试可以在一定程度上保证供应商关于DoS强化的声明的有效性。
Knowledge of potential performance shortcomings may serve to help new implementations avoid pitfalls. It is unlikely that such knowledge could be the basis of new denial of service, as these pitfalls are already widely known in the service provider community and among leading equipment suppliers. In practice, extreme data and packet rates are needed to affect existing equipment and to affect networks that may be still vulnerable due to failure to implement adequate protection. The extreme data and packet rates make this type of denial of service unlikely and make undetectable denial of service of this type impossible.
了解潜在的性能缺陷可能有助于新实现避免陷阱。这些知识不太可能成为新的拒绝服务的基础，因为这些陷阱已经在服务提供商社区和领先的设备供应商中广为人知。在实践中，需要极端的数据和数据包速率来影响现有设备，并影响由于未能实施充分保护而可能仍然易受攻击的网络。极端的数据和数据包速率使得此类拒绝服务不太可能发生，也使得无法检测到的此类拒绝服务不可能发生。
Each normative reference contains security considerations. A brief summarization of MPLS security considerations applicable to forwarding follows:
每个规范性引用都包含安全注意事项。以下简要总结了适用于转发的MPLS安全注意事项：
1. MPLS encapsulation does not support an authentication extension. This is reflected in the security section of [RFC3032]. Documents that clarify MPLS header fields such as TTL [RFC3443], the explicit null label [RFC4182], renaming EXP to TC [RFC5462], ECN for MPLS [RFC5129], and MPLS Ethernet encapsulation [RFC5332] make no changes to security considerations in [RFC3032].
1. MPLS封装不支持身份验证扩展。这反映在[RFC3032]的安全部分中。澄清MPLS报头字段的文档，如TTL[RFC3443]、显式空标签[RFC4182]、将EXP重命名为TC[RFC5462]、MPLS的ECN[RFC5129]和MPLS以太网封装[RFC5332]对[RFC3032]中的安全注意事项没有任何更改。
2. Some cited RFCs are related to Diffserv forwarding. [RFC3270] refers to MPLS and Diffserv security. [RFC2474] mentions theft of service and denial of service due to mismarking. [RFC2474] mentions IPsec interaction, but with MPLS, not being carried by IP, the type of interaction in [RFC2474] is not relevant.
2. 一些引用的RFC与Diffserv转发相关。[RFC3270]指MPLS和区分服务安全。[RFC2474]提到了由于错误标记导致的服务盗窃和拒绝服务。[RFC2474]提到IPsec交互，但对于不由IP承载的MPLS，[RFC2474]中的交互类型不相关。
3. [RFC3209] is cited here due only to make-before-break forwarding requirements. This is related to resource sharing and the theft-of-service and denial-of-service concerns in [RFC2474] apply.
3. 此处引用[RFC3209]仅是为了满足先通后断的转发要求。这与[RFC2474]中的资源共享、服务盗窃和拒绝服务相关。
4. [RFC4090] defines FRR, which provides protection but does not add security concerns. RFC 4201 defines link bundling but raises no additional security concerns.
4. [RFC4090]定义了FRR，它提供保护，但不增加安全问题。RFC 4201定义了链接绑定，但没有引起额外的安全问题。
5. Various OAM control channels are defined in [RFC4385] (PW CW), [RFC5085] (VCCV), and [RFC5586] (G-Ach and GAL). These documents describe potential abuse of these OAM control channels.
5. [RFC4385]（PW CW）、[RFC5085]（VCCV）和[RFC5586]（G-Ach和GAL）中定义了各种OAM控制信道。这些文档描述了这些OAM控制通道的潜在滥用。
6. [RFC4950] defines ICMP extensions when MPLS TTL expires and the payload is IP. This provides MPLS header information that is of no use to an IP attacker, but sending this information can be suppressed through configuration.
6. [RFC4950]定义MPLS TTL到期且有效负载为IP时的ICMP扩展。这会提供对IP攻击者没有用处的MPLS头信息，但通过配置可以抑制发送此信息。
7. GTSM [RFC5082] provides a means to improve protection against high traffic volume spoofing as a form of DoS attack.
7. GTSM[RFC5082]提供了一种方法来提高对作为DoS攻击形式的高流量欺骗的保护。
8. BFD [RFC5880] [RFC5884] [RFC5885] provides a form of OAM used in MPLS and MPLS-TP. The security considerations related to the OAM control channel are relevant. The BFD payload supports authentication. The MPLS encapsulation, the MPLS control channel, or the PW control channel, which BFD may be carried in, do not support authentication. Where an IP return OAM path is used, IPsec is suggested as a means of securing the return path.
8. BFD[RFC5880][RFC5884][RFC5885]提供了一种用于MPLS和MPLS-TP的OAM形式。与OAM控制通道相关的安全注意事项是相关的。BFD有效负载支持身份验证。可以携带BFD的MPLS封装、MPLS控制通道或PW控制通道不支持身份验证。在使用IP返回OAM路径的情况下，建议使用IPsec作为保护返回路径的方法。
9. Other forms of OAM are supported by [RFC6374] [RFC6375] (Loss and Delay Measurement), [RFC6428] (Continuity Check/Verification based on BFD), and [RFC6427] (Fault Management). The security considerations related to the OAM control channel are relevant. IP return paths, where used, can be secured with IPsec.
9. [RFC6374][RFC6375]（损耗和延迟测量）、[RFC6428]（基于BFD的连续性检查/验证）和[RFC6427]（故障管理）支持其他形式的OAM。与OAM控制通道相关的安全注意事项是相关的。使用IP返回路径时，可以使用IPsec进行保护。
10. Linear protection is defined by [RFC6378] and updated by [RFC7324]. Security concerns related to MPLS encapsulation and OAM control channels apply. Security concerns reiterate [RFC5920] as applied to protection switching.
10. 线性保护由[RFC6378]定义，并由[RFC7324]更新。与MPLS封装和OAM控制通道相关的安全问题也适用。安全问题重申[RFC5920]适用于保护切换。
11. The PW Flow Label [RFC6391] and MPLS Entropy Label [RFC6790] affect multipath load balancing. Security concerns reiterate [RFC5920]. Security impacts would be limited to load distribution.
11. PW流标签[RFC6391]和MPLS熵标签[RFC6790]影响多路径负载平衡。安全问题重申[RFC5920]。安全影响仅限于负载分布。
MPLS security including data-plane security is discussed in greater detail in [RFC5920] (MPLS/GMPLS Security Framework). The MPLS-TP security framework [RFC6941] builds upon this, focusing largely on the MPLS-TP OAM additions and OAM channels with some attention given to using network management in place of control-plane setup. In both security framework documents, MPLS is assumed to run within a "trusted zone", defined as being where a single service provider has total operational control over that part of the network.
[RFC5920]（MPLS/GMPLS安全框架）更详细地讨论了包括数据平面安全在内的MPLS安全。MPLS-TP安全框架[RFC6941]以此为基础，主要关注MPLS-TP OAM添加和OAM通道，并注意使用网络管理代替控制平面设置。在这两份安全框架文件中，MPLS都假定在“受信任区域”内运行，该区域定义为单个服务提供商对网络的该部分拥有完全的操作控制权。
If control-plane security and management-plane security are sufficiently robust, compromise of a single network element may result in chaos in the data plane anywhere in the network through denial-of-service attacks, but not a Byzantine security failure in which other network elements are fully compromised.
如果控制平面安全性和管理平面安全性足够可靠，则单个网元的泄露可能会通过拒绝服务攻击导致网络中任何位置的数据平面混乱，但不会导致其他网元完全泄露的拜占庭式安全故障。
MPLS security, or lack thereof, can affect whether traffic can be misrouted and lost, or intercepted, or intercepted and reinserted (a man-in-the-middle attack), or spoofed. End-user applications, including control-plane and management-plane protocols used by the service provider, are expected to make use of appropriate end-to-end authentication and, where appropriate, end-to-end encryption.
MPLS安全性，或其缺乏，可能会影响流量是否会被错误路由和丢失，或被拦截，或被拦截和重新插入（中间人攻击），或被欺骗。最终用户应用程序，包括服务提供商使用的控制平面和管理平面协议，预计将使用适当的端到端身份验证，并在适当情况下使用端到端加密。
The References section is split into Normative and Informative subsections. References that directly specify forwarding encapsulations or behaviors are listed as normative. References that describe signaling only, though normative with respect to signaling, are listed as informative. They are informative with respect to MPLS forwarding.
参考文献部分分为规范性小节和信息性小节。直接指定转发封装或行为的引用列为规范性引用。仅描述信号的参考文献，虽然是关于信号的规范性参考文献，但被列为信息性参考文献。它们提供了有关MPLS转发的信息。
[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月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032]Rosen，E.，Tappan，D.，Fedorkow，G.，Rekhter，Y.，Farinaci，D.，Li，T.，和A.Conta，“MPLS标签堆栈编码”，RFC 3032，2001年1月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[RFC3270]Le Faucheur，F.，Wu，L.，Davie，B.，Davari，S.，Vaananen，P.，Krishnan，R.，Cheval，P.，和J.Heinanen，“区分服务的多协议标签交换（MPLS）支持”，RFC 32702002年5月。
[RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, January 2003.
[RFC3443]Agarwal，P.和B.Akyol，“多协议标签交换（MPLS）网络中的生存时间（TTL）处理”，RFC 3443，2003年1月。
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090]Pan，P.，Swallow，G.，和A.Atlas，“LSP隧道RSVP-TE快速重路由扩展”，RFC 40902005年5月。
[RFC4182] Rosen, E., "Removing a Restriction on the use of MPLS Explicit NULL", RFC 4182, September 2005.
[RFC4182]Rosen，E.，“消除对MPLS显式NULL使用的限制”，RFC 41822005年9月。
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4201]Kompella，K.，Rekhter，Y.，和L.Berger，“MPLS流量工程（TE）中的链路捆绑”，RFC 42012005年10月。
[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月。
[RFC4950] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP Extensions for Multiprotocol Label Switching", RFC 4950, August 2007.
[RFC4950]Bonica，R.，Gan，D.，Tappan，D.，和C.Pignataro，“多协议标签交换的ICMP扩展”，RFC 49502007年8月。
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007.
[RFC5082]Gill，V.，Heasley，J.，Meyer，D.，Savola，P.，和C.Pignataro，“广义TTL安全机制（GTSM）”，RFC 5082，2007年10月。
[RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.
[RFC5085]Nadeau，T.和C.Pignataro，“伪线虚拟电路连接验证（VCCV）：伪线的控制通道”，RFC 5085，2007年12月。
[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion Marking in MPLS", RFC 5129, January 2008.
[RFC5129]Davie，B.，Briscoe，B.，和J.Tay，“MPLS中的显式拥塞标记”，RFC 5129，2008年1月。
[RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS Multicast Encapsulations", RFC 5332, August 2008.
[RFC5332]Eckert，T.，Rosen，E.，Aggarwal，R.，和Y.Rekhter，“MPLS多播封装”，RFC 5332，2008年8月。
[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic Associated Channel", RFC 5586, June 2009.
[RFC5586]Bocci，M.，Vigoureux，M.，和S.Bryant，“MPLS通用关联信道”，RFC 55862009年6月。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010.
[RFC5880]Katz，D.和D.Ward，“双向转发检测（BFD）”，RFC 58802010年6月。
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010.
[RFC5884]Aggarwal，R.，Kompella，K.，Nadeau，T.，和G.Swallow，“MPLS标签交换路径（LSP）的双向转发检测（BFD）”，RFC 58842010年6月。
[RFC5885] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", RFC 5885, June 2010.
[RFC5885]Nadeau，T.和C.Pignataro，“伪线虚拟电路连接验证（VCCV）的双向转发检测（BFD）”，RFC 58852010年6月。
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, September 2011.
[RFC6374]Frost，D.和S.Bryant，“MPLS网络的数据包丢失和延迟测量”，RFC 63742011年9月。
[RFC6375] Frost, D. and S. Bryant, "A Packet Loss and Delay Measurement Profile for MPLS-Based Transport Networks", RFC 6375, September 2011.
[RFC6375]Frost，D.和S.Bryant，“基于MPLS的传输网络的数据包丢失和延迟测量模式”，RFC 63752011年9月。
[RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear Protection", RFC 6378, October 2011.
[RFC6378]Y.Weingarten、S.Bryant、E.Osborne、N.Sprecher和A.Fulignoli，“MPLS传输模式（MPLS-TP）线性保护”，RFC 6378，2011年10月。
[RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, J., and S. Amante, "Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network", RFC 6391, November 2011.
[RFC6391]Bryant，S.，Filsfils，C.，Drafz，U.，Kompella，V.，Regan，J.，和S.Amante，“MPLS分组交换网络上伪线的流感知传输”，RFC 63912011年11月。
[RFC6427] Swallow, G., Fulignoli, A., Vigoureux, M., Boutros, S., and D. Ward, "MPLS Fault Management Operations, Administration, and Maintenance (OAM)", RFC 6427, November 2011.
[RFC6427]Swallow，G.，Fulignoli，A.，Vigoureux，M.，Boutros，S.，和D.Ward，“MPLS故障管理操作、管理和维护（OAM）”，RFC 64272011年11月。
[RFC6428] Allan, D., Swallow Ed. , G., and J. Drake Ed. , "Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile", RFC 6428, November 2011.
[RFC6428]Allan，D.，Swallow Ed.，G.，和J.Drake Ed.，“MPLS传输配置文件的主动连接验证、连续性检查和远程缺陷指示”，RFC 6428，2011年11月。
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, November 2012.
[RFC6790]Kompella，K.，Drake，J.，Amante，S.，Henderickx，W.，和L.Yong，“MPLS转发中熵标签的使用”，RFC 67902012年11月。
[RFC7324] Osborne, E., "Updates to MPLS Transport Profile Linear Protection", RFC 7324, July 2014.
[RFC7324]Osborne，E.“MPLS传输配置文件线性保护的更新”，RFC 73242014年7月。
[ACK-compression] Zhang, L., Shenker, S., and D. Clark, "Observations and Dynamics of a Congestion Control Algorithm: The Effects of Two-Way Traffic", Proc. ACM SIGCOMM, ACM Computer Communications Review (CCR) Vol. 21, No. 4, pp. 133-147., 1991.
[ACK压缩]Zhang，L.，Shenker，S.，和D.Clark，“拥塞控制算法的观察和动力学：双向流量的影响”，Proc。ACM SIGCOMM，《ACM计算机通信评论》（CCR）第21卷，第4期，第133-147页，1991年。
[MPLS-IN-UDP] Xu, X., Sheth, N., Yong, L., Pignataro, C., and F. Yongbing, "Encapsulating MPLS in UDP", Work in Progress, January 2014.
[MPLS-IN-UDP]Xu，X.，Sheth，N.，Yong，L.，Pignataro，C.，和F.Yongbing，“用UDP封装MPLS”，正在进行的工作，2014年1月。
[MRT] Atlas, A., Kebler, R., Bowers, C., Envedi, G., Csaszar, A., Tantsura, J., Konstantynowicz, M., and R. White, "An Architecture for IP/LDP Fast-Reroute Using Maximally Redundant Trees", Work in Progress, July 2014.
[MRT]Atlas，A.，Kebler，R.，Bowers，C.，Envedi，G.，Csaszar，A.，Tantsura，J.，Konstantynowicz，M.，和R.White，“使用最大冗余树的IP/LDP快速重路由架构”，正在进行的工作，2014年7月。
[REMOTE-LFA] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and S. Ning, "Remote LFA FRR", Work in Progress, May 2014.
【远程LFA】Bryant，S.，Filsfils，C.，Previdi，S.，Shand，M.，和S.Ning，“远程LFA FRR”，正在进行的工作，2014年5月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.，和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC2597]Heinanen，J.，Baker，F.，Weiss，W.，和J.Wroclawski，“保付PHB集团”，RFC 25971999年6月。
[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月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168]Ramakrishnan，K.，Floyd，S.，和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，2001年9月。
[RFC3429] Ohta, H., "Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions", RFC 3429, November 2002.
[RFC3429]Ohta，H.，“多协议标签交换体系结构（MPLS）操作和维护（OAM）功能的‘OAM警报标签’分配”，RFC 34292002年11月。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]Berger，L.“通用多协议标签交换（GMPLS）信令功能描述”，RFC 3471，2003年1月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004.
[RFC3828]Larzon，L-A.，Degermark，M.，Pink，S.，Jonsson，L-E.，和G.Fairhurst，“轻量级用户数据报协议（UDP Lite）”，RFC 38282004年7月。
[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月。
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005.
[RFC4023]Worster，T.，Rekhter，Y.，和E.Rosen，“在IP或通用路由封装（GRE）中封装MPLS”，RFC 4023，2005年3月。
[RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4110, July 2005.
[RFC4110]Callon，R.和M.Suzuki，“第3层提供商提供的虚拟专用网络（PPVPN）框架”，RFC 4110，2005年7月。
[RFC4124] Le Faucheur, F., "Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering", RFC 4124, June 2005.
[RFC4124]Le Faucheur，F.“支持区分服务的MPLS流量工程的协议扩展”，RFC 41242005年6月。
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC4206]Kompella，K.和Y.Rekhter，“具有通用多协议标签交换（GMPLS）流量工程（TE）的标签交换路径（LSP）层次结构”，RFC 4206，2005年10月。
[RFC4221] Nadeau, T., Srinivasan, C., and A. Farrel, "Multiprotocol Label Switching (MPLS) Management Overview", RFC 4221, November 2005.
[RFC4221]Nadeau，T.，Srinivasan，C.，和A.Farrel，“多协议标签交换（MPLS）管理概述”，RFC 42212005年11月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340]Kohler，E.，Handley，M.和S.Floyd，“数据报拥塞控制协议（DCCP）”，RFC 43402006年3月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]Rosen，E.和Y.Rekhter，“BGP/MPLS IP虚拟专用网络（VPN）”，RFC 4364，2006年2月。
[RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. Matsushima, "Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks", RFC 4377, February 2006.
[RFC4377]Nadeau，T.，Morrow，M.，Swallow，G.，Allan，D.，和S.Matsushima，“多协议标签交换（MPLS）网络的运营和管理（OAM）要求”，RFC 4377，2006年2月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379]Kompella，K.和G.Swallow，“检测多协议标签交换（MPLS）数据平面故障”，RFC 4379，2006年2月。
[RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006.
[RFC4664]Andersson，L.和E.Rosen，“第二层虚拟专用网络（L2VPN）框架”，RFC 4664，2006年9月。
[RFC4817] Townsley, M., Pignataro, C., Wainner, S., Seely, T., and J. Young, "Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3", RFC 4817, March 2007.
[RFC4817]Townsley，M.，Pignataro，C.，Wainner，S.，Seely，T.，和J.Young，“第2层隧道协议版本3上的MPLS封装”，RFC 48172007年3月。
[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC4875]Aggarwal，R.，Papadimitriou，D.，和S.Yasukawa，“资源预留协议的扩展-点对多点TE标签交换路径（LSP）的流量工程（RSVP-TE）”，RFC 4875，2007年5月。
[RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal Cost Multipath Treatment in MPLS Networks", BCP 128, RFC 4928, June 2007.
[RFC4928]Swallow，G.，Bryant，S.和L.Andersson，“避免MPLS网络中的等成本多路径处理”，BCP 128，RFC 4928，2007年6月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]Stewart，R.，“流控制传输协议”，RFC 49602007年9月。
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007.
[RFC5036]Andersson，L.，Minei，I.，和B.Thomas，“LDP规范”，RFC 5036，2007年10月。
[RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, September 2008.
[RFC5286]Atlas，A.和A.Zinin，“IP快速重路由的基本规范：无环路交替”，RFC 5286，2008年9月。
[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月。
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, February 2009.
[RFC5462]Andersson，L.和R.Asati，“多协议标签交换（MPLS）标签堆栈条目：“EXP”字段重命名为“流量类”字段”，RFC 5462，2009年2月。
[RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture for IP Flow Information Export", RFC 5470, March 2009.
[RFC5470]Sadasivan，G.，Brownlee，N.，Claise，B.，和J.Quitek，“IP流信息导出架构”，RFC 54702009年3月。
[RFC5640] Filsfils, C., Mohapatra, P., and C. Pignataro, "Load-Balancing for Mesh Softwires", RFC 5640, August 2009.
[RFC5640]Filsfils，C.，Mohapatra，P.，和C.Pignataro，“网状软电线的负载平衡”，RFC 56402009年8月。
[RFC5695] Akhter, A., Asati, R., and C. Pignataro, "MPLS Forwarding Benchmarking Methodology for IP Flows", RFC 5695, November 2009.
[RFC5695]Akhter，A.，Asati，R.，和C.Pignataro，“IP流的MPLS转发基准测试方法”，RFC 56952009年11月。
[RFC5704] Bryant, S., Morrow, M., and IAB, "Uncoordinated Protocol Development Considered Harmful", RFC 5704, November 2009.
[RFC5704]Bryant，S.，Morrow，M.，和IAB，“认为不协调的方案制定有害”，RFC 57042009年11月。
[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 5714, January 2010.
[RFC5714]Shand，M.和S.Bryant，“IP快速重路由框架”，RFC 5714，2010年1月。
[RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free Convergence", RFC 5715, January 2010.
[RFC5715]Shand，M.和S.Bryant，“无环收敛框架”，RFC 5715，2010年1月。
[RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks", RFC 5860, May 2010.
[RFC5860]Vigoureux，M.，Ward，D.，和M.Betts，“MPLS传输网络中的操作、管理和维护（OAM）要求”，RFC 5860，2010年5月。
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.
[RFC5905]Mills，D.，Martin，J.，Burbank，J.，和W.Kasch，“网络时间协议版本4：协议和算法规范”，RFC 59052010年6月。
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920]方，L，“MPLS和GMPLS网络的安全框架”，RFC 5920，2010年7月。
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, D., and S. Mansfield, "Guidelines for the Use of the "OAM" Acronym in the IETF", BCP 161, RFC 6291, June 2011.
[RFC6291]Andersson，L.，van Helvoort，H.，Bonica，R.，Romascanu，D.，和S.Mansfield，“IETF中“OAM”首字母缩写词的使用指南”，BCP 161，RFC 62912011年6月。
[RFC6310] Aissaoui, M., Busschbach, P., Martini, L., Morrow, M., Nadeau, T., and Y(J). Stein, "Pseudowire (PW) Operations, Administration, and Maintenance (OAM) Message Mapping", RFC 6310, July 2011.
[RFC6310]Aissaoui，M.，Busschbach，P.，Martini，L.，Morrow，M.，Nadeau，T.，和Y（J）。Stein，“伪线（PW）操作、管理和维护（OAM）消息映射”，RFC63102011年7月。
[RFC6371] Busi, I. and D. Allan, "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, September 2011.
[RFC6371]Busi，I.和D.Allan，“基于MPLS的传输网络的运营、管理和维护框架”，RFC 6371，2011年9月。
[RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, November 2011.
[RFC6388]Wijnands，IJ.，Minei，I.，Kompella，K.，和B.Thomas，“点对多点和多点对多点标签交换路径的标签分发协议扩展”，RFC 6388，2011年11月。
[RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for Performing Label Switched Path Ping (LSP Ping) over MPLS Tunnels", RFC 6424, November 2011.
[RFC6424]Bahadur，N.，Kompella，K.，和G.Swallow，“在MPLS隧道上执行标签交换路径Ping（LSP Ping）的机制”，RFC 64242011年11月。
[RFC6425] Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa, S., and T. Nadeau, "Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 6425, November 2011.
[RFC6425]Saxena，S.，Swallow，G.，Ali，Z.，Farrel，A.，Yasukawa，S.，和T.Nadeau，“检测点对多点MPLS中的数据平面故障-LSP Ping扩展”，RFC 64252011年11月。
[RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS On-Demand Connectivity Verification and Route Tracing", RFC 6426, November 2011.
[RFC6426]Gray，E.，Bahadur，N.，Boutros，S.，和R.Aggarwal，“MPLS按需连接验证和路由跟踪”，RFC 6426，2011年11月。
[RFC6435] Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux, M., and X. Dai, "MPLS Transport Profile Lock Instruct and Loopback Functions", RFC 6435, November 2011.
[RFC6435]Boutros，S.，Sivabalan，S.，Aggarwal，R.，Vigoureux，M.，和X.Dai，“MPLS传输配置文件锁定指令和环回功能”，RFC 64352011年11月。
[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels", RFC 6438, November 2011.
[RFC6438]Carpenter，B.和S.Amante，“在隧道中使用IPv6流标签进行等成本多路径路由和链路聚合”，RFC 6438，2011年11月。
[RFC6478] Martini, L., Swallow, G., Heron, G., and M. Bocci, "Pseudowire Status for Static Pseudowires", RFC 6478, May 2012.
[RFC6478]Martini，L.，Swallow，G.，Heron，G.，和M.Bocci，“静态伪线的伪线状态”，RFC 6478，2012年5月。
[RFC6639] King, D. and M. Venkatesan, "Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-Based Management Overview", RFC 6639, June 2012.
[RFC6639]King，D.和M.Venkatesan，“多协议标签交换传输配置文件（MPLS-TP）基于MIB的管理概述”，RFC 66392012年6月。
[RFC6669] Sprecher, N. and L. Fang, "An Overview of the Operations, Administration, and Maintenance (OAM) Toolset for MPLS-Based Transport Networks", RFC 6669, July 2012.
[RFC6669]Sprecher，N.和L.Fang，“基于MPLS的传输网络的操作、管理和维护（OAM）工具集概述”，RFC 6669，2012年7月。
[RFC6670] Sprecher, N. and KY. Hong, "The Reasons for Selecting a Single Solution for MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM)", RFC 6670, July 2012.
[RFC6670]Sprecher，N.和KY.Hong，“为MPLS传输配置文件（MPLS-TP）操作、管理和维护（OAM）选择单一解决方案的原因”，RFC 66702012年7月。
[RFC6720] Pignataro, C. and R. Asati, "The Generalized TTL Security Mechanism (GTSM) for the Label Distribution Protocol (LDP)", RFC 6720, August 2012.
[RFC6720]Pignataro，C.和R.Asati，“标签分发协议（LDP）的通用TTL安全机制（GTSM）”，RFC 6720，2012年8月。
[RFC6829] Chen, M., Pan, P., Pignataro, C., and R. Asati, "Label Switched Path (LSP) Ping for Pseudowire Forwarding Equivalence Classes (FECs) Advertised over IPv6", RFC 6829, January 2013.
[RFC6829]Chen，M.，Pan，P.，Pignataro，C.，和R.Asati，“IPv6上广告的伪线转发等价类（FEC）的标签交换路径（LSP）Ping”，RFC 68292013年1月。
[RFC6894] Papneja, R., Vapiwala, S., Karthik, J., Poretsky, S., Rao, S., and JL. Le Roux, "Methodology for Benchmarking MPLS Traffic Engineered (MPLS-TE) Fast Reroute Protection", RFC 6894, March 2013.
[RFC6894]Papneja，R.，Vapiwala，S.，Karthik，J.，Poretsky，S.，Rao，S.，和JL。Le Roux，“MPLS流量工程（MPLS-TE）快速重路由保护基准测试方法”，RFC 68942013年3月。
[RFC6941] Fang, L., Niven-Jenkins, B., Mansfield, S., and R. Graveman, "MPLS Transport Profile (MPLS-TP) Security Framework", RFC 6941, April 2013.
[RFC6941]Fang，L.，Niven Jenkins，B.，Mansfield，S.，和R.Graveman，“MPLS传输配置文件（MPLS-TP）安全框架”，RFC 69412013年4月。
[RFC6981] Bryant, S., Previdi, S., and M. Shand, "A Framework for IP and MPLS Fast Reroute Using Not-Via Addresses", RFC 6981, August 2013.
[RFC6981]Bryant，S.，Previdi，S.，和M.Shand，“使用非经由地址的IP和MPLS快速重路由框架”，RFC 6981，2013年8月。
[RFC7012] Claise, B. and B. Trammell, "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, September 2013.
[RFC7012]Claise，B.和B.Trammell，“IP流信息导出（IPFIX）的信息模型”，RFC 7012，2013年9月。
[RFC7023] Mohan, D., Bitar, N., Sajassi, A., DeLord, S., Niger, P., and R. Qiu, "MPLS and Ethernet Operations, Administration, and Maintenance (OAM) Interworking", RFC 7023, October 2013.
[RFC7023]Mohan，D.，Bitar，N.，Sajassi，A.，DeLord，S.，Niger，P.，和R.Qiu，“MPLS和以太网操作、管理和维护（OAM）互通”，RFC 70232013年10月。
[RFC7074] Berger, L. and J. Meuric, "Revised Definition of the GMPLS Switching Capability and Type Fields", RFC 7074, November 2013.
[RFC7074]Berger，L.和J.Meuria，“GMPLS交换能力和类型字段的修订定义”，RFC 7074，2013年11月。
[RFC7079] Del Regno, N. and A. Malis, "The Pseudowire (PW) and Virtual Circuit Connectivity Verification (VCCV) Implementation Survey Results", RFC 7079, November 2013.
[RFC7079]Del Regno，N.和A.Malis，“伪线（PW）和虚拟电路连接验证（VCCV）实施调查结果”，RFC 7079，2013年11月。
[RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating and Retiring Special-Purpose MPLS Labels", RFC 7274, June 2014.
[RFC7274]Kompella，K.，Andersson，L.，和A.Farrel，“特殊用途MPLS标签的分配和退役”，RFC 7274，2014年6月。
[TIMING-OVER-MPLS] Davari, S., Oren, A., Bhatia, M., Roberts, P., and L. Montini, "Transporting Timing messages over MPLS Networks", Work in Progress, April 2014.
[TIMING-OVER-MPLS]Davari，S.，Oren，A.，Bhatia，M.，Roberts，P.，和L.Montini，“通过MPLS网络传输定时消息”，正在进行的工作，2014年4月。
Numerous very useful comments have been received in private email. Some of these contributions are acknowledged here, approximately in chronologic order.
在私人电子邮件中收到了许多非常有用的评论。其中一些贡献在这里被确认，大致按时间顺序排列。
Paul Doolan provided a brief review resulting in a number of clarifications, most notably regarding on-chip vs. system buffering, 100 Gb/s link speed assumptions in the 150 Mpps figure, and handling of large microflows. Pablo Frank reminded us of the sawtooth effect in PPS vs. packet-size graphs, prompting the addition of a few paragraphs on this. Comments from Lou Berger at IETF 85 prompted the addition of Section 2.7.
Paul Doolan提供了一个简短的回顾，随后进行了大量澄清，最显著的是关于片上缓冲与系统缓冲、150 Mpps图中的100 Gb/s链路速度假设以及大微流量的处理。Pablo Frank提醒我们PPS与数据包大小图中的锯齿效应，这促使我们在这方面增加了一些段落。Lou Berger在IETF 85上的评论促使增加了第2.7节。
Valuable comments were received on the BMWG mailing list. Jay Karthik pointed out testing methodology hints that after discussion were deemed out of scope and were removed but may benefit later work in BMWG.
BMWG邮件列表上收到了宝贵的意见。Jay Karthik指出，测试方法暗示，经过讨论后，被视为超出范围，被删除，但可能有利于BMWG的后续工作。
Nabil Bitar pointed out the need to cover QoS (Differentiated Services), MPLS multicast (P2MP and MP2MP), and MPLS-TP OAM. Nabil also provided a number of clarifications to the questions and tests in Sections 3 and 4.
Nabil Bitar指出需要涵盖QoS（区分服务）、MPLS多播（P2MP和MP2MP）和MPLS-TP OAM。Nabil还对第3节和第4节中的问题和测试进行了一些澄清。
Mark Szczesniak provided a thorough review and a number of useful comments and suggestions that improved the document.
Mark Szczesniak对该文件进行了全面审查，并提出了许多有用的意见和建议，以改进该文件。
Gregory Mirsky and Thomas Beckhaus provided useful comments during the review by the MPLS Review Team.
Gregory Mirsky和Thomas Beckhaus在MPLS审查小组审查期间提供了有用的意见。
Tal Mizrahi provided comments that prompted clarifications regarding timestamp processing, local delivery of packets, and the need for hardware assistance in processing OAM traffic.
Tal Mizrahi提供了一些意见，这些意见促使澄清了时间戳处理、数据包的本地交付以及处理OAM流量时需要硬件协助的问题。
Alexander (Sasha) Vainshtein pointed out errors in Section 2.1.8.1 and suggested new text that, after lengthy discussion, resulted in restating the summarization of requirements from PWE3 RFCs and more clearly stating the benefits and drawbacks of packet resequencing based on PW Sequence Number.
Alexander（Sasha）Vainstein指出了第2.1.8.1节中的错误，并提出了新的文本，经过长时间的讨论，重新阐述了PWE3 RFC的要求摘要，并更清楚地说明了基于PW序列号的数据包重新排序的优缺点。
Loa Anderson provided useful comments and corrections prior to WGLC. Adrian Farrel provided useful comments and corrections prior as part of the AD review.
Loa Anderson在WGLC之前提供了有用的意见和更正。阿德里安·法雷尔（Adrian Farrel）在广告审查之前提供了有用的评论和更正。
Discussion with Steve Kent during SecDir review resulted in expansion of Section 5, briefly summarizing security considerations related to forwarding in normative references. Tom Petch pointed out some editorial errors in private email plus an important math error. Al
在SecDir审查期间与Steve Kent的讨论导致第5节的扩展，简要总结了规范性引用中与转发相关的安全注意事项。Tom Petch指出了私人电子邮件中的一些编辑错误，以及一个重要的数学错误。艾尔
Morton during OpsDir review prompted clarification in the section about the target audience, suggested more clear wording in places, and found numerous editorial errors.
Morton在OpsDir审查期间，在该部分中对目标受众进行了澄清，建议在某些地方使用更清晰的措辞，并发现了大量编辑错误。
Discussion with Stewart Bryant and Alia Atlas as part of IESG review resulted in coverage of IPFIX and improvements to document coverage of MPLS FRR, and IP/LDP FRR, plus some corrections to the text elsewhere.
作为IESG审查的一部分，与Stewart Bryant和Alia Atlas的讨论导致了IPFIX的覆盖范围，改进了MPLS FRR和IP/LDP FRR的文件覆盖范围，并对其他地方的文本进行了一些更正。
Authors' Addresses
作者地址
Curtis Villamizar (editor) Outer Cape Cod Network Consulting, LLC
Curtis Villamizar（编辑）外科德角网络咨询有限责任公司
EMail: curtis@occnc.com
EMail: curtis@occnc.com
Kireeti Kompella Juniper Networks
Kireeti Kompella Juniper网络
EMail: kireeti@juniper.net
EMail: kireeti@juniper.net
Shane Amante Apple Inc. 1 Infinite Loop Cupertino, California 95014
Shane Amante苹果公司加利福尼亚州库比蒂诺市无限环路1号95014
EMail: amante@apple.com
EMail: amante@apple.com
Andrew Malis Huawei Technologies
安德鲁·马利斯华为技术有限公司
EMail: agmalis@gmail.com
EMail: agmalis@gmail.com
Carlos Pignataro Cisco Systems 7200-12 Kit Creek Road Research Triangle Park, NC 27709 US
卡洛斯·皮格纳塔罗思科系统7200-12美国北卡罗来纳州基特克里克路研究三角公园，邮编27709
EMail: cpignata@cisco.com
EMail: cpignata@cisco.com