Network Working Group Sira Panduranga Rao Internet Draft UTA Expiration Date: September 2001 Alex Zinin File name: draft-ietf-ospf-dc-01.txt Abhay Roy Cisco Systems March 2001 Detecting Inactive Neighbors over OSPF Demand Circuits draft-ietf-ospf-dc-01.txt 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 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract 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. 1. Motivation In some situations, when operating over demand circuits, the remote Rao, Zinin, Roy [Page 1]
INTERNET DRAFT OSPF DC Inactive Neighbor Detection March 2001 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- lems such as this, since Hello exchange is suppressed on demand cir- cuits. 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- warded 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 the number 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. 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). 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 Rao, Zinin, Roy [Page 2]
INTERNET DRAFT OSPF DC Inactive Neighbor Detection March 2001 link is brought up, and the routers may probe each other. The routers may also probe each other any time the link is up (could be imple- mented 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 document). The case when one or more of the router's links are oversubscribed (see section 7 of [RFC1793]) should be considered by the implementa- tions. In such a situation even if the link status is up and applica- tion 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 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- sidered 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. Rao, Zinin, Roy [Page 3]
INTERNET DRAFT OSPF DC Inactive Neighbor Detection March 2001 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- tial LSDB synchronization process (it most cases such LSA must have already been flooded to the neighbor by the time the probing pro- cedure 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 and the LSA is removed from the neighbor's retransmission list. If no acknowledgement is received, the mechanism described in Section 2.1 brings 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 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 2. 4. Compatibility issues All mechanisms described in this document are completely backward- compatible. 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 Rao, Zinin, Roy [Page 4]
INTERNET DRAFT OSPF DC Inactive Neighbor Detection March 2001 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 [RFC2328] J.Moy, OSPF Version 2. Technical Report RFC2328 Internet Engineer- ing Task Force, 1998 ftp://ftp.isi.edu/in-notes/rfc2328.txt [RFC1793] J.Moy, Extending OSPF to support Demand Circuits. Technical Report RFC1793 Internet Engineering Task Force, 1995 ftp://ftp.isi.edu/in-notes/rfc1793.txt 8. Authors' addresses Sira Panduranga Rao Alex Zinin The University of Texas at Arlington Cisco Systems Arlington, TX 76013 150 West Tasman Dr. Email: siraprao@hotmail.com San Jose, CA 95134 Email: azinin@cisco.com Abhay Roy Cisco Systems 170 W. Tasman Dr. San Jose,CA 95134 USA E-mail: akr@cisco.com Rao, Zinin, Roy [Page 5]
