Network Working Group N. Shen
Request for Comments: 3906 Redback Networks
Category: Informational H. Smit
October 2004
Network Working Group N. Shen
Request for Comments: 3906 Redback Networks
Category: Informational H. Smit
October 2004
Calculating Interior Gateway Protocol (IGP) Routes Over Traffic Engineering Tunnels
计算交通工程隧道上的内部网关协议（IGP）路由
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This document describes how conventional hop-by-hop link-state routing protocols interact with new Traffic Engineering capabilities to create Interior Gateway Protocol (IGP) shortcuts. In particular, this document describes how Dijkstra's Shortest Path First (SPF) algorithm can be adapted so that link-state IGPs will calculate IP routes to forward traffic over tunnels that are set up by Traffic Engineering.
本文档描述了传统逐跳链路状态路由协议如何与新的流量工程功能交互，以创建内部网关协议（IGP）快捷方式。特别是，本文件描述了Dijkstra的最短路径优先（SPF）算法如何进行调整，以便链路状态IGPs将计算IP路由，通过交通工程设置的隧道转发交通。
Link-state protocols like integrated Intermediate System to Intermediate System (IS-IS) [1] and OSPF [2] use Dijkstra's SPF algorithm to compute a shortest path tree to all nodes in the network. Routing tables are derived from this shortest path tree. The routing tables contain tuples of destination and first-hop information. If a router does normal hop-by-hop routing, the first-hop will be a physical interface attached to the router. New traffic engineering algorithms calculate explicit routes to one or more nodes in the network. At the router that originates explicit routes, such routes can be viewed as logical interfaces which supply Label Switched Paths through the network. In the context of this document, we refer to these Label Switched Paths as Traffic Engineering tunnels (TE-tunnels). Such capabilities are specified in [3] and [4].
集成中间系统到中间系统（IS-IS）[1]和OSPF[2]等链路状态协议使用Dijkstra的SPF算法计算到网络中所有节点的最短路径树。路由表由此最短路径树派生。路由表包含目的地和第一跳信息的元组。如果路由器执行正常的逐跳路由，则第一跳将是连接到路由器的物理接口。新的流量工程算法计算到网络中一个或多个节点的显式路由。在发起显式路由的路由器上，此类路由可被视为通过网络提供标签交换路径的逻辑接口。在本文档中，我们将这些标签交换路径称为交通工程隧道（TE隧道）。[3]和[4]中规定了此类能力。
The existence of TE-tunnels in the network and how the traffic in the network is switched over those tunnels are orthogonal issues. A node may define static routes pointing to the TE-tunnels, it may match the
网络中TE隧道的存在以及网络中的流量如何通过这些隧道进行切换是正交问题。节点可以定义指向TE隧道的静态路由，它可以匹配
recursive route next-hop with the TE-tunnel end-point address, or it may define local policy such as affinity based tunnel selection for switching certain traffic. This document describes a mechanism utilizing link-state IGPs to dynamically install IGP routes over those TE-tunnels.
使用TE隧道端点地址递归路由下一跳，或者它可以定义本地策略，例如基于亲和性的隧道选择，用于切换特定流量。本文档描述了一种利用链路状态IGP在这些TE隧道上动态安装IGP路由的机制。
The tunnels under consideration are tunnels created explicitly by the node performing the calculation, and with an end-point address known to this node. For use in algorithms such as the one described in this document, it does not matter whether the tunnel itself is strictly or loosely routed. A simple constraint can ensure that the mechanism be loop free. When a router chooses to inject a packet addressed to a destination D, the router may inject the packet into a tunnel where the end-point is closer (according to link-state IGP topology) to the destination D than is the injecting router. In other words, the tail-end of the tunnel has to be a downstream IGP node for the destination D. The algorithms that follow are one way that a router may obey this rule and dynamically make intelligent choices about when to use TE-tunnels for traffic. This algorithm may be used in conjunction with other mechanisms such as statically defined routes over TE-tunnels or traffic flow and QoS based TE-tunnel selection.
正在考虑的隧道是由执行计算的节点显式创建的隧道，并且具有该节点已知的端点地址。对于本文档中描述的算法，隧道本身是严格路由还是松散路由并不重要。一个简单的约束可以确保机构是无回路的。当路由器选择注入寻址到目的地D的分组时，路由器可以将分组注入到端点（根据链路状态IGP拓扑）比注入路由器更靠近目的地D的隧道中。换句话说，隧道的尾端必须是目的地D的下游IGP节点。下面的算法是路由器遵守这一规则并动态做出关于何时使用TE隧道进行通信的智能选择的一种方法。该算法可与其他机制结合使用，例如TE隧道上的静态定义路由或基于流量和QoS的TE隧道选择。
This IGP shortcut mechanism assumes the TE-tunnels have already been setup. The TE-tunnels in the network may be used for QoS, bandwidth, redundancy, or fastreroute reasons. When an IGP shortcut mechanism is applied on those tunnels, or other mechanisms are used in conjunction with an IGP shortcut, the physical traffic switching through those tunnels may not match the initial traffic engineering setup goal. Also the traffic pattern in the network may change with time. Some forwarding plane measurement and feedback into the adjustment of TE-tunnel attributes need to be there to ensure that the network is being traffic engineered efficiently [6].
此IGP快捷方式机制假定TE隧道已设置。网络中的TE隧道可用于QoS、带宽、冗余或快速重路由。当在这些隧道上应用IGP快捷方式机制，或与IGP快捷方式一起使用其他机制时，通过这些隧道的物理流量切换可能与初始流量工程设置目标不匹配。网络中的流量模式也可能随时间而变化。需要对TE隧道属性的调整进行一些转发平面测量和反馈，以确保有效地设计网络流量[6]。
During each step of the SPF computation, a router discovers the path to one node in the network. If that node is directly connected to the calculating router, the first-hop information is derived from the adjacency database. If a node is not directly connected to the calculating router, it inherits the first-hop information from the parent(s) of that node. Each node has one or more parents. Each node is the parent of zero or more down-stream nodes.
在SPF计算的每个步骤中，路由器都会发现到网络中一个节点的路径。如果该节点直接连接到计算路由器，则第一跳信息来自邻接数据库。如果节点未直接连接到计算路由器，它将从该节点的父节点继承第一跳信息。每个节点都有一个或多个父节点。每个节点都是零个或多个下游节点的父节点。
For traffic engineering purposes, each router maintains a list of all TE-tunnels that originate at this router. For each of those TE-tunnels, the router at the tail-end is known.
出于流量工程的目的，每个路由器都维护一个源于此路由器的所有TE隧道的列表。对于这些TE隧道中的每一个，末端的路由器是已知的。
During SPF, when a router finds the path to a new node (in other words, this new node is moved from the TENTative list to the PATHS list), the router must determine the first-hop information. There are three possible ways to do this:
在SPF期间，当路由器找到新节点的路径时（换句话说，该新节点从暂定列表移动到路径列表），路由器必须确定第一跳信息。有三种可能的方法可以做到这一点：
- Examine the list of tail-end routers directly reachable via a TE-tunnel. If there is a TE-tunnel to this node, we use the TE-tunnel as the first-hop.
- 检查可通过TE隧道直接访问的后端路由器列表。如果有到该节点的TE隧道，我们将使用TE隧道作为第一跳。
- If there is no TE-tunnel, and the node is directly connected, we use the first-hop information from the adjacency database.
- 如果没有TE隧道，且节点直接连接，则使用邻接数据库中的第一跳信息。
- If the node is not directly connected, and is not directly reachable via a TE-tunnel, we copy the first-hop information from the parent node(s) to the new node.
- 如果节点没有直接连接，并且不能通过TE隧道直接到达，我们将第一跳信息从父节点复制到新节点。
The result of this algorithm is that traffic to nodes that are the tail-end of TE-tunnels, will flow over those TE-tunnels. Traffic to nodes that are downstream of the tail-end nodes will also flow over those TE-tunnels. If there are multiple TE-tunnels to different intermediate nodes on the path to destination node X, traffic will flow over the TE-tunnel whose tail-end node is closest to node X. In certain applications, there is a need to carry both the native adjacency and the TE-tunnel next-hop information for the TE-tunnel tail-end and its downstream nodes. The head-end node may conditionally switch the data traffic onto TE-tunnels based on user defined criteria or events; the head-end node may also split flow of traffic towards either types of the next-hops; the head-end node may install the routes with two different types of next-hops into two separate RIBs. Multicast protocols running over physical links may have to perform RPF checks using the native adjacency next-hops rather than the TE-tunnel next-hops.
该算法的结果是，到TE隧道末端节点的流量将流过这些TE隧道。到尾端节点下游节点的流量也将流过这些TE隧道。如果在到目的地节点X的路径上有多个到不同中间节点的TE隧道，则流量将流过其尾端节点最接近节点X的TE隧道。在某些应用中，需要携带TE隧道尾端及其下游节点的本机邻接和TE隧道下一跳信息。前端节点可以基于用户定义的标准或事件有条件地将数据业务切换到TE隧道上；前端节点还可以将业务流分割到下一跳的任一类型；头部节点可以将具有两种不同类型的下一跳的路由安装到两个单独的肋骨中。在物理链路上运行的多播协议可能必须使用本机邻接下一跳而不是TE隧道下一跳来执行RPF检查。
The Shortest Path First algorithm will find equal-cost parallel paths to destinations. The enhancement described in this document does not change this. Traffic can be forwarded over one or more native IP paths, over one or more TE-tunnels, or over a combination of native IP paths and TE-tunnels.
最短路径优先算法将寻找到目的地的等成本并行路径。本文档中描述的增强功能不会改变这一点。流量可以通过一个或多个本机IP路径、一个或多个TE隧道或本机IP路径和TE隧道的组合进行转发。
A special situation occurs in the following topology:
以下拓扑中会出现特殊情况：
rtrA -- rtrB -- rtrC
| |
rtrD -- rtrE
rtrA -- rtrB -- rtrC
| |
rtrD -- rtrE
Assume all links have the same cost. Assume a TE-tunnel is set up from rtrA to rtrD. When the SPF calculation puts rtrC on the TENTative list, it will realize that rtrC is not directly connected, and thus it will use the first-hop information from the parent, which is rtrB. When the SPF calculation on rtrA moves rtrD from the TENTative list to the PATHS list, it realizes that rtrD is the tail-end of a TE-tunnel. Thus rtrA will install a route to rtrD via the TE-tunnel, and not via rtrB.
假设所有链接都具有相同的成本。假设从rtrA到rtrD设置了TE隧道。当SPF计算将rtrC放入暂定列表时，它将意识到rtrC不是直接连接的，因此它将使用来自父级的第一跳信息，即rtrB。当rtrA上的SPF计算将rtrD从暂定列表移动到路径列表时，它意识到rtrD是TE隧道的末端。因此，rtrA将通过TE隧道（而非rtrB）安装至rtrD的路线。
When rtrA puts rtrE on the TENTative list, it realizes that rtrE is not directly connected, and that rtrE is not the tail-end of a TE-tunnel. Therefore, rtrA will copy the first-hop information from the parents (rtrC and rtrD) to the first-hop information of rtrE. Traffic to rtrE will now load-balance over the native IP path via rtrA->rtrB->rtrC, and the TE-tunnel rtrA->rtrD.
当rtrA将rtrE放在暂定列表中时，它意识到rtrE不是直接连接的，并且rtrE不是TE隧道的末端。因此，rtrA将第一跳信息从父级（rtrC和rtrD）复制到rtrE的第一跳信息。到rtrE的流量现在将通过rtrA->rtrB->rtrC和TE隧道rtrA->rtrD在本机IP路径上实现负载平衡。
In the case where both parallel native IP paths and paths over TE-tunnels are available, implementations can allow the network administrator to force traffic to flow over only TE-tunnels (or only over native IP paths) or both to be used for load sharing.
在并行本机IP路径和TE隧道上的路径都可用的情况下，实现可以允许网络管理员强制流量仅通过TE隧道（或仅通过本机IP路径）或两者用于负载共享。
When an IGP route is installed in the routing table with a TE-tunnel as the next hop, an interesting question is what should be the cost or metric of this route? The most obvious answer is to assign a metric that is the same as the IGP metric of the native IP path as if the TE-tunnels did not exist. For example, rtrA can reach rtrC over a path with a cost of 20. X is an IP prefix advertised by rtrC. We install the route to X in rtrA's routing table with a cost of 20. When a TE-tunnel from rtrA to rtrC comes up, by default the route is still installed with metric of 20, only the next-hop information for X is changed.
当IGP路由安装在路由表中，TE隧道作为下一跳时，一个有趣的问题是该路由的成本或度量应该是什么？最明显的答案是分配一个与本机IP路径的IGP度量相同的度量，就好像TE隧道不存在一样。例如，rtrA可以通过一条成本为20美元的路径到达rtrC。X是rtrC公布的IP前缀。我们在rtrA的路由表中安装到X的路由，花费20美元。当从rtrA到rtrC的TE隧道出现时，默认情况下，路由仍然以20的度量安装，只有X的下一跳信息被更改。
While this scheme works well, in some networks it might be useful to change the cost of the path over a TE-tunnel, to make the route over the TE-tunnel less or more preferred than other routes.
虽然该方案工作良好，但在某些网络中，改变TE隧道上路径的成本，使TE隧道上的路由比其他路由更少或更优选可能是有用的。
For instance, when equal cost paths exist over a TE-tunnel and over a native IP path, by adjusting the cost of the path over the TE-tunnel, we can force traffic to prefer the path via the TE-tunnel, to prefer the native IP path, or to load-balance among them. Another example is when multiple TE-tunnels go to the same or different destinations. Adjusting TE-tunnel metrics can force the traffic to prefer some TE-tunnels over others regardless of underlining IGP cost to those destinations.
例如，当TE隧道和本机IP路径上存在相同成本的路径时，通过调整TE隧道上路径的成本，我们可以强制流量选择通过TE隧道的路径，选择本机IP路径，或者在它们之间进行负载平衡。另一个例子是当多个TE隧道到达相同或不同的目的地时。调整TE隧道度量可以迫使流量选择某些TE隧道而不是其他隧道，而不考虑这些目的地的IGP成本。
Setting a manual metric on a TE-tunnel does not impact the SPF algorithm itself. It only affects the comparison of the new route with existing routes in the routing table. Existing routes can be either IP routes to another router that advertises the same IP prefix, or it can be a path to the same router, but via a different outgoing interface or different TE-tunnel. All routes to IP prefixes advertised by the tail-end router will be affected by the TE-tunnel metric. Also, the metrics of paths to routers that are downstream of the tail-end router will be influenced by the manual TE-tunnel metric.
在TE隧道上设置手动度量不会影响SPF算法本身。它仅影响路由表中新路由与现有路由的比较。现有路由可以是到另一个播发相同IP前缀的路由器的IP路由，也可以是到同一路由器的路径，但通过不同的传出接口或不同的TE隧道。终端路由器播发的IP前缀的所有路由都将受到TE隧道度量的影响。此外，到位于后端路由器下游的路由器的路径的度量将受到手动TE隧道度量的影响。
This mechanism is loop free since the TE-tunnels are source-routed and the tunnel egress is a downstream node to reach the computed destinations. The end result of TE-tunnel metric adjustment is more control over traffic loadsharing. If there is only one way to reach a particular IP prefix through a single TE-tunnel, then no matter what metric is assigned, the traffic has only one path to go.
该机制是无环路的，因为TE隧道是源路由的，隧道出口是到达计算目的地的下游节点。TE隧道度量调整的最终结果是对交通负荷分担的更多控制。如果只有一种方法可以通过单个TE隧道到达特定IP前缀，那么无论分配了什么度量，通信量都只有一条路径。
The routing table described in this section can be viewed as the private RIB for the IGP. The metric is an important attribute to the routes in the routing table. A path or paths with lower metric will be selected over other paths for the same route in the routing table.
本节所述的路由表可被视为IGP的专用RIB。度量是路由表中路由的一个重要属性。对于路由表中的同一路由，将选择一个或多个具有较低度量的路径，而不是其他路径。
It is possible to represent the TE-tunnel metric in two different ways: an absolute (or fixed) metric or a relative metric, which is merely an adjustment of the dynamic IGP metric as calculated by the SPF computation. When using an absolute metric on a TE-tunnel, the cost of the IP routes in the routing table does not depend on the topology of the network. Note that this fixed metric is not only used to compute the cost of IP routes advertised by the router that is the tail-end of the TE-tunnel, but also for all the routes that are downstream of this tail-end router. For example, if we have TE-tunnels to two core routers in a remote POP, and one of them is assigned with an absolute metric of 1, then all the traffic going to that POP will traverse this low-metric TE-tunnel.
可以用两种不同的方式表示TE隧道度量：绝对（或固定）度量或相对度量，这仅仅是SPF计算所计算的动态IGP度量的调整。在TE隧道上使用绝对度量时，路由表中IP路由的成本不取决于网络拓扑。请注意，此固定度量不仅用于计算作为TE隧道末端的路由器播发的IP路由的成本，还用于计算此末端路由器下游的所有路由的成本。例如，如果在一个远程POP中有到两个核心路由器的TE隧道，并且其中一个被分配了1的绝对度量，那么所有到该POP的流量都将通过这个低度量TE隧道。
By setting a relative metric, the cost of IP routes in the routing table is based on the IGP metric as calculated by the SPF computation. This relative metric can be a positive or a negative number. Not configuring a metric on a TE-tunnel is a special case of the relative metric scheme. No metric is the same as a relative metric of 0. The relative metric is bounded by minimum and maximum allowed metric values while the positive metric disables the TE-tunnel in the SPF calculation.
通过设置相对度量，路由表中IP路由的成本基于SPF计算所计算的IGP度量。此相对度量可以是正数或负数。不在TE隧道上配置度量是相对度量方案的一种特殊情况。没有度量与0的相对度量相同。相对度量由允许的最小和最大度量值限定，而正度量在SPF计算中禁用TE隧道。
Assume the following topology. X, Y, and Z are IP prefixes advertised by rtrC, rtrD, and rtrE respectively. T1 is a TE-tunnel from rtrA to rtrC. Each link in the network has an IGP metric of 10.
假设以下拓扑。十、 Y和Z分别是rtrC、rtrD和rtrE播发的IP前缀。T1是从rtrA到rtrC的TE隧道。网络中的每个链路的IGP度量为10。
===== T1 =====>
rtrA -- rtrB -- rtrC -- rtrD -- rtrE
10 10 | 10 | 10 |
X Y Z
===== T1 =====>
rtrA -- rtrB -- rtrC -- rtrD -- rtrE
10 10 | 10 | 10 |
X Y Z
Without TE-tunnel T1, rtrA will install IP routes X, Y, and Z in the routing table with metrics 20, 30, and 40 respectively. When rtrA has brought up TE-tunnel T1 to rtrC, and if rtrA is configured with the relative metric of -5 on tunnel T1, then the routes X, Y, and Z will be installed in the routing table with metrics 15, 25, and 35. If an absolute metric of 5 is configured on tunnel T1, then rtrA will install routes X, Y, and Z all with metrics 5, 15, and 25 respectively.
在没有TE隧道T1的情况下，rtrA将在路由表中安装IP路由X、Y和Z，其度量值分别为20、30和40。当rtrA将TE隧道T1调到rtrC时，如果rtrA在隧道T1上配置了相对度量-5，那么路由X、Y和Z将安装在路由表中，度量为15、25和35。如果在隧道T1上配置了5的绝对度量，则rtrA将安装路由X、Y和Z，所有这些路由分别具有5、15和25的度量。
This document does not change the security aspects of IS-IS or OSPF. Security considerations specific to each protocol still apply. For more information see [5] and [2].
本文件不改变IS-IS或OSPF的安全方面。特定于每个协议的安全注意事项仍然适用。有关更多信息，请参见[5]和[2]。
The authors would like to thank Joel Halpern and Christian Hopps for their comments on this document.
作者感谢Joel Halpern和Christian Hopps对本文件的评论。
[1] ISO. Information Technology - Telecommunications and Information Exchange between Systems - Intermediate System to Intermediate System Routing Exchange Protocol for Use in Conjunction with the Protocol for Providing the Connectionless-Mode Network Service. ISO, 1990.
[1] ISO。信息技术.系统间远程通信和信息交换.与提供无连接模式网络服务协议一起使用的中间系统到中间系统路由交换协议。国际标准化组织，1990年。
[2] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[2] Moy，J.，“OSPF版本2”，RFC 23281998年4月。
[3] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
[3] Awduche，D.，Malcolm，J.，Agogbua，J.，O'Dell，M.，和J.McManus，“MPLS上的流量工程要求”，RFC 2702，1999年9月。
[4] 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.
[4] Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[5] Li, T. and R. Atkinson, "Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication", RFC 3567, July 2003.
[5] Li，T.和R.Atkinson，“中间系统到中间系统（IS-IS）密码认证”，RFC 3567，2003年7月。
[6] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. Xiao, "Overview and Principles of Internet Traffic Engineering", RFC 3272, May 2002.
[6] Awduche，D.，Chiu，A.，Elwalid，A.，Widjaja，I.，和X.Xiao，“互联网流量工程概述和原则”，RFC 3272，2002年5月。
Naiming Shen Redback Networks, Inc. 300 Holger Way San Jose, CA 95134
沈乃明红背网络有限公司，加利福尼亚州圣何塞霍尔格路300号，邮编95134
EMail: naiming@redback.com
EMail: naiming@redback.com
Henk Smit
亨克斯密特
EMail: hhwsmit@xs4all.nl
EMail: hhwsmit@xs4all.nl
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
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 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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 IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关IETF文件中权利的IETF程序信息，请参见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编辑功能的资金目前由互联网协会提供。