Internet Engineering Task Force (IETF) S. Bryant
Request for Comments: 7876 Independent
Category: Standards Track S. Sivabalan
ISSN: 2070-1721 S. Soni
Cisco Systems
July 2016
Internet Engineering Task Force (IETF) S. Bryant
Request for Comments: 7876 Independent
Category: Standards Track S. Sivabalan
ISSN: 2070-1721 S. Soni
Cisco Systems
July 2016
UDP Return Path for Packet Loss and Delay Measurement for MPLS Networks
MPLS网络丢包和时延测量的UDP返回路径
Abstract
摘要
RFC 6374 defines a protocol for Packet Loss and Delay Measurement for MPLS networks (MPLS-PLDM). This document specifies the procedures to be used when sending and processing out-of-band MPLS performance management Responses over an UDP/IP return path.
RFC6374为MPLS网络（MPLS-PLDM）定义了一个包丢失和延迟测量协议。本文档指定了通过UDP/IP返回路径发送和处理带外MPLS性能管理响应时要使用的过程。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第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/rfc7876.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7876.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Requirements Language ...........................................3
3. Solution Overview ...............................................3
3.1. UDP Return Object ..........................................4
4. Theory of Operation .............................................5
4.1. Sending an MPLS-PLDM Query .................................5
4.2. Receiving an MPLS-PLDM Query Request .......................5
4.3. Sending an MPLS-PLDM Response ..............................6
4.4. Receiving an MPLS-PLDM Response ............................7
5. Congestion Considerations .......................................7
6. Manageability Considerations ....................................8
7. Security Considerations .........................................8
8. IANA Considerations .............................................8
9. References ......................................................9
9.1. Normative References .......................................9
9.2. Informative References .....................................9
Acknowledgements ..................................................10
Authors' Addresses ................................................10
1. Introduction ....................................................3
2. Requirements Language ...........................................3
3. Solution Overview ...............................................3
3.1. UDP Return Object ..........................................4
4. Theory of Operation .............................................5
4.1. Sending an MPLS-PLDM Query .................................5
4.2. Receiving an MPLS-PLDM Query Request .......................5
4.3. Sending an MPLS-PLDM Response ..............................6
4.4. Receiving an MPLS-PLDM Response ............................7
5. Congestion Considerations .......................................7
6. Manageability Considerations ....................................8
7. Security Considerations .........................................8
8. IANA Considerations .............................................8
9. References ......................................................9
9.1. Normative References .......................................9
9.2. Informative References .....................................9
Acknowledgements ..................................................10
Authors' Addresses ................................................10
This document describes how MPLS-PLDM [RFC6374] out-of-band Responses can be delivered to the querier using UDP/IP.
本文档描述了如何使用UDP/IP将MPLS-PLDM[RFC6374]带外响应传递给查询器。
The use of UDP may be required to support data-path management such as passage through firewalls or to provide the necessary multiplexing needed in bistatic operation where the querier and the collector are not co-located and the collector is gathering the Response information for a number of responders. In a highly scaled system, some MPLS-PLDM sessions may be off-loaded to a specific node within the distributed system that comprises the Label Switching Router (LSR) as a whole. In such systems, the Response may arrive via any interface in the LSR and needs to be forwarded internally to the processor tasked with handling the particular MPLS-PLDM measurement. Currently, the MPLS-PLDM protocol does not have any mechanism to deliver the PLDM Response message to a particular node within a multi-CPU LSR.
可能需要使用UDP来支持数据路径管理，例如通过防火墙，或者在查询器和收集器不在同一位置且收集器正在为多个响应器收集响应信息的双基地操作中提供必要的多路复用。在高规模系统中，一些MPLS-PLDM会话可以卸载到包括标签交换路由器（LSR）作为一个整体的分布式系统内的特定节点。在这样的系统中，响应可以通过LSR中的任何接口到达，并且需要在内部转发给负责处理特定MPLS-PLDM测量的处理器。目前，MPLS-PLDM协议没有任何机制将PLDM响应消息传递到多CPU LSR内的特定节点。
The procedure described in this specification describes how the querier requests delivery of the MPLS-PLDM Response over IP to a dynamic UDP port. It makes no other changes to the protocol and thus does not affect the case where the Response is delivered over an MPLS Associated Channel [RFC5586].
本规范中描述的过程描述了查询器如何请求通过IP将MPLS-PLDM响应传递到动态UDP端口。它不会对协议进行任何其他更改，因此不会影响通过MPLS相关信道发送响应的情况[RFC5586]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This document specifies that, unless configured otherwise, if a UDP Return Object (URO) is present in an MPLS-PLDM Query, the responder SHOULD use the IP address and UDP port in the URO to reply back to the querier. The querier MAY include multiple UROs in an MPLS-PLDM Query indicating to the responder that an identical Response SHOULD be sent to each address-port pair. A responder MAY be designed or configured to only transmit a single Response, in which case the Response MUST be sent using the parameters specified in the first URO in the Query packet that it is able to use (see Section 4.3).
本文档规定，除非另有配置，否则如果MPLS-PLDM查询中存在UDP返回对象（URO），响应者应使用URO中的IP地址和UDP端口回复查询者。查询器可以在MPLS-PLDM查询中包括多个URO，该查询向响应器指示应向每个地址端口对发送相同的响应。响应器可设计或配置为仅发送单个响应，在这种情况下，必须使用其能够使用的查询数据包中第一个URO中指定的参数发送响应（见第4.3节）。
The procedures defined in this document may be applied to both unidirectional and bidirectional Label Switched Paths (LSPs). In this document, the term "bidirectional LSP" includes the co-routed bidirectional LSP defined in [RFC3945] and the associated bidirectional LSP that is constructed from a pair of unidirectional
本文件中定义的程序可适用于单向和双向标签交换路径（LSP）。在本文件中，术语“双向LSP”包括[RFC3945]中定义的共路由双向LSP和由一对单向LSP构造的相关双向LSP
LSPs (one for each direction) that are associated with one another at the LSP's ingress/egress points [RFC5654]. The mechanisms defined in this document can apply to both IP/MPLS and to the MPLS Transport Profile (MPLS-TP) [RFC5654] [RFC5921].
在LSP的入口/出口点处彼此关联的LSP（每个方向一个）[RFC5654]。本文档中定义的机制可应用于IP/MPLS和MPLS传输配置文件（MPLS-TP）[RFC5654][RFC5921]。
The format of the UDP Return Object (URO) is as follows:
UDP返回对象（URO）的格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| URO Type | Length={6,18} | UDP-Destination-Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| URO Type | Length={6,18} | UDP-Destination-Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type and Length fields are each 8 bits long. The Length field indicates the size in bytes of the remainder of the object (i.e., it is the size of the address in bytes plus 2). When the address is IPv4, the Length field is thus 6; when the address is IPv6, the Length field is thus 18. The Length field therefore acts as both the TLV parsing parameter and the address family type indicator.
类型字段和长度字段的长度均为8位。长度字段表示对象剩余部分的字节大小（即，它是地址的字节大小加2）。当地址为IPv4时，长度字段为6；当地址为IPv6时，长度字段因此为18。因此，长度字段同时充当TLV解析参数和地址族类型指示符。
The UDP Return Object Type (URO Type) has a value of 131.
UDP返回对象类型（URO类型）的值为131。
The UDP-Destination-Port is a UDP destination port as specified in [RFC768].
UDP目标端口是[RFC768]中指定的UDP目标端口。
The Address is either an IPv4 or an IPv6 address.
该地址是IPv4或IPv6地址。
The URO MUST NOT appear in a Response and MUST be ignored if it is found to be present.
URO不得出现在响应中，如果发现它存在，则必须忽略。
To prevent any ambiguity as to which address the responder needs to reply to, an MPLS-PLDM Query message containing a URO MUST NOT include an RFC 6374 Return Address TLV (TLV 1). Additionally, the method of constructing the return address from the Source Address TLV (TLV 130) described in Section 3.5.2 of [RFC6374] MUST NOT be used to construct a Response to a Query message that contains a URO.
为避免对响应者需要回复的地址产生歧义，包含URO的MPLS-PLDM查询消息不得包含RFC 6374返回地址TLV（TLV 1）。此外，[RFC6374]第3.5.2节中描述的从源地址TLV（TLV 130）构造返回地址的方法不得用于构造对包含URO的查询消息的响应。
This document defines the UDP Return Object to enable the MPLS-PLDM querier to specify the return path for the MPLS-PLDM reply using UDP/ IP encapsulation.
本文档定义UDP返回对象，使MPLS-PLDM查询器能够使用UDP/IP封装指定MPLS-PLDM回复的返回路径。
When the MPLS-PLDM Response is requested out-of-band by setting the Control Code of the MPLS-PLDM Query to "Out-of-band Response Requested", and the URO is present, the responder SHOULD send the Response back to querier on the specified destination UDP port at the specified destination IP address contained in the URO.
当通过将MPLS-PLDM查询的控制代码设置为“请求带外响应”请求带外MPLS-PLDM响应时，且存在URO，响应者应将响应发送回URO中包含的指定目标IP地址的指定目标UDP端口上的查询者。
If the URO is expected but is not present in a Query message and an MPLS-PLDM Response is requested out-of-band, the Query message MUST NOT be processed further, and if possible, an "Error - Invalid Message" ([RFC6374], Section 3.1) SHOULD be sent to the querier and the operator notified via the management system (see Section 4.2 for further details).
如果预期URO，但查询消息中不存在，并且在带外请求MPLS-PLDM响应，则不得进一步处理查询消息，如果可能，应向查询者发送“错误-无效消息”（[RFC6374]，第3.1节），并通过管理系统通知操作员（详见第4.2节）。
When sending an MPLS-PLDM Query message, in addition to the rules and procedures defined in [RFC6374], the Control Code of the MPLS-PLDM Query MUST be set to "Out-of-band Response Requested", and a URO MUST be carried in the MPLS-PLDM Query message.
发送MPLS-PLDM查询消息时，除了[RFC6374]中定义的规则和程序外，MPLS-PLDM查询的控制代码必须设置为“带外响应请求”，并且必须在MPLS-PLDM查询消息中执行URO。
If the querier uses the UDP port to de-multiplex the Response for a different measurement type, there MUST be a different UDP port for each measurement type (delay, loss, and delay-loss combined).
如果查询者使用UDP端口对不同测量类型的响应进行解复用，则每个测量类型（延迟、丢失和延迟丢失组合）必须有不同的UDP端口。
An implementation MAY use multiple UDP ports for the same measurement type to direct the Response to the correct management process in the LSR.
一个实现可以对同一测量类型使用多个UDP端口，以将响应定向到LSR中的正确管理进程。
The processing of MPLS-PLDM Query messages as defined in [RFC6374] applies in this document. In addition, when an MPLS-PLDM Query message is received, with the Control Code of the MPLS-PLDM Query set to "Out-of-band Response Requested" with a URO present, then the responder SHOULD use that IP address and UDP port to send an MPLS-PLDM Response back to the querier.
[RFC6374]中定义的MPLS-PLDM查询消息处理适用于本文件。此外，当接收到MPLS-PLDM查询消息时，MPLS-PLDM查询的控制代码设置为“带外响应请求”，且存在URO，则响应者应使用该IP地址和UDP端口将MPLS-PLDM响应发送回查询者。
If an out-of-band Response is requested and the URO is missing, the Query SHOULD be dropped in the case of a unidirectional LSP. If the TLV is missing on a bidirectional LSP, the Control Code of the Response message SHOULD set to 0x1C indicating "Error - Invalid Message" ([RFC6374], Section 3.1), and the Response SHOULD be sent
如果请求带外响应且缺少URO，则在单向LSP的情况下应删除查询。如果双向LSP上缺少TLV，则响应消息的控制代码应设置为0x1C，指示“错误-无效消息”（[RFC6374]，第3.1节），并且应发送响应
over the reverse LSP. The receipt of such a malformed request SHOULD be reported to the operator through the management system, with normal precautions taken in respect to the prevention of overload of the error-reporting system.
在反向LSP上。应通过管理系统向操作员报告收到的此类错误请求，并采取正常预防措施，防止错误报告系统过载。
As specified in [RFC6374], the MPLS-PLDM Response can be sent either over the reverse MPLS LSP for a bidirectional LSP or over an IP path. It MUST NOT be sent other than in Response to an MPLS-PLDM Query message.
如[RFC6374]所述，MPLS-PLDM响应可以通过双向LSP的反向MPLS LSP或IP路径发送。除响应MPLS-PLDM查询消息外，不得发送该消息。
When the requested return path is an IP forwarding path and this method is in use, the destination IP address and UDP port are copied from the URO. The source IP address and the source UDP port of the Response packet are left to the discretion of the responder, subject to the normal management and security considerations. If the querier has included URO(s) for only one IP address family and a return path of that type is not available, then the Query message MUST be discarded, and the operator SHOULD be informed of the error through the management system using the normal rate-limited approach. If the responder is configured to only respond with a single Response, and a path using the IP address family in the first URO is not available, the responder MAY search the UROs for the first URO specifying a return address family for which it does have a path and use the parameters in that URO to respond. If the responder is designed or configured not to search for a URO that it can respond to, then the operator SHOULD be informed of the error through the management system using the normal rate-limited approach.
当请求的返回路径是IP转发路径且此方法正在使用时，将从URO复制目标IP地址和UDP端口。响应包的源IP地址和源UDP端口由响应者根据正常管理和安全考虑自行决定。如果查询者仅为一个IP地址系列包含URO，且该类型的返回路径不可用，则必须放弃查询消息，并应使用正常速率限制方法通过管理系统通知操作员错误。如果响应者配置为仅使用单个响应进行响应，并且使用第一个URO中的IP地址族的路径不可用，则响应者可以在URO中搜索第一个URO，以指定其确实具有路径的返回地址族，并使用该URO中的参数进行响应。如果响应者被设计或配置为不搜索其可以响应的URO，则应使用正常速率限制方法通过管理系统通知操作员错误。
The packet format for the MPLS-PLDM Response after the UDP header is as specified in [RFC6374]. As shown in Figure 1, the Associated Channel Header (ACH) [RFC5586] is not included. The information provided by the ACH is not needed since the correct binding between the Query and Response messages is achieved through the UDP port and the session identifier contained in the RFC 6374 message.
UDP报头后MPLS-PLDM响应的数据包格式如[RFC6374]中所述。如图1所示，不包括相关的信道头（ACH）[RFC5586]。由于查询和响应消息之间的正确绑定是通过UDP端口和RFC 6374消息中包含的会话标识符实现的，因此不需要ACH提供的信息。
+----------------------------------------------------------+
| IP Header |
. Source Address = Responders IP Address |
. Destination Address = URO.Address |
. Protocol = UDP .
. .
+----------------------------------------------------------+
| UDP Header |
. Source Port = As chosen by Responder .
. Destination Port = URO.UDP-Destination-Port .
. .
+----------------------------------------------------------+
| Message as specified in RFC 6374 |
. .
+----------------------------------------------------------+
+----------------------------------------------------------+
| IP Header |
. Source Address = Responders IP Address |
. Destination Address = URO.Address |
. Protocol = UDP .
. .
+----------------------------------------------------------+
| UDP Header |
. Source Port = As chosen by Responder .
. Destination Port = URO.UDP-Destination-Port .
. .
+----------------------------------------------------------+
| Message as specified in RFC 6374 |
. .
+----------------------------------------------------------+
Figure 1: Response Packet Format
图1：响应包格式
If the return path is an IP path, only one-way delay or one-way loss measurement can be carried out. In this case, timestamps 3 and 4 MUST be zero as specified in [RFC6374].
如果返回路径是IP路径，则只能进行单向延迟或单向损耗测量。在这种情况下，时间戳3和4必须是[RFC6374]中指定的零。
If the Response was received over UDP/IP and an out-of-band Response was expected, the Response message SHOULD be directed to the appropriate measurement process as determined by the destination UDP port and processed using the corresponding measurement type procedure specified in [RFC6374].
如果通过UDP/IP接收到响应，并且预期会出现带外响应，则响应消息应定向到目标UDP端口确定的适当测量过程，并使用[RFC6374]中指定的相应测量类型过程进行处理。
If the Response was received over UDP/IP and an out-of-band Response was not requested, that Response SHOULD be dropped, and the event SHOULD be reported to the operator through the management system, with normal precautions taken in respect to the prevention of overload of the error-reporting system.
如果通过UDP/IP接收到响应，但未请求带外响应，则应放弃该响应，并通过管理系统向操作员报告事件，同时采取正常预防措施以防止错误报告系统过载。
This protocol MUST be run in accordance with the guidance provided in [RFC5405]. As advised in Section 3.1.2 of RFC 5405, operators that wish to run this protocol at rates in excess of one packet per three seconds need to ensure that the MPLS path being monitored and any IP path that may be used to carry the Response are provisioned such that there is a negligible chance of this protocol causing congestion. Additionally, if a significant number of Response packets are lost, the querier MUST reduce the sending rate to a point where there is a negligible chance that this protocol is contributing to network congestion. The operator should also take precautions that Response
本协议必须按照[RFC5405]中提供的指南运行。如RFC 5405第3.1.2节所述，希望以超过每三秒一个数据包的速率运行该协议的运营商需要确保提供被监控的MPLS路径和可用于承载响应的任何IP路径，以确保该协议造成拥塞的可能性微乎其微。此外，如果大量响应数据包丢失，查询者必须将发送速率降低到该协议导致网络拥塞的可能性可以忽略不计的程度。操作员还应采取预防措施，以确保响应
packets do not leak out of the network domain being used and cause congestion elsewhere. If a default IP address is configured by the equipment vendor, this MUST be an address known to contain the Response packet within the responder. A responder receiving a Query specifying this as a return address, and not being configured to expect such a return address, SHOULD notify the operator in a suitably rate-limited manner.
数据包不会泄漏出正在使用的网络域，并在其他地方造成拥塞。如果设备供应商配置了默认IP地址，则该地址必须是响应程序中包含响应数据包的已知地址。接收到指定为返回地址的查询且未配置为期望此类返回地址的响应者应以适当的速率限制方式通知操作员。
The manageability considerations described in Section 7 of [RFC6374] are applicable to this specification. Additional manageability considerations are noted within the elements of procedure in this document.
[RFC6374]第7节中描述的可管理性注意事项适用于本规范。其他可管理性注意事项见本文件中的程序要素。
Nothing in this document precludes the use of a configured UDP/IP return path in a deployment in which configuration is preferred to signaling. In these circumstances, the URO MAY be omitted from the MPLS-PLDM messages.
本文档中的任何内容都不排除在配置优先于信令的部署中使用已配置的UDP/IP返回路径。在这些情况下，可以从MPLS-PLDM消息中省略URO。
The MPLS-PLDM system is not intended to be deployed on the public Internet. It is intended for deployment in well-managed private and service provider networks. The security considerations described in Section 8 of [RFC6374] are applicable to this specification, and particular attention should be paid to the last two paragraphs. Cryptographic measures may be enhanced by the correct configuration of access-control lists and firewalls.
MPLS-PLDM系统不打算部署在公共互联网上。它旨在部署在管理良好的专用网络和服务提供商网络中。[RFC6374]第8节中描述的安全注意事项适用于本规范，应特别注意最后两段。通过正确配置访问控制列表和防火墙，可以增强加密措施。
To prevent the use of this protocol as a reflection attack vector, the operator should ensure that the IP address in the URO addresses a system that is expecting to act as a receiver of PLDM Responses.
为了防止使用该协议作为反射攻击向量，操作员应确保URO中的IP地址满足期望充当PLDM响应的接收器的系统。
There is no additional exposure of information to pervasive monitoring systems observing LSPs that are being monitored.
没有额外的信息暴露于普遍的监测系统，这些系统观察正在监测的LSP。
IANA has assigned a new optional TLV type from the "MPLS Loss/Delay Measurement TLV Object" registry contained within the "Generic Associated Channel (G-ACh) Parameters" registry set:
IANA已从“通用关联通道（G-ACh）参数”注册表集中包含的“MPLS丢失/延迟测量TLV对象”注册表中分配了一个新的可选TLV类型：
Code Description Reference 131 UDP Return [RFC7876]
代码说明参考131 UDP返回[RFC7876]
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <http://www.rfc-editor.org/info/rfc768>.
[RFC768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，DOI 10.17487/RFC0768，1980年8月<http://www.rfc-editor.org/info/rfc768>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, DOI 10.17487/RFC3945, October 2004, <http://www.rfc-editor.org/info/rfc3945>.
[RFC3945]Mannie，E.，Ed.“通用多协议标签交换（GMPLS）体系结构”，RFC 3945，DOI 10.17487/RFC3945，2004年10月<http://www.rfc-editor.org/info/rfc3945>.
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, DOI 10.17487/RFC5405, November 2008, <http://www.rfc-editor.org/info/rfc5405>.
[RFC5405]Eggert，L.和G.Fairhurst，“应用程序设计者的单播UDP使用指南”，BCP 145，RFC 5405，DOI 10.17487/RFC5405，2008年11月<http://www.rfc-editor.org/info/rfc5405>.
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, DOI 10.17487/RFC5586, June 2009, <http://www.rfc-editor.org/info/rfc5586>.
[RFC5586]Bocci，M.，Ed.，Vigoureux，M.，Ed.，和S.Bryant，Ed.，“MPLS通用关联信道”，RFC 5586，DOI 10.17487/RFC55862009年6月<http://www.rfc-editor.org/info/rfc5586>.
[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, DOI 10.17487/RFC5654, September 2009, <http://www.rfc-editor.org/info/rfc5654>.
[RFC5654]Niven Jenkins，B.，Ed.，Brungard，D.，Ed.，Betts，M.，Ed.，Sprecher，N.，和S.Ueno，“MPLS传输配置文件的要求”，RFC 5654，DOI 10.17487/RFC5654，2009年9月<http://www.rfc-editor.org/info/rfc5654>.
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, DOI 10.17487/RFC6374, September 2011, <http://www.rfc-editor.org/info/rfc6374>.
[RFC6374]Frost，D.和S.Bryant，“MPLS网络的数据包丢失和延迟测量”，RFC 6374，DOI 10.17487/RFC6374，2011年9月<http://www.rfc-editor.org/info/rfc6374>.
[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010, <http://www.rfc-editor.org/info/rfc5921>.
[RFC5921]Bocci，M.，Ed.，Bryant，S.，Ed.，Frost，D.，Ed.，Levrau，L.，和L.Berger，“传输网络中MPLS的框架”，RFC 5921，DOI 10.17487/RFC59212010年7月<http://www.rfc-editor.org/info/rfc5921>.
Acknowledgements
致谢
We acknowledge the contributions of Joseph Chin and Rakesh Gandhi, both with Cisco Systems. We thank Loa Andersson, Eric Osborne, Mustapha Aissaoui, Jeffrey Zhang, and Ross Callon for their review comments.
我们感谢Joseph Chin和Rakesh Gandhi对思科系统的贡献。我们感谢Loa Andersson、Eric Osborne、Mustapha Aissaoui、Jeffrey Zhang和Ross Callon的评论。
We thank all who have reviewed this text and provided feedback.
我们感谢所有审阅本文并提供反馈的人。
Authors' Addresses
作者地址
Stewart Bryant Independent
斯图尔特·布莱恩特独立报
Email: stewart.bryant@gmail.com
Email: stewart.bryant@gmail.com
Siva Sivabalan Cisco Systems
Siva Sivabalan思科系统公司
Email: msiva@cisco.com
Email: msiva@cisco.com
Sagar Soni Cisco Systems
萨加尔索尼思科系统公司
Email: sagsoni@cisco.com
Email: sagsoni@cisco.com