Network Working Group J.-P. Vasseur, Ed.
Request for Comments: 4561 Z. Ali
Category: Standards Track S. Sivabalan
Cisco Systems, Inc.
June 2006
Network Working Group J.-P. Vasseur, Ed.
Request for Comments: 4561 Z. Ali
Category: Standards Track S. Sivabalan
Cisco Systems, Inc.
June 2006
Definition of a Record Route Object (RRO) Node-Id Sub-Object
记录路由对象（RRO）节点Id子对象的定义
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
In the context of MPLS TE Fast Reroute, the Merge Point (MP) address is required at the Point of Local Repair (PLR) in order to select a backup tunnel intersecting a fast reroutable Traffic Engineering Label Switched Path (TE LSP) on a downstream Label Switching Router (LSR). However, existing protocol mechanisms are not sufficient to find an MP address in multi-domain routing networks where a domain is defined as an Interior Gateway Protocol (IGP) area or an Autonomous System (AS). Hence, the current MPLS Fast Reroute mechanism cannot be used in order to protect inter-domain TE LSPs from a failure of an Area Border Router (ABR) or Autonomous System Border Router (ASBR). This document specifies the use of existing Record Route Object (RRO) IPv4 and IPv6 sub-objects (with a new flag defined) thus defining the node-id sub-object in order to solve this issue. The MPLS Fast Reroute mechanism mentioned in this document refers to the "Facility backup" MPLS TE Fast Reroute method.
在MPLS TE快速重路由的上下文中，在本地修复点（PLR）处需要合并点（MP）地址，以便选择与下游标签交换路由器（LSR）上的快速重路由流量工程标签交换路径（TE LSP）相交的备份隧道。然而，现有的协议机制不足以在多域路由网络中找到MP地址，其中域被定义为内部网关协议（IGP）区域或自治系统（as）。因此，当前的MPLS快速重路由机制不能用于保护域间TE lsp免受区域边界路由器（ABR）或自治系统边界路由器（ASBR）的故障。本文档指定使用现有的记录路由对象（RRO）IPv4和IPv6子对象（定义了新标志），从而定义节点id子对象以解决此问题。本文档中提到的MPLS快速重路由机制是指“设施备份”MPLS TE快速重路由方法。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................4
2.1. Conventions Used in This Document ..........................5
3. Signaling Node-Ids in RROs ......................................5
4. Finding Merge Point .............................................6
5. Security Considerations .........................................7
6. Acknowledgements ................................................7
7. References ......................................................7
7.1. Normative References .......................................7
7.2. Informative References .....................................8
1. Introduction ....................................................2
2. Terminology .....................................................4
2.1. Conventions Used in This Document ..........................5
3. Signaling Node-Ids in RROs ......................................5
4. Finding Merge Point .............................................6
5. Security Considerations .........................................7
6. Acknowledgements ................................................7
7. References ......................................................7
7.1. Normative References .......................................7
7.2. Informative References .....................................8
MPLS Fast Reroute (FRR) [FAST-REROUTE] is a fast recovery local protection technique used to protect Traffic Engineering LSPs from link/node/Shared Risk Link Group (SRLG) failure. One or more backup tunnels are pre-established to protect against the failure of a link/node/SRLG. In case of failure, every protected TE LSP traversing the failed resource is rerouted onto the appropriate backup tunnel.
MPLS快速重路由（FRR）[快速重路由]是一种快速恢复本地保护技术，用于保护流量工程LSP免受链路/节点/共享风险链路组（SRLG）故障的影响。预先建立一个或多个备份隧道，以防止链路/节点/SRLG出现故障。在发生故障的情况下，遍历故障资源的每个受保护的TE LSP将被重新路由到相应的备份隧道。
There are several requirements on the backup tunnel path that must be satisfied. First, the backup tunnel must not traverse the element that it protects. In addition, a primary tunnel and its associated backup tunnel should intersect at least at two points (nodes): Point of Local Repair (PLR) and Merge Point (MP). The former is the head-end LSR of the backup tunnel, and the latter is the tail-end LSR of the backup tunnel. The PLR is where FRR is triggered when link/node/SRLG failure happens.
备份隧道路径上有几个必须满足的要求。首先，备份隧道不能穿过它所保护的元素。此外，主隧道及其关联的备份隧道应至少相交于两个点（节点）：本地修复点（PLR）和合并点（MP）。前者是备份隧道的前端LSR，后者是备份隧道的后端LSR。PLR是发生链路/节点/SRLG故障时触发FRR的位置。
There are different methods for computing paths for backup tunnels at a given PLR. Specifically, a user can statically configure one or more backup tunnels at the PLR with an explicitly configured path, or the PLR can be configured to automatically compute a backup path or to send a path computation request to a PCE (see [PCE-ARCH]).
在给定的PLR上，有不同的方法来计算备用隧道的路径。具体地说，用户可以在PLR处使用显式配置的路径静态地配置一个或多个备份隧道，或者可以将PLR配置为自动计算备份路径或向PCE发送路径计算请求（参见[PCE-ARCH]）。
Consider the following scenario (Figure 1).
考虑下面的场景（图1）。
Assumptions:
假设：
- A multi-area network made of three areas: 0, 1, and 2.
- 由三个区域组成的多区域网络：0、1和2。
- A fast reroutable TE LSP T1 (TE LSP signaled with the "Local Protection Desired" bit set in the SESSION-ATTRIBUTE object or the FAST-REROUTE object) from R0 to R3.
- 从R0到R3的快速可重路由TE LSP T1（使用会话属性对象或快速重路由对象中设置的“所需本地保护”位发送TE LSP信号）。
- A backup tunnel B1 from R1 to R2, not traversing ABR1, and following the R1-ABR3-R2 path.
- 从R1到R2的备用隧道B1，不穿过ABR1，沿着R1-ABR3-R2路径。
- The PLR R1 reroutes any protected TE LSP traversing ABR1 onto the backup tunnel B1 in case of ABR1's failure.
- 如果ABR1发生故障，PLR R1将任何穿过ABR1的受保护TE LSP重新路由到备用隧道B1上。
<--- area 1 --><---area 0---><---area 2--->
R0-----R1-ABR1--R2------ABR2--------R3
\ /
\ /
ABR3
<--- area 1 --><---area 0---><---area 2--->
R0-----R1-ABR1--R2------ABR2--------R3
\ /
\ /
ABR3
Figure 1: Use of Fast Reroute to protect a TE LSP against an ABR failure with MPLS Traffic Engineering Fast Reroute
图1：使用MPLS流量工程快速重路由，使用快速重路由保护TE LSP免受ABR故障
When T1 is first signaled, the PLR R1 needs to dynamically select an appropriate backup tunnel intersecting T1 on a downstream LSR. However, existing protocol mechanisms are not sufficient to unambiguously find the MP address in a network with inter-domain TE LSP. This document addresses these limitations.
当T1第一次发出信号时，PLR R1需要动态选择一个与下游LSR上的T1相交的适当的备用隧道。然而，现有的协议机制不足以在具有域间TE LSP的网络中明确地找到MP地址。本文件阐述了这些限制。
R1 needs to select an existing backup tunnel with the following properties:
R1需要选择具有以下属性的现有备份隧道：
1. The backup tunnel intersects with the primary tunnel at the MP. For the sake of illustration, in Figure 1, R1 needs to determine that T1 and B1 intersect at the node R2.
1. 备用隧道在MP处与主隧道相交。为了便于说明，在图1中，R1需要确定T1和B1在节点R2处相交。
2. The backup tunnel satisfies the primary LSP's request with respect to the bandwidth protection request (i.e., bandwidth guaranteed for the primary tunnel during failure), and the type of protection (link or node failure), as specified in [FAST-REROUTE].
2. 备份隧道满足主LSP关于带宽保护请求（即故障期间主隧道保证的带宽）和保护类型（链路或节点故障）的请求，如[快速重路由]中所述。
One technique for the PLR to ensure that condition (1) is met consists of examining the Record Route Object (RRO) of the primary tunnel to see whether any of the addresses specified in the RRO correspond to the MP. That said, as per [RSVP-TE], the addresses specified in the RRO IPv4 or IPv6 sub-objects sent in Resv messages can be node-ids and/or interface addresses. Hence, in Figure 1, router R2 may specify interface addresses in the RROs for T1 and B1. Note that these interface addresses are different in this example.
PLR确保满足条件（1）的一种技术包括检查主隧道的记录路由对象（RRO），以查看在RRO中指定的任何地址是否对应于MP。也就是说，根据[RSVP-TE]，在Resv消息中发送的RRO IPv4或IPv6子对象中指定的地址可以是节点ID和/或接口地址。因此，在图1中，路由器R2可以在T1和B1的RRO中指定接口地址。请注意，在本例中，这些接口地址是不同的。
The problem of finding the MP using the interface addresses or node-ids can be easily solved in the case of a single IGP area. Specifically, in the case of a single IGP area, the PLR has the knowledge of all the interfaces attached to the tail-end of the backup tunnel. This information is available in PLR's IGP topology
在单个IGP区域的情况下，使用接口地址或节点ID查找MP的问题很容易解决。具体地说，在单个IGP区域的情况下，PLR知道连接到备用隧道尾部的所有接口。该信息可在PLR的IGP拓扑中获得
database. Thus, the PLR can unambiguously determine whether a backup tunnel intersecting a protected TE LSP on a downstream node exists and can also find the MP address regardless of how the addresses carried in the RRO IPv4 or IPv6 sub-objects are specified (i.e., whether using the interface addresses or the node-ids). However, such routing information is not available in the case of inter-domain environments. Hence, unambiguously making sure that condition (1) above is met in the case of inter-domain TE LSPs is not possible with existing mechanisms.
数据库因此，PLR可以明确地确定与下游节点上的受保护TE LSP相交的备份隧道是否存在，并且也可以找到MP地址，而不管如何指定在RRO IPv4或IPv6子对象中携带的地址（即，是否使用接口地址或节点id）。但是，这种路由信息在域间环境中不可用。因此，明确地确保在域间TE lsp的情况下满足上述条件（1）在现有机制中是不可能的。
In this document, we define extensions to and describe the use of Resource Reservation Protocol (RSVP) [RSVP, RSVP-TE] to solve the above-mentioned problem. Note that the requirement for the support of the fast recovery technique specified in [FAST-REROUTE] to inter-domain TE LSPs has been specified in [INTER-AREA-TE-REQS] and [INTER-AS-TE-REQS].
在本文中，我们定义了资源预留协议（RSVP）[RSVP，RSVP-TE]的扩展并描述了如何使用它来解决上述问题。注意，【快速重路由】中规定的支持域间TE LSP的快速恢复技术的要求已在【区域间TE-REQS】和【区域间TE-REQS】中规定。
Area Border Routers (ABRs): Border routers used to connect two Interior Gateway Protocol (IGP) areas (areas in OSPF or levels in IS-IS).
区域边界路由器（ABR）：用于连接两个内部网关协议（IGP）区域（OSPF中的区域或IS-IS中的级别）的边界路由器。
Autonomous System Border Router (ASBRs): Border routers used to connect to another AS of a different or the same Service Provider via one or more links inter-connecting between ASes.
自治系统边界路由器（ASBRs）：用于通过ASE之间的一条或多条链路连接到不同或相同服务提供商的另一个AS的边界路由器。
Backup Tunnel: The LSP that is used to back up one of the many LSPs in many-to-one backup.
备份隧道：用于备份多对一备份中多个LSP之一的LSP。
Inter-AS TE LSP: A TE LSP that crosses an AS boundary.
内部AS TE LSP：跨越AS边界的TE LSP。
Inter-area TE LSP: A TE LSP that crosses an IGP area.
区域间TE LSP：穿过IGP区域的TE LSP。
LSR: Label Switching Router.
标签交换路由器。
LSP: Label Switched Path.
标签交换路径。
Local Repair: Techniques used to repair TE LSPs quickly when a link, an SRLG, or a node along the TE LSP fails.
本地修复：用于在链路、SRLG或TE LSP沿线的节点发生故障时快速修复TE LSP的技术。
PCE: Path Computation Element. An entity (component, application, or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints.
PCE：路径计算元素。能够基于网络图计算网络路径或路由并应用计算约束的实体（组件、应用程序或网络节点）。
MP: Merge Point. The LSR where one or more backup tunnels rejoin the path of the protected LSP downstream of the potential failure.
MP：合并点。LSR，其中一个或多个备用隧道重新连接潜在故障下游受保护LSP的路径。
Protected LSP: An LSP is said to be protected at a given hop if it has one or multiple associated backup tunnels originating at that hop.
受保护的LSP：如果LSP具有一个或多个源自该跃点的关联备份隧道，则称其在给定跃点受到保护。
PLR: Point of Local Repair. The head-end of a backup tunnel.
PLR：局部维修点。备用隧道的前端。
Reroutable LSP: Any LSP for which the "Local Protection Desired" bit is set in the Flag field of the SESSION_ATTRIBUTE object of its Path messages.
可重新运行LSP：在其路径消息的会话_属性对象的标志字段中设置了“所需本地保护”位的任何LSP。
TE LSP: Traffic Engineering Label Switched Path.
TE LSP：流量工程标签交换路径。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
As mentioned above, the limitation that we need to address is the generality of the contents of the RRO IPv4 and IPv6 sub-objects, as defined in [RSVP-TE]. [RSVP-TE] defines the IPv4 and IPv6 RRO sub-objects. Moreover, two additional flags are defined in [FAST-REROUTE]: the "Local Protection Available" and "Local Protection in Use" bits.
如上所述，我们需要解决的限制是[RSVP-TE]中定义的RRO IPv4和IPv6子对象内容的一般性。[RSVP-TE]定义IPv4和IPv6 RRO子对象。此外，在[FAST-REROUTE]中定义了两个附加标志：“本地保护可用”和“本地保护正在使用”位。
In this document, we define the following new flag:
在本文档中，我们定义了以下新标志：
Node-id: 0x20
节点id:0x20
When set, this indicates that the address specified in the RRO's IPv4 or IPv6 sub-object is a node-id address, which refers to the "Router Address" as defined in [OSPF-TE], or "Traffic Engineering Router ID" as defined in [ISIS-TE]. A node MUST use the same address consistently. Once an address is used in the RRO's IPv4 or IPv6 sub-object, it SHOULD always be used for the lifetime of the TE LSP.
设置时，这表示RRO的IPv4或IPv6子对象中指定的地址是节点id地址，该地址指[OSPF-TE]中定义的“路由器地址”，或[ISIS-TE]中定义的“流量工程路由器id”。节点必须一致地使用相同的地址。一旦在RRO的IPv4或IPv6子对象中使用了地址，则应在TE LSP的生存期内始终使用该地址。
An IPv4 or IPv6 RRO sub-object with the node-id flag set is also called a node-id sub-object. The problem of finding an MP address in a network with inter-domain TE LSP is solved by inserting a node-id sub-object (an RRO "IPv4" and "IPv6" sub-object with the 0x20 flag set) in the RRO object carried in the RSVP Resv message.
设置了节点id标志的IPv4或IPv6 RRO子对象也称为节点id子对象。通过在RSVP Resv消息中携带的RRO对象中插入节点id子对象（设置了0x20标志的RRO“IPv4”和“IPv6”子对象），解决了在具有域间TE LSP的网络中查找MP地址的问题。
An implementation may decide to either:
实施可决定：
1) Add the node-id sub-object in the RRO carried in an RSVP Resv message and, when required, also add another IPv4/IPv6 sub-object to record interface address.
1) 在RSVP Resv消息中携带的RRO中添加节点id子对象，并在需要时添加另一个IPv4/IPv6子对象以记录接口地址。
Example: an inter-domain fast reroutable TE LSP would have the following two sub-objects in the RRO carried in Resv message: a node-id sub-object and a label sub-object. If recording the interface address is required, then an additional IPv4/IPv6 sub-object is added.
示例：域间快速可重新运行TE LSP在Resv消息中携带的RRO中将具有以下两个子对象：节点id子对象和标签子对象。如果需要记录接口地址，则会添加额外的IPv4/IPv6子对象。
or
或
2) Add an IPv4/IPv6 sub-object recording the interface address and, when required, add a node-id sub-object in the RRO.
2) 添加记录接口地址的IPv4/IPv6子对象，必要时，在RRO中添加节点id子对象。
Example: an inter-domain fast reroutable TE LSP would have the following three sub-objects in the RRO carried in Resv message: an IPv4/IPv6 sub-object recording interface address, a label sub-object, and a node-id sub-object.
示例：域间快速可重新运行TE LSP在Resv消息中携带的RRO中将具有以下三个子对象：IPv4/IPv6子对象记录接口地址、标签子对象和节点id子对象。
Note also that the node-id sub-object may have other applications than Fast Reroute backup tunnel selection. Moreover, it is RECOMMENDED that an LSR recording a node-id address in an IPv4/IPv6 RRO sub-object also set the node-id flag.
还请注意，节点id子对象可能具有快速重路由备份隧道选择以外的其他应用程序。此外，建议在IPv4/IPv6 RRO子对象中记录节点id地址的LSR也设置节点id标志。
Two cases should be considered:
应考虑两种情况：
- Case 1: If the backup tunnel destination is the MP's node-id, then a PLR can find the MP and suitable backup tunnel by simply comparing the backup tunnel's destination address with the node-id included in the RRO of the primary tunnel.
- 案例1：如果备份隧道目标是MP的节点id，则PLR可以通过简单地将备份隧道的目标地址与主隧道的RRO中包含的节点id进行比较来找到MP和合适的备份隧道。
- Case 2: If the backup tunnel terminates at an address different from the MP's node-id, then a node-id sub-object MUST also be included in the RRO of the backup tunnel. A PLR can find the MP and suitable backup tunnel by simply comparing the node-ids present in the RROs of both the primary and backup tunnels.
- 案例2：如果备份隧道终止于不同于MP节点id的地址，则备份隧道的RRO中还必须包含节点id子对象。PLR可以通过简单地比较主隧道和备份隧道的RRO中存在的节点ID来找到MP和合适的备份隧道。
It must be noted that although the technique described in this document for selecting an appropriate backup tunnel using the node-id sub-object applies to the case of Inter-area and Inter-AS, in the case of Inter-AS, the assumption is made that the MP's node-id (of the downstream domain) does not overlap with any LSR's node-id present in the PLR's AS.
必须注意的是，尽管本文档中描述的使用节点id子对象选择适当备份隧道的技术适用于Inter-area和Inter-AS的情况，但在Inter-AS的情况下，假设MP的节点id（下游域的）不与PLR AS中存在的任何LSR节点id重叠。
When both IPv4 node-id and IPv6 node-id sub-objects are present, a PLR may use any or both of them in finding the MP address.
当IPv4节点id和IPv6节点id子对象都存在时，PLR可以使用其中任何一个或两个来查找MP地址。
This document does not introduce new security issues. The security considerations pertaining to [RSVP] and [RSVP-TE] remain relevant.
本文档不会引入新的安全问题。与[RSVP]和[RSVP-TE]相关的安全注意事项仍然相关。
We would like to acknowledge input and helpful comments from Carol Iturralde, Anca Zamfir, Reshad Rahman, Rob Goguen, and Philip Matthews. A special thanks to Adrian Farrel for his thorough review of this document.
我们要感谢Carol Iturralde、Anca Zamfir、Reshad Rahman、Rob Goguen和Philip Matthews的意见和帮助。特别感谢阿德里安·法雷尔对本文件的全面审查。
[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月。
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RSVP]Braden，R.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——第1版功能规范”，RFC 22052997年9月。
[RSVP-TE] 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.
[RSVP-TE]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[FAST-REROUTE] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[FAST-REROUTE]Pan，P.，Swallow，G.，和A.Atlas，“LSP隧道RSVP-TE的快速重路由扩展”，RFC 40902005年5月。
[OSPF-TE] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[OSPF-TE]Katz，D.，Kompella，K.，和D.Yeung，“OSPF版本2的交通工程（TE）扩展”，RFC 3630，2003年9月。
[ISIS-TE] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.
[ISIS-TE]Smit，H.和T.Li，“交通工程（TE）的中间系统到中间系统（IS-IS）扩展”，RFC 37842004年6月。
[INTER-AREA-TE-REQS] Le Roux, J.-L., Vasseur, J.-P., and J. Boyle, "Requirements for Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005.
[INTER-AREA-TE-REQS]Le Roux，J.-L.，Vasseur，J.-P.，和J.Boyle，“区域间MPLS流量工程的要求”，RFC 4105，2005年6月。
[INTER-AS-TE-REQS] Zhang, R. and J.-P. Vasseur, "MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements", RFC 4216, November 2005.
[INTER-AS-TE-REQS]Zhang，R.和J.-P.Vasseur，“MPLS内部自治系统（AS）流量工程（TE）要求”，RFC 42162005年11月。
[PCE-ARCH] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE) Based Architecture", Work in Progress, April 2006.
[PCE-ARCH]Farrel，A.，Vasseur，J.-P.，和J.Ash，“基于路径计算元素（PCE）的体系结构”，正在进行的工作，2006年4月。
Authors' Addresses
作者地址
J.-P. Vasseur (Editor) Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough , MA - 01719 USA
J.-P.Vasseur（编辑）思科系统公司，美国马萨诸塞州伯斯堡马萨诸塞大道1414号，邮编01719
EMail: jpv@cisco.com
EMail: jpv@cisco.com
Zafar Ali Cisco Systems, Inc. 100 South Main St. #200 Ann Arbor, MI 48104 USA
Zafar Ali Cisco Systems，Inc.美国密歇根州安阿伯市南大街100号，邮编：48104
EMail: zali@cisco.com
EMail: zali@cisco.com
Siva Sivabalan Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario, K2K 3E8 Canada
Siva Sivabalan Cisco Systems，Inc.加拿大安大略省卡纳塔市创新大道2000号，K2K 3E8
EMail: msiva@cisco.com
EMail: msiva@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
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 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 provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。