1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc3883.txt b/doc/rfc/rfc3883.txt
new file mode 100644
index 0000000..eaf6fd0
--- /dev/null
+++ b/doc/rfc/rfc3883.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                             S. Rao
+Request for Comments: 3883                                           UTA
+Updates: 1793                                                   A. Zinin
+Category: Standards Track                                        Alcatel
+                                                                  A. Roy
+                                                           Cisco Systems
+                                                            October 2004
+
+
+      Detecting Inactive Neighbors over OSPF Demand Circuits (DC)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).
+
+Abstract
+
+   OSPF is a link-state intra-domain routing protocol used in IP
+   networks.  OSPF behavior over demand circuits (DC) is optimized in
+   RFC 1793 to minimize the amount of overhead traffic.  A part of the
+   OSPF demand circuit extensions is the Hello suppression mechanism.
+   This technique allows a demand circuit to go down when no interesting
+   traffic is going through the link.  However, it also introduces a
+   problem, where it becomes impossible to detect an OSPF-inactive
+   neighbor over such a link.  This memo introduces a new mechanism
+   called "neighbor probing" to address the above problem.
+
+1.  Motivation
+
+   In some situations, when operating over demand circuits, the remote
+   neighbor may be unable to run OSPF [RFC2328], and, as a possible
+   result, unable to route application traffic.  Possible scenarios
+   include:
+
+   o  The OSPF process might have died on the remote neighbor.
+
+   o  Oversubscription (Section 7 of [RFC1793]) may cause a continuous
+      drop of application data at the link level.
+
+
+
+
+
+Rao, et al.                 Standards Track                     [Page 1]
+
+RFC 3883          OSPF DC Inactive Neighbor Detection       October 2004
+
+
+   The problem here is that the local router cannot identify problems
+   such as this, since the Hello exchange is suppressed on demand
+   circuits.  If the topology of the network is such that other routers
+   cannot communicate their knowledge about the remote neighbor via
+   flooding, the local router and all the routers behind it will never
+   know about the problem, so application traffic may continue being
+   forwarded to the OSPF-incapable router.
+
+   This memo describes a backward-compatible neighbor probing mechanism
+   based on the details of the standard flooding procedure followed by
+   OSPF routers.
+
+2.  Proposed Solution
+
+   The solution this document proposes uses the link-state 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.1).
+
+   The routers across the demand circuit can be connected by either a
+   point-to-point link, a virtual link, or a point-to-multipoint
+   interface.  The case of routers connected by broadcast networks or
+   Non-Broadcast Multi-Access (NBMA) links 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 Link State Database (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 link is brought up.  If ospfIfDemandNbrProbe
+   is enabled, the routers SHOULD probe each other.  While the link is
+   up, the routers may also periodically probe each other every
+   ospfIfDemandNbrProbeInterval.  Neighbor probing should not be
+   considered as interesting traffic and should 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
+   (see section 7 of [RFC1793]) should be considered by the
+   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
+   of neighbors are really reachable.  To make sure temporarily
+   unreachable neighbors are not mistakenly declared down, Neighbor
+   probing should be restricted to those neighbors that are actually
+
+
+
+
+
+Rao, et al.                 Standards Track                     [Page 2]
+
+RFC 3883          OSPF DC Inactive Neighbor Detection       October 2004
+
+
+   reachable (i.e., there is a circuit established with the neighbor at
+   the moment the probing procedure needs to be initiated).  This check
+   itself is also considered an implementation detail.
+
+2.1.  Neighbor Probing
+
+   The neighbor probing method described in this section is completely
+   compatible with standard OSPF implementations, because it is based on
+   standard behavior that must be followed by OSPF implementations in
+   order to keep their LSDBs synchronized.
+
+   When a router needs to verify the OSPF capability of a neighbor
+   reachable 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 initial LSDB synchronization process (in most cases, such
+   an LSA must have already been flooded to the neighbor by the time the
+   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.  If the neighbor is still alive and OSPF-capable, it
+   replies with a link state acknowledgement or a link state update (an
+   implied acknowledgement), and the LSA is removed from the neighbor's
+   retransmission list.  The implementations should limit the number of
+   times an LSA can be retransmitted to ospfIfDemandNbrProbeRetxLimit,
+   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
+   update packet, the received LSA has the same contents as the LSA in
+   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
+   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 has already been flooded to the neighbor, it will not be
+   propagated any further by the neighbor.  Also note that in any case,
+   subsequent (non-first) probe LSAs will not cause further flooding
+   until the LSA's sequence number is incremented.
+
+   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.
+
+
+
+
+
+
+Rao, et al.                 Standards Track                     [Page 3]
+
+RFC 3883          OSPF DC Inactive Neighbor Detection       October 2004
+
+
+3.  Support of Virtual Links and Point-to-multipoint Interfaces
+
+   Virtual links can be treated analogously to point-to-point links, so
+   the techniques described in this memo are applicable to virtual links
+   as well.  The case of point-to-multipoint interface running as a
+   demand circuit (section 3.5 [RFC1793]) can be treated as individual
+   point-to-point links, for which the solution has been described in
+   section 2.
+
+4.  Compatibility Issues
+
+   All mechanisms described in this document are backward-compatible
+   with standard OSPF implementations.
+
+5.  Deployment Considerations
+
+   In addition to the lost functionality mentioned in Section 6 of
+   [RFC1793], there is additional overhead in terms of the amount of
+   data (link state updates and acknowledgements) being transmitted due
+   to neighbor probing whenever the link is up, thereby increasing the
+   overall cost.
+
+6.  Acknowledgements
+
+   The original idea of limiting the number of LSA retransmissions on
+   demand circuits (used as part of the solution described in this
+   document) and its implementation belong to Padma Pillay-Esnault and
+   Derek Yeung.
+
+   The authors would like to thank John Moy, Vijayapal Reddy Patil, SVR
+   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.  Security Considerations
+
+   The mechanism described in this document does not modify security
+   aspects of the OSPF routing protocol.
+
+8.  Normative References
+
+   [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
+
+   [RFC1793] Moy, J., "Extending OSPF to Support Demand Circuits", RFC
+             1793, April 1995.
+
+
+
+
+Rao, et al.                 Standards Track                     [Page 4]
+
+RFC 3883          OSPF DC Inactive Neighbor Detection       October 2004
+
+
+Appendix A.  Configurable Parameters
+
+   This memo defines the following additional configuration parameters
+   for OSPF interfaces.
+
+      ospfIfDemandNbrProbe
+         Indicates whether or not neighbor probing is enabled to
+         determine whether the neighbor is inactive.  Neighbor probing
+         is disabled by default.
+
+      ospfIfDemandNbrProbeRetxLimit
+         The number of consecutive LSA retransmissions before the
+         neighbor is deemed inactive and the neighbor adjacency is
+         brought down.  Sample value is 10 consecutive LSA
+         retransmissions.
+
+      ospfIfDemandNbrProbeInterval
+         Defines how often the neighbor will be probed.  The sample
+         value is 2 minutes.
+
+Authors' Addresses
+
+   Sira Panduranga Rao
+   The University of Texas at Arlington
+   416 Yates Street, 300 Nedderman Hall
+   Arlington, TX 76019
+
+   EMail: siraprao@hotmail.com
+
+
+   Alex Zinin
+   Alcatel
+   701 E Middlefield Rd
+   Mountain View, CA 94043
+
+   EMail: zinin@psg.com
+
+
+   Abhay Roy
+   Cisco Systems
+   170 W. Tasman Dr.
+   San Jose,CA 95134
+
+   EMail: akr@cisco.com
+
+
+
+
+
+
+
+Rao, et al.                 Standards Track                     [Page 5]
+
+RFC 3883          OSPF DC Inactive Neighbor Detection       October 2004
+
+
+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.
+
+
+
+
+
+
+
+Rao, et al.                 Standards Track                     [Page 6]
+