文章总结： 本文档RFC7876定义了在MPLS网络中通过UDP/IP返回路径发送带外丢包和延迟测量响应的标准方法，核心是UDP返回对象(URO)的格式与操作流程，支持防火墙穿越和分布式系统场景，同时明确了拥塞控制和安全部署要求。 综合评分： 85 文章分类： 技术标准,解决方案,网络安安全
用于MPLS网络丢包和延迟测量的UDP返回路径
衡水石头哥 衡水石头哥
铁军哥
2026年5月5日 07:30 北京
在小说阅读器读本章
去阅读
RFC7876：UDP Return Path for Packet Loss and Delay Measurement for MPLS Networks，July 2016
梗概
RFC 6374定义了MPLS网络丢包和延迟测量协议（Packet Loss and Delay Measurement for MPLS，MPLS-PLDM）。本文件规定了通过UDP/IP返回路径发送和处理带外MPLS性能管理响应时要使用的程序。
本备忘录的状态
这是一份互联网标准跟踪文档。
本文档是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已接受公众审查，并已被互联网工程指导小组（IESG）批准发布。有关互联网标准的更多信息，请参阅RFC 7841第2节。
有关本文档当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7876。
版权声明
版权所有（c）2016 IETF Trust和文档作者。版权所有。
本文档受本文档发布之日生效的BCP 78和IETF Trust与IETF文件相关的法律规定（http://trustee.ietf.org/license-info）的约束。请仔细阅读这些文件，因为它们描述了您与本文件相关的权利和限制。从本文档中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并且在提供时不提供简化BSD许可证中所述的保证。
1、简介
本文档描述了如何使用UDP/IP将MPLS-PLDM[RFC6374]带外响应传送到查询器。
可能需要使用UDP来支持数据路径管理，例如穿过防火墙，或者提供双基地操作中所需的必要多路复用，其中查询器和收集器不位于同一位置，并且收集器正在收集多个响应器的响应信息。在高度扩展的系统中，一些MPLS-PLDM会话可能会被卸载到分布式系统内的特定节点，该分布式系统整体上包括标签交换路由器（Label Switching Router，LSR）。在此类系统中，响应可以通过LSR中的任何接口到达，并且需要在内部转发到负责处理特定MPLS-PLDM测量的处理器。目前，MPLS-PLDM协议没有任何机制来将PLDM响应消息传递到多CPU LSR内的特定节点。
本规范中描述的过程描述了查询器如何请求通过IP将MPLS-PLDM响应传递到动态UDP端口。它不对协议进行其他更改，因此不会影响通过MPLS关联通道[RFC5586]传送响应的情况。
2、需求语言
本文档中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应该”、“不应该”、“推荐”、“可以”和“可选”应按[RFC2119]中的描述进行解释。
3、解决方案概述
本文档规定，除非另有配置，如果MPLS-PLDM查询中存在UDP返回对象（UDP Return Object，URO），则响应器应使用URO中的IP地址和UDP端口来回复查询方。查询器可以在MPLS-PLDM查询中包含多个URO，向响应器指示应该向每个地址端口对发送相同的响应。响应器可以被设计或配置为仅传输单个响应，在这种情况下，必须使用它能够使用的查询数据包中的第一个URO中指定的参数来发送响应（参见第4.3节）。
本文档中定义的过程可应用于单向和双向标签交换路径（Label Switched Paths，LSP）。在本文档中，术语“双向LSP”包括[RFC3945]中定义的共路由双向LSP以及由一对单向LSP构造的相关双向LSP。
在LSP的入口/出口点相互关联的LSP（每个方向一个）[RFC5654]。本文档中定义的机制可应用于IP/MPLS和MPLS传输配置文件（MPLS Transport Profile，MPLS-TP）[RFC5654][RFC5921]。
3.1、UDP返回对象
UDP返回对象（URO）的格式如下：
类型和长度字段均为8位长。长度字段指示对象剩余部分的大小（以字节为单位）（即，它是以字节为单位的地址大小加2）。当地址为IPv4时，长度字段为6；当地址为IPv6时，长度字段为18。因此，长度字段既充当TLV解析参数又充当地址族类型指示符。
UDP返回对象类型（URO类型）的值为131。
UDP-Destination-Port是[RFC768]中指定的UDP目标端口。
地址是IPv4或IPv6地址。
URO不得出现在响应中，如果发现它存在，则必须将其忽略。
为了防止响应者需要回复哪个地址出现任何歧义，包含URO的MPLS-PLDM查询消息不得包含RFC 6374返回地址TLV（TLV 1）。此外，[RFC6374]第3.5.2节中描述的从源地址TLV（TLV 130）构造返回地址的方法不得用于构造对包含URO的查询消息的响应。
4、操作原理
本文档定义了UDP返回对象，以使MPLS-PLDM查询器能够使用UDP/IP封装指定MPLS-PLDM回复的返回路径。
当通过将MPLS-PLDM查询的控制代码设置为“带外响应请求”来请求带外MPLS-PLDM响应时，并且URO存在，响应器应该在URO中包含的指定目标IP地址上的指定目标UDP端口上将响应发送回查询器。
如果URO是预期的但不存在于查询消息中，并且在带外请求MPLS-PLDM响应，则不得进一步处理查询消息，并且如果可能，应将“错误 – 无效消息”（[RFC6374]，第3.1节）发送到查询者并通过管理系统通知操作员（有关更多详细信息，请参阅第4.2节）。
4.1、发送MPLS-PLDM查询
当发送MPLS-PLDM查询消息时，除了[RFC6374]中定义的规则和过程之外，MPLS-PLDM查询的控制码必须设置为“带外响应请求”，并且URO必须在MPLS-PLDM查询消息中携带。
如果查询器使用UDP端口来解复用不同测量类型的响应，则每种测量类型（延迟、丢失和延迟-丢失组合）必须有不同的UDP端口。
一个实现可以使用多个UDP端口用于相同的测量类型，以将响应引导到LSR中的正确管理过程。
4.2、接收MPLS-PLDM查询请求
[RFC6374]中定义的MPLS-PLDM查询消息的处理适用于本文档。此外，当收到MPLS-PLDM查询消息时，MPLS-PLDM查询的控制代码设置为“带外响应请求”且存在URO，则响应器应使用该IP地址和UDP端口将MPLSPLDM响应发送回查询方。
如果请求带外响应并且URO丢失，则在单向LSP的情况下应该丢弃查询。如果双向 LSP 上缺少 TLV，则响应消息的控制代码应设置为 0x1C，表示“错误 – 无效消息”（[RFC6374]，第 3.1 节），并且应通过反向 LSP 发送响应。收到这种格式错误的请求应该通过管理系统报告给操作员，并采取正常的预防措施来防止错误报告系统过载。
4.3、发送MPLS-PLDM响应
正如[RFC6374]中所指定的，MPLS-PLDM响应可以通过双向LSP的反向MPLS LSP或通过IP路径发送。除了响应MPLS-PLDM查询消息之外，不得发送该消息。
当请求的返回路径是IP转发路径并且使用该方法时，从URO中复制目的IP地址和UDP端口。响应数据包的源IP地址和源UDP端口由响应者自行决定，但须遵守正常的管理和安全考虑。如果查询器仅包含一个IP地址族的URO，并且该类型的返回路径不可用，则必须丢弃查询消息，并且应该使用正常的速率限制方法通过管理系统向操作员通知错误。如果响应器配置为仅使用单个响应进行响应，并且使用第一个URO中的IP地址族的路径不可用，则响应器可以在URO中搜索第一个URO，指定其确实具有路径的返回地址族，并使用该URO中的参数进行响应。如果响应器被设计或配置为不搜索它可以响应的URO，则应该使用正常的速率限制方法通过管理系统向操作员通知错误。
UDP标头之后的MPLS-PLDM响应的数据包格式如[RFC6374]中指定。如图1所示，不包括关联信道标头（Associated Channel Header，ACH）[RFC5586]。不需要ACH提供的信息，因为查询和响应消息之间的正确绑定是通过UDP端口和RFC 6374消息中包含的会话标识符实现的。
图1：响应数据包格式
如果返回路径是IP路径，则只能进行单向时延或单向损耗测量。在这种情况下，时间戳3和4必须为零，如[RFC6374]中所指定。
4.4、接收MPLS-PLDM响应
如果响应是通过UDP/IP接收的，并且预期是带外响应，则响应消息应该定向到由目标UDP端口确定的适当测量过程，并使用[RFC6374]中指定的相应测量类型过程进行处理。
如果响应是通过UDP/IP接收的，并且未请求带外响应，则应丢弃该响应，并且应通过管理系统向操作员报告该事件，并采取正常的预防措施来防止错误报告系统过载。
5、拥塞注意事项
该协议必须按照[RFC5405]中提供的指导运行。正如RFC 5405第3.1.2节中所建议的，希望以超过每三秒一个数据包的速率运行该协议的运营商需要确保配置受监控的MPLS路径以及可用于承载响应的任何IP路径，以便该协议导致拥塞的可能性可以忽略不计。此外，如果丢失大量响应数据包，查询器必须将发送速率降低到该协议导致网络拥塞的可能性可以忽略不计的程度。操作员还应采取预防措施
数据包不会泄漏出正在使用的网络域并导致其他地方拥塞。如果设备供应商配置了默认IP地址，则该地址必须是响应器内包含响应数据包的已知地址。接收将其指定为返回地址的查询的响应者，并且没有被配置为期望这样的返回地址，应该以适当的速率限制方式通知操作员。
6、可管理性考虑
[RFC6374]第7节中描述的可管理性注意事项适用于本规范。本文档的程序要素中注明了其他可管理性注意事项。
本文档中的任何内容都不排除在配置优先于信令的部署中使用已配置的UDP/IP返回路径。在这些情况下，URO可以从MPLS-PLDM消息中省略。
7、安全考虑
MPLS-PLDM系统不适合部署在公共互联网上。它旨在部署在管理良好的专用网络和服务提供商网络中。[RFC6374]第8节中描述的安全考虑因素适用于本规范，并且应特别注意最后两段。通过访问控制列表和防火墙的正确配置可以增强加密措施。
为了防止使用该协议作为反射攻击媒介，运营商应确保URO中的IP地址对期望充当PLDM响应接收方的系统进行寻址。
没有额外的信息暴露给普遍监控系统来观察正在监控的LSP。
8、IANA考虑因素
IANA已从“通用关联信道（Generic Associated Channel，G-ACh）参数”注册表集中包含的“MPLS丢失/延迟测量TLV对象”注册表中分配了新的可选TLV类型：
9、参考文献
9.1、规范性参考文献
[RFC768]Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <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>.[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>.[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>.[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>.[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>.[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>.
9.2、参考资料
[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>.
致谢
我们感谢Cisco Systems的Joseph Chin和Rakesh Gandhi所做的贡献。我们感谢Loa Andersson、Eric Osborne、Mustapha Aissaoui、Jeffrey Zhang和Ross Callon的审阅意见。
我们感谢所有审阅本文并提供反馈的人。
***推荐阅读***
我们的WireGuard管理系统支持手机电脑了！全平台终端配置，支持扫码连接，一键搞定
保姆级教程：一条命令部署OpenVPN管理系统V4版，支持Win/Mac/安卓/iOS全平台接入
成本省下99.7%！用40元的腾讯云服务器自建IPsecVPN，成功对接企业级飞塔防火墙
原生支持真的好用吗？Ubuntu 24.04桌面共享vs远程登录全解析
从屡战屡败到一气呵成：EVE-NG专业版 + Cumulus VX终于跑通RoCE
告别OSPF！EVE-NG专业版+BGP Unnumbered打通Underlay的完整实战
从180秒到0.01秒：智算中心Underlay路由优化的速度与激情
ECN配置折戟记：vEOS模拟器局限性深度剖析
告别云服务器费用：零成本将旧手机改造Linux服务器实战指南
手机也能跑DeepSeek-R1/Qwen3了：零成本搭建AI推理平台
2048卡昇腾910C集群算力集群交付工程手册
2048卡H100算力中心100G无阻塞存储网建设方案
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：铁军哥 衡水石头哥 衡水石头哥《用于MPLS网络丢包和延迟测量的UDP返回路径》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论