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

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/