Network Working Group S. Rao
Request for Comments: 3883 UTA
Updates: 1793 A. Zinin
Category: Standards Track Alcatel
A. Roy
Cisco Systems
October 2004
Network Working Group S. Rao
Request for Comments: 3883 UTA
Updates: 1793 A. Zinin
Category: Standards Track Alcatel
A. Roy
Cisco Systems
October 2004
Detecting Inactive Neighbors over OSPF Demand Circuits (DC)
检测OSPF需求电路（DC）上的非活动邻居
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 (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
OSPF is a link-state intra-domain routing protocol used in IP networks. OSPF behavior over demand circuits (DC) is optimized in RFC 1793 to minimize the amount of overhead traffic. A part of the OSPF demand circuit extensions is the Hello suppression mechanism. This technique allows a demand circuit to go down when no interesting traffic is going through the link. However, it also introduces a problem, where it becomes impossible to detect an OSPF-inactive neighbor over such a link. This memo introduces a new mechanism called "neighbor probing" to address the above problem.
OSPF是IP网络中使用的链路状态域内路由协议。在RFC1793中优化了OSPF行为过需求电路（DC），以最小化开销通信量。OSPF需求电路扩展的一部分是Hello抑制机制。当没有感兴趣的流量通过链路时，这种技术允许需求电路下降。然而，它也带来了一个问题，即无法通过这样的链路检测到OSPF非活动邻居。该备忘录引入了一种称为“邻居探测”的新机制来解决上述问题。
In some situations, when operating over demand circuits, the remote neighbor may be unable to run OSPF [RFC2328], and, as a possible result, unable to route application traffic. Possible scenarios include:
在某些情况下，当操作超需电路时，远程邻居可能无法运行OSPF[RFC2328]，并且可能导致无法路由应用程序流量。可能的情况包括：
o The OSPF process might have died on the remote neighbor.
o OSPF进程可能已在远程邻居上终止。
o Oversubscription (Section 7 of [RFC1793]) may cause a continuous drop of application data at the link level.
o 超额认购（RFC1793第7节）可能会导致链接级别的应用程序数据持续下降。
The problem here is that the local router cannot identify problems such as this, since the Hello exchange is suppressed on demand circuits. If the topology of the network is such that other routers cannot communicate their knowledge about the remote neighbor via flooding, the local router and all the routers behind it will never know about the problem, so application traffic may continue being forwarded to the OSPF-incapable router.
这里的问题是，本地路由器无法识别这样的问题，因为Hello交换被按需电路抑制。如果网络的拓扑结构使得其他路由器无法通过泛洪传输其关于远程邻居的知识，则本地路由器及其后面的所有路由器将永远不会知道该问题，因此应用程序流量可能会继续转发到OSPF路由器。
This memo describes a backward-compatible neighbor probing mechanism based on the details of the standard flooding procedure followed by OSPF routers.
本备忘录根据OSPF路由器遵循的标准泛洪过程的细节，描述了一种向后兼容的邻居探测机制。
The solution this document proposes uses the link-state update packets to detect whether the OSPF process is operational on the remote neighbor. We call this process "Neighbor probing". The idea behind this technique is to allow either of the two neighbors connected over a demand circuit to test the remote neighbor at any time (see Section 2.1).
本文提出的解决方案使用链路状态更新数据包来检测远程邻居上的OSPF进程是否可操作。我们称这个过程为“邻居探测”。这种技术背后的想法是允许通过需求电路连接的两个邻居中的任何一个在任何时候测试远程邻居（见第2.1节）。
The routers across the demand circuit can be connected by either a point-to-point link, a virtual link, or a point-to-multipoint interface. The case of routers connected by broadcast networks or Non-Broadcast Multi-Access (NBMA) links is not considered, since Hello suppression is not used in these cases (Section 3.2 [RFC1793]).
需求电路中的路由器可以通过点对点链路、虚拟链路或点对多点接口进行连接。不考虑通过广播网络或非广播多址（NBMA）链路连接的路由器的情况，因为在这些情况下不使用Hello抑制（第3.2节[RFC1793]）。
The neighbor probing mechanism is used as follows. After a router has synchronized the Link State Database (LSDB) with its neighbor over the demand circuit, the demand circuit may be torn down if there is no more application traffic. When application traffic starts going over the link, the link is brought up. If ospfIfDemandNbrProbe is enabled, the routers SHOULD probe each other. While the link is up, the routers may also periodically probe each other every ospfIfDemandNbrProbeInterval. Neighbor probing should not be considered as interesting traffic and should not cause the demand circuit to remain up (relevant details of implementation are outside of the scope of this document).
邻居探测机制使用如下。路由器通过请求电路将链路状态数据库（LSDB）与其邻居同步后，如果没有更多的应用程序流量，请求电路可能会被拆除。当应用程序流量开始通过该链接时，该链接被启动。如果启用了ospfIfDemandNbrProbe，则路由器应相互探测。当链路接通时，路由器也可以每隔一个OSPFIDEMENDNBRPROBEINTERVAL周期性地相互探测。邻居探测不应被视为有趣的通信量，也不应导致需求电路保持正常（实施的相关细节不在本文件范围内）。
The case when one or more of the router's links are oversubscribed (see section 7 of [RFC1793]) should be considered by the implementations. In such a situation, even if the link status is up and application data is being sent on the link, only a limited number of neighbors are really reachable. To make sure temporarily unreachable neighbors are not mistakenly declared down, Neighbor probing should be restricted to those neighbors that are actually
当一个或多个路由器链路被超额订阅时（参见[RFC1793]第7节），实施应考虑这种情况。在这种情况下，即使链路状态为up并且应用程序数据正在链路上发送，也只有有限数量的邻居是真正可访问的。为了确保暂时无法访问的邻居不会被错误地声明为关闭，邻居探测应该仅限于那些实际无法访问的邻居
reachable (i.e., there is a circuit established with the neighbor at the moment the probing procedure needs to be initiated). This check itself is also considered an implementation detail.
可到达（即，在需要启动探测程序时，与邻居建立了电路）。该检查本身也被视为一个实现细节。
The neighbor probing method described in this section is completely compatible with standard OSPF implementations, because it is based on standard behavior that must be followed by OSPF implementations in order to keep their LSDBs synchronized.
本节中描述的邻居探测方法与标准OSPF实现完全兼容，因为它基于OSPF实现必须遵循的标准行为，以保持其LSDB的同步。
When a router needs to verify the OSPF capability of a neighbor reachable through a demand circuit, it should flood to the neighbor any LSA in its LSDB that would normally be sent to the neighbor during the initial LSDB synchronization process (in most cases, such an LSA must have already been flooded to the neighbor by the time the probing procedure starts). For example, the router may flood its own router-LSA (without originating a new version), or the neighbor's own router-LSA. If the neighbor is still alive and OSPF-capable, it replies with a link state acknowledgement or a link state update (an implied acknowledgement), and the LSA is removed from the neighbor's retransmission list. The implementations should limit the number of times an LSA can be retransmitted to ospfIfDemandNbrProbeRetxLimit, when used for neighbor probing. If no acknowledgement (explicit or implicit) is received for a predefined period of time, the probing router should treat this as evidence of the neighbor's unreachability (proving wrong the assumption of reachability used in [RFC1793]) and should bring the adjacency down.
当路由器需要验证可通过请求电路到达的邻居的OSPF能力时，它应该将其LSDB中通常在初始LSDB同步过程中发送给邻居的任何LSA洪泛到邻居（在大多数情况下，在探测过程开始时，这样的LSA必须已经被淹没到邻居）。例如，路由器可能会淹没它自己的路由器LSA（而不产生新版本），或邻居自己的路由器LSA。如果邻居仍处于活动状态且支持OSPF，则它会以链路状态确认或链路状态更新（隐含确认）进行回复，并且LSA将从邻居的重新传输列表中删除。当用于邻居探测时，实现应限制LSA可以重新传输到OSPFIDEMANDNBRPROBERETXLIMIT的次数。如果没有确认（显式或隐式）如果在预定义的时间段内收到，探测路由器应将其视为邻居不可访问性的证据（证明[RFC1793]中使用的可访问性假设是错误的），并应降低相邻性。
Note that when the neighbor being probed receives such a link state update packet, the received LSA has the same contents as the LSA in the neighbor's LSDB, and hence should normally not cause any additional flooding. However, since LSA refreshes are not flooded over demand circuits, the received LSA may have a higher Sequence Number. This will result in the first probe LSA being flooded further by the neighbor. Note that if the current version of the probe LSA has already been flooded to the neighbor, it will not be propagated any further by the neighbor. Also note that in any case, subsequent (non-first) probe LSAs will not cause further flooding until the LSA's sequence number is incremented.
注意，当被探测的邻居接收到这样的链路状态更新分组时，接收到的LSA与邻居的LSDB中的LSA具有相同的内容，因此通常不应引起任何额外的泛洪。然而，由于LSA刷新不会淹没在按需电路上，因此接收到的LSA可能具有更高的序列号。这将导致第一个探测器LSA被邻居进一步淹没。请注意，如果探测器LSA的当前版本已被淹没到邻居，则邻居不会进一步传播它。还要注意，在任何情况下，后续（非第一个）探测LSA都不会导致进一步的泛洪，直到LSA的序列号增加。
Again, the implementation should insure (through internal mechanisms) that OSPF link state update packets sent over the demand circuit for the purpose of neighbor probing do not prevent that circuit from being torn down.
同样，实现应确保（通过内部机制）为邻居探测目的通过请求电路发送的OSPF链路状态更新包不会阻止该电路被拆除。
Virtual links can be treated analogously to point-to-point links, so the techniques described in this memo are applicable to virtual links as well. The case of point-to-multipoint interface running as a demand circuit (section 3.5 [RFC1793]) can be treated as individual point-to-point links, for which the solution has been described in section 2.
虚拟链接可以类似于点对点链接，因此本备忘录中描述的技术也适用于虚拟链接。点对多点接口作为需求电路运行的情况（第3.5节[RFC1793]）可被视为单独的点对点链路，解决方案已在第2节中描述。
All mechanisms described in this document are backward-compatible with standard OSPF implementations.
本文档中描述的所有机制都与标准OSPF实现向后兼容。
In addition to the lost functionality mentioned in Section 6 of [RFC1793], there is additional overhead in terms of the amount of data (link state updates and acknowledgements) being transmitted due to neighbor probing whenever the link is up, thereby increasing the overall cost.
除了[RFC1793]第6节中提到的功能丢失外，由于链路启动时的邻居探测，在传输的数据量（链路状态更新和确认）方面还有额外的开销，从而增加了总体成本。
The original idea of limiting the number of LSA retransmissions on demand circuits (used as part of the solution described in this document) and its implementation belong to Padma Pillay-Esnault and Derek Yeung.
限制LSA按需重传电路数量（用作本文件所述解决方案的一部分）的原始想法及其实施属于Padma Pillay Esnault和Derek Yang。
The authors would like to thank John Moy, Vijayapal Reddy Patil, SVR Anand, and Peter Psenak for their comments on this work.
作者要感谢John Moy、Vijayapal Reddy Patil、SVR Anand和Peter Psenak对这项工作的评论。
A significant portion of Sira's work was carried out as part of the HFCL-IISc Research Project (HIRP), Bangalore, India. He would like to thank the team for their insightful discussions.
Sira的大部分工作是作为印度班加罗尔HFCL IISc研究项目（HIRP）的一部分进行的。他要感谢该小组进行了富有洞察力的讨论。
The mechanism described in this document does not modify security aspects of the OSPF routing protocol.
本文档中描述的机制不会修改OSPF路由协议的安全方面。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]Moy，J.，“OSPF版本2”，STD 54，RFC 2328，1998年4月。
[RFC1793] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, April 1995.
[RFC1793]莫伊，J.，“扩展OSPF以支持需求电路”，RFC1793，1995年4月。
This memo defines the following additional configuration parameters for OSPF interfaces.
本备忘录定义了OSPF接口的以下附加配置参数。
ospfIfDemandNbrProbe Indicates whether or not neighbor probing is enabled to determine whether the neighbor is inactive. Neighbor probing is disabled by default.
OSPFIDEMANDNBRPROBE指示是否启用邻居探测以确定邻居是否处于非活动状态。默认情况下禁用邻居探测。
ospfIfDemandNbrProbeRetxLimit The number of consecutive LSA retransmissions before the neighbor is deemed inactive and the neighbor adjacency is brought down. Sample value is 10 consecutive LSA retransmissions.
OSPFIDEMANDNBR PROBERETXL在邻居被视为非活动且邻居邻接被降低之前，限制连续LSA重新传输的次数。样本值为10次连续LSA重传。
ospfIfDemandNbrProbeInterval Defines how often the neighbor will be probed. The sample value is 2 minutes.
OSPFIDEMANDNBRPROBEINTERVAL定义探测邻居的频率。采样值为2分钟。
Authors' Addresses
作者地址
Sira Panduranga Rao The University of Texas at Arlington 416 Yates Street, 300 Nedderman Hall Arlington, TX 76019
西拉潘多朗加饶德州大学阿灵顿分校416耶特街，300 Nedderman Hall Arlington，TX 76019
EMail: siraprao@hotmail.com
EMail: siraprao@hotmail.com
Alex Zinin Alcatel 701 E Middlefield Rd Mountain View, CA 94043
加利福尼亚州米德尔菲尔德东路山景城701号亚历克斯·齐宁阿尔卡特，邮编94043
EMail: zinin@psg.com
EMail: zinin@psg.com
Abhay Roy Cisco Systems 170 W. Tasman Dr. San Jose,CA 95134
Abhay Roy Cisco Systems 170 W.Tasman Dr.圣何塞，加利福尼亚州95134
EMail: akr@cisco.com
EMail: akr@cisco.com
Full Copyright Statement
完整版权声明
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/S HE 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编辑功能的资金目前由互联网协会提供。