doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

diff --git a/doc/rfc/rfc7038.txt b/doc/rfc/rfc7038.txt
new file mode 100644
index 0000000..be3c049
--- /dev/null
+++ b/doc/rfc/rfc7038.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          R. Ogier
+Request for Comments: 7038                             SRI International
+Updates: 5614                                               October 2013
+Category: Experimental
+ISSN: 2070-1721
+
+
+            Use of OSPF-MDR in Single-Hop Broadcast Networks
+
+Abstract
+
+   RFC 5614 (OSPF-MDR) extends OSPF to support mobile ad hoc networks
+   (MANETs) by specifying its operation on the new OSPF interface of
+   type MANET.  This document describes the use of OSPF-MDR (MANET
+   Designated Router) in a single-hop broadcast network, which is a
+   special case of a MANET in which each router is a (one-hop) neighbor
+   of each other router.  Unlike an OSPF broadcast interface, such an
+   interface can have a different cost associated with each neighbor.
+   The document includes configuration recommendations and simplified
+   mechanisms that can be used in single-hop broadcast networks.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for examination, experimental implementation, and
+   evaluation.
+
+   This document defines an Experimental Protocol for the Internet
+   community.  This document is a product of the Internet Engineering
+   Task Force (IETF).  It represents the consensus of the IETF
+   community.  It has received public review and has been approved for
+   publication by the Internet Engineering Steering Group (IESG).  Not
+   all documents approved by the IESG are a candidate for any level of
+   Internet Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7038.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ogier                         Experimental                      [Page 1]
+
+RFC 7038        OSPF-MDR in Single-Hop Broadcast Networks   October 2013
+
+
+Copyright Notice
+
+   Copyright (c) 2013 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+1.  Introduction
+
+   OSPF-MDR [RFC5614] specifies an extension of OSPF [RFC2328, RFC5340]
+   to support mobile ad hoc networks (MANETs) by specifying its
+   operation on the new OSPF interface of type MANET.  OSPF-MDR
+   generalizes the Designated Router (DR) to a connected dominating set
+   (CDS) consisting of a typically small subset of routers called MANET
+   Designated Routers (MDRs).  Similarly, the Backup Designated Router
+   (BDR) is generalized to a subset of routers called Backup MDRs
+   (BMDRs).  MDRs achieve scalability in MANETs similar to the way DRs
+   achieve scalability in broadcast networks:
+
+   o  MDRs have primary responsibility for flooding the Link State
+      Advertisements (LSAs). Backup MDRs provide backup flooding when
+      MDRs temporarily fail.
+
+   o  MDRs allow the number of adjacencies to be dramatically reduced by
+      requiring adjacencies to be formed only between MDR/BMDR routers
+      and their neighbors.
+
+   In addition, OSPF-MDR has the following features:
+
+   o  MDRs and BMDRs are elected based on information obtained from
+      modified Hello packets received from neighbors.
+
+   o  If adjacency reduction is used (the default), adjacencies are
+      formed between MDRs so as to form a connected subgraph.  An option
+      (AdjConnectivity = 2) allows for additional adjacencies to be
+      formed between MDRs/BMDRs to produce a biconnected subgraph.
+
+   o  Each non-MDR router becomes adjacent with an MDR called its
+      Parent, and optionally (if AdjConnectivity = 2) becomes adjacent
+      with another MDR or BMDR called its Backup Parent.
+
+
+
+Ogier                         Experimental                      [Page 2]
+
+RFC 7038        OSPF-MDR in Single-Hop Broadcast Networks   October 2013
+
+
+   o  Each router advertises connections to its neighbor routers as
+      point-to-point links in its router-LSA.  Network-LSAs are not
+      used.
+
+   o  In addition to full-topology LSAs, partial-topology LSAs may be
+      used to reduce the size of router-LSAs.  Such LSAs are formatted
+      as standard LSAs, but advertise links to only a subset of
+      neighbors.
+
+   o  Optionally, differential Hellos can be used, which reduce overhead
+      by reporting only changes in neighbor states.
+
+   This document describes the use of OSPF-MDR in a single-hop broadcast
+   network, which is a special case of a MANET in which each router is a
+   (one-hop) neighbor of each other router.  An understanding of
+   [RFC5614] is assumed.  Unlike an OSPF broadcast interface, such an
+   interface can have a different cost associated with each neighbor.
+   An example use case is when the underlying radio system performs
+   layer-2 routing but has a different number of (layer-2) hops to
+   (layer-3) neighbors.
+
+   The rationale for using this interface type for single-hop broadcast
+   networks, instead of a broadcast interface type, is to represent the
+   underlying network in a point-to-multipoint manner, allowing each
+   router to advertise different costs to different neighbors in its
+   router-LSA.  In this sense, this document shows how the OSPF-MDR
+   interface type can be configured (and simplified if desired) to
+   achieve the same goals as the OSPF Hybrid Broadcast and
+   Point-to-Multipoint interface type [RFC6845].
+
+   Section 2 describes the operation of OSPF-MDR in a single-hop
+   broadcast network with recommended parameter settings.  Section 3
+   describes an alternative procedure that may be used to decide which
+   neighbors on a single-hop broadcast network to advertise in the
+   router-LSA.  Section 4 describes a simplified version of the MDR
+   selection algorithm for single-hop networks.
+
+   The alternative procedure of Section 3 and the simplified algorithm
+   of Section 4 are optional and MUST NOT be used if it is possible for
+   two routers in the network to be more than one hop from each other.
+
+1.1.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+
+
+
+
+Ogier                         Experimental                      [Page 3]
+
+RFC 7038        OSPF-MDR in Single-Hop Broadcast Networks   October 2013
+
+
+2.  Operation in a Single-Hop Broadcast Network
+
+   When OSPF-MDR is used in a single-hop broadcast network, the
+   following parameter settings and options (defined in [RFC5614])
+   should be used:
+
+   o  AdjConnectivity SHOULD be equal to 2 (biconnected); this provides
+      the smoothest transition when one router replaces another as MDR,
+      since the set of adjacencies forms a biconnected network that
+      remains connected during the transition.
+
+   o  AdjConnectivity MAY be equal to 1 (uniconnected), resulting in a
+      slightly less smooth transition, since adjacencies must be formed
+      between the new MDR and all of its neighbors.
+
+   o  AdjConnectivity SHOULD NOT be equal to 0 (full topology), since
+      this requires adjacencies to be formed between all pairs of
+      routers, adding unnecessary message overhead.
+
+   o  An adjacency SHOULD be eliminated if neither the router nor the
+      neighbor is an MDR or BMDR (see Section 7.3 of [RFC5614]).
+
+   o  LSAFullness MUST be equal to 4 or 5 if full-topology LSAs are
+      required. (The value 5 is defined in Section 3 of this document.)
+
+   o  LSAFullness MAY be equal to 1 (min-cost LSAs) if full-topology
+      LSAs are not required.  This option reduces the number of
+      advertised links while still providing shortest paths.
+
+   If AdjConnectivity equals 1 or 2 and full-topology LSAs are used,
+   OSPF-MDR running on a single-hop broadcast network has the following
+   properties:
+
+   o  A single MDR is selected, which becomes adjacent with every other
+      router, as in an OSPF broadcast network.
+
+   o  Two BMDRs are selected.  This occurs because the MDR selection
+      algorithm ensures that the MDR/BMDR backbone is biconnected.  If
+      AdjConnectivity = 2, every non-MDR/BMDR router becomes adjacent
+      with one of the BMDRs in addition to the MDR.
+
+   o  When all adjacencies are fully adjacent, the router-LSA for each
+      router includes point-to-point (type 1) links to all bidirectional
+      neighbors (in state 2-Way or greater).
+
+
+
+
+
+
+
+Ogier                         Experimental                      [Page 4]
+
+RFC 7038        OSPF-MDR in Single-Hop Broadcast Networks   October 2013
+
+
+3.  Originating Router-LSAs
+
+   A router running OSPF-MDR with LSAFullness = 4 includes in its
+   router-LSA point-to-point (type 1) links for all fully adjacent
+   neighbors, and for all bidirectional neighbors that are routable.  A
+   neighbor is routable if the SPF calculation has produced a route to
+   the neighbor and a flexible quality condition is satisfied.
+
+   This section describes an alternative procedure that MAY be used
+   instead of the procedure described in Section 6 of [RFC5614], to
+   decide which neighbors on a single-hop broadcast network to advertise
+   in the router-LSA.  The alternative procedure will correspond to
+   LSAFullness = 5, and is interoperable with the other choices for
+   LSAFullness.  This procedure avoids the need to check whether a
+   neighbor is routable, and thus avoids having to update the set of
+   routable neighbors.
+
+   If LSAFullness = 5, then the Selected Advertised Neighbor Set (SANS)
+   is the same as specified for LSAFullness = 4, and the following steps
+   are performed instead of the first paragraph of Section 9.4 in
+   [RFC5614].
+
+   (1) The MDR includes in its router-LSA a point-to-point (type 1) link
+       for each fully adjacent neighbor.  (Note that the MDR becomes
+       adjacent with all of its neighbors.)
+
+   (2) Each non-MDR router includes in its router-LSA a point-to-point
+       link for each fully adjacent neighbor, and, if the router is
+       fully adjacent with the MDR, for each bidirectional neighbor j
+       such that the MDR's router-LSA includes a link to j.
+
+   To provide rationale for the above procedure, let i and j be two
+   non-MDR routers.  Since the SPF calculation (Section 16.1 of
+   [RFC2328]) allows router i to use router j as a next hop only if
+   router j advertises a link back to router i, routers i and j must
+   both advertise a link to each other in their router-LSAs before
+   either can use the other as a next hop.  Therefore, the above
+   procedure for non-MDR routers (Step 2) implies there must exist a
+   path of fully adjacent links between i and j (via the MDR) in both
+   directions before this can happen.  The above procedure for non-MDR
+   routers is similar to one described in Section 4.6 of [RFC6845] for
+   non-DR routers.
+
+
+
+
+
+
+
+
+
+Ogier                         Experimental                      [Page 5]
+
+RFC 7038        OSPF-MDR in Single-Hop Broadcast Networks   October 2013
+
+
+4.  MDR Selection Algorithm
+
+   The MDR selection algorithm of [RFC5614] simplifies as follows in
+   single-hop networks.  The resulting algorithm is similar to the DR
+   election algorithm of OSPF, but is slightly different (e.g., two
+   Backup MDRs are selected).  The following simplified algorithm is
+   interoperable with the full MDR selection algorithm.
+
+   Note that lexicographic order is used when comparing tuples of the
+   form (RtrPri, MDR Level, RID).  Also note that each router will form
+   adjacencies with its Parents and dependent neighbors.  In the
+   following, the term "neighbor" refers to a bidirectional neighbor (in
+   state 2-Way or greater).
+
+   Phase 1: Creating the neighbor connectivity matrix is not required.
+
+   Phase 2: MDR Selection
+
+   (2.1) The set of Dependent Neighbors is initialized to be empty.
+
+   (2.2) If the router has a larger value of (RtrPri, MDR Level, RID)
+         than all of its (bidirectional) neighbors, the router selects
+         itself as an MDR; selects its BMDR neighbors as Dependent
+         Neighbors if AdjConnectivity = 2; then proceeds to Phase 4.
+
+   (2.3) Otherwise, if the router's MDR Level is currently MDR, then it
+         is changed to BMDR before executing Phase 3.
+
+   Phase 3: Backup MDR Selection
+
+   (3.1) Let Rmax be the neighbor with the largest value of (RtrPri, MDR
+         Level, RID).
+
+   (3.2) Determine whether or not there exist two neighbors, other than
+         Rmax, with a larger value of (RtrPri, MDR Level, RID) than the
+         router itself.
+
+   (3.3) If there exist two such neighbors, then the router sets its MDR
+         Level to MDR Other.
+
+   (3.4) Else, the router sets its MDR Level to BMDR, and if
+         AdjConnectivity = 2, adds Rmax and its MDR/BMDR neighbors as
+         Dependent Neighbors.
+
+   (3.5) If steps 3.1 through 3.4 resulted in the MDR Level changing
+         from MDR Other to BMDR, then execute Step 2.2 again before
+         proceeding to Phase 4.  (This is necessary because running Step
+         2.2 again can cause the MDR Level to change to MDR.)
+
+
+
+Ogier                         Experimental                      [Page 6]
+
+RFC 7038        OSPF-MDR in Single-Hop Broadcast Networks   October 2013
+
+
+   Phase 4: Parent Selection
+
+   Each router selects a Parent and (if AdjConnectivity = 2) a Backup
+   Parent for the single-hop broadcast network.  The Parent for a
+   non-MDR router will be the MDR.  The Backup Parent for an MDR Other,
+   if it exists, will be a BMDR.  Each non-MDR router becomes adjacent
+   with its Parent and its Backup Parent, if it exists.  The Parent
+   selection algorithm is already simple, so a simplified version is not
+   given here.
+
+   The Parent and Backup Parent are analogous to the Designated Router
+   and Backup Designated Router interface data items in OSPF.  As in
+   OSPF, these are advertised in the DR and Backup DR fields of each
+   Hello sent on the interface.
+
+5.  Security Considerations
+
+   This document describes the use of OSPF-MDR in a single-hop broadcast
+   network, and raises no security issues in addition to those already
+   covered in [RFC5614].
+
+6.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
+
+   [RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
+              for IPv6", RFC 5340, July 2008.
+
+   [RFC5614]  Ogier, R. and P. Spagnolo, "Mobile Ad Hoc Network (MANET)
+              Extension of OSPF Using Connected Dominating Set (CDS)
+              Flooding", RFC 5614, August 2009.
+
+7.  Informative References
+
+   [RFC6845]  Sheth, N., Wang, L., and J. Zhang, "OSPF Hybrid Broadcast
+              and Point-to-Multipoint Interface Type", RFC 6845, January
+              2013.
+
+Author's Address
+
+   Richard G. Ogier
+   EMail: ogier@earthlink.net
+
+
+
+
+
+
+Ogier                         Experimental                      [Page 7]
+