Movatterモバイル変換

Internet Engineering Task Force (IETF)                          R. OgierRequest for Comments: 7038                             SRI InternationalUpdates:5614                                               October 2013Category: ExperimentalISSN: 2070-1721Use of OSPF-MDR in Single-Hop Broadcast NetworksAbstractRFC 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; seeSection 2 of RFC 5741.   Information about the current status of this document, any errata,   and how to provide feedback on it may be obtained athttp://www.rfc-editor.org/info/rfc7038.Ogier                         Experimental                      [Page 1]

RFC 7038        OSPF-MDR in Single-Hop Broadcast Networks   October 2013Copyright Notice   Copyright (c) 2013 IETF Trust and the persons identified as the   document authors.  All rights reserved.   This document is subject toBCP 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 ofSection 3 and the simplified algorithm   ofSection 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 20132.  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 (seeSection 7.3 of [RFC5614]).   o  LSAFullness MUST be equal to 4 or 5 if full-topology LSAs are      required. (The value 5 is defined inSection 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 20133.  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 inSection 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 ofSection 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 inSection 4.6 of [RFC6845] for   non-DR routers.Ogier                         Experimental                      [Page 5]

RFC 7038        OSPF-MDR in Single-Hop Broadcast Networks   October 20134.  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.netOgier                         Experimental                      [Page 7]