draft-ietf-ospf-dc-00.txt   draft-ietf-ospf-dc-01.txt 
Network Working Group Sira Panduranga Rao Network Working Group Sira Panduranga Rao
Internet Draft UTA Internet Draft UTA
Expiration Date: July 2001 Alex Zinin Expiration Date: September 2001 Alex Zinin
File name: draft-ietf-ospf-dc-00.txt Cisco Systems File name: draft-ietf-ospf-dc-01.txt Abhay Roy
Cisco Systems
November 2000 March 2001
Detecting Inactive Neighbors over OSPF Demand Circuits Detecting Inactive Neighbors over OSPF Demand Circuits
draft-ietf-ospf-dc-00.txt draft-ietf-ospf-dc-01.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 43 skipping to change at page 1, line 44
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 three mechanisms---Hello probes, limitation of the number introducing two mechanisms---limitation of the number of LSA
of LSA retransmits and flushing of self-originated LSAs. 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 continuous
skipping to change at page 2, line 20 skipping to change at page 2, line 21
The problem here is that the local router cannot identify the prob- The problem here is that the local router cannot identify the prob-
lems such as this, since Hello exchange is suppressed on demand cir- lems such as this, since Hello exchange is suppressed on demand cir-
cuits. If the topology of the network is such that other routers cuits. 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 for-
warded to the OSPF-incapable router. warded to the OSPF-incapable router.
This memo describes two techniques that solve the described problem. This memo describes two techniques that solve the described problem.
First, a neighbor probing mechanism using Hellos is introduced, and First, the number of LSA retransmit attempts on demand circuits is
second, the number of LSA retransmit attempts on demand circuits is limited. This method addresses most of network scenarios, but alone
limited. We also encourage flushing of self-originated LSAs when the is not enough to cover all possible cases, so we extend it by intro-
OSPF process is going down. ducing a backward-compatible neighbor probing mechanism.
2. Proposed Solution 2. Proposed Solution
The first part of the solution this document proposes makes use of The first part of the solution is limiting the number of times LSAs
Hellos to detect whether the OSPF process is operational on the can be retransmitted over a demand circuit. The fact that LSAs are
remote neighbor. We call this process "Hello probing". The idea not acknowledged by the remote router is used to detect the fact that
behind this technique is to allow either of the two neighbors con- the neighbor is not reachable any more. See Section 2.1 for more
nected over a demand circuit to test the remote neighbor at any time details.
(see Section 2.1.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]). Since Hellos are
suppressed on demand circuit interfaces, the local router must make
sure the remote router supports Hello probing before testing it. Oth-
erwise the remote router may be mistakenly declared inoperational. To
accomplish this, we introduce a new capability bit that is exchanged
in DBD packets (see Section 2.1.1).
The Hello probing mechanism is used as follows. After a router has The second part of the solution this document proposes uses LSA
synchronized the LSDB with its neighbor over the demand circuit, the update packets to detect whether the OSPF process is operational on
demand circuit may be torn down if there is no more application 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 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 probe each other any time the link is up (could be imple-
mented as a configurable option) with the caution that OSPF Hello mented as a configurable option) with the caution that OSPF packets
packets are not considered as interesting traffic and do not cause sent as a part of neighbor probing are not considered as interesting
the demand circuit to remain up. 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 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 implementa-
tions. In such a situation even if the link status is up and applica- 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 tion data being sent on the link, only a limited number of neighbors
is really reachable. To make sure temporarily unreachable neighbors is really reachable. To make sure temporarily unreachable neighbors
are not mistakenly declared down, Hello probing should be restricted are not mistakenly declared down, Neighbor probing should be res-
to those neighbors that are actually reachable (i.e., there is a cir- tricted to those neighbors that are actually reachable (i.e., there
cuit established with the neighbor at the moment the probing pro- is a circuit established with the neighbor at the moment the probing
cedure needs to be initiated). This check itself is considered an procedure needs to be initiated). This check itself is also con-
implementation detail. sidered an implementation detail.
The second part of the solution is limiting the number of times LSAs
can be retransmitted over a demand circuit. See Section 2.2 for more
details.
The third part of the solution is flushing of self-originated LSAs
whenever the OSPF process on a router is going down.
Hello probing and LSA retransmission limit may be used together or
alone. This memo does not dictate which one and how many of them
must be implemented, but only provides mechanisms to solve the
described problem. This memo, however, recommends to flush some
locally originated LSAs when possible when OSPF process is going
down.
2.1 Hello Probing
The Hello probing mechanism allows routers connected over a demand
circuit to test each other's OSPF capabilities. In order to do so,
both routers need to support this functionality, otherwise opera-
tional routers may mistakenly be declared unreachable. We insure this
by introducing a new capability bit in the Extended Options TLV
announced in the link-local signaling (LLS) data block of DBD packets
(see [LLS] for more information on LLS).
We also use the same bit in Hello packets as a Hello reply request
(RR) flag. This helps avoid racing conditions when a Hello sent in
reply causes another reply to be sent, and so on. When a router needs
to probe its neighbor, it sends a Hello with the RR bit set. The
receiving side sends a Hello packet in reply with RR bit clear.
2.1.1 Extended Options TLV
The Extended Options TLV is a part of LLS specification (see [LLS])
and is announced in both Hello and DBD packets.
A new bit is introduced in the Value field of this TLV as shown in
Figure 1. The value of the bit is 0x00000004.
+---+---+---+---+---+---+---+- -+---+---+---+---+-----+---+---+
| * | * | * | * | * | * | * |...| * | * | * | * |HP/RR| RS| OR|
+---+---+---+---+---+---+---+- -+---+---+---+---+-----+---+---+
Figure 1. Bits in Extended Options TLV
When used in DBD packets, the new bit indicates router's Hello Prob-
ing capability and is called the HP-bit. When used in Hello packets,
the new bit means that a Hello must be sent in reply and is called
the Reply Request (RR) bit.
Routers supporting Hello probing must always set the HP bit in their
DBD packets.
For description of RS and OR bits, see [HELLO] and [OOB] correspond-
ingly.
2.1.2 Hello Probing Procedure
OSPF routers are allowed to perform Hello probing at any time. How-
ever, it is not recommended to do so when the link is down, because,
in its one extreme, it will keep the demand circuit up or bouncing,
or, in its other extreme, it may cause a neighbor to be mistakenly
declared unreachable.
It is recommended that both sides perform Hello probing whenever the
demand circuit goes up, and periodically if the circuit stays in the
active state. Note however that care must be taken not to let OSPF
Hello probes keep the circuit in the active state without any appli-
cation traffic going through it.
When a router needs to probe a neighbor, it should start its Hello
and Dead timers and send Hello packets with the RR-bit set. If asso-
ciated interface is point-to-multipoint, it is recommended to account
for neighbor-specific timers and send Hello probes as IP unicasts.
On the receiving side, when a packet with the RR-bit set is received,
the router should immediately reply with a unicast Hello packet
without setting the RR-bit. Unicast Hello limits the scope of Hello
probing.
The described procedure makes it possible for the sides to probe
their corresponding neighbors asynchronously and without coordina-
tion.
2.2 Limiting Number of LSA Retransmissions 2.1 Limiting Number of LSA Retransmissions
An alternative method (that can be used together with Hello probing) In the presence of LSAs that need to be flooded through a demand-
to identify OSPF-incapable neighbors is to limit the amount of LSA circuit link, it is possible to identify OSPF-incapable neighbors by
retransmits over a demand circuit. The router should count the number limiting the amount of LSA retransmits over a demand circuit. The
of retransmit attempts for each neighbor. When an LSA is acknowledged router should count the number of retransmit attempts for each neigh-
by the neighbor, the router should zero the counter. When the counter bor reachable through a demand-circuit link. When an LSA is ack-
reaches a predefined (or configured) value, a KillNbr event should be nowledged by the neighbor, the router should zero the counter. When
generated for the neighbor experiencing the problem. 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 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 both sides of a demand circuit and can be used with already installed
OSPF routers without requiring them to be upgraded with new software. 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.3 OSPF Process Shutdown and Flushing of LSAs 2.2 Neighbor Probing
It is recommended for an OSPF process to flush its self-originated Because the method described in Section 2.1 is not sufficient to
LSAs when the OSPF process is going down. This way the router informs cover the situation when the topology of the network is stable and
all other routers in the area that they should not consider it tran- the demand circuit link does not change its state (and hence no LSAs
sit any more and should look for alternative routes. are flooded through the demand circuit), there must be a mechanism to
explicitly verify neighbor's OSPF capability.
Care must be taken not to introduce instability in the network by The neighbor probing method described in this section is completely
flushing all LSAs. It is acceptable to flush only the self-originated compatible with standard OSPF implementations, because it is based on
router-LSA in the appropriate area and let other LSAs age out. standard behavior that must be followed by OSPF implementations in
order to keep their LSDBs synchronized.
Note that there can happen situations where the router cannot reli- When a router needs to verify OSPF capability of a neighbor reachable
ably flush its LSAs within reasonable time frame. This could be due through a demand circuit, it should flood to the neighbor any LSA in
to the loss of the packets, the demand circuit being down or the its LSDB that would normally be sent to the neighbor during the ini-
delay in establishing a path to the neighbor. A situation highlight- tial LSDB synchronization process (it most cases such LSA must have
ing this problem is when the router is oversubscribed (see Section 7 already been flooded to the neighbor by the time the probing pro-
of [RFC1793]) and thus cannot communicate the news to its neighbors. 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 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
Backward compatibility of the Hello probing mechanism is insured by All mechanisms described in this document are completely backward-
introducing the HP bit in the Extended Options TLV. compatible.
Limiting the number of LSA retransmission is a backward-compatible
technique by its nature.
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
(hello packets) being transmitted due to Hello probing whenever the (link state updates and acknowledgements) being transmitted due to
link is up and thereby increasing the overall cost. neighbor probing whenever the link is up and thereby increasing the
overall cost.
6. Acknowledgements 6. Acknowledgements
The authors would like to thank John Moy, Vijayapal Reddy Patil, SVR The authors would like to thank John Moy, Vijayapal Reddy Patil, SVR
Anand, and Peter Psenak for their comments on this work. 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 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-notes/rfc1793.txt ftp://ftp.isi.edu/in-notes/rfc1793.txt
[LLS] Zinin, Friedman, Roy, Nguyen, Yeung, "OSPF Link-local Signaling",
draft-ietf-ospf-lls-00.txt, Work in progress.
[HELLO]
Zinin, Roy, Nguyen, "OSPF Restart Signaling", draft-ietf-ospf-
restart-00.txt, Work in progress.
[OOB] Zinin, Roy, Nguyen, "OSPF Out-of-band LSDB resynchronization",
draft-ietf-ospf-oob-resync-00.txt, Work in progress.
8. Authors' addresses 8. Authors' addresses
Sira Panduranga Rao Sira Panduranga Rao Alex Zinin
The University of Texas at Arlington The University of Texas at Arlington Cisco Systems
Arlington, TX 76013 Arlington, TX 76013 150 West Tasman Dr.
Email: siraprao@hotmail.com Email: siraprao@hotmail.com San Jose, CA 95134
Email: azinin@cisco.com
Alex Zinin Abhay Roy
Cisco Systems Cisco Systems
150 West Tasman Dr. 170 W. Tasman Dr.
San Jose, CA 95134 San Jose, CA 95134
Email: azinin@cisco.com USA
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/