Network Working Group A. Malis
Request for Comments: 4720 Tellabs
Category: Standards Track D. Allan
Nortel Networks
N. Del Regno
MCI
November 2006
Network Working Group A. Malis
Request for Comments: 4720 Tellabs
Category: Standards Track D. Allan
Nortel Networks
N. Del Regno
MCI
November 2006
Pseudowire Emulation Edge-to-Edge (PWE3) Frame Check Sequence Retention
伪线仿真边到边（PWE3）帧检查序列保留
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 IETF Trust (2006).
版权所有（C）IETF信托基金（2006年）。
Abstract
摘要
This document defines a mechanism for preserving Frame Check Sequence (FCS) through Ethernet, Frame Relay, High-Level Data Link Control (HDLC), and PPP pseudowires.
本文件定义了通过以太网、帧中继、高级数据链路控制（HDLC）和PPP伪线保留帧检查序列（FCS）的机制。
Table of Contents
目录
1. Overview ........................................................1
2. Specification of Requirements ...................................3
3. Signaling FCS Retention with MPLS-Based Pseudowires .............3
4. Signaling FCS Retention with L2TPv3-Based Pseudowires ...........4
5. Security Considerations .........................................5
6. Applicability Statement .........................................5
7. IANA Considerations .............................................6
8. Acknowledgement .................................................6
9. Normative References ............................................6
1. Overview ........................................................1
2. Specification of Requirements ...................................3
3. Signaling FCS Retention with MPLS-Based Pseudowires .............3
4. Signaling FCS Retention with L2TPv3-Based Pseudowires ...........4
5. Security Considerations .........................................5
6. Applicability Statement .........................................5
7. IANA Considerations .............................................6
8. Acknowledgement .................................................6
9. Normative References ............................................6
The specifications for Ethernet, Frame Relay, HDLC, and PPP pseudowire encapsulation [1] [2] [3] [9] [10] [11] include a mode of use whereby frames are transparently delivered across the pseudowire without any header or other alterations by the pseudowire ingress or egress Provider Edge (PE). (Note that this mode is inherent for HDLC and PPP Pseudowires.)
以太网、帧中继、HDLC和PPP伪线封装[1][2][3][9][10][11]的规范包括一种使用模式，其中帧通过伪线透明地传送，而无需伪线入口或出口提供商边缘（PE）进行任何头部或其他更改。（请注意，此模式是HDLC和PPP伪线固有的。）
However, these specifications all specify that the original Frame Check Sequence (FCS) be removed at ingress and regenerated at egress, which means that the frames may be subject to unintentional alteration during their traversal of the pseudowire from the ingress to the egress PE. Thus, the pseudowire cannot absolutely be guaranteed to be "transparent" in nature.
然而，这些规范都规定在入口处移除原始帧检查序列（FCS）并在出口处重新生成，这意味着帧在从入口到出口PE的伪线穿越期间可能会受到无意的改变。因此，不能绝对保证伪线在本质上是“透明的”。
To be more precise, pseudowires, as currently defined, leave the payload vulnerable to unintended modification occurring while transiting the encapsulating network. Not only can a PW-aware device internally corrupt an encapsulated payload, but ANY LSR or router in the path can corrupt the encapsulated payload. In the event of such corruption, there is no way to detect the corruption through the path of the pseudowire. Further, because the FCS is calculated upon network egress, any corruption will pass transparently through ALL Layer 2 switches (Ethernet and Frame Relay) through which the packets travel. Only at the endpoint, assuming that the corrupted packet even reaches the correct endpoint, can the packet be discarded, and depending on the contents of the packet, the corruption may not ever be detected.
更准确地说，目前定义的伪线使有效负载在传输封装网络时容易受到意外修改的影响。PW感知设备不仅可以在内部损坏封装的有效负载，而且路径中的任何LSR或路由器都可以损坏封装的有效负载。在发生此类损坏的情况下，无法通过伪线路径检测损坏。此外，由于FCS是在网络出口时计算的，因此任何损坏都将透明地通过包所经过的所有第2层交换机（以太网和帧中继）。只有在端点处，假设损坏的数据包甚至到达正确的端点，数据包才能被丢弃，并且根据数据包的内容，可能永远不会检测到损坏。
Not only does the encapsulation technique leave the payload unprotected, it also subverts the error checking mechanisms already in place in SP and customer networks by calculating FCS on questionable data.
封装技术不仅使有效负载不受保护，还通过对可疑数据计算FCS，破坏SP和客户网络中已有的错误检查机制。
In a perfect network comprising perfect equipment, this is not an issue. However, as there is no such thing, it is an issue. SPs should have the option of saving overhead by yielding the ability to detect faults. Equally, SPs should have the option to sacrifice the overhead of carrying the original FCS end-to-end to ensure the ability to detect faults in the encapsulating network.
在由完美设备组成的完美网络中，这不是一个问题。然而，由于没有这样的事情，这是一个问题。SP应该可以通过提供故障检测能力来节省开销。同样，SP也可以选择牺牲承载原始FCS端到端的开销，以确保能够检测封装网络中的故障。
This document defines such a mechanism to allow the ingress PE to retain the original frame FCS on ingress to the network, and it relieves the egress PE of the task of regenerating the FCS.
本文件定义了这样一种机制，允许入口PE在进入网络时保留原始帧FCS，并免除出口PE重新生成FCS的任务。
This is an OPTIONAL mechanism for pseudowire implementations. For interoperability with systems that do not implement this document, the default behavior is that the FCS is removed at the ingress PE and regenerated at the egress PE, as specified in [1], [2], and [3].
这是伪线实现的可选机制。对于与未实施本文件的系统的互操作性，默认行为是在入口PE处移除FCS，并在出口PE处重新生成FCS，如[1]、[2]和[3]中所述。
This capability may be used only with Ethernet pseudowires that use "raw mode" [1], Frame Relay pseudowires that use "port mode" [2] [3], and HDLC and PPP pseudowires [3].
此功能只能用于使用“原始模式”[1]的以太网伪线、使用“端口模式”[2][3]的帧中继伪线以及HDLC和PPP伪线[3]。
Note that this mechanism is not intended to carry errored frames through the pseudowire; as usual, the FCS MUST be examined at the ingress PE, and errored frames MUST be discarded. The FCS MAY also be examined by the egress PE; if this is done, errored frames MUST be discarded. The egress PE MAY also wish to generate an alarm or count the number of errored frames.
注意，该机制不用于通过伪线传输错误帧；通常，必须在入口PE处检查FCS，并且必须丢弃错误帧。FCS也可由出口PE进行检查；如果这样做，则必须丢弃出错的帧。出口PE还可能希望生成警报或计算出错帧的数量。
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 [6].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[6]中所述进行解释。
When using the signaling procedures in [4], there is a Pseudowire Interface Parameter Sub-TLV type used to signal the desire to retain the FCS when advertising a VC label [5]:
当使用[4]中的信令程序时，有一个伪线接口参数Sub-TLV类型，用于在发布VC标签[5]时表示希望保留FCS：
Parameter Length Description 0x0A 4 FCS Retention Indicator
参数长度描述0x0A 4 FCS保留指示器
The presence of this parameter indicates that the egress PE requests that the ingress PE retain the FCS for the VC label being advertised. It does not obligate the ingress PE to retain the FCS; it is simply an indication that the ingress PE MAY retain the FCS. The sender MUST NOT retain the FCS if this parameter is not present in the VC FEC element.
此参数的存在表示出口PE请求入口PE保留正在播发的VC标签的FCS。它不要求入口PE保留FCS；这只是表明入口PE可能保留FCS。如果VC FEC元素中不存在此参数，则发送方不得保留FCS。
The parameter includes a 16-bit FCS length field, which indicates the length of the original FCS being retained. For Ethernet pseudowires, this length will always be set to 4. For HDLC, PPP, and Frame Relay pseudowires, this length will be set to either 2 or 4. Since the FCS length on these interfaces is a local setting, retaining the FCS only makes sense if the FCS length is identical on both ends of the pseudowire. Including the FCS length in this parameter allows the PEs to ensure that the FCS is only retained when it makes sense.
该参数包括一个16位FCS长度字段，该字段指示保留的原始FCS的长度。对于以太网伪线，此长度将始终设置为4。对于HDLC、PPP和帧中继伪线，此长度将设置为2或4。由于这些接口上的FCS长度是本地设置，因此只有在伪线两端的FCS长度相同时，保留FCS才有意义。将FCS长度包括在该参数中，允许PEs确保FCS仅在合理时保留。
Since unknown parameters are silently ignored [4], backward compatibility with systems that do not implement this document is provided by requiring that the FCS be retained ONLY if the FCS Retention Indicator with an identical setting for the FCS length has been included in the advertisements for both directions on a pseudowire.
由于未知参数被默默忽略[4]，因此，只有在伪导线上两个方向的公告中包含具有相同FCS长度设置的FCS保留指示器时，才要求保留FCS，以提供与未实施本文件的系统的向后兼容性。
If the ingress PE recognizes the FCS Retention Indicator parameter but does not wish to retain the FCS with the indicated length, it need only issue its own label mapping message for the opposite direction without including the FCS Retention Indicator. This will prevent FCS retention in either direction.
如果入口PE识别FCS保留指示器参数，但不希望保留具有指示长度的FCS，则只需针对相反方向发出自己的标签映射消息，而不包括FCS保留指示器。这将阻止FCS在两个方向的保留。
If PWE3 signaling [4] is not in use for a pseudowire, then whether the FCS is to be retained MUST be identically provisioned in both PEs at the pseudowire endpoints. If there is no provisioning support for this option, the default behavior is to remove the FCS.
如果PWE3信令[4]未用于伪线，则必须在伪线端点的两个PE中相同地设置是否保留FCS。如果此选项不支持资源调配，则默认行为是删除FCS。
This section uses the following terms as defined in [7]:
本节使用了[7]中定义的以下术语：
Incoming-Call-Request (ICRQ) Incoming-Call-Reply (ICRP) Incoming-Call-Connected (ICCN) Attribute Value Pair (AVP) L2TP Control Connection Endpoint (LCCE)
传入呼叫请求（ICRQ）传入呼叫应答（ICRP）传入呼叫连接（ICCN）属性值对（AVP）L2TP控制连接端点（LCCE）
When using the signaling procedures in [7], the FCS Retention AVP, Attribute Type 92, is used.
使用[7]中的信令程序时，使用FCS保留AVP属性类型92。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FCS Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FCS Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The FCS Length is a 2-octet unsigned integer.
FCS长度是一个2-octet无符号整数。
The presence of this AVP in an ICRQ or ICRP message indicates that an LCCE (PE) requests that its peer retain FCS for the L2TP session being established. If the receiving LCCE recognizes the AVP and complies with the FCS retention request, it MUST include an FCS Retention AVP as an acknowledgement in a corresponding ICRP or ICCN message. FCS Retention is always bidirectional; thus, FCS is only
ICRQ或ICRP消息中存在此AVP表示LCCE（PE）请求其对等方保留FCS以用于建立的L2TP会话。如果接收LCCE识别AVP并符合FCS保留请求，则必须在相应ICRP或ICCN报文中包含FCS保留AVP作为确认。FCS保留始终是双向的；因此，“未来作战系统”只是
retained if both LCCEs send an FCS Retention AVP during session establishment.
如果两个LCCE在会话建立期间发送FCS保留AVP，则保留。
The Attribute Value is a 16-bit FCS length field, which indicates the length of the original FCS being retained. For Ethernet pseudowires, this length will always be set to 4. For HDLC, PPP, and Frame Relay pseudowires, this length will be set to either 2 or 4. Since the FCS length on these interfaces is a local setting, retaining the FCS only makes sense if the FCS length is identical on both ends of the pseudowire. Including the FCS length in this AVP allows the PEs to ensure that the FCS is only retained when doing so makes sense.
属性值为16位FCS长度字段，表示保留的原始FCS的长度。对于以太网伪线，此长度将始终设置为4。对于HDLC、PPP和帧中继伪线，此长度将设置为2或4。由于这些接口上的FCS长度是本地设置，因此只有在伪线两端的FCS长度相同时，保留FCS才有意义。将FCS长度包括在本AVP中，允许PEs确保只有在合理的情况下才能保留FCS。
The Length of this AVP is 8. The M bit for this AVP MUST be set to 0 (zero). This AVP MAY be hidden (the H bit MAY be 1 or 0).
这个AVP的长度是8。此AVP的M位必须设置为0（零）。该AVP可能被隐藏（H位可能为1或0）。
This mechanism enhances the data integrity of transparent Ethernet, Frame Relay, and HDLC pseudowires, because the original FCS, as generated by the Customer Edge (CE), is included in the encapsulation. When the encapsulated payload passes FCS checking at the destination CE, it is clear that the payload was not altered during its transmission through the network (or at least to the accuracy of the original FCS; but that is demonstrably better than no FCS at all).
该机制增强了透明以太网、帧中继和HDLC伪线的数据完整性，因为封装中包含了由客户边缘（CE）生成的原始FCS。当封装的有效载荷通过目的地CE的FCS检查时，很明显，有效载荷在通过网络传输的过程中没有改变（或至少达到原始FCS的精度；但这显然比根本没有FCS要好）。
Of course, nothing comes for free; this requires the additional overhead of carrying the original FCS (in general, either two or four octets per payload packet).
当然，没有什么是免费的；这需要额外的承载原始FCS的开销（通常，每个有效负载数据包有两个或四个八位字节）。
This signaling is backward compatible and interoperable with systems that do not implement this document.
此信令向后兼容，可与未实现本文档的系统互操作。
In general, this document is intended to further extend the applicability of the services defined by [1], [2], and [3] to make them more suitable for use in deployments where data integrity is an issue (or at least is as much of an issue as in the original services that defined the FCS usage in the first place). There are some situations where this extension is not necessary, such as where the inner payloads have their own error-checking capabilities (such as TCP). But for inner payloads that do rely on the error-detecting capabilities of the link layer (such as SNA), this additional protection can be invaluable.
一般而言，本文件旨在进一步扩展[1]、[2]和[3]中定义的服务的适用性，使其更适合在数据完整性存在问题的部署中使用（或至少与最初定义FCS使用的原始服务中的问题相同）。有些情况下不需要此扩展，例如内部有效负载具有自己的错误检查功能（如TCP）。但对于确实依赖于链路层（如SNA）的错误检测能力的内部有效负载，这种额外的保护是非常宝贵的。
When pseudowires are being used to connect 802.1 bridges, this document allows pseudowires to comply with the requirement that all media interconnecting 802.1 bridges have (at least) 32-bit FCS protection.
当使用伪线连接802.1网桥时，本文件允许伪线符合所有互连802.1网桥的媒体都具有（至少）32位FCS保护的要求。
Note that this document is one possible alternative for a service provider to enhance the end-to-end data integrity of pseudowires. Other mechanisms may include the use of end-to-end IPsec between the PEs, or internal mechanisms in the P routers to ensure the integrity of packets as they are switched between ingress and egress interfaces. Service providers may wish to compare the relative strengths of each approach when planning their pseudowire deployments; however, an argument can be made that it may be wasteful for an SP to use an end-to-end integrity mechanism that is STRONGER than the FCS generated by the source CE and checked by the destination CE.
请注意，本文档是服务提供商增强伪线的端到端数据完整性的一种可能的替代方案。其他机制可包括在PEs之间使用端到端IPsec，或在P路由器中使用内部机制以确保分组在入口和出口接口之间切换时的完整性。服务提供商可能希望在规划其伪线部署时比较每种方法的相对优势；但是，可以提出这样的论点，即SP使用比源CE生成并由目标CE检查的FCS更强大的端到端完整性机制可能是浪费。
This document does not specify any new registries for IANA to maintain.
本文件未指定IANA需要维护的任何新注册。
Note that [5] allocates the FCS Retention Indicator interface parameter; therefore, no further IANA action is required.
注意[5]分配了FCS保留指标接口参数；因此，无需IANA采取进一步行动。
IANA assigned one value within the L2TP "Control Message Attribute Value Pairs" section as per [8]. The new AVP is 92 and is referred to in the IANA L2TP parameters registry as "FCS Retention".
IANA根据[8]在L2TP“控制消息属性值对”部分中分配了一个值。新的AVP为92，在IANA L2TP参数注册表中称为“FCS保留”。
The authors would like to thank Mark Townsley for the text in Section 4.
作者要感谢Mark Townsley在第4节中的文本。
[1] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006.
[1] Martini，L.，Rosen，E.，El Aawar，N.，和G.Heron，“通过MPLS网络传输以太网的封装方法”，RFC 4448，2006年4月。
[2] Martini, L., Ed., Kawa, C., Ed., and A. Malis, Ed., "Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks", RFC 4619, September 2006.
[2] Martini，L.，Ed.，Kawa，C.，Ed.，和A.Malis，Ed.，“多协议标签交换（MPLS）网络上帧中继传输的封装方法”，RFC 4619，2006年9月。
[3] Martini, L., Rosen, E., Heron, G., and A. Malis, "Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks", RFC 4618, September 2006.
[3] Martini，L.，Rosen，E.，Heron，G.，和A.Malis，“通过MPLS网络传输PPP/高级数据链路控制（HDLC）的封装方法”，RFC 4618，2006年9月。
[4] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[4] Martini，L.，Rosen，E.，El Aawar，N.，Smith，T.，和G.Heron，“使用标签分发协议（LDP）的伪线设置和维护”，RFC 4447，2006年4月。
[5] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[5] Martini，L.，“伪线边到边仿真（PWE3）的IANA分配”，BCP 116，RFC 4446，2006年4月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[6] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[7] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[7] Lau，J.，Townsley，M.，和I.Goyret，“第二层隧道协议-版本3（L2TPv3）”，RFC 39312005年3月。
[8] Townsley, W., "Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update", BCP 68, RFC 3438, December 2002.
[8] 汤斯利，W.，“第二层隧道协议（L2TP）互联网分配号码管理局（IANA）注意事项更新”，BCP 68，RFC 3438，2002年12月。
[9] Aggarwal, R., Townsley, M., and M. Dos Santos, "Transport of Ethernet Frames over Layer 2 Tunneling Protocol Version 3 (L2TPv3)", RFC 4719, November 2006.
[9] Aggarwal，R.，Townsley，M.和M.Dos Santos，“通过第2层隧道协议版本3（L2TPv3）传输以太网帧”，RFC 4719，2006年11月。
[10] Townsley, M., Wilkie, G., Booth, S., Bryant, S., and J. Lau, "Frame Relay over Layer 2 Tunneling Protocol Version 3 (L2TPv3)", RFC 4591, August 2006.
[10] Townsley，M.，Wilkie，G.，Booth，S.，Bryant，S.，和J.Lau，“第2层隧道协议第3版（L2TPv3）上的帧中继”，RFC 45912006年8月。
[11] Pignataro, C. and M. Townsley, "High-Level Data Link Control (HDLC) Frames over Layer 2 Tunneling Protocol, Version 3 (L2TPv3)", RFC 4349, February 2006.
[11] Pignataro，C.和M.Townsley，“第2层隧道协议上的高级数据链路控制（HDLC）帧，第3版（L2TPv3）”，RFC 4349，2006年2月。
Authors' Addresses
作者地址
Andrew G. Malis Tellabs 90 Rio Robles Dr. San Jose, CA 95134
安德鲁·G·马里斯·特拉伯斯90里约热内卢·罗伯斯博士，加利福尼亚州圣何塞，邮编95134
EMail: Andy.Malis@tellabs.com
EMail: Andy.Malis@tellabs.com
David Allan Nortel Networks 3500 Carling Ave. Ottawa, Ontario, CANADA
加拿大安大略省渥太华卡林大道3500号北电网络公司
EMail: dallan@nortel.com
EMail: dallan@nortel.com
Nick Del Regno MCI 400 International Parkway Richardson, TX 75081
德克萨斯州理查森市Nick Del Regno MCI 400国际公园路75081
EMail: nick.delregno@mci.com
EMail: nick.delregno@mci.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2006).
版权所有（C）IETF信托基金（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, 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编辑功能的资金目前由互联网协会提供。