Network Working Group P. Agarwal
Request for Comments: 3443 Brocade
Updates: 3032 B. Akyol
Category: Standards Track Cisco Systems
January 2003
Network Working Group P. Agarwal
Request for Comments: 3443 Brocade
Updates: 3032 B. Akyol
Category: Standards Track Cisco Systems
January 2003
Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks
多协议标签交换（MPLS）网络中的生存时间（TTL）处理
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 (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document describes Time To Live (TTL) processing in hierarchical Multi-Protocol Label Switching (MPLS) networks and is motivated by the need to formalize a TTL-transparent mode of operation for an MPLS label-switched path. It updates RFC 3032, "MPLS Label Stack Encoding". TTL processing in both Pipe and Uniform Model hierarchical tunnels are specified with examples for both "push" and "pop" cases. The document also complements RFC 3270, "MPLS Support of Differentiated Services" and ties together the terminology introduced in that document with TTL processing in hierarchical MPLS networks.
本文档描述了分层多协议标签交换（MPLS）网络中的生存时间（TTL）处理，其动机是为MPLS标签交换路径形式化TTL透明操作模式。它更新了RFC 3032，“MPLS标签堆栈编码”。管道和均匀模型分层隧道中的TTL处理均以“推送”和“弹出”两种情况为例进行了说明。本文档还补充了RFC 3270“MPLS对差异化服务的支持”，并将该文档中引入的术语与分层MPLS网络中的TTL处理联系在一起。
Conventions used in this document
本文件中使用的公约
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC-2119]中所述进行解释。
This document describes Time To Live (TTL) processing in hierarchical MPLS networks. We believe that this document adds details that have not been addressed in [MPLS-ARCH, MPLS-ENCAPS], and that the methods presented in this document complement [MPLS-DS].
本文档描述分层MPLS网络中的生存时间（TTL）处理。我们认为，本文件增加了[MPLS-ARCH，MPLS-ENCAPS]中未提及的细节，本文件中介绍的方法补充了[MPLS-DS]。
In particular, a new mode of operation (referred to as the Pipe Model) is introduced to support the practice of configuring MPLS LSPs such that packets transiting the LSP see the tunnel as a single hop regardless of the number of intermediary label switch routers (LSR). The Pipe Model for TTL is currently being used in multiple networks and is provided as an option configurable by the network operator by several vendors.
特别地，引入了一种新的操作模式（称为管道模型）来支持配置MPLS-LSP的实践，使得通过LSP的分组将隧道视为单跳，而不考虑中间标签交换路由器（LSR）的数量。TTL的管道模型目前正在多个网络中使用，并作为一个选项提供，可由多个供应商的网络运营商配置。
This document formalizes the TTL processing in MPLS networks and ties it with the terminology introduced in [MPLS-DS].
本文档将MPLS网络中的TTL处理形式化，并将其与[MPLS-DS]中引入的术语联系起来。
a) [MPLS-ENCAPS] only covers the Uniform Model and does NOT address the Pipe Model or the Short Pipe Model. This document addresses these two models and for completeness will also address the Uniform Model.
a) [MPLS-ENCAPS]仅涵盖统一模型，不涉及管道模型或短管模型。本文件涉及这两种模型，为完整起见，还将涉及统一模型。
b) [MPLS-ENCAPS] does not cover hierarchical LSPs. This document addresses this issue.
b) [MPLS-ENCAPS]不包括分层LSP。本文件涉及这一问题。
c) [MPLS-ENCAPS] does not define TTL processing in the presence of Penultimate Hop Popping (PHP). This document addresses this issue.
c) [MPLS-ENCAPS]不定义倒数第二跳弹出（PHP）情况下的TTL处理。本文件涉及这一问题。
As defined in [MPLS-ENCAPS], MPLS packets use a MPLS shim header that indicates the following information about a packet:
如[MPLS-ENCAPS]中所定义，MPLS数据包使用MPLS垫片报头，该报头指示关于数据包的以下信息：
a) MPLS Label (20 bits) b) TTL (8 bits) c) Bottom of stack (1 bit) d) Experimental bits (3 bits)
a) MPLS标签（20位）b）TTL（8位）c）栈底（1位）d）实验位（3位）
The experimental bits were later redefined in [MPLS-DS] to indicate the scheduling and shaping behavior that could be associated with an MPLS packet.
实验比特后来在[MPLS-DS]中重新定义，以指示可能与MPLS数据包相关联的调度和成形行为。
[MPLS-DS] also defined two models for MPLS tunnel operation: Pipe and Uniform Models. In the Pipe Model, a MPLS network acts like a circuit when MPLS packets traverse the network such that only the LSP ingress and egress points are visible to nodes that are outside the tunnel. A Short variation of the Pipe Model is also defined in [MPLS-DS] to differentiate between different egress forwarding and QoS treatments. On the other hand, the Uniform Model makes all the
[MPLS-DS]还为MPLS隧道操作定义了两种模型：管道模型和统一模型。在管道模型中，当MPLS数据包穿过网络时，MPLS网络就像一个电路，因此只有LSP入口和出口点对隧道外的节点可见。[MPLS-DS]中还定义了管道模型的一个简短变体，以区分不同的出口转发和QoS处理。另一方面，统一模型使所有
nodes that a LSP traverses visible to nodes outside the tunnel. We will extend the Pipe and Uniform Models to include TTL processing in the following sections. Furthermore, TTL processing, when performing PHP, is also described in this document. For a detailed description of Pipe and Uniform Models, please see [MPLS-DS].
LSP穿过的节点对隧道外的节点可见。我们将在以下章节中扩展管道和统一模型，以包括TTL处理。此外，本文档还描述了执行PHP时的TTL处理。有关管道和统一模型的详细说明，请参见[MPLS-DS]。
TTL processing in MPLS networks can be broken down into two logical blocks: (i) the incoming TTL determination to take into account any tunnel egress due to MPLS Pop operations; (ii) packet processing of (possibly) exposed packets and outgoing TTLs.
MPLS网络中的TTL处理可分为两个逻辑块：（i）传入TTL确定，以考虑由于MPLS Pop操作而产生的任何隧道出口；（ii）暴露包和传出TTL的包处理（可能）。
We also note here that signaling the LSP type (Pipe, Short Pipe or Uniform Model) is out of the scope of this document, and that is also not addressed in the current versions of the label distribution protocols, e.g. LDP [MPLS-LDP] and RSVP-TE [MPLS-RSVP]. Currently, the LSP type is configured by the network operator manually by means of either a command line or network management interface.
我们在此还注意到，LSP类型（管道、短管或统一模型）的信令不在本文件的范围内，目前版本的标签分发协议（如LDP[MPLS-LDP]和RSVP-TE[MPLS-RSVP]）也没有涉及到这一点。目前，LSP类型由网络运营商通过命令行或网络管理界面手动配置。
iTTL: The TTL value to use as the incoming TTL. No checks are performed on the iTTL.
iTTL：用作传入TTL的TTL值。未对iTTL执行任何检查。
oTTL: This is the TTL value used as the outgoing TTL value (see section 3.5 for exception). It is always (iTTL - 1) unless otherwise stated.
oTTL：这是用作输出TTL值的TTL值（例外情况见第3.5节）。除非另有说明，否则始终为（iTTL-1）。
oTTL Check: Check if oTTL is greater than 0. If the oTTL Check is false, then the packet is not forwarded. Note that the oTTL check is performed only if any outgoing TTL (either IP or MPLS) is set to oTTL (see section 3.5 for exception).
oTTL检查：检查oTTL是否大于0。如果oTTL检查为false，则不转发数据包。注意，只有当任何输出TTL（IP或MPLS）设置为oTTL时，才会执行oTTL检查（例外情况见第3.5节）。
This section describes the TTL processing for LSPs conforming to each of the 3 models (Uniform, Short Pipe and Pipe) in the presence/absence of PHP (where applicable).
本节描述了在存在/不存在PHP（如适用）的情况下，符合3种模型（统一、短管和管道）的LSP的TTL处理。
(consistent with [MPLS-ENCAPS]):
（与[MPLS-ENCAPS]一致）：
========== LSP =============================>
========== LSP =============================>
+--Swap--(n-2)-...-swap--(n-i)---+
/ (outer header) \
(n-1) (n-i)
/ \
>--(n)--Push...............(x).....................Pop--(n-i-1)->
(I) (inner header) (E or P)
+--Swap--(n-2)-...-swap--(n-i)---+
/ (outer header) \
(n-1) (n-i)
/ \
>--(n)--Push...............(x).....................Pop--(n-i-1)->
(I) (inner header) (E or P)
(n) represents the TTL value in the corresponding header (x) represents non-meaningful TTL information (I) represents the LSP ingress node (P) represents the LSP penultimate node (E) represents the LSP Egress node
(n) 表示对应报头中的TTL值（x）表示无意义的TTL信息（I）表示LSP入口节点（P）表示LSP倒数第二个节点（E）表示LSP出口节点
This picture shows TTL processing for a Uniform Model MPLS LSP. Note that the inner and outer TTLs of the packets are synchronized at tunnel ingress and egress.
此图显示了统一型号MPLS LSP的TTL处理。注意，包的内部和外部ttl在隧道入口和出口处同步。
========== LSP =============================>
========== LSP =============================>
+--Swap--(N-1)-...-swap--(N-i)-----+
/ (outer header) \
(N) (N-i)
/ \
>--(n)--Push...............(n-1).....................Pop--(n-2)->
(I) (inner header) (E)
+--Swap--(N-1)-...-swap--(N-i)-----+
/ (outer header) \
(N) (N-i)
/ \
>--(n)--Push...............(n-1).....................Pop--(n-2)->
(I) (inner header) (E)
(N) represents the TTL value (may have no relationship to n) (n) represents the tunneled TTL value in the encapsulated header (I) represents the LSP ingress node (E) represents the LSP Egress node
（N） 表示TTL值（可能与N没有关系）（N）表示封装报头中的隧道TTL值（I）表示LSP入口节点（E）表示LSP出口节点
The Short Pipe Model was introduced in [MPLS-DS]. In the Short Pipe Model, the forwarding treatment at the egress LSR is based on the tunneled packet, as opposed to the encapsulating packet.
[MPLS-DS]中引入了短管模型。在短管模型中，出口LSR处的转发处理基于隧道分组，而不是封装分组。
3.2.2. TTL Processing for Short Pipe Model with PHP:
3.2.2. 使用PHP对短管模型进行TTL处理：
========== LSP =====================================>
+-Swap-(N-1)-...-swap-(N-i)-+
/ (outer header) \
(N) (N-i)
/ \
>--(n)--Push.............(n-1)............Pop-(n-1)-Decr.-(n-2)->
(I) (inner header) (P) (E)
========== LSP =====================================>
+-Swap-(N-1)-...-swap-(N-i)-+
/ (outer header) \
(N) (N-i)
/ \
>--(n)--Push.............(n-1)............Pop-(n-1)-Decr.-(n-2)->
(I) (inner header) (P) (E)
(N) represents the TTL value (may have no relationship to n) (n) represents the tunneled TTL value in the encapsulated header (I) represents the LSP ingress node (P) represents the LSP penultimate node (E) represents the LSP egress node.
（N） 表示TTL值（可能与N没有关系）（N）表示封装报头中的隧道TTL值（I）表示LSP入口节点（P）表示LSP倒数第二个节点（E）表示LSP出口节点。
Since the label has already been popped by the LSP's penultimate node, the LSP egress node just decrements the header TTL.
由于标签已经被LSP的倒数第二个节点弹出，因此LSP出口节点只是减少报头TTL。
Also note that at the end of the Short Pipe Model LSP, the TTL of the tunneled packet has been decremented by two, with or without PHP.
还请注意，在短管模型LSP的末尾，隧道数据包的TTL已经减少了2，无论是否使用PHP。
3.3. TTL Processing for Pipe Model LSPs (without PHP only):
3.3. 管道模型LSP的TTL处理（仅不含PHP）：
========== LSP =============================>
========== LSP =============================>
+--Swap--(N-1)-...-swap--(N-i)-----+
/ (outer header) \
(N) (N-i)
/ \
>--(n)--Push...............(n-1)....................Pop--(n-2)->
(I) (inner header) (E)
+--Swap--(N-1)-...-swap--(N-i)-----+
/ (outer header) \
(N) (N-i)
/ \
>--(n)--Push...............(n-1)....................Pop--(n-2)->
(I) (inner header) (E)
(N) represents the TTL value (may have no relationship to n) (n) represents the tunneled TTL value in the encapsulated header (I) represents the LSP ingress node (E) represents the LSP Egress node
（N） 表示TTL值（可能与N没有关系）（N）表示封装报头中的隧道TTL值（I）表示LSP入口节点（E）表示LSP出口节点
From the TTL perspective, the treatment for a Pipe Model LSP is identical to the Short Pipe Model without PHP.
从TTL的角度来看，对管道模型LSP的处理与不使用PHP的短管模型相同。
If the incoming packet is an IP packet, then the iTTL is the TTL value of the incoming IP packet.
如果传入数据包是IP数据包，则iTTL是传入IP数据包的TTL值。
If the incoming packet is an MPLS packet and we are performing a Push/Swap/PHP, then the iTTL is the TTL of the topmost incoming label.
如果传入的数据包是MPLS数据包，并且我们正在执行Push/Swap/PHP，那么iTTL是最顶层传入标签的TTL。
If the incoming packet is an MPLS packet and we are performing a Pop (tunnel termination), the iTTL is based on the tunnel type (Pipe or Uniform) of the LSP that was popped. If the popped label belonged to a Pipe Model LSP, then the iTTL is the value of the TTL field of the header, exposed after the label was popped (note that for the purpose of this document, the exposed header may be either an IP header or an MPLS label). If the popped label belonged to a Uniform Model LSP, then the iTTL is equal to the TTL of the popped label. If multiple Pop operations are performed sequentially, then the procedure given above is repeated with one exception: the iTTL computed during the previous Pop is used as the TTL of subsequent labels being popped; i.e. the TTL contained in the subsequent label is essentially ignored and replaced with the iTTL computed during the previous pop.
如果传入数据包是MPLS数据包，并且我们正在执行Pop（隧道终止），则iTTL基于弹出的LSP的隧道类型（管道或统一）。如果弹出的标签属于管道型号LSP，则iTTL是标题的TTL字段的值，在标签弹出后公开（注意，在本文档中，公开的标题可以是IP标题或MPLS标签）。如果弹出标签属于统一型号LSP，则iTTL等于弹出标签的TTL。如果连续执行多个Pop操作，则重复上述过程，但有一个例外：在前一个Pop期间计算的iTTL用作后续弹出标签的TTL；i、 e.后续标签中包含的TTL基本上被忽略，并替换为前一pop期间计算的iTTL。
After the iTTL computation is performed, the oTTL check is performed. If the oTTL check succeeds, then the outgoing TTL of the (labeled/unlabeled) packet is calculated and packet headers are updated as defined below.
执行iTTL计算后，执行oTTL检查。如果oTTL检查成功，则计算（已标记/未标记）数据包的传出TTL，并按照以下定义更新数据包头。
If the packet was routed as an IP packet, the TTL value of the IP packet is set to oTTL (iTTL - 1). The TTL value(s) for any pushed label(s) is determined as described in section 3.6.
如果数据包作为IP数据包路由，则IP数据包的TTL值设置为oTTL（iTTL-1）。按第3.6节所述确定任何推送标签的TTL值。
For packets that are routed as MPLS, we have four cases:
对于作为MPLS路由的数据包，我们有四种情况：
1) Swap-only: The routed label is swapped with another label and the TTL field of the outgoing label is set to oTTL.
1) 仅交换：路由标签与另一个标签交换，并且传出标签的TTL字段设置为oTTL。
2) Swap followed by a Push: The swapped operation is performed as described in (1). The TTL value(s) of any pushed label(s) is determined as described in section 3.6.
2) 先交换后推：交换操作按（1）中所述执行。按第3.6节所述确定任何推送标签的TTL值。
3) Penultimate Hop Pop (PHP): The routed label is popped. The oTTL check should be performed irrespective of whether the oTTL is used to update the TTL field of the outgoing header. If the PHPed label belonged to a Short Pipe Model LSP, then the TTL field of the PHP exposed header is neither checked nor updated. If the
3) 倒数第二跳弹出（PHP）：弹出路由标签。无论oTTL是否用于更新传出标头的TTL字段，都应执行oTTL检查。如果PHPed标签属于短管模型LSP，则PHP公开头的TTL字段既不检查也不更新。如果
PHPed label was a Uniform Model LSP, then the TTL field of the PHP exposed header is set to the oTTL. The TTL value(s) of additional labels are determined as described in section 3.6
PHPed标签是一个统一模型LSP，那么PHP暴露头的TTL字段设置为oTTL。附加标签的TTL值按第3.6节所述确定
4) Pop: The pop operation happens before routing and hence it is not considered here.
4) Pop：Pop操作发生在路由之前，因此这里不考虑它。
For each pushed Uniform Model label, the TTL is copied from the label/IP-packet immediately underneath it.
对于每个推送的统一型号标签，TTL从其正下方的标签/IP数据包复制。
For each pushed Pipe Model or Short Pipe Model label, the TTL field is set to a value configured by the network operator. In most implementations, this value is set to 255 by default.
对于每个推送管道模型或短管模型标签，TTL字段设置为网络运营商配置的值。在大多数实现中，此值默认设置为255。
1) Although iTTL can be decremented by a value larger than 1 while it is being updated or oTTL is being determined, this feature should be only used for compensating for network nodes that are not capable of decrementing TTL values.
1) 虽然iTTL可以在更新或确定oTTL时减小大于1的值，但此功能应仅用于补偿无法减小TTL值的网络节点。
2) Whenever iTTL is decremented, the implementer must make sure that the value does not become negative.
2) 每当iTTL递减时，实现者必须确保该值不会变为负值。
3) In the Short Pipe Model with PHP enabled, the TTL of the tunneled packet is unchanged after the PHP operation.
3) 在启用PHP的短管模型中，隧道数据包的TTL在PHP操作后保持不变。
This Internet Document describes how the TTL field can be processed in an MPLS network. We clarified the various methods that are applied in the presence of hierarchical tunnels and completed the integration of Pipe and Uniform Models with TTL processing.
本Internet文档描述了如何在MPLS网络中处理TTL字段。我们阐明了在分层隧道中应用的各种方法，并完成了管道和统一模型与TTL处理的集成。
This document does not add any new security issues other than the ones defined in [MPLS-ENCAPS, MPLS-DS]. In particular, the document does not define a new protocol or expand an existing one and does not introduce security problems into the existing protocols. The authors believe that clarification of TTL handling in MPLS networks benefits service providers and their customers since troubleshooting is simplified.
除[MPLS-ENCAPS，MPLS-DS]中定义的安全问题外，本文档未添加任何新的安全问题。特别是，本文件没有定义新协议或扩展现有协议，也没有在现有协议中引入安全问题。作者认为，澄清MPLS网络中的TTL处理有利于服务提供商及其客户，因为故障排除简化了。
[RFC-2119] Bradner, S. "Key words for use in RFC's to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119]Bradner，S.“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[MPLS-ARCH] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[MPLS-ARCH]Rosen，E.，Viswanathan，A.和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[MPLS-ENCAPS] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[MPLS-ENCAPS]Rosen，E.，Tappan，D.，Fedorkow，G.，Rekhter，Y.，Farinaci，D.，Li，T.和A.Conta，“MPLS标签堆栈编码”，RFC 3032，2001年1月。
[MPLS-DS] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P. and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[MPLS-DS]Le Faucheur，F.，Wu，L.，Davie，B.，Davari，S.，Vaananen，P.，Krishnan，R.，Cheval，P.和J.Heinanen，“区分服务的多协议标签交换（MPLS）支持”，RFC 32702002年5月。
[MPLS-LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[MPLS-LDP]Andersson，L.，Doolan，P.，Feldman，N.，Fredette，A.和B.Thomas，“LDP规范”，RFC 3036，2001年1月。
[MPLS-RSVP] 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.
[MPLS-RSVP]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
The authors would like to thank the members of the MPLS working group for their feedback. We would especially like to thank Shahram Davari and Loa Andersson for their careful review of the document and their comments.
作者要感谢MPLS工作组成员的反馈。我们要特别感谢Shahram Davari和Loa Andersson仔细审查了该文件及其评论。
Puneet Agarwal Brocade Communications Systems, Inc. 1745 Technology Drive San Jose, CA 95110
Puneet Agarwal Brocade Communications Systems，Inc.位于加利福尼亚州圣何塞市技术大道1745号，邮编95110
EMail: puneet@acm.org
EMail: puneet@acm.org
Bora Akyol Cisco Systems 170 W. Tasman Drive San Jose, CA 95134
加利福尼亚州圣何塞塔斯曼大道西170号博拉阿克约尔思科系统公司，邮编95134
EMail: bora@cisco.com
EMail: bora@cisco.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。