Network Working Group G. Swallow
Request for Comments: 4928 S. Bryant
BCP: 128 Cisco Systems, Inc.
Category: Best Current Practice L. Andersson
Acreo AB
June 2007
Network Working Group G. Swallow
Request for Comments: 4928 S. Bryant
BCP: 128 Cisco Systems, Inc.
Category: Best Current Practice L. Andersson
Acreo AB
June 2007
Avoiding Equal Cost Multipath Treatment in MPLS Networks
MPLS网络中避免等代价多径处理
Status of This Memo
关于下段备忘
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document describes the Equal Cost Multipath (ECMP) behavior of currently deployed MPLS networks. This document makes best practice recommendations for anyone defining an application to run over an MPLS network that wishes to avoid the reordering that can result from transmission of different packets from the same flow over multiple different equal cost paths. These recommendations rely on inspection of the IP version number field in packets. Despite the heuristic nature of the recommendations, they provide a relatively safe way to operate MPLS networks, even if future allocations of IP version numbers were made for some purpose.
本文档描述当前部署的MPLS网络的等成本多路径（ECMP）行为。本文档为任何定义要在MPLS网络上运行的应用程序的人提供了最佳实践建议，这些应用程序希望避免由于在多个不同的等成本路径上传输来自同一流的不同数据包而导致的重新排序。这些建议依赖于对数据包中IP版本号字段的检查。尽管这些建议具有启发性，但它们提供了一种相对安全的方式来操作MPLS网络，即使将来分配IP版本号是出于某种目的。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Terminology ................................................2
2. Current ECMP Practices ..........................................2
3. Recommendations for Avoiding ECMP Treatment .....................4
4. Security Considerations .........................................5
5. IANA Considerations .............................................5
6. References ......................................................6
6.1. Normative References .......................................6
6.2. Informative References .....................................6
1. Introduction ....................................................2
1.1. Terminology ................................................2
2. Current ECMP Practices ..........................................2
3. Recommendations for Avoiding ECMP Treatment .....................4
4. Security Considerations .........................................5
5. IANA Considerations .............................................5
6. References ......................................................6
6.1. Normative References .......................................6
6.2. Informative References .....................................6
This document describes the Equal Cost Multipath (ECMP) behavior of currently deployed MPLS networks. We discuss cases where multiple packets from the same top-level LSP might be transmitted over different equal cost paths, resulting in possible mis-ordering of packets that are part of the same top-level LSP. This document also makes best practice recommendations for anyone defining an application to run over an MPLS network that wishes to avoid the resulting potential for mis-ordered packets. While disabling ECMP behavior is an option open to most operators, few (if any) have chosen to do so, and the application designer does not have control over the behavior of the networks that the application may run over. Thus, ECMP behavior is a reality that must be reckoned with.
本文档描述当前部署的MPLS网络的等成本多路径（ECMP）行为。我们讨论了来自同一顶级LSP的多个数据包可能通过不同的等成本路径传输的情况，这可能导致属于同一顶级LSP的数据包的排序错误。本文档还为任何定义要在MPLS网络上运行的应用程序的人提供了最佳实践建议，以避免由此产生的误序数据包的可能性。尽管禁用ECMP行为是大多数运营商可以选择的选项，但很少（如果有的话）选择这样做，并且应用程序设计者无法控制应用程序可能运行的网络的行为。因此，ECMP行为是一个必须考虑的现实。
ECMP Equal Cost Multipath
等成本多路径
FEC Forwarding Equivalence Class
转发等价类
IP ECMP A forwarding behavior in which the selection of the next-hop between equal cost routes is based on the header(s) of an IP packet
IP ECMP一种转发行为，在这种转发行为中，根据IP数据包的报头在等成本路由之间选择下一跳
Label ECMP A forwarding behavior in which the selection of the next-hop between equal cost routes is based on the label stack of an MPLS packet
标签ECMP一种转发行为，在这种转发行为中，根据MPLS数据包的标签堆栈选择等成本路由之间的下一跳
LSP Label Switched Path
标签交换路径
LSR Label Switching Router
标签交换路由器
The MPLS label stack and Forwarding Equivalence Classes are defined in [RFC3031]. The MPLS label stack does not carry a Protocol Identifier. Instead the payload of an MPLS packet is identified by the Forwarding Equivalence Class (FEC) of the bottom most label. Thus, it is not possible to know the payload type if one does not know the label binding for the bottom most label. Since an LSR, which is processing a label stack, need only know the binding for the label(s) it must process, it is very often the case that LSRs along an LSP are unable to determine the payload type of the carried contents.
MPLS标签堆栈和转发等价类在[RFC3031]中定义。MPLS标签堆栈不携带协议标识符。相反，MPLS数据包的有效负载由最底层标签的转发等价类（FEC）标识。因此，如果不知道最底部标签的标签绑定，就不可能知道有效负载类型。由于正在处理标签堆栈的LSR只需要知道其必须处理的标签的绑定，因此通常情况下，LSP上的LSR无法确定所携带内容的有效负载类型。
As a means of potentially reducing delay and congestion, IP networks have taken advantage of multiple paths through a network by splitting
作为一种潜在减少延迟和拥塞的手段，IP网络通过拆分利用了通过网络的多条路径
traffic flows across those paths. The general name for this practice is Equal Cost Multipath or ECMP. In general, this is done by hashing on various fields on the IP or contained headers. In practice, within a network core, the hashing is based mainly or exclusively on the IP source and destination addresses. The reason for splitting aggregated flows in this manner is to minimize the re-ordering of packets belonging to individual flows contained within the aggregated flow. Within this document, we use the term IP ECMP for this type of forwarding algorithm.
交通在这些道路上流动。这种做法的通用名称是等成本多路径或ECMP。通常，这是通过对IP或包含的标头上的各个字段进行散列来完成的。实际上，在网络核心内，哈希主要或完全基于IP源地址和目标地址。以这种方式分割聚合流的原因是最小化属于聚合流中包含的单个流的分组的重新排序。在本文中，我们使用术语IP ECMP来表示这种类型的转发算法。
For packets that contain both a label stack and an encapsulated IPv4 (or IPv6) packet, current implementations in some cases may hash on any combination of labels and IPv4 (or IPv6) source and destination addresses.
对于同时包含标签堆栈和封装的IPv4（或IPv6）数据包的数据包，在某些情况下，当前的实现可能会对标签和IPv4（或IPv6）源地址和目标地址的任意组合进行散列。
In the early days of MPLS, the payload was almost exclusively IP. Even today the overwhelming majority of carried traffic remains IP. Providers of MPLS equipment sought to continue this IP ECMP behavior. As shown above, it is not possible to know whether the payload of an MPLS packet is IP at every place where IP ECMP needs to be performed. Thus vendors have taken the liberty of guessing the payload. By inspecting the first nibble beyond the label stack, existing equipment infers that a packet is not IPv4 or IPv6 if the value of the nibble (where the IP version number would be found) is not 0x4 or 0x6 respectively. Most deployed LSRs will treat a packet whose first nibble is equal to 0x4 as if the payload were IPv4 for purposes of IP ECMP.
在MPLS的早期，负载几乎完全是IP。即使在今天，绝大多数的承载流量仍然是IP。MPLS设备的提供商试图继续这种IP ECMP行为。如上所示，不可能知道在需要执行IP ECMP的每个地方MPLS分组的有效负载是否为IP。因此，供应商可以随意猜测有效负载。通过检查标签堆栈之外的第一个半字节，现有设备推断，如果半字节的值（可以找到IP版本号）分别不是0x4或0x6，则数据包不是IPv4或IPv6。出于IP ECMP的目的，大多数部署的LSR将把第一个半字节等于0x4的数据包视为有效负载是IPv4。
A consequence of this is that any application that defines an FEC that does not take measures to prevent the values 0x4 and 0x6 from occurring in the first nibble of the payload may be subject to IP ECMP and thus having their flows take multiple paths and arriving with considerable jitter and possibly out of order. While none of this is in violation of the basic service offering of IP, it is detrimental to the performance of various classes of applications. It also complicates the measurement, monitoring, and tracing of those flows.
这样做的结果是，任何定义FEC的应用程序如果没有采取措施防止值0x4和0x6出现在有效负载的第一个半字节中，则可能会受到IP ECMP的影响，从而使其流采用多条路径，并以相当大的抖动和可能的无序到达。虽然所有这些都没有违反IP的基本服务提供，但这对各类应用程序的性能是有害的。它还使这些流的测量、监视和跟踪变得复杂。
New MPLS payload types are emerging, such as those specified by the IETF PWE3 and AVT working groups. These payloads are not IP and, if specified without constraint, might be mistaken for IP.
新的MPLS有效负载类型正在出现，如IETF PWE3和AVT工作组指定的类型。这些有效载荷不是IP，如果在没有约束的情况下指定，可能会被误认为是IP。
It must also be noted that LSRs that correctly identify a payload as not being IP most often will load-share traffic across multiple equal-cost paths based on the label stack. Any reserved label, no matter where it is located in the stack, may be included in the computation for load balancing. Modification of the label stack between packets of a single flow could result in re-ordering that
还必须注意，正确地将有效负载标识为非IP的LSR通常会基于标签堆栈跨多个等成本路径共享流量。任何保留标签，无论其位于堆栈中的何处，都可以包含在负载平衡计算中。修改单个流的数据包之间的标签堆栈可能会导致重新排序
flow. That is, were an explicit null or a router-alert label to be added to a packet, that packet could take a different path through the network.
流也就是说，如果向数据包添加显式null或路由器警报标签，则该数据包可能会在网络中采用不同的路径。
Note that for some applications, being mistaken for IPv4 may not be detrimental. The trivial case being where the payload behind the top label is a packet belonging to an MPLS IPv4 VPN. Here the real payload is IP and most (if not all) deployed equipment will locate the end of the label stack and correctly perform IP ECMP.
请注意，对于某些应用程序，被误认为是IPv4可能并不有害。最常见的情况是，顶部标签后面的有效负载是属于MPLS IPv4 VPN的数据包。这里真正的有效载荷是IP，大多数（如果不是全部）部署的设备将定位标签堆栈的末端，并正确执行IP ECMP。
A less obvious case is when the packets of a given flow happen to have constant values in the fields upon which IP ECMP would be performed. For example, if an Ethernet frame immediately follows the label and the LSR does ECMP on IPv4, but does not do ECMP on IPv6, then either the first nibble will be 0x4, or it will be something else. If the nibble is not 0x4 then no IP ECMP is performed, but Label ECMP may be performed. If it is 0x4, then the constant values of the MAC addresses overlay the fields that would have been occupied by the source and destination addresses of an IP header. In this case, the input to the ECMP algorithm would be a constant value and thus the algorithm would always return the same result.
一个不太明显的情况是，给定流的数据包恰好在执行IP ECMP的字段中具有常量值。例如，如果一个以太网帧紧跟在标签后面，并且LSR在IPv4上执行ECMP，但在IPv6上不执行ECMP，那么第一个半字节将是0x4，或者是其他内容。如果半字节不是0x4，则不执行IP ECMP，但可以执行标签ECMP。如果是0x4，则MAC地址的常量值覆盖IP头的源地址和目标地址所占用的字段。因此，在这种情况下，算法的输入值和算法的输入值总是相同的。
We will use the term "Application Label" to refer to a label that has been allocated with an FEC Type that is defined (or simply used) by an application. Such labels necessarily appear at the bottom of the label stack, that is, below labels associated with transporting the packet across an MPLS network. The FEC Type of the Application label defines the payload that follows. Anyone defining an application to be transported over MPLS is free to define new FEC Types and the format of the payload that will be carried.
我们将使用术语“应用程序标签”来指已分配有由应用程序定义（或简单使用）的FEC类型的标签。这样的标签必然出现在标签堆栈的底部，即，在与通过MPLS网络传输分组相关联的标签下面。应用程序标签的FEC类型定义了随后的有效负载。任何定义要通过MPLS传输的应用程序的人都可以自由定义新的FEC类型和将要承载的有效负载的格式。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | Exp |0| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . . .
. . . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | Exp |0| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application Label | Exp |1| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1st Nbl| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | Exp |0| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . . .
. . . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | Exp |0| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application Label | Exp |1| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1st Nbl| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In order to avoid IP ECMP treatment, it is necessary that an application take precautions to not be mistaken as IP by deployed equipment that snoops on the presumed location of the IP Version field. Thus, at a minimum, the chosen format must disallow the values 0x4 and 0x6 in the first nibble of their payload.
为了避免IP ECMP处理，应用程序必须采取预防措施，以免在IP版本字段的假定位置窥探部署的设备将其误认为IP。因此，所选格式至少必须禁止其有效负载的第一个半字节中的值0x4和0x6。
It is REQUIRED, however, that applications depend upon in-order packet delivery restrict the first nibble values to 0x0 and 0x1. This will ensure that their traffic flows will not be affected if some future routing equipment does similar snooping on some future version(s) of IP.
然而，应用程序需要依赖于数据包传递顺序，将第一个半字节值限制为0x0和0x1。这将确保如果某些未来路由设备对某些未来版本的IP进行类似的窥探，它们的流量不会受到影响。
This behavior implies that if in the future an IP version is defined with a version number of 0x0 or 0x1, then equipment complying with this BCP would be unable to look past one or more MPLS headers, and loadsplit traffic from a single LSP across multiple paths based on a hash of specific fields in the IPv0 or IPv1 headers. That is, IP traffic employing these version numbers would be safe from disturbances caused by inappropriate loadsplitting, but would also not be able to get the performance benefits.
此行为意味着，如果将来定义的IP版本的版本号为0x0或0x1，则符合此BCP的设备将无法查看一个或多个MPLS报头，并基于IPv0或IPv1报头中特定字段的散列，跨多个路径加载来自单个LSP的拆分流量。也就是说，使用这些版本号的IP流量将不会受到不适当的负载拆分造成的干扰，但也无法获得性能优势。
For an example of how ECMP is avoided in Pseudowires, see [RFC4385].
有关如何在伪导线中避免ECMP的示例，请参见[RFC4385]。
This memo discusses the conditions under which MPLS traffic associated with a single top-level LSP either does or does not have the possibility of being split between multiple paths, implying the possibility of mis-ordering between packets belonging to the same top-level LSP. From a security point of view, the worse that could result from a security breach of the mechanisms described here would be mis-ordering of packets, and possible corresponding loss of throughput (for example, TCP connections may in some cases reduce the window size in response to mis-ordered packets). However, in order to create even this limited result, an attacker would need to either change the configuration or implementation of a router, or change the bits on the wire as transmitted in a packet.
本备忘录讨论了与单个顶级LSP相关联的MPLS流量是否可能在多条路径之间分割的情况，这意味着属于同一顶级LSP的数据包之间可能存在顺序错误。从安全性的角度来看，违反此处所述机制的安全性可能导致的最坏情况是数据包的错误排序，以及可能相应的吞吐量损失（例如，TCP连接在某些情况下可能会减少窗口大小，以响应错误排序的数据包）。然而，为了创建这种有限的结果，攻击者需要更改路由器的配置或实现，或者更改数据包中传输的线路上的位。
Other security issues in the deployment of MPLS are outside the scope of this document, but are discussed in other MPLS specifications, such as [RFC3031], [RFC3036], [RFC3107], [RFC3209], [RFC3478], [RFC3479], [RFC4206], [RFC4220], [RFC4221], [RFC4378], AND [RFC4379].
MPLS部署中的其他安全问题不在本文档的范围内，但在其他MPLS规范中讨论，如[RFC3031]、[RFC3036]、[RFC3107]、[RFC3209]、[RFC3478]、[RFC3479]、[RFC4206]、[RFC4220]、[RFC4221]、[RFC4378]和[RFC4379]。
IANA has marked the value 0x1 in the IP protocol version number space as "Reserved" and placed a reference to this document to both values 0x0 and 0x1.
IANA已将IP协议版本号空间中的值0x1标记为“保留”，并将对本文档的引用放置为值0x0和0x1。
Note that this document does not in any way change the policies regarding the allocation of version numbers, including the possible use of the reserved numbers for some future purpose.
请注意，本文件不会以任何方式更改有关版本号分配的政策，包括将来可能使用保留的版本号。
[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月。
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC3036]Andersson，L.，Doolan，P.，Feldman，N.，Fredette，A.，和B.Thomas，“LDP规范”，RFC 3036，2001年1月。
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001.
[RFC3107]Rekhter，Y.和E.Rosen，“在BGP-4中携带标签信息”，RFC 3107，2001年5月。
[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月。
[RFC3478] Leelanivas, M., Rekhter, Y., and R. Aggarwal, "Graceful Restart Mechanism for Label Distribution Protocol", RFC 3478, February 2003.
[RFC3478]Leelanivas，M.，Rekhter，Y.，和R.Aggarwal，“标签分发协议的优雅重启机制”，RFC 3478，2003年2月。
[RFC3479] Farrel, A., Ed., "Fault Tolerance for the Label Distribution Protocol (LDP)", RFC 3479, February 2003.
[RFC3479]Farrel，A.，Ed.“标签分发协议（LDP）的容错”，RFC 3479，2003年2月。
[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月。
[RFC4220] Dubuc, M., Nadeau, T., and J. Lang, "Traffic Engineering Link Management Information Base", RFC 4220, November 2005.
[RFC4220]Dubuc，M.，Nadeau，T.，和J.Lang，“交通工程链路管理信息库”，RFC 4220，2005年11月。
[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月。
[RFC4378] Allan, D., Ed., and T. Nadeau, Ed., "A Framework for Multi-Protocol Label Switching (MPLS) Operations and Management (OAM)", RFC 4378, February 2006.
《多协议管理》（RFOA）和《多协议管理》，2006年2月，第378页。
[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月。
[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月。
Authors' Addresses
作者地址
Loa Andersson Acreo AB Electrum 236 SE-146 40 Kista Sweden
Loa Andersson Acreo AB Electrum 236 SE-146 40瑞典基斯塔
EMail: loa@pi.se
EMail: loa@pi.se
Stewart Bryant Cisco Systems 250, Longwater, Green Park, Reading, RG2 6GB, UK
Stewart Bryant Cisco Systems 250，朗沃特，格林公园，雷丁，RG2 6GB，英国
EMail: stbryant@cisco.com
EMail: stbryant@cisco.com
George Swallow Cisco Systems, Inc. 1414 Massachusetts Ave Boxborough, MA 01719
George Swallow Cisco Systems，Inc.马萨诸塞州Boxborough大道1414号，邮编01719
EMail: swallow@cisco.com
EMail: swallow@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。