Network Working Group                                Sira Panduranga Rao
Internet Draft                                                       UTA
Expiration Date: September 2001 March 2002                                   Alex Zinin
File name: draft-ietf-ospf-dc-01.txt draft-ietf-ospf-dc-02.txt                       Nexsi Systems
                                                               Abhay Roy
                                                           Cisco Systems


                                                          September 2001

         Detecting Inactive Neighbors over OSPF Demand Circuits

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet Drafts are working documents of the Internet Engineering
   Task Force (IETF), its Areas, and its Working Groups. Note that other
   groups may also distribute working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months. Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time. It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a "working
   draft" or "work in progress".

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   OSPF [RFC2328] is a link-state intra-domain routing protocol used in
   IP networks. OSPF behavior over demand circuits is optimized in
   [RFC1793] to minimize the amount of overhead traffic. A part of 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 a OSPF-inactive
   neighbor over such a link. This memo addresses the above problem by
   introducing two mechanisms---limitation of
   the number of LSA
   retransmits, and neighbor probing. probing mechanism.

1. Motivation

   In some situations, when operating over demand circuits, the remote
   neighbor may be unable to run OSPF, and, as a possible result, unable
   to route application traffic. Possible scenarios include:

       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.

   The problem here is that the local router cannot identify the prob-
   problems such as this, since Hello exchange is suppressed on demand cir-
   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 routers behind it will never know
   about the problem, so application traffic may continue being for-
   forwarded to the OSPF-incapable router.

   This memo describes two techniques that solve the described problem.
   First, the number of LSA retransmit attempts on demand circuits is
   limited. This method addresses most of network scenarios, but alone
   is not enough to cover all possible cases, so we extend it by intro-
   ducing a backward-compatible neighbor probing mechanism.

2. Proposed Solution

   The first part of the solution is limiting mechanism
   based on the number details of times LSAs
   can be retransmitted over a demand circuit. The fact that LSAs are
   not acknowledged by the remote router is used to detect the fact that
   the neighbor is not reachable any more. See Section 2.1 for more
   details. standard flooding procedure followed by
   OSPF routers.

2. Proposed Solution

   The second part of the solution this document proposes uses LSA 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.2). 2.1).

   The routers across the demand circuit can be connected by either a
   point-to-point link, or a virtual link, or a point-to-multipoint
   interface. The case of routers connected by broadcast networks or
   NBMA 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 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, and the routers may probe each other. The routers
   may also periodically probe each other any time the link is up (could
   be imple-
   mented implemented as a configurable option) with the caution that OSPF
   packets sent as a part of neighbor probing are not considered as
   interesting traffic and do not cause the demand circuit to remain up
   (relevant details of implementation are outside of the scope of this

   The case when one or more of the router's links are oversubscribed
   (see section 7 of [RFC1793]) should be considered by the implementa-
   implementations. In such a situation even if the link status is up
   and applica-
   tion application data being sent on the link, only a limited number of
   neighbors is really reachable. To make sure temporarily unreachable
   neighbors are not mistakenly declared down, Neighbor probing should
   be res-
   tricted restricted to those neighbors that are actually 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 con-
   considered an implementation detail.

 2.1 Limiting Number of LSA Retransmissions

   In the presence of LSAs that need to be flooded through a demand-
   circuit link, it is possible to identify OSPF-incapable neighbors by
   limiting the amount of LSA retransmits over a demand circuit. The
   router should count the number of retransmit attempts for each neigh-
   bor reachable through a demand-circuit link. When an LSA is ack-
   nowledged by the neighbor, the router should zero the counter. When
   the counter reaches a predefined (or configured) value, a KillNbr
   event should be generated for the neighbor experiencing the problem.

   Note that this method does not require cooperation of the routers on
   both sides of a demand circuit and can be used with already installed
   OSPF routers without requiring them to be upgraded with new software.
   This method has been implemented by Cisco Systems in 1998, has been
   widely deployed, and has proven its validity.

 2.2 Neighbor Probing

   Because the method described in Section 2.1 is not sufficient to
   cover the situation when the topology of the network is stable and
   the demand circuit link does not change its state (and hence no LSAs
   are flooded through the demand circuit), there must be a mechanism to
   explicitly verify neighbor's OSPF capability.

   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.

   When a router needs to verify 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 ini-
   initial LSDB synchronization process (it most cases such LSA must
   have already been flooded to the neighbor by the time the probing pro-
   procedure starts). For example, the router may flood its own router-LSA router-
   LSA (without originating a new version), or the neighbor's own router-
   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 when used for neighbor probing. If
   no acknowledgement (explicit or implicit) is received, received for a
   predefined period of time, the mechanism described probing router should treat this as
   evidence of the neighbor's unreachability (proving wrong the
   assumption of reachability used in Section 2.1 brings [RFC1793]) and should bring the
   adjacency down.

   Note that when the neighbor being probed receives such a link state
   update packet, it acknowledges the LSA but does not flood it any
   further synce since received copy of the LSA is concidered to be the same
   as the neighbor's database copy. Because of this property, the link
   state update based neighbor probing mechanism is localized to the
   demand circuit and does not increase flooding in the area.

   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.

3. Support of Virtual Links and Point-to-multipoint Interfaces
   Virtual links can be treated analogous to point-to-point links and so
   the techniques described in this memo are applicable to virtual links
   as well.  The case of point-to-multipoint interface running as demand
   circuit (section 3.5 [RFC1793]) can be treated as individual point-
   to-point links, for which the solution has been described in section

4. Compatibility issues

   All mechanisms described in this document are completely backward-
   compatible. backward-compatible
   with standard OSPF implementations.

5. Considerations

   In addition to the lost functionality mentioned in Section 6 of
   [RFC1793], there is an added overhead in terms of the amount of data
   (link state updates and acknowledgements) being transmitted due to
   neighbor probing whenever the link is up and thereby increasing the
   overall cost.

6. Acknowledgements

   The authors would like to thank John Moy, Vijayapal Reddy Patil, SVR
   Anand, and Peter Psenak for their comments on this work.

   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.

7. References

     J.Moy, OSPF Version 2. Technical Report RFC2328 Internet Engineer-
     ing Task Force, 1998

     J.Moy, Extending OSPF to support Demand Circuits.  Technical Report
     RFC1793 Internet Engineering Task Force, 1995

8. Authors' addresses

   Sira Panduranga Rao                       Alex Zinin
   The University of Texas at Arlington      Cisco      Nexsi Systems
   Arlington, TX 76013                       150 West Tasman Dr.                       1959 Concourse Drive
   Email:               San Jose, CA 95134 95131
   Abhay Roy
   Cisco Systems
   170 W. Tasman Dr.
   San Jose,CA 95134