Network Working Group S. Rao
Request for Comments: 3883 UTA
Updates: 1793 A. Zinin
Category: Standards Track Alcatel
Detecting Inactive Neighbors over OSPF Demand Circuits (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.
Copyright (C) The Internet Society (2004).
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.
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
o The OSPF process might have died on the remote neighbor.
o Oversubscription (Section 7 of [RFC1793]) may cause a continuous
drop of application data at the link level.
Rao, et al. Standards Track [Page 1]RFC 3883 OSPF DC Inactive Neighbor Detection October 2004
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.
This memo describes a backward-compatible neighbor probing mechanism
based on the details of the standard flooding procedure followed by
2. Proposed Solution
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).
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]).
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).
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
Rao, et al. Standards Track [Page 2]