idnits 2.17.1 draft-ogier-ospf-manet-mdr-or-comparison-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 3, 2010) is 4984 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OSPF Working Group R. Ogier 3 Internet-Draft SRI International 4 Intended status: Informational September 3, 2010 5 Expires: March 7, 2011 7 Comparison of OSPF-MDR and OSPF-OR 8 draft-ogier-ospf-manet-mdr-or-comparison-04.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 Copyright Notice 32 Copyright (c) 2010 IETF Trust and the persons identified as the 33 document authors. All rights reserved. 35 This document is subject to BCP 78 and the IETF Trust's Legal 36 Provisions Relating to IETF Documents 37 (http://trustee.ietf.org/license-info) in effect on the date of 38 publication of this document. Please review these documents 39 carefully, as they describe your rights and restrictions with respect 40 to this document. 42 Abstract 44 This document presents a comparison of two proposed MANET extensions 45 of OSPF: OSPF-MDR and OSPF-OR. It includes a simulation comparison 46 and a qualitative comparison, which discusses the different design 47 choices and how they can affect performance and scalability. 49 Table of Contents 51 1 Introduction ................................................. 3 52 2 Brief Overview of OSPF-MDR ................................... 3 53 3 Brief Overview of OSPF-OR .................................... 4 54 4 Qualitative Comparison ....................................... 5 55 4.1 Adjacency Reduction .......................................... 5 56 4.2 Backup Relays ................................................ 6 57 4.3 OSPF-OR Requires a New Bit in the Router-LSA ................. 6 58 4.4 OSPF-OR Does Not Provide Scalable Shortest-Path Routing ...... 6 59 4.5 Using Hellos versus LSAs for 2-Hop Neighbor Information ...... 7 60 4.6 Fundamental Limitation of using MPRs with Smart Peering ...... 8 61 4.7 Complexity ................................................... 8 62 5 Simulation Results ........................................... 9 63 5.1 Comparison Using Partial-Topology LSAs ...................... 9 64 5.2 Effect of External LSAs ..................................... 13 65 5.3 Comparison Using Full-Topology LSAs and Adjacency Reduction . 13 66 5.4 Comparison Using Full-Topology LSAs Without Adjacency 67 Reduction ................................................... 15 68 6 Conclusions ................................................. 18 69 7 Security Considerations ..................................... 19 70 8 IANA Considerations ......................................... 19 71 9 Informative References ...................................... 19 72 A Instructions for Running Simulations ........................ 20 73 A.1 Running OSPF-MDR Simulations ................................ 20 74 A.2 Running OSPF-OR Simulations ................................. 20 75 Author's Address ............................................ 21 77 1. Introduction 79 This document presents a comparison of two proposed MANET extensions 80 of OSPF: OSPF-MDR [OSPF-MDR] and OSPF-OR [OSPF-OR]. It includes a 81 simulation comparison and a qualitative comparison that discusses the 82 different design choices and how they can affect performance and 83 scalability. The conclusions of this document can be summarized as 84 follows: 86 o OSPF-MDR provides an option for partial-topology LSAs that 87 provides routing along shortest (minimum-cost) paths, and is 88 scalable to at least 160 nodes. OSPF-OR does not provide such an 89 option, and therefore does not provide a scalable solution for 90 shortest-path routing. 92 o OSPF-OR requires a modification to the router-LSA packet format 93 when adjacency reduction is used, whereas OSPF-MDR does not. 95 o Simulations show that OSPF-OR forms a much larger number of new 96 adjacencies per second than OSPF-MDR in large mobile networks 97 when both protocols use adjacency reduction. In a scenario with 98 120 nodes, OSPF-OR forms 5.6 times as many adjacencies as 99 OSPF-MDR, resulting in 5.8 times as much overhead from Database 100 Description (DD) packets. Overhead from DD packets can be very 101 substantial if there is a large number of inter-area-prefix-LSAs 102 or AS-external-LSAs. 104 o OSPF-OR has a much larger number of backup relays (called non- 105 active ORs) than OSPF-MDR, which results in greater overhead 106 in large, dense networks due to redundant backup flooding. 108 o When both protocols use adjacency reduction and minimal LSAs 109 (which provide suboptimal routing), simulations show that OSPF-MDR 110 generates much less overhead and is much more scalable than 111 OSPF-OR, achieving good performance in mobile networks with up to 112 200 nodes. In dense, mobile networks, OSPF-MDR generates less 113 overhead with 200 nodes than OSPF-OR generates with 100 nodes. 115 o When both protocols use full-topology LSAs with adjacency 116 reduction, OSPF-MDR still generates significantly less overhead 117 than OSPF-OR with 40 or more nodes, even if OSPF-OR is modified 118 to omit backup flooding. 120 o When both protocols use full-topology LSAs without adjacency 121 reduction, OSPF-MDR performs about the same as OSPF-OR when 122 OSPF-OR is modified to omit backup flooding. 124 2. Brief Overview of OSPF-MDR 126 OSPF-MDR [OSPF-MDR] is based on the selection of generalized 127 designated routers, called MANET designated routers (MDRs), which 128 form a connected dominating set (CDS). MDRs achieve scalability in 129 MANETs similar to the way DRs achieve scalability in broadcast 130 networks: 132 o MDRs have primary responsibility for flooding LSAs. Backup MDRs 133 provide backup flooding when MDRs temporarily fail. 135 o MDRs allow the number of adjacencies to be dramatically reduced, 136 by requiring adjacencies to be formed only between MDR/BMDR 137 routers and their neighbors. 139 Each router decides whether it is an MDR, BMDR, or neither based on 140 2-hop neighbor information obtained from modified Hello packets 141 received from neighbors. Optionally, differential Hellos can be 142 used, which reduce overhead by reporting only changes in neighbor 143 states. 145 In OSPF-MDR, the contents of router-LSAs is flexible. Either 146 partial-topology or full-topology LSAs can be used, either with or 147 without adjacency reduction. Partial-topology LSAs can be used to 148 reduce the size and origination frequency of LSAs while still 149 providing shortest-path routing. OSPF-MDR also allows the option of 150 "minimal LSAs", which minimizes overhead while providing nearly 151 shortest-path routing. 153 3. Brief Overview of OSPF-OR 155 OSPF-OR [OSPF-OR] is based on overlapping relays (OR), which are used 156 to flood LSAs. An OR for a particular router is simply a neighbor 157 that has an adjacent neighbor. Each router selects a subset of its 158 ORs, called active ORs, using 2-hop neighbor information obtained 159 from router-LSAs originated by neighbors. Active ORs are selected to 160 cover all 2-hop neighbors in the adjacency graph, and are equivalent 161 to multipoint relays (MPRs). They are used for initial flooding of 162 LSAs, similar to OLSR [RFC3626] and OSPF-MPR [OSPF-MPR]. Any OR that 163 is not active (not an MPR) is called a non-active OR, and provides 164 backup flooding by flooding a received LSA after PushbackInterval 165 seconds if the LSA, or an ack for the LSA, has not been received by 166 all adjacent neighbors. 168 To allow scalability, OSPF-OR has an option called "smart peering", 169 which reduces the number of adjacencies [Roy06]. If smart peering is 170 used, the router does not form an adjacency with a neighbor if there 171 already exists a path of fully adjacent links from the router to the 172 neighbor. Router-LSAs can include both fully adjacent (synchronized) 173 neighbors and unsynchronized neighbors. If only synchronized 174 neighbors are advertised in router-LSAs, then routing is suboptimal. 175 Any unsynchronized neighbor that is advertised in the router-LSA must 176 be indicated by setting the U-bit, which is a previously unused bit 177 in the link description. The SPF calculation must be run twice, once 178 allowing only synchronized links (to determine which neighbors should 179 be adjacent, and once allowing all links (to compute routes). 181 OSPF-OR with smart peering (denoted OR/SP) allows some or all 182 unsynchronized neighbors to be advertised in the router-LSA. 183 However, it does not specify an algorithm to construct a partial- 184 topology LSA that provides shortest-path routing, unlike OSPF-MDR and 185 OSPF-MPR. (As discussed below, the methods of OSPF-MDR and OSPF-MPR 186 cannot be used in OSPF-OR to provide shortest-path routing without 187 changing packet formats or introducing a new LLS TLV.) Therefore, 188 only two LSA choices are specified in OSPF-OR: minimal LSAs that 189 advertise only synchronized neighbors, and full-topology LSAs that 190 advertise all bidirectional neighbors. 192 We note that the MPRs (active ORs) selected by OR/SP do not provide 193 flooding along min-hop paths, unlike OSPF-MPR, since they are 194 restricted to be adjacent neighbors, and must cover all 2-hop 195 neighbor in the adjacency graph, which is a subgraph of the full 196 topology graph. 198 Like OSPF-MDR, OSPF-OR also provides the option of using differential 199 Hellos, but uses a different method for constructing differential 200 Hellos. Unlike OSPF-MDR, OSPF-OR uses router-LSAs, not Hellos, to 201 obtain 2-hop neighbor information. 203 4. Qualitative Comparison 205 4.1. Adjacency Reduction 207 Even though OR/SP attempts to minimize the number of adjacencies that 208 are formed, it still results in a much larger number of adjacencies, 209 and a much larger number of adjacencies formations per second, than 210 OSPF-MDR in large, dense networks. The number of adjacencies is 211 important because, in both OR/SP and OSPF-MDR, all fully adjacent 212 neighbors must be advertised in partial-topology LSAs (when adjacency 213 reduction is used). The number of adjacency formations per second is 214 important because each adjacency formation incurs a significant 215 amount of overhead due to database exchange. This overhead is 216 proportional to the number of LSAs, and can be very substantial if 217 there is a large number of inter-area-prefix-LSAs or AS-external- 218 LSAs. 220 The simulation results presented below for 120 nodes show that the 221 rate of new adjacencies for OR/SP is 5.6 times that of OSPF-MDR, 222 resulting in 5.8 times as much overhead from Database Description 223 (DD) packets. The results for 120 nodes also show that the average 224 number of adjacencies for OR/SP is 4.6 times that of OSPF-MDR, 225 resulting in much larger LSA overhead when minimal LSAs are used. As 226 a result, OSPF-MDR generates less overhead with 200 nodes than OR/SP 227 generates with 100 nodes, showing that OSPF-MDR is much more 228 scalable. 230 4.2. Backup Relays 232 OSPF-MDR and OSPF-OR both provide backup relays, called Backup MDRs 233 and non-active ORs, respectively. These backup relays perform backup 234 flooding while MDRs or ORs are being updated following topology 235 changes, thus providing robustness by allowing LSAs to be flooded 236 with minimum delay even when link failures occur. 238 An important difference is that in OSPF-OR, the number of backup 239 relays can be very large in dense network, since each OR that is not 240 active (not an MPR) is a backup relay. Although non-active ORs use 241 random jitter to try to avoid having several non-active ORs flood the 242 same LSA, the number of such redundant floods becomes quite 243 significant in large, dense networks, contributing to the larger 244 overhead observed for OSPF-OR in the simulation results presented 245 below. 247 In OSPF-MDR, a minimum number of Backup MDRs are selected to provide 248 biconnected coverage, so that each router is a neighbor of at least 249 two (Backup) MDRs. Biconnected coverage provides sufficient 250 robustness while achieving scalability. Unlike the non-active ORs of 251 OSPF-OR, the number of Backup MDRs does not increase as the number of 252 neighbors (density) increases. 254 4.3. OSPF-OR Requires a New Bit in the Router-LSA 256 OSPF-OR requires a new bit, called the Unsynchronized bit (U-bit), in 257 the link description of the router-LSA. The U-bit must be set for 258 each advertised link corresponding to an unsynchronized neighbor. In 259 addition, a new LSA must be originated even if the only change to the 260 LSA is that an unsynchronized neighbor becomes synchronized (to 261 change the U-bit to zero). 263 This change to the router-LSA format does not appear to cause 264 significant problems. However, there might be a better use for the 8 265 unused bits of the link descriptor in the router-LSA of OSPFv3. 266 Therefore, a solution that avoids modifying the router-LSA, while 267 performing at least as well, would be preferable. OSPF-MDR is such a 268 solution. 270 4.4. OSPF-OR Does Not Provide Scalable Shortest-Path Routing 272 As mentioned above, OSPF-OR specifies only two choices for router- 273 LSAs when smart peering is used: minimal LSAs that advertise only 274 fully adjacent (synchronized) neighbors, and full-topology LSAs that 275 advertise all bidirectional neighbors. 277 In order to provide a scalable solution for shortest-path routing, it 278 is necessary to provide a choice for partial-topology LSAs that 279 provide routing along shortest (minimum-cost) paths. OSPF-MDR 280 achieves this goal with its min-cost LSAs, which perform well in 281 mobile networks with up to 160 nodes (see the simulation results 282 below). Although OSPF-OR can be modified to use min-cost LSAs, this 283 would require a packet format change or a new LLS TLV. It would also 284 require a change to the SPF calculation to remove the requirement 285 that the first link on a path be in the router's Router-LSA, and that 286 the reverse of such a link be in the neighbor's Router-LSA. 288 OSPF-MPR also provides partial-topology LSAs based on "path MPRs", 289 which provide routing along shortest paths. However, the MPRs 290 selected by OSPF-OR do not provide shortest paths when smart peering 291 is used, since they are confined to the adjacency subgraph. OSPF-OR 292 can also be modified to use partial-topology LSAs based on path MPRs, 293 but this would also require a packet format change or a new LLS TLV 294 to indicate path MPRs, and a change to the SPF calculation as 295 mentioned above. 297 In addition, OSPF-MDR allows partial-topology LSAs to be used with 298 full-topology adjacencies. OSPF-OR does not allow this, since it 299 requires each router to advertise all fully adjacent neighbors in its 300 router-LSA. 302 4.5. Using Hellos versus LSAs for 2-Hop Neighbor Information 304 OSPF-MDR selects MDRs using information about each neighbor's 305 neighbors obtained from modified Hello packets received from each 306 neighbor. In contrast, OSPF-OR selects MPRs using similar 307 information obtained from the router-LSA originated by each neighbor. 308 If OSPF-OR uses smart peering (OR/SP), then such information is not 309 full 2-hop information, but is restricted to 2-hop neighbors on the 310 reduced adjacency graph, and MPRs are restricted to the reduced 311 adjacency graph. (Section 4.6 discusses a fundamental limitation of 312 selecting MPRs that are restricted to a reduced adjacency graph). 314 An important advantage of using Hellos to obtain 2-hop neighbor 315 information is that they provide *full* 2-hop neighbor information 316 even when partial-topology LSAs are used. Such information is 317 required for the construction of partial-topology router-LSAs that 318 provide shortest-path routing, as OSPF-MDR provides with its min-cost 319 LSAs. 321 Another possible advantage of using Hellos to obtain 2-hop neighbor 322 information is that Hellos are much smaller than full-topology LSAs, 323 especially if differential Hellos are used. Although it is 324 reasonable to send differential Hellos every 1 or 2 seconds, sending 325 full-topology LSAs that often would generate an excessive amount of 326 overhead in a dense, mobile network. Therefore, it is reasonable to 327 use 5 seconds for MinLSInterval as specified in RFC 2328, resulting 328 in a possible 5 second delay to update MPRs when a topology change 329 occurs. 331 4.6. Fundamental Limitation of using MPRs with Smart Peering 333 If OSPF-OR with smart peering succeeded in selecting the minimum 334 number of adjacencies, which would form a tree with n-1 links, then 335 every adjacent neighbor that is not a leaf of the adjacency tree 336 would have to be an MPR (since it provides the only 2-hop path to 337 some 2-hop neighbor on the tree). Unless the adjacency tree has a 338 large number of leaves and very few interior nodes (which is the case 339 with OSPF-MDR, since each interior node is an MDR), this will result 340 in a large number of transmissions to flood each LSA. However, smart 341 peering results in far more than the minimum number of adjacencies 342 (as shown in the simulation results), which therefore avoids the 343 above problem at the expense of additional overhead resulting from 344 having to form a larger number of adjacencies. The MDR/CDS approach 345 avoids this tradeoff by minimizing the number of interior nodes 346 (MDRs) as well as selecting nearly the minimum number of adjacencies. 347 This explains why OSPF-MDR can scale to 200 nodes, unlike OSPF-OR, 348 which generates more overhead with 100 nodes than OSPF-MDR generates 349 with 200 nodes (as shown in the simulation results). 351 The above limitation is illustrated by a 50-node example in the slide 352 presentation "Comparison of Three MANET Extensions of OSPF", 353 available at http://www.manet-routing.org. 355 4.7. Complexity 357 The OSPF-MDR draft is significantly longer than the OSPF-OR draft, 358 but the additional length is justified because it provides more 359 features, more options, and better performance/scalability, as 360 discussed in this section. 362 The calculation of relays (MDRs or MPRs) has about the same 363 complexity in both drafts, with both algorithms requiring O(d^2) time 364 where d is the number of neighbors. 366 As discussed above, OSPF-OR considers any non-active OR to be a 367 backup relay, which does not require additional computation. 368 However, this results in a large number of backup relays, which 369 increases overhead and limits scalability as discussed above. OSPF- 370 MDR can similarly consider any non-MDR to be a backup relay, but 371 provides the option of selecting Backup MDRs more intelligently, to 372 provide biconnected coverage while achieving scalability. The 373 algorithm for selecting Backup MDRs also runs in O(d^2), and an 374 optional, simplified version of the algorithm is also specified. 376 OSPF-MDR provides the option of biconnected adjacencies, which may 377 improve robustness in some scenarios. OSPF-OR does not specify an 378 algorithm for biconnected adjacencies. 380 OSPF-OR with smart peering requires that two different SPF 381 calculations be performed: one allowing only synchronized links and 382 one allowing both synchronized and unsynchronized links. OSPF-MDR 383 does not distinguish between synchronized and unsynchronized links in 384 the SPF calculation. 386 As mentioned above, OSPF-MDR provides partial-topology LSAs that 387 provide routing along shortest paths, which OSPF-OR does not provide. 388 Thus, OSPF-OR does not provide a scalable solution for shortest-path 389 routing, which is a very important capability. In addition, OSPF-MDR 390 allows partial-topology LSAs to be used with full-topology 391 adjacencies, unlike OSPF-OR. 393 5. Simulation Results 395 This section presents simulation results that compare the performance 396 of OSPF-MDR and OSPF-OR, using the GTNetS OSPFv3 MANET simulator. 397 The results for OSPF-MDR were obtained using the GTNetS simulator 398 with OSPF-MDR version 1.01, available at 399 http://hipserver.mct.phantomworks.org/ietf/ospf. The results for 400 OSPF-OR were obtained using the same GTNetS code used for the 401 MILCOM'06 paper [MILCOM06] by Spagnolo and Henderson, modified to use 402 the database exchange optimization of [RFC5243] (since OSPF-MDR uses 403 this optimization). Instructions for downloading this code and 404 running the simulations presented here are given in Appendix A. (The 405 OSPF-MDR code used for the MILCOM'06 paper is not compliant with the 406 current version of the OSPF-MDR draft, and contains some bugs that 407 have been fixed in version 1.01.) 409 The following scenario parameter values were used: radio range = 250 410 m and 200 m, grid length = 500 m, wireless alpha = 0.5, (maximum) 411 velocity = 10 m/s, pause time = 0, packet rate = 10 pkts/s, packet 412 size = 40 bytes, random seed = 8, start time (for gathering 413 statistics) = 1800 s. The stop time was 3600 s for up to 80 nodes 414 and 2700 s for more than 80 nodes. The source and destination are 415 selected randomly for each generated UDP packet. The simulated MAC 416 protocol is 802.11b. 418 The following protocol parameter values were used for both protocols: 419 HelloInterval = 2 s, DeadInterval = 6 s, RxmtInterval = 7 s, 420 MinLSInterval = 5 s, MinLSArrival = 1 s, AckInterval = 1 s. 421 Differential hellos were used in both protocols. For OSPF-OR, 422 PushbackInterval was set to 3 s, since the draft specifies that it 423 must be less than 1/2 RxmtInterval. All other parameters of OSPF-MDR 424 were set to their default values. 426 5.1. Comparison Using Partial-Topology LSAs 428 The first set of experiments focused on scalability, and thus used 429 partial-topology LSAs and adjacency reduction. The following three 430 protocol configurations were compared: (1) OSPF-MDR with uniconnected 431 adjacencies and minimal LSAs, (2) OSPF-OR with smart peering (OR/SP) 432 and minimal LSAs, and (3) OSPF-MDR with uniconnected adjacencies and 433 min-cost LSAs. As mentioned above, OSPF-OR does not provide an 434 option for partial-topology LSAs that provides shortest-path routing. 436 5.1.1. Results for Dense Networks 438 The results for the three configurations with range equal to 250 m 439 are shown in Tables 1, 2, and 3, respectively. The tables show the 440 results for total OSPF overhead in kb/s, the overhead for DD packets, 441 the average number of fully adjacent neighbors per node, the number 442 of changes in the set of fully adjacent neighbors per node per 443 second, the delivery ratio for UDP packets, and the average number of 444 hops traveled by UDP packets that reach their destination. 446 OSPF-MDR generated much less overhead than OR/SP, especially in large 447 networks. For 120 nodes, OR/SP generated about 6.5 times as much 448 overhead as OSPF-MDR. OSPF-MDR generated less overhead for 200 nodes 449 than OR/SP generated for 100 nodes. 451 For 120 nodes, OR/SP formed 5.6 times as many adjacencies per second 452 as OSPF-MDR, resulting in 5.8 times as much overhead from DD packets. 453 As shown in Section 5.2, overhead from DD packets can be very 454 substantial if there is a large number of inter-area-prefix-LSAs or 455 AS-external-LSAs. 457 The delivery ratio is significantly larger for OSPF-MDR, especially 458 in larger networks (.960 versus .941 for 100 nodes, and .962 versus 459 .935 for 120 nodes). The average number of hops is larger for OR/SP 460 because, unlike OSPF-MDR, it does not allow a neighbor to be a next 461 hop unless it is advertised in the router-LSA. (The specification 462 for OR/SP can be modified to allow this, but this is an indication 463 that OR/SP is not yet stable.) 465 Differential Hellos were used in both protocols, and OSPF-MDR was 466 found to generate about half as much overhead from Hello packets as 467 OR/SP in large networks, indicating that the differential Hello 468 method of OSPF-MDR is more efficient. 470 Number of nodes 40 80 120 160 200 471 ---------------------------------------------------------------- 472 OSPF overhead (kb/s) 41.65 132.88 246.31 418.96 637.45 473 DD overhead (kb/s) 8.12 34.48 64.53 120.70 210.33 474 Adjacencies/node 2.32 2.26 2.25 2.32 2.13 475 Adj changes/node/sec 0.036 0.040 0.032 0.035 0.039 476 Delivery ratio 0.968 0.953 0.962 0.956 0.951 477 Avg no. hops 1.387 1.412 1.407 1.430 1.411 479 Table 1. Results for OSPF-MDR with minimal LSAs for range 250 m. 481 Number of nodes 40 60 80 100 120 482 --------------------------------------------------------------- 483 OSPF Overhead (kb/s) 90.09 238.12 521.90 916.83 1615.57 484 DD overhead (kb/s) 12.92 41.75 98.69 183.51 376.82 485 Adjacencies/node 6.81 7.31 9.17 10.04 10.42 486 Adj changes/node/sec 0.06 0.09 0.11 0.14 0.18 487 Delivery ratio 0.961 0.945 0.940 0.941 0.935 488 Avg no. hops 2.282 2.361 2.358 2.386 2.452 490 Table 2. Results for OR/SP with minimal LSAs for range 250 m. 492 As shown in Table 3, OSPF-MDR with min-cost LSAs still generated much 493 less overhead than OR/SP with minimal LSAs. In fact, OSPF-MDR with 494 min-cost LSAs generated less overhead for 160 nodes than OR/SP with 495 minimal LSAs generated for 100 nodes. 497 Number of nodes 40 60 80 100 120 160 498 -------------------------------------------------------------------- 499 OSPF overhead (kb/s) 74.17 175.31 248.55 354.60 479.17 795.73 500 DD overhead (kb/s) 8.14 23.50 35.00 42.66 76.01 121.42 501 Adjacencies/node 2.44 2.45 2.28 2.17 2.34 2.28 502 Adj changes/node/sec 0.037 0.047 0.040 0.029 0.037 0.035 503 Delivery ratio 0.968 0.954 0.958 0.957 0.956 0.953 504 Avg no. hops 1.348 1.389 1.368 1.411 1.361 1.386 506 Table 3. Results for OSPF-MDR with min-cost LSAs for range 250 m. 508 Backup flooding generates a substantial amount of additional overhead 509 in OR/SP. Table 4 shows the results for OR/SP if it were modified to 510 omit backup flooding. (Backup flooding is required in the 511 specification.) With this modification, OR/SP still generated about 512 4.3 times as much overhead as OSPF-MDR with 120 nodes; and OSPF-MDR 513 generated much less overhead with 200 nodes than OR/SP generated with 514 120 nodes (when both protocols use minimal LSAs). 516 Number of nodes 40 60 80 100 120 517 ----------------------------------------------------------------- 518 OSPF Overhead (kb/s) 74.58 191.13 357.62 617.45 1049.29 519 Delivery ratio 0.962 0.942 0.942 0.935 0.935 520 Avg no. hops 2.236 2.341 2.360 2.462 2.393 522 Table 4. Results for OR/SP with minimal LSAs, modified to omit 523 backup flooding, for range 250 m. 525 5.1.2. Results for Sparser Networks 527 Tables 5 through 8 show the results for OSPF-MDR and OR/SP with the 528 same configurations as above, but with the range equal to 200 m. The 529 trend is similar to the results for range 250 m. Again, OSPF-MDR 530 generated much less overhead than OR/SP, especially in large 531 networks. For 120 nodes, OR/SP generated about 6.4 times as much 532 overhead as OSPF-MDR. OSPF-MDR generated less overhead with 200 533 nodes than OR/SP generated with 100 nodes. 535 As shown in Table 7, OSPF-MDR with min-cost LSAs still generated much 536 less overhead than OR/SP with minimal LSAs. 538 Number of nodes 40 80 120 160 200 539 ---------------------------------------------------------------- 540 OSPF overhead (kb/s) 63.62 195.24 346.86 573.22 824.56 541 DD overhead (kb/s) 15.81 60.20 112.90 202.58 316.00 542 Adjacencies/node 2.60 2.50 2.39 2.36 2.24 543 Adj changes/node/sec 0.069 0.068 0.055 0.058 0.057 544 Delivery ratio 0.927 0.907 0.907 0.904 0.902 545 Avg no. hops 1.714 1.743 1.727 1.758 1.747 547 Table 5. Results for OSPF-MDR with minimal LSAs for range 200 m. 549 Number of nodes 40 60 80 100 120 550 --------------------------------------------------------------- 551 OSPF Overhead (kb/s) 124.17 340.41 674.56 1138.24 2230.07 552 DD overhead (kb/s) 22.93 74.70 153.28 284.64 657.07 553 Adjacencies/node 5.25 6.22 7.36 7.69 8.56 554 Adj changes/node/sec 0.10 0.15 0.17 0.19 0.28 555 Delivery ratio 0.908 0.865 0.875 0.872 0.870 556 Avg no. hops 2.863 2.799 2.753 2.843 2.827 558 Table 6. Results for OR/SP with minimal LSAs for range 200 m. 560 Number of nodes 40 60 80 100 120 160 561 ------------------------------------------------------------------- 562 OSPF overhead (kb/s) 123.45 286.40 415.69 597.50 788.87 1309.78 563 DD overhead (kb/s) 15.04 44.60 62.20 81.45 120.05 213.63 564 Adjacencies/node 2.53 2.72 2.58 2.32 2.37 2.41 565 Adj changes/node/sec 0.065 0.085 0.068 0.055 0.057 0.060 566 Delivery ratio 0.919 0.897 0.900 0.898 0.895 0.892 567 Avg no. hops 1.628 1.666 1.632 1.683 1.608 1.641 569 Table 7. Results for OSPF-MDR with min-cost LSAs for range 200 m. 571 Table 8 shows the results for OR/SP if it were modified to omit 572 backup flooding. Even with this modification, OR/SP still generates 573 much more overhead with 120 nodes than OSPF-MDR generates with 200 574 nodes (when both protocols use minimal LSAs). 576 Number of nodes 40 60 80 100 120 577 ----------------------------------------------------------------- 578 OSPF Overhead (kb/s) 104.68 258.88 480.48 811.72 1379.50 579 Delivery ratio 0.892 0.870 0.881 0.874 0.872 580 Avg no. hops 2.730 2.747 2.760 2.860 2.769 582 Table 8. Results for OR/SP with minimal LSAs, modified to omit 583 backup flooding, for range 200 m. 585 5.2. Effect of External LSAs 587 The above simulation results are for a single area, and they assume 588 there are no LSAs originating from outside the area, such as inter- 589 area-prefix-LSAs or AS-external LSAs. If such LSAs existed, they 590 would add to the database exchange overhead even if they are static 591 (never change). We can estimate this additional overhead, using the 592 results for the adjacency change rate when adjacency reduction is 593 used. First, since only half of the adjacency changes are adjacency 594 formations (the other half being adjacency eliminations), we must 595 divide the adjacency change rate by 2. Since the database exchange 596 optimization of [RFC5243] is used, each LSA is listed in a DD packet 597 by only one of the two neighbors forming the adjacency. Therefore, 598 we must again divide by 2. Since a separate inter-area-prefix-LSA is 599 required for each prefix, and each LSA header is 20 bytes, the amount 600 of additional overhead required for M such prefixes when there are N 601 nodes is 603 (M * N * adjacency change rate / 4) * 20 bytes/s 605 Applying this formula to the results in Tables 1 and 2 for 120 nodes, 606 the additional overhead for OSPF-MDR with min-cost LSAs is (M * 120 * 607 .032 / 4) * 20 = 19.2*M bytes/s, and the additional overhead for 608 OSPF-OR is (M * 120 * .18 / 4) * 20 = 108*M bytes/s. For example, if 609 there are 1000 external prefixes, then the additional overhead for 610 OSPF-MDR is about 19,200 bytes/s or 153.6 kb/s, and the additional 611 overhead for OSPF-OR is about 108,000 bytes/s or 864 kb/s. Thus, 612 OSPF-MDR is also much more scalable than OSPF-OR with respect to the 613 number of external prefixes, because of its smaller adjacency change 614 rate. 616 5.3. Comparison Using Full-Topology LSAs and Adjacency Reduction 618 5.3.1. Results for Dense Networks 620 Tables 9 and 10 show the results for OSPF-MDR and OR/SP with the same 621 configurations as above except that both protocols use full-topology 622 LSAs. For 80 nodes, OR/SP generated almost twice as much overhead as 623 OSPF-MDR. 625 Table 11 shows the results for OR/SP if it were modified to omit 626 backup flooding. Even without backup flooding, OR/SP generated 42% 627 more overhead than OSPF-MDR for 80 nodes. 629 The average number of hops is about 3% larger for OSPF-MDR because 630 the implementation imposes an optional stricter condition on a new 631 neighbor before its state can change from Down to Init or greater, as 632 specified in Section 4.3 of [OSPF-MDR]. This condition requires two 633 consecutive Hellos to be received from a new neighbor. When this 634 stricter condition is removed, the average number of hops for OSPF- 635 MDR is within 1% of that for OR/SP. 637 Number of nodes 20 40 60 80 638 -------------------------------------------------------- 639 OSPF overhead (kb/s) 37.76 162.17 447.00 889.97 640 DD overhead (kb/s) 2.07 3.39 24.63 35.46 641 Adjacencies/node 2.42 2.38 2.45 2.31 642 Adj changes/node/sec 0.032 0.037 0.050 0.040 643 Delivery ratio 0.968 0.962 0.952 0.953 644 Avg no. hops 1.427 1.337 1.379 1.362 646 Table 9. Results for OSPF-MDR with full LSAs for range 250 m. 648 Number of nodes 20 40 60 80 649 -------------------------------------------------------- 650 OSPF overhead (kb/s) 52.88 308.24 843.46 1762.99 651 DD overhead (kb/s) 2.63 14.34 47.20 111.01 652 Adjacencies/node 4.23 6.83 7.22 8.58 653 Adj changes/node/sec 0.04 0.07 0.10 0.12 654 Delivery ratio 0.962 0.960 0.947 0.945 655 Avg no. hops 1.380 1.300 1.339 1.321 657 Table 10. Results for OR/SP with full LSAs for range 250 m. 659 Number of nodes 20 40 60 80 660 -------------------------------------------------------- 661 OSPF overhead (kb/s) 41.19 240.53 621.49 1268.07 662 Delivery ratio 0.960 0.961 0.948 0.949 663 Avg no. hops 1.380 1.302 1.338 1.323 665 Table 11. Results for OR/SP with full LSAs, modified to omit 666 backup flooding, for range 250 m. 668 5.3.2. Results for Sparser Networks 670 Tables 12 and 13 show the results for OSPF-MDR and OR/SP with the 671 same configurations as above (using full-topology LSAs), but with the 672 range equal to 200 m. For 80 nodes, OR/SP generated 92% more 673 overhead than OSPF-MDR. In addition, the delivery ratio is about 2% 674 higher for OSPF-MDR than for OR/SP. 676 Again, the average number of hops is slightly larger for OSPF-MDR 677 because the implementation imposes an optional stricter condition on 678 a new neighbor before its state can change from Down to Init or 679 greater. 681 Table 14 shows the results for OR/SP if it were modified to omit 682 backup flooding. Even without backup flooding, OR/SP generated about 683 30% more overhead than OSPF-MDR for 80 nodes. 685 Number of nodes 20 40 60 80 686 -------------------------------------------------------- 687 OSPF overhead (kb/s) 45.39 200.55 542.98 1013.44 688 DD overhead (kb/s) 4.82 15.45 42.24 64.05 689 Adjacencies/node 2.76 2.60 2.74 2.53 690 Adj changes/node/sec 0.069 0.066 0.081 0.071 691 Delivery ratio 0.924 0.919 0.904 0.897 692 Avg no. hops 1.779 1.611 1.656 1.616 694 Table 12. Results for OSPF-MDR with full LSAs for range 200 m. 696 Number of nodes 20 40 60 80 697 -------------------------------------------------------- 698 OSPF overhead (kb/s) 59.66 341.25 920.92 1945.31 699 DD overhead (kb/s) 4.59 23.94 76.85 178.59 700 Adjacencies/node 3.81 5.47 6.34 7.24 701 Adj changes/node/sec 0.07 0.11 0.14 0.18 702 Delivery ratio 0.905 0.907 0.876 0.874 703 Avg no. hops 1.666 1.518 1.552 1.522 705 Table 13. Results for OR/SP with full LSAs for range 200 m. 707 Number of nodes 20 40 60 80 708 -------------------------------------------------------- 709 OSPF overhead (kb/s) 42.86 241.16 647.75 1311.61 710 Delivery ratio 0.910 0.901 0.881 0.877 711 Avg no. hops 1.682 1.515 1.555 1.525 713 Table 14. Results for OR/SP with full LSAs, modified to omit 714 backup flooding, for range 200 m. 716 5.4. Comparison Using Full-Topology LSAs Without Adjacency Reduction 718 Although OSPF-MDR allows the option of using full-topology 719 adjacencies (i.e., not using adjacency reduction), this option is not 720 recommended, especially in dense networks, because it generates a 721 large amount of unnecessary overhead by forming a large number of 722 unnecessary adjacencies. (For the same reason, OSPF does not form 723 adjacencies between all pairs of routers attached to a broadcast 724 network.) However, some users may decide not to use adjacency 725 reduction in sparse networks. Therefore, results for full-topology 726 adjacencies are presented with the range equal to 200 m and 150 m. 728 In this set of experiments, OSPF-MDR did not impose the optional 729 stricter condition that requires two consecutive Hellos to be 730 received from a new neighbor before its state can change to Init or 731 greater. This allows the average number of hops traveled by UDP 732 packets to be compared on a fair basis. (Instructions for modifying 733 the code to omit this stricter condition are given in the appendix.) 735 In addition to overhead, delivery ratio, and average number of hops 736 traveled by UDP packets, the results also include the average end-to- 737 end delay for UDP packets and the average number of LSAs requested by 738 a router during database exchange. The latter measure indicates how 739 well routers maintain synchronized databases. 741 5.4.1. Results for Radio Range 200 m 743 Tables 15 through 17 show the results for full-topology LSAs and no 744 adjacency reduction, for range 200 m. Table 15 shows the results for 745 OSPF-MDR, and Tables 16 and 17 show the results for OSPF-OR with and 746 without backup flooding, respectively. The performance of OSPF-MDR 747 is close to that of OSPF-OR without backup flooding. However, OSPF- 748 OR with backup flooding generates significantly more overhead than 749 OSPF-MDR. For 60 nodes, OSPF-OR with backup flooding generates about 750 70% more overhead than OSPF-MDR, and has a significantly larger 751 average end-to-end delay for UDP packets due to congestion. 753 The average number of LSAs requested by a router during database 754 synchronization is significantly larger for OSPF-OR than for OSPF- 755 MDR, showing that OSPF-MDR does a better job of maintaining 756 synchronized databases. As shown in Table 17, the average number of 757 requested LSAs becomes even larger for OSPF-OR when backup flooding 758 is not used. 760 Number of nodes 20 40 60 761 ---------------------------------------------- 762 OSPF overhead (kb/s) 68.35 400.58 1282.05 763 Delivery ratio 0.924 0.920 0.900 764 Avg no. hops 1.778 1.608 1.695 765 Avg delay (msec) 13.41 16.94 46.78 766 Avg # LSAs requested 0.61 0.51 0.59 768 Table 15. Results for OSPF-MDR with full LSAs and no adjacency 769 reduction, for range 200 m. 771 Number of nodes 20 40 60 772 ----------------------------------------------- 773 OSPF overhead (kb/s) 84.58 593.01 2188.44 774 Delivery ratio 0.927 0.920 0.900 775 Avg no. hops 1.795 1.619 1.738 776 Avg delay (msec) 13.36 17.09 65.49 777 Avg # LSAs requested 0.83 0.73 0.74 779 Table 16. Results for OSPF-OR with full LSAs and no adjacency 780 reduction, for range 200 m. 782 Number of nodes 20 40 60 783 ----------------------------------------------- 784 OSPF overhead (kb/s) 65.87 405.50 1323.53 785 Delivery ratio 0.925 0.924 0.903 786 Avg no. hops 1.794 1.619 1.718 787 Avg delay (msec) 13.09 16.64 50.69 788 Avg # LSAs requested 1.12 0.93 0.88 790 Table 17. Results for OSPF-OR with full LSAs and no adjacency 791 reduction, modified to omit backup flooding, for range 200. 793 5.4.2. Results for Radio Range 150 m 795 Tables 18 through 20 show the results for full-topology LSAs and no 796 adjacency reduction, for range 150 m. Again, the performance of 797 OSPF-MDR is close to that of OSPF-OR without backup flooding, and 798 OSPF-OR with backup flooding generates significantly more overhead 799 than OSPF-MDR. 801 Number of nodes 20 40 60 802 ---------------------------------------------- 803 OSPF overhead (kb/s) 52.29 350.72 1020.73 804 Delivery ratio 0.772 0.834 0.802 805 Avg no. hops 2.365 2.024 2.090 806 Avg delay (msec) 19.25 19.91 34.09 807 Avg # LSAs requested 1.06 0.581 0.54 809 Table 18. Results for OSPF-MDR with full LSAs and no adjacency 810 reduction, for range 150 m. 812 Number of nodes 20 40 60 813 ----------------------------------------------- 814 OSPF overhead (kb/s) 61.34 479.43 1513.51 815 Delivery ratio 0.752 0.838 0.799 816 Avg no. hops 2.354 2.046 2.102 817 Avg delay (msec) 17.70 20.04 35.40 818 Avg # LSAs requested 1.56 0.81 0.68 820 Table 19. Results for OSPF-OR with full LSAs and no adjacency 821 reduction, for range 150 m. 823 Number of nodes 20 40 60 824 ----------------------------------------------- 825 OSPF overhead (kb/s) 51.30 352.85 1039.89 826 Delivery ratio 0.755 0.840 0.808 827 Avg no. hops 2.355 2.044 2.107 828 Avg delay (msec) 18.02 19.12 31.73 829 Avg # LSAs requested 1.89 1.06 0.81 831 Table 20. Results for OSPF-OR with full LSAs and no adjacency 832 reduction, modified to omit backup flooding, for range 150. 834 6. Conclusions 836 OSPF-MDR is much more scalable than OSPF-OR, achieving good 837 performance in mobile networks with 200 nodes using minimal LSAs, and 838 160 nodes using min-cost LSAs (which provide shortest-path routing). 839 OSPF-OR does not provide partial-topology LSAs that provide shortest- 840 path routing. When both protocols use minimal LSAs, OSPF-OR 841 generates more overhead with 100 nodes than OSPF-MDR generates with 842 200 nodes. If OSPF-OR is modified to omit backup flooding, it still 843 generates much more overhead with 120 nodes than OSPF-MDR generates 844 with 200 nodes. 846 When both protocols use full-topology LSAs with adjacency reduction, 847 OSPF-OR still generates significantly more overhead than OSPF-MDR 848 with 40 or more nodes, even if OSPF-OR is modified to omit backup 849 flooding. 851 When both protocols use full-topology LSAs and full-topology 852 adjacencies (no adjacency reduction), OSPF-OR generates about the 853 same amount of overhead as OSPF-MDR when backup flooding is omitted, 854 but generates significantly more overhead than OSPF-MDR with 40 or 855 more nodes when backup flooding is used. 857 OSPF-OR did not perform significantly better than OSPF-MDR in any of 858 the scenarios considered. 860 OSPF-MDR is also much more scalable than OSPF-OR with respect to the 861 number of external prefixes, because it forms a much smaller number 862 of new adjacencies per second. (For 120 nodes, OSPF-OR with smart 863 peering forms about 5.6 times as many new adjacencies as OSPF-MDR.) 864 Such prefixes add to the database exchange overhead even if they are 865 static (never change). 867 We tested one implementation of OSPF-OR, using parameters that are 868 the same as for OSPF-MDR when possible, and that are compliant with 869 the OSPF-OR draft. It may be possible to improve the performance of 870 OSPF-OR by modifying the code, but the best available code was used 871 that is compliant with the draft. One such modification was tested 872 by omitting backup flooding to reduce overhead, but the resulting 873 overhead was still significantly larger than for OSPF-MDR except in 874 small networks and when both protocols use full-topology LSAs without 875 adjacency reduction. 877 Even if performance can be improved to be close to that of OSPF-MDR, 878 OSPF-OR does not provide a scalable solution for shortest-path 879 routing (using partial-topology LSAs), and modifying OSPF-OR to 880 provide this important capability would require major changes to the 881 specification. 883 Although the OSPF-MDR draft is significantly longer than the OSPF-OR 884 draft, the additional length is justified because it provides more 885 options and capabilities, in addition to achieving better performance 886 and scalability. 888 Additional information and resources for OSPF-MDR can be found at 889 http://www.manet-routing.org. 891 7. Security Considerations 893 This document does not raise any new security concerns. 895 8. IANA Considerations 897 This document has no actions for IANA. 899 9. Informative References 901 [MILCOM06] Spagnolo, P.A. and T.R. Henderson, "Comparison of Proposed 902 OSPF MANET Extensions", Proc. IEEE MILCOM 2006, October 2006. 904 [OSPF-MDR] Ogier, R. and P. Spagnolo, "Mobile Ad Hoc Network (MANET) 905 Extension of OSPF Using Connected Dominating Set (CDS) 906 Flooding", RFC 5614, August 2009. 908 [OSPF-MPR] Baccelli, E., P. Jacquet, D. Nguyen, and T. Clausen, "OSPF 909 Multipoint Relay (MPR) Extension for Ad Hoc Networks", RFC 5449, 910 February 2009. 912 [OSPF-OR] Roy, A. (Ed.) and M. Chandra (Ed.), "Extensions to OSPF to 913 Support Mobile Ad Hoc Networking", RFC 5820, March 2010. 915 [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State 916 Routing Protocol", RFC 3626, October 2003. 918 [RFC5243] Ogier, R., "OSPF Database Exchange Summary List 919 Optimization", RFC 5243, May 2008. 921 [Roy06] Roy, A. (ed.), "Adjacency Reduction in OSPF using SPT 922 Reachability", draft-roy-ospf-smart-peering-01.txt (work in 923 progress), November 2005. 925 A. Instructions for Running Simulations 927 A.1. Running OSPF-MDR Simulations 929 The results for OSPF-MDR were obtained using the GTNetS simulator 930 with OSPF-MDR version 1.01, available at 931 http://hipserver.mct.phantomworks.org/ietf/ospf. 933 The command used for 20 nodes, radio range 250, min-cost LSAs, and 934 uniconnected adjacencies is as follows: 936 ./random_waypoint_manet-opt seed=8 num_nodes=20 pktrate=10 \ 937 velocity=10 pause_time=0 radio_range=250 alpha=0.5 \ 938 HelloInterval=2 RxmtInterval=7 DeadInterval=6 AckInterval=1000 \ 939 BackupWaitInterval=500 TwoHopRefresh=3 AdjConnectivity=1 \ 940 LSAFullness=1 diff_hellos start_time=1800 stop_time=3600 942 For the different scenarios, num_nodes varied from from 20 to 200; 943 radio_range was 150, 200, and 250; LSAFullness was 0 for minimal 944 LSAs, 1 for min-cost LSAs, and 4 for full LSAs; AdjConnectivity was 1 945 for uniconnected adjacencies and 0 for full-topology adjacencies; 946 stop_time was set to 2700 when num_nodes was 100 or larger. 948 A.2. Running OSPF-OR Simulations 950 The results for OSPF-OR were obtained using the GTNetS code that was 951 used for the paper [MILCOM06]. A link for this code is given in the 952 slide presentation "Comparison of Three MANET Extensions of OSPF", 953 available at www.manet-routing.org. (The OSPF-MDR code contained in 954 this code is not compliant with the current version of the OSPF-MDR 955 draft and contains some bugs.) 957 To activate the database exchange optimization of RFC 5243, uncomment 958 the following line in Makefile in the gtnets-milcom06 directory: 960 CFLAGS += -DOSPF6_MANET_MDR_FLOOD_DD 962 The command used for 40 nodes, radio range 250, using smart peering 963 and minimal LSAs, is as follows: 965 ./random_waypoint_manet-opt seed=8 num_nodes=40 pktrate=10 \ 966 wireless_interface=2 wireless_flooding=1 velocity=10 pause_time=0 \ 967 radio_range=250 alpha=0.5 HelloInterval=2 RxmtInterval=7 \ 968 DeadInterval=6 PushbackInterval=3000 AckInterval=1000 \ 969 MinLSInterval=5 SmartPeering diff_hellos \ 970 start_time=1800 stop_time=3600 972 For the different scenarios, num_nodes varied from from 20 to 120; 973 radio_range was 150, 200, and 250; stop_time was set to 2700 when 974 num_nodes was 100 or larger. To use full-topology LSAs (including 975 unsynchronized neighbors) with smart peering, the argument 976 "UnsynchAdj" is added. To use full-topology adjacencies, the 977 arguments "SmartPeering" and "UnsynchAdj" are both omitted. 979 For the scenarios in which backup flooding was omitted, the code was 980 modified by commenting out the following line in the function 981 ospf6_flood_interface_mpr() in the file ospf6_flood.c (and 982 recompiling): 984 ospf6_pushback_lsa_add(lsa, on); 986 Author's Address 988 Richard G. Ogier 989 Email: rich.ogier@earthlink.net