draft-ietf-ospf-dc-07.txt   rfc3883.txt 
Network Working Group Sira Panduranga Rao Network Working Group S. Rao
Internet Draft UTA Request for Comments: 3883 UTA
Expiration Date: July 2004 Alex Zinin Updates: 1793 A. Zinin
File name: draft-ietf-ospf-dc-07.txt Alcatel Category: Standards Track Alcatel
Abhay Roy A. Roy
Cisco Systems Cisco Systems
October 2004
January 2004 Detecting Inactive Neighbors over OSPF Demand Circuits (DC)
Detecting Inactive Neighbors over OSPF Demand Circuits
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 specifies an Internet standards track protocol for the
all provisions of Section 10 of RFC2026. Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Internet Drafts are working documents of the Internet Engineering Official Protocol Standards" (STD 1) for the standardization state
Task Force (IETF), its Areas, and its Working Groups. Note that other and status of this protocol. Distribution of this memo is unlimited.
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 Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2004).
http://www.ietf.org/shadow.html.
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 (DC) is optimized in
to minimize the amount of overhead traffic. A part of OSPF demand RFC 1793 to minimize the amount of overhead traffic. A part of the
circuit extensions is the Hello suppression mechanism. This technique OSPF demand circuit extensions is the Hello suppression mechanism.
allows a demand circuit to go down when no interesting traffic is This technique allows a demand circuit to go down when no interesting
going through the link. However, it also introduces a problem, where traffic is going through the link. However, it also introduces a
it becomes impossible to detect a OSPF-inactive neighbor over such a problem, where it becomes impossible to detect an OSPF-inactive
link. This memo introduces a new mechanism called "neighbor probing" neighbor over such a link. This memo introduces a new mechanism
to address the above problem. called "neighbor probing" 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 [RFC2328], and, as a possible
to route application traffic. Possible scenarios include: result, unable 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
continuous drop of application data at the link level. drop of application data at the link level.
Problem here is that the local router cannot identify the problems The problem here is that the local router cannot identify problems
such as this, since Hello exchange is suppressed on demand circuits. such as this, since the Hello exchange is suppressed on demand
If the topology of the network is such that other routers cannot circuits. If the topology of the network is such that other routers
communicate their knowledge about the remote neighbor via flooding, cannot communicate their knowledge about the remote neighbor via
the local router and all routers behind it will never know about the flooding, the local router and all the routers behind it will never
problem, so application traffic may continue being forwarded to the know about the problem, so application traffic may continue being
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 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
behind this technique is to allow either of the two neighbors behind this technique is to allow either of the two neighbors
connected over a demand circuit to test the remote neighbor at any connected over a demand circuit to test the remote neighbor at any
time (see Section 2.1). 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, 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 Non-Broadcast Multi-Access (NBMA) links is not considered, since
cases (Section 3.2 [RFC1793]). Hello suppression is not used in these 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 Link State Database (LSDB) with its neighbor
the demand circuit may be torn down if there is no more application over the demand circuit, the demand circuit may be torn down if there
traffic. When application traffic starts going over the link, the is no more application traffic. When application traffic starts
link is brought up. If ospfIfDemandNbrProbe is enabled, the routers going over the link, the link is brought up. If ospfIfDemandNbrProbe
SHOULD probe each other. While the link is up, the routers may also is enabled, the routers SHOULD probe each other. While the link is
periodically probe each other every ospfIfDemandNbrProbeInterval. up, the routers may also periodically probe each other every
Neighbor probing should not be considered as interesting traffic and ospfIfDemandNbrProbeInterval. Neighbor probing should not be
do not cause the demand circuit to remain up (relevant details of considered as interesting traffic and should not cause the demand
implementation are outside of the scope of this document). 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 (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 are 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
itself is also 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 the OSPF capability of a neighbor
through a demand circuit, it should flood to the neighbor any LSA in reachable through a demand circuit, it should flood to the neighbor
its LSDB that would normally be sent to the neighbor during the any LSA in its LSDB that would normally be sent to the neighbor
initial LSDB synchronization process (it most cases such an LSA must during the initial LSDB synchronization process (in most cases, such
have already been flooded to the neighbor by the time the probing an LSA must have already been flooded to the neighbor by the time the
procedure starts). For example, the router may flood its own probing procedure starts). For example, the router may flood its own
router-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 to ospfIfDemandNbrProbeRetxLimit, times an LSA can be retransmitted to ospfIfDemandNbrProbeRetxLimit,
when used for neighbor probing. If no acknowledgement (explicit or when used for neighbor probing. If no acknowledgement (explicit or
implicit) is received for a predefined period of time, the probing implicit) is received for a predefined period of time, the probing
router should treat this as evidence of the neighbor's unreachability router should treat this as evidence of the neighbor's unreachability
(proving wrong the assumption of reachability used in [RFC1793]) and (proving wrong the assumption of reachability used in [RFC1793]) and
should bring the 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
by the neighbor. Note that if the current version of the probe LSA further by the neighbor. Note that if the current version of the
has already been flooded to the neighbor, it will not be propagated probe LSA has already been flooded to the neighbor, it will not be
any further by the neighbor. Also note that in any case subsequent propagated any further by the neighbor. Also note that in any case,
(non-first) probe LSAs will not cause further flooding until the subsequent (non-first) probe LSAs will not cause further flooding
LSA's sequence number is incremented. until the 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 analogously to point-to-point links, 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 a
circuit (section 3.5 [RFC1793]) can be treated as individual demand circuit (section 3.5 [RFC1793]) can be treated as individual
point-to-point links, for which the solution has been described in point-to-point links, for which the solution has been described in
section 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. Deployment 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 additional overhead in terms of the amount of
(link state updates and acknowledgements) being transmitted due to data (link state updates and acknowledgements) being transmitted due
neighbor probing whenever the link is up and thereby increasing the to neighbor probing whenever the link is up, thereby increasing the
overall cost. overall cost.
6. Acknowledgements 6. Acknowledgements
The original idea of limiting the number of LSA retransmissions on The original idea of limiting the number of LSA retransmissions on
demand circuits (used as part of the solution described in this demand circuits (used as part of the solution described in this
document) and its implementation belong to Padma Pillay-Esnault and document) and its implementation belong to Padma Pillay-Esnault and
Derek Yeung. Derek Yeung.
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 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 HFCL-IISc Research Project (HIRP), Bangalore, India. He would like
thank the team for their insightful discussions. to thank the team for their insightful discussions.
7. Security Considerations 7. Security Considerations
The mechanism described in this document does not modify security The mechanism described in this document does not modify security
aspects of the OSPF routing protocol. aspects of the OSPF routing protocol.
8. Normative References 8. Normative References
[RFC2328] [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[RFC1793] [RFC1793] Moy, J., "Extending OSPF to Support Demand Circuits", RFC
Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, 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 Indicates whether or not neighbor probing is enabled to
determine whether or not the neighbor is inactive. Neighbor determine whether the neighbor is inactive. Neighbor probing
probing is disabled by default. 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 brought down. Sample value is 10 consecutive LSA
retransmissions. retransmissions.
ospfIfDemandNbrProbeInterval ospfIfDemandNbrProbeInterval
Defines how often the neighbor will be probed. Sample value is Defines how often the neighbor will be probed. The sample
2 minutes. value is 2 minutes.
Authors' addresses Authors' Addresses
Sira Panduranga Rao Alex Zinin Sira Panduranga Rao
The University of Texas at Arlington Alcatel The University of Texas at Arlington
Arlington, TX 76013 Sunnyvale, CA 416 Yates Street, 300 Nedderman Hall
Email: siraprao@hotmail.com E-mail: zinin@psg.com Arlington, TX 76019
EMail: siraprao@hotmail.com
Alex Zinin
Alcatel
701 E Middlefield Rd
Mountain View, CA 94043
EMail: 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
E-mail: akr@cisco.com
EMail: akr@cisco.com
Full Copyright Statement
Copyright (C) The Internet Society (2004).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the IETF's procedures with respect to rights in IETF Documents can
be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 46 change blocks. 
115 lines changed or deleted 113 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/