Network Working Group A. Lindem
Request for Comments: 4167 Cisco Systems, Inc
Category: Informational October 2005
Network Working Group A. Lindem
Request for Comments: 4167 Cisco Systems, Inc
Category: Informational October 2005
Graceful OSPF Restart Implementation Report
OSPF重启实施报告
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 (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
Graceful OSPF Restart, as specified in RFC 3623, provides a mechanism whereby an OSPF router can stay on the forwarding path even as its OSPF software is restarted. This document provides an implementation report for this extension to the base OSPF protocol.
RFC 3623中规定的优雅OSPF重启提供了一种机制，使得OSPF路由器即使在其OSPF软件重启时也可以保持在转发路径上。本文档提供了基本OSPF协议扩展的实施报告。
Table of Contents
目录
1. Overview ........................................................2
2. Implementation Experience .......................................2
2.1. Implementation Differences .................................2
3. MIB Reference ...................................................3
4. Authentication Mechanisms .......................................3
5. List of Implementations .........................................3
6. Test Scenarios ..................................................3
7. Operational Experience ..........................................4
8. Security Considerations .........................................4
9. Normative References ............................................4
10. Informative References .........................................4
11. Acknowledgments ................................................5
1. Overview ........................................................2
2. Implementation Experience .......................................2
2.1. Implementation Differences .................................2
3. MIB Reference ...................................................3
4. Authentication Mechanisms .......................................3
5. List of Implementations .........................................3
6. Test Scenarios ..................................................3
7. Operational Experience ..........................................4
8. Security Considerations .........................................4
9. Normative References ............................................4
10. Informative References .........................................4
11. Acknowledgments ................................................5
Today, many Internet routers implement a separation of control and forwarding functions. Certain processors are dedicated to control and management tasks such as OSPF routing, while other processors perform the data forwarding tasks. This separation creates the possibility of maintaining a router's data forwarding capability while the router's control software is restarted/reloaded. For the OSPF protocol [OSPF], the protocol mechanisms necessary to accomplish this are described in Graceful OSPF Restart [GRACE].
今天，许多互联网路由器实现了控制和转发功能的分离。某些处理器专用于控制和管理任务，如OSPF路由，而其他处理器则执行数据转发任务。这种分离创造了在路由器控制软件重新启动/重新加载时保持路由器数据转发能力的可能性。对于OSPF协议[OSPF]，在优雅的OSPF重启[GRACE]中描述了实现这一点所需的协议机制。
This document satisfies the RFC 1264 [CRITERIA] requirement for a report on implementation experience for Graceful OSPF Restart. Section 2 of this document contains the results of an implementation survey. It also documents implementation differences between the vendors responding to the survey. Section 3 contains a MIB reference. Section 4 provide an authentication reference. Section 5 simply refers to the implementations listed in section 2. Section 6 includes a minimal set of test scenarios. Finally, section 7 includes a disclaimer with respect to operational experience.
本文件满足RFC 1264[标准]的要求，即关于OSPF正常重启实施经验的报告。本文件第2节包含实施调查的结果。它还记录了响应调查的供应商之间的实施差异。第3节包含一个MIB引用。第4节提供了一个认证参考。第5节仅提及第2节中列出的实现。第6节包括一组最小的测试场景。最后，第7节包含了一个关于操作经验的免责声明。
Eleven vendors have implemented graceful OSPF and have completed the implementation survey. These include Redback, Juniper, Motorola Computer Group (formerly Netplane Systems), Mahi Networks, Nexthop technologies, Force10 Networks, Procket, Alcatel, Laurel Networks, DCL (Data Connection Limited), and Ericsson. All have implemented restart from the perspective of both a restarting and helper router. All but one vendor implemented both planned and unplanned restart. All implementations are original. Seven successfully tested interoperability with Juniper. Juniper successfully tested interoperability with Force10 Networks. One vendor tested with John Moy's GNU Public License implementation [OSPFD]. Two vendors had not tested interoperability at the time of the survey.
11家供应商已经实施了优雅的OSPF，并完成了实施调查。这些公司包括Redback、Juniper、摩托罗拉计算机集团（前身为Netplane Systems）、Mahi Networks、Nexthop technologies、Force10 Networks、Procket、Alcatel、Laurel Networks、DCL（数据连接有限公司）和爱立信。所有这些都从重启和帮助路由器的角度实现了重启。除一家供应商外，所有供应商均实施了计划内和计划外重启。所有的实现都是原创的。七个成功地测试了与Juniper的互操作性。Juniper成功测试了与Force10网络的互操作性。一家供应商使用John Moy的GNU公共许可证实现[OSPFD]进行了测试。在调查时，两个供应商尚未测试互操作性。
The first difference was whether strict LSA checking was implemented and, if so, whether it was configurable. In the context of graceful OSPF restart, strict LSA checking indicates whether a changed LSA will result in the termination of graceful restart by a helping router. Four vendors made it configurable (three defaulted it to enabled and one to disabled), another made it a compile option (shipping with strict LSA checking disabled), another didn't implement it at all, and five implemented strict LSA checking with no configuration option to disable it.
第一个区别是是否实施了严格的LSA检查，如果是，是否可配置。在正常OSPF重启的上下文中，严格的LSA检查指示更改的LSA是否会导致路由器终止正常重启。四家供应商将其设置为可配置（三家默认为已启用，一家为已禁用），另一家供应商将其设置为编译选项（出厂时禁用了严格的LSA检查），另一家供应商根本没有实现它，五家供应商实现了严格的LSA检查，但没有禁用它的配置选项。
The second was whether a received grace LSA would be taken to apply only to the adjacency on which it was received or to all adjacencies with the restarting router. This is a rather subtle difference since it only applies to helping and restarting routers with more than one full adjacency at the time of restart. Eight vendors implemented the option of the received grace LSA only applying to the adjacency on which it was received. Three vendors applied the grace LSA to all adjacencies with the grace LSA originator (i.e., the restarting router).
第二个问题是，接收到的宽限LSA是否只应用于接收到它的邻接，还是应用于重启路由器的所有邻接。这是一个相当微妙的区别，因为它只适用于在重启时帮助和重启具有多个完全邻接的路由器。八家供应商实施了接收到的宽限LSA选项，该选项仅适用于接收到它的相邻区域。三家供应商将grace LSA应用于与grace LSA发起人（即重新启动的路由器）的所有邻接。
The final difference was in whether additional extensions were implemented to accommodate other features such as protocol redistribution or interaction with MPLS VPNs [VPN]. Five vendors implemented extensions and six did not. It should be noted that such extensions are beyond the scope of Graceful OSPF Restart [GRACE].
最后一个区别在于是否实现了附加扩展以适应其他功能，如协议重新分发或与MPLS VPN[VPN]的交互。五家供应商实现了扩展，六家没有。应该注意的是，这种扩展超出了优雅的OSPF重启[GRACE]的范围。
MIB objects for the Graceful OSPF Restart have been added to the OSPF Version 2 Management Information Base [OSPFMIB]. Additions include:
OSPF重新启动的MIB对象已添加到OSPF版本2管理信息库[OSPFMIB]。新增内容包括：
- Objects ospfRestartSupport, ospfRestartInterval, ospfRestartAge, ospfRestartExitReason, and ospfRestartStrictLsaChecking to ospfGeneralGroup.
- 对象ospfRestartSupport、ospfRestartInterval、ospfRestartAge、ospfRestartExitReason和OSPFrestartStrictLSacheck到ospfGeneralGroup。
- Objects ospfNbrRestartHelperStatus, ospfNbrRestartHelperAge, and ospfNbrRestartHelperExitReason to ospfNbrEntry.
- 对象ospfNbrRestartHelperStatus、ospfNbrRestartHelperAge和OSPFNBRRESTARTHELPEREXIT原因到OSPFNBRETRY。
- Objects ospfVirtNbrRestartHelperStatus, ospfVirtNbrRestartHelperAge, and ospfVirtNbrRestartHelperExitReason to ospfVirtNbrEntry.
- 对象ospfVirtNbrRestartHelperStatus、ospfVirtNbrRestartHelperAge和OSPFVIRTNBRRESTARTHELPEREXIT原因到ospfVirtNbrEntry。
The authentication mechanisms are the same as those implemented by the base OSPF protocol [OSPF].
认证机制与基本OSPF协议[OSPF]实现的认证机制相同。
Refer to section 2.
参见第2节。
A router implementing graceful restart should test, at a minimum, the following scenarios as both a restarting and helping router. For all scenarios, monitoring data plane traffic may be used to ensure that the restart is non-disruptive:
实现优雅重启的路由器应至少测试以下场景，作为重启和帮助路由器。对于所有情况，可使用监控数据平面流量来确保重启无中断：
1. Operation over a broadcast network.
1. 通过广播网络进行的操作。
2. Operation over a P2P network.
2. 在P2P网络上的操作。
3. Operation over a virtual link.
3. 虚拟链接上的操作。
4. Operation using OSPF MD5 authentication.
4. 使用OSPF MD5身份验证的操作。
5. Early graceful restart termination when an LSA inconsistency is detected.
5. 当检测到LSA不一致时，提前终止正常重启。
6. Early graceful restart termination when a flooded LSA changes (if implemented).
6. 当泛洪LSA发生更改时（如果已实施），提前终止正常重启。
Since OSPF graceful restart is configurable, it is difficult to gage operational experience at this juncture. However, multiple service providers have tested and evaluated it.
由于OSPF优雅重启是可配置的，因此很难在此时评估操作经验。然而，多家服务提供商已经对其进行了测试和评估。
This document does not discuss implementation and interoperability aspects of the security mechanisms in great detail, as no new security mechanisms are introduced with Graceful OSPF Restart. Security considerations for the OSPF protocol are included in RFC 2328 [OSPF]. Security considerations for Graceful OSPF Restart are included in [GRACE].
本文档没有详细讨论安全机制的实现和互操作性方面，因为OSPF重启时没有引入新的安全机制。RFC 2328[OSPF]中包含了OSPF协议的安全注意事项。[GRACE]中包含了正常OSPF重启的安全注意事项。
[OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[OSPF]Moy，J.，“OSPF版本2”，STD 54，RFC 23281998年4月。
[GRACE] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF Restart", RFC 3623, November 2003.
[GRACE]Moy，J.，Pillay Esnault，P.，和A.Lindem，“优雅的OSPF重启”，RFC 36232003年11月。
[CRITERIA] Hinden, R., "Internet Engineering Task Force Internet Routing Protocol Standardization Criteria", RFC 1264, October 1991.
[标准]Hinden，R.，“互联网工程任务组互联网路由协议标准化标准”，RFC 1264，1991年10月。
[VPN] Rosen, E. and Y Rekhter, "BGP/MPLS IP VPNs", Work in Progress, September 2003.
[VPN]Rosen，E.和Y Rekhter，“BGP/MPLS IP VPN”，正在进行的工作，2003年9月。
[OSPFD] Moy, J., "OSPF Complete Implementation", Addison-Wesley, 1991, ISBN 0-201-30966-1
[OSPFD]莫伊，J.，“OSPF的全面实施”，艾迪生·韦斯利，1991年，ISBN 0-201-30966-1
[OSPFMIB] Joyal, D., et al, "OSPF Version 2 Management Information Base", Work in Progress, December 2003.
[OSPFMIB]Joyal，D.等人，“OSPF版本2管理信息库”，正在进行的工作，2003年12月。
The author wishes to acknowledge the individuals/vendors who have completed the implementation survey.
作者希望感谢完成实施调查的个人/供应商。
- Anand Oswal (Redback Networks) - Padma Pillay-Esnault (Juniper Networks) - Vishwas Manral (Motorola Computer Group, formerly Netplane System). - Sriganesh Kini (Mahi Networks) - Jason Chen (Force10 Networks) - Daniel Gryniewicz (NextHop Technologies) - Hasmit Grover (Procket Networks) - Pramoda Nallur (Alcatel) - Ardas Cilingiroglu (Laurel Networks) - Philip Crocker (Data Connection Limited) - Le-Vinh Hoang (Ericsson)
- Anand Oswal（Redback Networks）——Padma Pillay Esnault（Juniper Networks）——Vishwas Manral（摩托罗拉计算机集团，前身为Netplane系统）斯里格内什·基尼（玛希网络）-詹森·陈（Force10网络）-丹尼尔·格里尼维奇（NextHop Technologies）-哈斯米特·格罗弗（Procket网络）-普拉莫达·纳鲁尔（阿尔卡特）-阿尔达斯·西林吉罗格鲁（劳雷尔网络）-菲利普·克罗克（数据连接有限公司）-勒文豪（爱立信）
Author's Address
作者地址
Acee Lindem Cisco Systems, Inc 7025 Kit Creek Road Research Triangle Park, NC 27709 USA
美国北卡罗来纳州基特克里克路三角研究园7025号Acee Lindem思科系统有限公司，邮编：27709
EMail: acee@cisco.com
EMail: acee@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
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 currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。