draft-ietf-ospf-dc-03.txt   draft-ietf-ospf-dc-04.txt 
Network Working Group Sira Panduranga Rao Network Working Group Sira Panduranga Rao
Internet Draft UTA Internet Draft UTA
Expiration Date: April 2002 Alex Zinin Expiration Date: March 2003 Alex Zinin
File name: draft-ietf-ospf-dc-03.txt Nexsi Systems File name: draft-ietf-ospf-dc-04.txt Alcatel
Abhay Roy Abhay Roy
Cisco Systems Cisco Systems
October 2001 September 2002
Detecting Inactive Neighbors over OSPF Demand Circuits Detecting Inactive Neighbors over OSPF Demand Circuits
draft-ietf-ospf-dc-03.txt draft-ietf-ospf-dc-04.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet Drafts are working documents of the Internet Engineering Internet Drafts are working documents of the Internet Engineering
Task Force (IETF), its Areas, and its Working Groups. Note that other Task Force (IETF), its Areas, and its Working Groups. Note that other
groups may also distribute working documents as Internet Drafts. groups may also distribute working documents as Internet Drafts.
skipping to change at page 2, line 26 skipping to change at page 2, line 26
flooding, the local router and all routers behind it will never know flooding, the local router and all routers behind it will never know
about the problem, so application traffic may continue being about the problem, so application traffic may continue being
forwarded to the OSPF-incapable router. forwarded to the OSPF-incapable router.
This memo describes a backward-compatible neighbor probing mechanism This memo describes a backward-compatible neighbor probing mechanism
based on the details of the standard flooding procedure followed by based on the details of the standard flooding procedure followed by
OSPF routers. OSPF routers.
2. Proposed Solution 2. Proposed Solution
The solution this document proposes uses LSA update packets to detect The solution this document proposes uses the link-state update
whether the OSPF process is operational on the remote neighbor. We packets to detect whether the OSPF process is operational on the
call this process "Neighbor probing". The idea behind this technique remote neighbor. We call this process "Neighbor probing". The idea
is to allow either of the two neighbors connected over a demand behind this technique is to allow either of the two neighbors
circuit to test the remote neighbor at any time (see Section 2.1). 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 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 point-to-point link, a virtual link, or a point-to-multipoint
interface. The case of routers connected by broadcast networks or interface. The case of routers connected by broadcast networks or
NBMA is not considered, since Hello suppression is not used in these NBMA is not considered, since Hello suppression is not used in these
cases (Section 3.2 [RFC1793]). cases (Section 3.2 [RFC1793]).
The neighbor probing mechanism is used as follows. After a router The neighbor probing mechanism is used as follows. After a router
has synchronized the LSDB with its neighbor over the demand circuit, has synchronized the LSDB with its neighbor over the demand circuit,
the demand circuit may be torn down if there is no more application the demand circuit may be torn down if there is no more application
traffic. When application traffic starts going over the link, the traffic. When application traffic starts going over the link, the
link is brought up, and the routers may probe each other. The routers 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 may also periodically probe each other any time the link is up (could
be implemented as a configurable option) with the caution that OSPF be implemented as a configurable option) with the caution that OSPF
packets sent as a part of neighbor probing are not considered as packets sent as part of neighbor probing are not considered as
interesting traffic and do not cause the demand circuit to remain up interesting traffic and do not cause the demand circuit to remain up
(relevant details of implementation are outside of the scope of this (relevant details of implementation are outside of the scope of this
document). document).
The case when one or more of the router's links are oversubscribed The case when one or more of the router's links are oversubscribed
(see section 7 of [RFC1793]) should be considered by the (see section 7 of [RFC1793]) should be considered by the
implementations. In such a situation even if the link status is up implementations. In such a situation even if the link status is up
and application data being sent on the link, only a limited number of and application data is being sent on the link, only a limited number
neighbors is really reachable. To make sure temporarily unreachable of neighbors is really reachable. To make sure temporarily
neighbors are not mistakenly declared down, Neighbor probing should unreachable neighbors are not mistakenly declared down, Neighbor
be restricted to those neighbors that are actually reachable (i.e., probing should be restricted to those neighbors that are actually
there is a circuit established with the neighbor at the moment the reachable (i.e., there is a circuit established with the neighbor at
probing procedure needs to be initiated). This check itself is also the moment the probing procedure needs to be initiated). This check
considered an implementation detail. itself is also considered an implementation detail.
2.1 Neighbor Probing 2.1 Neighbor Probing
The neighbor probing method described in this section is completely The neighbor probing method described in this section is completely
compatible with standard OSPF implementations, because it is based on compatible with standard OSPF implementations, because it is based on
standard behavior that must be followed by OSPF implementations in standard behavior that must be followed by OSPF implementations in
order to keep their LSDBs synchronized. order to keep their LSDBs synchronized.
When a router needs to verify OSPF capability of a neighbor reachable 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 through a demand circuit, it should flood to the neighbor any LSA in
skipping to change at page 3, line 40 skipping to change at page 3, line 41
retransmission list. The implementations should limit the number of retransmission list. The implementations should limit the number of
times an LSA can be retransmitted when used for neighbor probing. If times an LSA can be retransmitted when used for neighbor probing. If
no acknowledgement (explicit or implicit) is received for a no acknowledgement (explicit or implicit) is received for a
predefined period of time, the probing router should treat this as predefined period of time, the probing router should treat this as
evidence of the neighbor's unreachability (proving wrong the evidence of the neighbor's unreachability (proving wrong the
assumption of reachability used in [RFC1793]) and should bring the assumption of reachability used in [RFC1793]) and should bring the
adjacency down. adjacency down.
Note that when the neighbor being probed receives such a link state 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 update packet, the received LSA has the same contents as the LSA in
the neighbor's LSDB. However, since LSA refreshes are not flooded 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 over demand circuits, the received LSA may have a higher Sequence
Number. This will result in the first probe LSA being flooded further 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 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 has already been flooded to the neighbor, it will not be propagated
any further by the neighbor. Also note that in any case subsequent any further by the neighbor. Also note that in any case subsequent
(non-first) probe LSAs will not effect further flooding until the (non-first) probe LSAs will not effect further flooding until the
LSA's sequence number is incremented. LSA's sequence number is incremented.
Again, the implementation should insure (through internal mechanisms) Again, the implementation should insure (through internal mechanisms)
that OSPF link state update packets sent over the demand circuit for that OSPF link state update packets sent over the demand circuit for
skipping to change at page 4, line 49 skipping to change at page 5, line 4
[RFC2328] [RFC2328]
J.Moy, OSPF Version 2. Technical Report RFC2328 Internet Engineer- J.Moy, OSPF Version 2. Technical Report RFC2328 Internet Engineer-
ing Task Force, 1998 ftp://ftp.isi.edu/in-notes/rfc2328.txt ing Task Force, 1998 ftp://ftp.isi.edu/in-notes/rfc2328.txt
[RFC1793] [RFC1793]
J.Moy, Extending OSPF to support Demand Circuits. Technical Report J.Moy, Extending OSPF to support Demand Circuits. Technical Report
RFC1793 Internet Engineering Task Force, 1995 ftp://ftp.isi.edu/in- RFC1793 Internet Engineering Task Force, 1995 ftp://ftp.isi.edu/in-
notes/rfc1793.txt notes/rfc1793.txt
8. Authors' addresses 8. Authors' addresses
Sira Panduranga Rao Alex Zinin Sira Panduranga Rao Alex Zinin
The University of Texas at Arlington Nexsi Systems The University of Texas at Arlington Alcatel
Arlington, TX 76013 1959 Concourse Drive Arlington, TX 76013 Sunnyvale, CA
Email: siraprao@hotmail.com San Jose, CA 95131 Email: siraprao@hotmail.com E-mail: zinin@psg.com
Email: azinin@nexsi.com
Abhay Roy Abhay Roy
Cisco Systems Cisco Systems
170 W. Tasman Dr. 170 W. Tasman Dr.
San Jose,CA 95134 San Jose,CA 95134
USA USA
E-mail: akr@cisco.com E-mail: akr@cisco.com
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/