draft-ietf-ospf-dc-06.txt   draft-ietf-ospf-dc-07.txt 
Network Working Group Sira Panduranga Rao Network Working Group Sira Panduranga Rao
Internet Draft UTA Internet Draft UTA
Expiration Date: September 2003 Alex Zinin Expiration Date: July 2004 Alex Zinin
File name: draft-ietf-ospf-dc-06.txt Alcatel File name: draft-ietf-ospf-dc-07.txt Alcatel
Abhay Roy Abhay Roy
Cisco Systems Cisco Systems
February 2003 January 2004
Detecting Inactive Neighbors over OSPF Demand Circuits Detecting Inactive Neighbors over OSPF Demand Circuits
draft-ietf-ospf-dc-06.txt draft-ietf-ospf-dc-07.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 1, line 45 skipping to change at page 1, line 45
Abstract Abstract
OSPF is a link-state intra-domain routing protocol used in IP OSPF is a link-state intra-domain routing protocol used in IP
networks. OSPF behavior over demand circuits is optimized in RFC1793 networks. OSPF behavior over demand circuits is optimized in RFC1793
to minimize the amount of overhead traffic. A part of OSPF demand to minimize the amount of overhead traffic. A part of OSPF demand
circuit extensions is the Hello suppression mechanism. This technique circuit extensions is the Hello suppression mechanism. This technique
allows a demand circuit to go down when no interesting traffic is allows a demand circuit to go down when no interesting traffic is
going through the link. However, it also introduces a problem, where going through the link. However, it also introduces a problem, where
it becomes impossible to detect a OSPF-inactive neighbor over such a it becomes impossible to detect a OSPF-inactive neighbor over such a
link. This memo addresses the above problem by the neighbor probing link. This memo introduces a new mechanism called "neighbor probing"
mechanism. to address the above problem.
1. Motivation 1. Motivation
In some situations, when operating over demand circuits, the remote In some situations, when operating over demand circuits, the remote
neighbor may be unable to run OSPF, and, as a possible result, unable neighbor may be unable to run OSPF, and, as a possible result, unable
to route application traffic. Possible scenarios include: to route application traffic. Possible scenarios include:
o The OSPF process might have died on the remote neighbor. o The OSPF process might have died on the remote neighbor.
o Oversubscription (Section 7 of [RFC1793]) may cause a o Oversubscription (Section 7 of [RFC1793]) may cause a
continuous drop of application data at the link level. continuous drop of application data at the link level.
The problem here is that the local router cannot identify the Problem here is that the local router cannot identify the problems
problems such as this, since Hello exchange is suppressed on demand such as this, since Hello exchange is suppressed on demand circuits.
circuits. If the topology of the network is such that other routers If the topology of the network is such that other routers cannot
cannot communicate their knowledge about the remote neighbor via communicate their knowledge about the remote neighbor via flooding,
flooding, the local router and all routers behind it will never know the local router and all routers behind it will never know about the
about the problem, so application traffic may continue being problem, so application traffic may continue being forwarded to the
forwarded to the OSPF-incapable router. 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 the link-state update The solution this document proposes uses the link-state update
packets to detect whether the OSPF process is operational on the packets to detect whether the OSPF process is operational on the
remote neighbor. We call this process "Neighbor probing". The idea remote neighbor. We call this process "Neighbor probing". The idea
skipping to change at page 2, line 47 skipping to change at page 2, line 47
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, 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. If ospfIfDemandNbrProbe is enabled, the routers
may also periodically probe each other any time the link is up (could SHOULD probe each other. While the link is up, the routers may also
be implemented as a configurable option) with the caution that OSPF periodically probe each other every ospfIfDemandNbrProbeInterval.
packets sent as part of neighbor probing are not considered as Neighbor probing should not be considered as interesting traffic and
interesting traffic and do not cause the demand circuit to remain up do not cause the demand circuit to remain up (relevant details of
(relevant details of implementation are outside of the scope of this 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 is being sent on the link, only a limited number and application data is being sent on the link, only a limited number
of neighbors is really reachable. To make sure temporarily of neighbors is really reachable. To make sure temporarily
unreachable neighbors are not mistakenly declared down, Neighbor unreachable neighbors are not mistakenly declared down, Neighbor
probing should be restricted to those neighbors that are actually probing should be restricted to those neighbors that are actually
reachable (i.e., there is a circuit established with the neighbor at reachable (i.e., there is a circuit established with the neighbor at
the moment the probing procedure needs to be initiated). This check the moment the probing procedure needs to be initiated). This check
skipping to change at page 3, line 29 skipping to change at page 3, line 28
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
its LSDB that would normally be sent to the neighbor during the its LSDB that would normally be sent to the neighbor during the
initial LSDB synchronization process (it most cases such an LSA must initial LSDB synchronization process (it most cases such an LSA must
have already been flooded to the neighbor by the time the probing have already been flooded to the neighbor by the time the probing
procedure starts). For example, the router may flood its own router- procedure starts). For example, the router may flood its own
LSA (without originating a new version), or the neighbor's 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 router-LSA. If the neighbor is still alive and OSPF-capable, it
replies with a link state acknowledgement or a link state update (an replies with a link state acknowledgement or a link state update (an
implied acknowledgement) and the LSA is removed from the neighbor's implied acknowledgement) and the LSA is removed from the neighbor's
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 to ospfIfDemandNbrProbeRetxLimit,
no acknowledgement (explicit or implicit) is received for a when used for neighbor probing. If no acknowledgement (explicit or
predefined period of time, the probing router should treat this as implicit) is received for a predefined period of time, the probing
evidence of the neighbor's unreachability (proving wrong the router should treat this as evidence of the neighbor's unreachability
assumption of reachability used in [RFC1793]) and should bring the (proving wrong the assumption of reachability used in [RFC1793]) and
adjacency down. should bring the 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, and hence should normally not cause any the neighbor's LSDB, and hence should normally not cause any
additional flooding. However, since LSA refreshes are not flooded 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 cause 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
the purpose of neighbor probing do not prevent that circuit from the purpose of neighbor probing do not prevent that circuit from
being torn down. being torn down.
3. Support of Virtual Links and Point-to-multipoint Interfaces 3. Support of Virtual Links and Point-to-multipoint Interfaces
Virtual links can be treated analogous to point-to-point links and so Virtual links can be treated analogous to point-to-point links and so
the techniques described in this memo are applicable to virtual links the techniques described in this memo are applicable to virtual links
as well. The case of point-to-multipoint interface running as demand as well. The case of point-to-multipoint interface running as demand
circuit (section 3.5 [RFC1793]) can be treated as individual point- circuit (section 3.5 [RFC1793]) can be treated as individual
to-point links, for which the solution has been described in section point-to-point links, for which the solution has been described in
2. section 2.
4. Compatibility issues 4. Compatibility issues
All mechanisms described in this document are backward-compatible All mechanisms described in this document are backward-compatible
with standard OSPF implementations. with standard OSPF implementations.
5. Considerations 5. Considerations
In addition to the lost functionality mentioned in Section 6 of In addition to the lost functionality mentioned in Section 6 of
[RFC1793], there is an added overhead in terms of the amount of data [RFC1793], there is an added overhead in terms of the amount of data
skipping to change at page 5, line 20 skipping to change at page 5, line 20
[RFC1793] [RFC1793]
Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793,
April 1995. April 1995.
Appendix A. Configurable Parameters Appendix A. Configurable Parameters
This memo defines the following additional configuration parameters This memo defines the following additional configuration parameters
for OSPF interfaces. for OSPF interfaces.
ospfIfDemandNbrProbe ospfIfDemandNbrProbe
Indicates whether or not neighbor probing is enabled to deter- Indicates whether or not neighbor probing is enabled to
mine whether or not the neighbor is inactive. Neighbor probing determine whether or not the neighbor is inactive. Neighbor
is disabled by default. probing is disabled by default.
ospfIfDemandNbrProbeRetxLimit ospfIfDemandNbrProbeRetxLimit
The number of consecutive LSA retransmissions before the The number of consecutive LSA retransmissions before the
neighbor is deemed inactive and the neighbor adjacency is neighbor is deemed inactive and the neighbor adjacency is
brought down. Sample value is 10 consecutive LSA retransmis- brought down. Sample value is 10 consecutive LSA
sions. retransmissions.
ospfIfDemandNbrProbeInterval ospfIfDemandNbrProbeInterval
Defines how often the neighbor will be probed. Sample value is Defines how often the neighbor will be probed. Sample value is
2 minutes. 2 minutes.
Authors' addresses Authors' addresses
Sira Panduranga Rao Alex Zinin Sira Panduranga Rao Alex Zinin
The University of Texas at Arlington Alcatel The University of Texas at Arlington Alcatel
Arlington, TX 76013 Sunnyvale, CA Arlington, TX 76013 Sunnyvale, CA
Email: siraprao@hotmail.com E-mail: zinin@psg.com Email: siraprao@hotmail.com E-mail: zinin@psg.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
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/