doc: Add RFC documents

1 files changed, 283 insertions, 0 deletions

diff --git a/doc/rfc/rfc4136.txt b/doc/rfc/rfc4136.txt
new file mode 100644
index 0000000..4fc8c10
--- /dev/null
+++ b/doc/rfc/rfc4136.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group                                  P. Pillay-Esnault
+Request for Comments: 4136                                 Cisco Systems
+Category: Informational                                        July 2005
+
+
+        OSPF Refresh and Flooding Reduction in Stable Topologies
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document describes an extension to the OSPF protocol to reduce
+   periodic flooding of Link State Advertisements (LSAs) in stable
+   topologies.
+
+   Current OSPF behavior requires that all LSAs, except DoNotAge LSAs,
+   to be refreshed every 30 minutes.  This document proposes to
+   generalize the use of DoNotAge LSAs in order to reduce protocol
+   traffic in stable topologies.
+
+1.  Introduction
+
+   The explosive growth of IP-based networks has placed focus on the
+   scalability of Interior Gateway Protocols such as OSPF.  Networks
+   using OSPF are growing every day and will continue to expand to
+   accommodate the demand for connections to the Internet or intranets.
+
+   Internet Service Providers and users that have large networks have
+   noticed non-negligible protocol traffic, even when their network
+   topologies were stable.
+
+   OSPF requires every LSA to be refreshed every 1800 seconds or else
+   they will expire when they reach 3600 seconds [1].
+
+   This document proposes to overcome the LSA expiration by generalizing
+   the use of DoNotAge LSAs.  This technique will facilitate OSPF
+   scaling by reducing OSPF traffic overhead in stable topologies.
+
+
+
+
+
+
+Pillay-Esnault               Informational                      [Page 1]
+
+RFC 4136          OSPF Refresh and Flooding Reduction          July 2005
+
+
+2.  Changes in the Existing Implementation
+
+   This enhancement relies on the implementation of the DoNotAge bit and
+   the Indication-LSA.  The details of the implementation of the
+   DoNotAge bit and the Indication-LSA are specified in "Extending OSPF
+   to Support Demand Circuits" [2].
+
+   Flooding-reduction-capable routers will continue to send hellos to
+   their neighbors and keep aging their self-originated LSAs in their
+   database.  However, these routers will flood their self-originated
+   LSAs with the DoNotAge bit set.  Thus, self-originated LSAs do not
+   have to be re-flooded every 30 minutes and the re-flooding interval
+   can be extended to the configured forced-flooding interval.  As in
+   normal OSPF operation, any change in the contents of the LSA will
+   cause a reoriginated LSA to be flooded with the DoNotAge bit set.
+   This will reduce protocol traffic overhead while allowing changes to
+   be flooded immediately.
+
+   Flooding-reduction-capable routers will flood received non-self-
+   originated LSAs with the DoNotAge bit set on all normal or flooding-
+   reduction-only interfaces within the LSA's flooding scope.  If an
+   interface is configured as both flooding-reduction-capable and
+   Demand-Circuit, then the flooding is done if and only if the contents
+   of the LSA have changed.  This allows LSA flooding for unchanged LSAs
+   to be periodically forced by the originating router.
+
+3.  Backward Compatibility
+
+   Routers supporting the demand circuit extensions [2] will be able to
+   correctly process DoNotAge LSAs flooded by routers supporting the
+   flooding reduction capability described herein.  These routers will
+   also suppress flooding DoNotAge LSAs on interfaces configured as
+   demand circuits.  However, they will also flood DoNotAge LSAs on
+   interfaces that are not configured as demand circuits.
+
+   When there are routers in the OSPF routing domain, stub area, or NSSA
+   area, that do not support the demand circuit extensions [2] then the
+   use of these flooding reduction capabilities will be subject to the
+   demand circuit interoperability constraints articulated in section
+   2.5 of "Extending OSPF to Support Demand Circuits" [2].  This implies
+   that detection of an LSA, with the DC bit clear, will result in the
+   re-origination of self-originated DoNotAge LSAs with the DoNotAge
+   clear and purging of non-self-originated DoNotAge LSAs.
+
+
+
+
+
+
+
+
+Pillay-Esnault               Informational                      [Page 2]
+
+RFC 4136          OSPF Refresh and Flooding Reduction          July 2005
+
+
+4.  Security Considerations
+
+   This memo does not create any new security issues for the OSPF
+   protocol.  Security considerations for the base OSPF protocol are
+   covered in [1].
+
+5.  Acknowledgments
+
+   The author would like to thank Jean-Michel Esnault, Barry Friedman,
+   Thomas Kramer, Acee Lindem, Peter Psenak, Henk Smit, and Alex Zinin
+   for their helpful comments on this work.
+
+6.  Normative References
+
+   [1] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
+
+   [2] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793,
+       April 1995.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pillay-Esnault               Informational                      [Page 3]
+
+RFC 4136          OSPF Refresh and Flooding Reduction          July 2005
+
+
+A.  Configurable Parameters
+
+   This memo defines new configuration parameters for the flooding
+   reduction feature.  The feature must be enabled by configuration on a
+   router and is, by default, off.
+
+    flooding-reduction <all | list of interfaces> Indicates that the
+       router has the flooding reduction feature enabled.  By default,
+       this parameter applies to all interfaces running under the OSPF
+       instance to which it applies.  The feature can be enabled on a
+       subset of explicitly specified interfaces.
+
+    flooding-interval <n minutes> Indicates the interval in minutes for
+       the periodic flooding of self-originated LSAs.  By default, this
+       value is 30 minutes as per [1].  The minimum value is also 30
+       minutes.  A value of infinity will prevent re-flooding of self-
+       originated LSAs that have not changed.
+
+Author's Address
+
+   Padma Pillay-Esnault
+   Cisco Systems
+   170 W. Tasman Drive
+   San Jose, CA  95134
+
+   EMail: ppe@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pillay-Esnault               Informational                      [Page 4]
+
+RFC 4136          OSPF Refresh and Flooding Reduction          July 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   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/SHE 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 procedures with respect to rights in RFC 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.
+
+
+
+
+
+
+
+Pillay-Esnault               Informational                      [Page 5]
+