draft-ietf-ospf-dc-01.txt   draft-ietf-ospf-dc-02.txt 
Network Working Group Sira Panduranga Rao Network Working Group Sira Panduranga Rao
Internet Draft UTA Internet Draft UTA
Expiration Date: September 2001 Alex Zinin Expiration Date: March 2002 Alex Zinin
File name: draft-ietf-ospf-dc-01.txt Abhay Roy File name: draft-ietf-ospf-dc-02.txt Nexsi Systems
Abhay Roy
Cisco Systems Cisco Systems
March 2001 September 2001
Detecting Inactive Neighbors over OSPF Demand Circuits Detecting Inactive Neighbors over OSPF Demand Circuits
draft-ietf-ospf-dc-01.txt draft-ietf-ospf-dc-02.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 44 skipping to change at page 1, line 45
Abstract Abstract
OSPF [RFC2328] is a link-state intra-domain routing protocol used in OSPF [RFC2328] is a link-state intra-domain routing protocol used in
IP networks. OSPF behavior over demand circuits is optimized in IP networks. OSPF behavior over demand circuits is optimized in
[RFC1793] to minimize the amount of overhead traffic. A part of OSPF [RFC1793] to minimize the amount of overhead traffic. A part of OSPF
demand circuit extensions is the Hello suppression mechanism. This demand circuit extensions is the Hello suppression mechanism. This
technique allows a demand circuit to go down when no interesting technique allows a demand circuit to go down when no interesting
traffic is going through the link. However, it also introduces a traffic is going through the link. However, it also introduces a
problem, where it becomes impossible to detect a OSPF-inactive problem, where it becomes impossible to detect a OSPF-inactive
neighbor over such a link. This memo addresses the above problem by neighbor over such a link. This memo addresses the above problem by
introducing two mechanisms---limitation of the number of LSA the neighbor probing mechanism.
retransmits, and neighbor probing.
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 continuous o Oversubscription (Section 7 of [RFC1793]) may cause a
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 prob- The problem here is that the local router cannot identify the
lems such as this, since Hello exchange is suppressed on demand cir- problems such as this, since Hello exchange is suppressed on demand
cuits. If the topology of the network is such that other routers circuits. If the topology of the network is such that other routers
cannot communicate their knowledge about the remote neighbor via cannot communicate their knowledge about the remote neighbor via
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 for- about the problem, so application traffic may continue being
warded to the OSPF-incapable router. forwarded to the OSPF-incapable router.
This memo describes two techniques that solve the described problem. This memo describes a backward-compatible neighbor probing mechanism
First, the number of LSA retransmit attempts on demand circuits is based on the details of the standard flooding procedure followed by
limited. This method addresses most of network scenarios, but alone OSPF routers.
is not enough to cover all possible cases, so we extend it by intro-
ducing a backward-compatible neighbor probing mechanism.
2. Proposed Solution 2. Proposed Solution
The first part of the solution is limiting the number of times LSAs The solution this document proposes uses LSA update packets to detect
can be retransmitted over a demand circuit. The fact that LSAs are whether the OSPF process is operational on the remote neighbor. We
not acknowledged by the remote router is used to detect the fact that call this process "Neighbor probing". The idea behind this technique
the neighbor is not reachable any more. See Section 2.1 for more is to allow either of the two neighbors connected over a demand
details. circuit to test the remote neighbor at any time (see Section 2.1).
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 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, or 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 probe each other any time the link is up (could be imple- may also periodically probe each other any time the link is up (could
mented as a configurable option) with the caution that OSPF packets be implemented as a configurable option) with the caution that OSPF
sent as a part of neighbor probing are not considered as interesting packets sent as a part of neighbor probing are not considered as
traffic and do not cause the demand circuit to remain up (relevant interesting traffic and do not cause the demand circuit to remain up
details of implementation are outside of the scope of this document). (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 The case when one or more of the router's links are oversubscribed
(see section 7 of [RFC1793]) should be considered by the implementa- (see section 7 of [RFC1793]) should be considered by the
tions. In such a situation even if the link status is up and applica- implementations. In such a situation even if the link status is up
tion data being sent on the link, only a limited number of neighbors and application data being sent on the link, only a limited number of
is really reachable. To make sure temporarily unreachable neighbors neighbors is really reachable. To make sure temporarily unreachable
are not mistakenly declared down, Neighbor probing should be res- neighbors are not mistakenly declared down, Neighbor probing should
tricted to those neighbors that are actually reachable (i.e., there be restricted to those neighbors that are actually reachable (i.e.,
is a circuit established with the neighbor at the moment the probing there is a circuit established with the neighbor at the moment the
procedure needs to be initiated). This check itself is also con- probing procedure needs to be initiated). This check itself is also
sidered an implementation detail. 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 2.1 Neighbor Probing
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 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 ini- its LSDB that would normally be sent to the neighbor during the
tial LSDB synchronization process (it most cases such LSA must have initial LSDB synchronization process (it most cases such LSA must
already been flooded to the neighbor by the time the probing pro- have already been flooded to the neighbor by the time the probing
cedure starts). For example, the router may flood its own router-LSA procedure starts). For example, the router may flood its own router-
(without originating a new version), or the neighbor's own router- LSA (without originating a new version), or the neighbor's own
LSA. If the neighbor is still alive and OSPF-capable, it replies with router-LSA. If the neighbor is still alive and OSPF-capable, it
a link state acknowledgement and the LSA is removed from the replies with a link state acknowledgement or a link state update (an
neighbor's retransmission list. If no acknowledgement is received, implied acknowledgement) and the LSA is removed from the neighbor's
the mechanism described in Section 2.1 brings the adjacency down. 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 for a
predefined period of time, the probing router should treat this as
evidence of the neighbor's unreachability (proving wrong the
assumption of reachability used in [RFC1793]) and 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, it acknowledges the LSA but does not flood it any 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 further since received copy of the LSA is concidered to be the same
as the neighbor's database copy. Because of this property, the link as the neighbor's database copy. Because of this property, the link
state update based neighbor probing mechanism is localized to the state update based neighbor probing mechanism is localized to the
demand circuit and does not increase flooding in the area. demand circuit and does not increase flooding in the area.
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
skipping to change at page 4, line 30 skipping to change at page 4, line 4
as the neighbor's database copy. Because of this property, the link as the neighbor's database copy. Because of this property, the link
state update based neighbor probing mechanism is localized to the state update based neighbor probing mechanism is localized to the
demand circuit and does not increase flooding in the area. demand circuit and does not increase flooding in the area.
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 point-
to-point links, for which the solution has been described in section to-point links, for which the solution has been described in section
2. 2.
4. Compatibility issues 4. Compatibility issues
All mechanisms described in this document are completely backward- All mechanisms described in this document are backward-compatible
compatible. 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
(link state updates and acknowledgements) being transmitted due to (link state updates and acknowledgements) being transmitted due to
neighbor probing whenever the link is up and thereby increasing the neighbor probing whenever the link is up and thereby increasing the
overall cost. overall cost.
6. Acknowledgements 6. Acknowledgements
skipping to change at page 5, line 19 skipping to change at page 4, line 41
thank the team for their insightful discussions. thank the team for their insightful discussions.
7. References 7. References
[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 RFC1793 Internet Engineering Task Force, 1995 ftp://ftp.isi.edu/in-
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 Cisco Systems The University of Texas at Arlington Nexsi Systems
Arlington, TX 76013 150 West Tasman Dr. Arlington, TX 76013 1959 Concourse Drive
Email: siraprao@hotmail.com San Jose, CA 95134 Email: siraprao@hotmail.com San Jose, CA 95131
Email: azinin@cisco.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/