From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3883.txt | 339 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 339 insertions(+) create mode 100644 doc/rfc/rfc3883.txt (limited to 'doc/rfc/rfc3883.txt') 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] + -- cgit v1.2.3