idnits 2.17.1 draft-spagnolo-manet-ospf-wireless-interface-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 592: '...od. The MPR set MUST be calculated by...' RFC 2119 keyword, line 605: '...R nodes. A node SHOULD select an MPR ...' RFC 2119 keyword, line 661: '...n implementation MAY select the node a...' RFC 2119 keyword, line 807: '...calculating node MUST be stored in the...' RFC 2119 keyword, line 811: '...the Wireless Hello it MUST be removed....' (9 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 323 has weird spacing: '...ference being...' == Line 355 has weird spacing: '... Packet name ...' -- 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 (May 12, 2004) is 7289 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '5' on line 225 -- Possible downref: Normative reference to a draft: ref. 'Bak02' -- Possible downref: Normative reference to a draft: ref. 'Bak03' -- Possible downref: Non-RFC (?) normative reference: ref. 'Hen03' ** Downref: Normative reference to an Experimental RFC: RFC 3626 (ref. 'OLSR') Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft J. Ahrenholz 3 Mobile Ad Hoc and OSPF Working Groups T. Henderson 4 Expires: November 2005 P. Spagnolo 5 Boeing 7 E. Baccelli 8 T. Clausen 9 P. Jacquet 10 INRIA 12 May 12, 2004 14 OSPFv2 Wireless Interface Type 16 draft-spagnolo-manet-ospf-wireless-interface-01 18 Status of this Memo 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC 2026. 23 Internet Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Abstract 41 This draft defines enhancements to the OSPFv2 protocol to support a 42 new interface type for wireless, broadcast-capable, multi-hop 43 networks. This interface type uses an unreliable flooding mechanism 44 to distribute LSAs within a wireless subnet. This draft also defines 45 rules for LSA distribution for edge routers that may have a mix of 46 interface types on different subnets. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 51 1.1. Summary of Changes . . . . . . . . . . . . . . . . . . . . 5 52 1.2. Wireless OSPF Terminology . . . . . . . . . . . . . . . . 5 54 2. The Link State Database . . . . . . . . . . . . . . . . . . 6 55 2.1. Representation of routers and networks . . . . . . . . . . 6 56 2.2. The shortest-path tree . . . . . . . . . . . . . . . . . . 7 57 2.3. Use of external routing information . . . . . . . . . . . 7 58 2.4. Equal-cost multipath . . . . . . . . . . . . . . . . . . . 7 60 3. Splitting the AS into Areas . . . . . . . . . . . . . . . . 7 62 4. Functional Summary . . . . . . . . . . . . . . . . . . . . . 8 63 4.1. Inter-area routing . . . . . . . . . . . . . . . . . . . . 8 64 4.2. AS external routes . . . . . . . . . . . . . . . . . . . . 8 65 4.3. Routing protocol packets . . . . . . . . . . . . . . . . . 8 66 4.4. Basic implementation requirements . . . . . . . . . . . . 9 67 4.5. Optional OSPF capabilities . . . . . . . . . . . . . . . . 9 69 5. Protocol Data Structures . . . . . . . . . . . . . . . . . . 9 71 6. The Area Data Structure . . . . . . . . . . . . . . . . . . 10 73 7. Bringing Up Adjacencies . . . . . . . . . . . . . . . . . . 10 74 7.1. The Hello Protocol . . . . . . . . . . . . . . . . . . . . 10 75 7.2. The Synchronization of Databases . . . . . . . . . . . . . 10 76 7.3. The Designated Router . . . . . . . . . . . . . . . . . . 11 77 7.4. The Backup Designated Router . . . . . . . . . . . . . . . 11 79 8. Protocol Packet Processing . . . . . . . . . . . . . . . . . 11 80 8.1. Sending protocol packets . . . . . . . . . . . . . . . . . 11 81 8.2. Receiving protocol packets . . . . . . . . . . . . . . . . 12 83 9. Interface Data Structure . . . . . . . . . . . . . . . . . . 12 84 9.1. Events causing interface state changes . . . . . . . . . . 13 85 9.2. Events causing interface state changes . . . . . . . . . . 13 86 9.3. The Interface state machine . . . . . . . . . . . . . . . 13 87 9.4. Electing the Designated Router . . . . . . . . . . . . . . 13 88 9.5. Sending Hello packets . . . . . . . . . . . . . . . . . . 14 89 9.5.1. Multipoint Relay Selection . . . . . . . . . . . . . . . 14 91 10. Neighbor Data Structure . . . . . . . . . . . . . . . . . . 16 92 10.1. Neighbor states . . . . . . . . . . . . . . . . . . . . . 16 93 10.2. Events causing neighbor state changes . . . . . . . . . . 17 94 10.3. The Neighbor state machine . . . . . . . . . . . . . . . 17 95 10.4. Whether to become adjacent . . . . . . . . . . . . . . . 19 96 10.5. Receiving Hello Packets . . . . . . . . . . . . . . . . . 19 97 10.6. Receiving Database Description Packets . . . . . . . . . 19 98 10.7. Receiving Link State Request Packets . . . . . . . . . . 19 99 10.8. Sending Database Description Packets . . . . . . . . . . 19 100 10.9. Sending Link State Request Packets . . . . . . . . . . . 20 102 11. Routing Table Structure . . . . . . . . . . . . . . . . . . 20 104 12. Link State Advertisements . . . . . . . . . . . . . . . . . 20 106 13. The Flooding Procedure . . . . . . . . . . . . . . . . . . 20 107 13.1. LSF message generation . . . . . . . . . . . . . . . . . 20 108 13.2. LSF message processing . . . . . . . . . . . . . . . . . 21 109 13.3. LSA processing . . . . . . . . . . . . . . . . . . . . . 22 111 14. Aging the Link State Database . . . . . . . . . . . . . . . 23 113 15. Virtual Links . . . . . . . . . . . . . . . . . . . . . . . 24 115 16. Calculation of the routing table . . . . . . . . . . . . . 24 117 17. OSPF data formats . . . . . . . . . . . . . . . . . . . . . 24 118 17.1. Wireless Hello packet . . . . . . . . . . . . . . . . . . 24 119 17.2. Link State Flood (LSF) Packet Format . . . . . . . . . . 25 121 18. Architectural Constants . . . . . . . . . . . . . . . . . . 26 123 19. Configurable Constants . . . . . . . . . . . . . . . . . . 27 125 20. Authentication . . . . . . . . . . . . . . . . . . . . . . 27 126 21. An algorithm for assigning Link State IDs . . . . . . . . . 27 127 22. Multiple interfaces to the same network/subnet . . . . . . 27 128 23. Security Considerations . . . . . . . . . . . . . . . . . . 27 129 24. References . . . . . . . . . . . . . . . . . . . . . . . . 27 130 25. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 28 131 26. IANA Considerations . . . . . . . . . . . . . . . . . . . . 28 133 1. Introduction 135 Wireless, broadcast-capable, multi-hop networks do not effectively 136 map into one of the four traditional OSPF network types (point-to- 137 point, broadcast, NBMA, or Point-to-MultiPoint). Specifically, NBMA, 138 point-to-point, and Point-to-MultiPoint are defined as non-broadcast 139 networks, and operation of non-broadcast interfaces on broadcast- 140 capable networks leads to high overhead. The OSPF broadcast network 141 type assumes full mesh connectivity between all routers on the 142 subnet, but in mobile wireless networks, connectivity may be partial 143 and the Designated Router election protocol may not converge. Some 144 vendors have extended the Point-to-MultiPoint interface type for 145 operation over multicast-capable networks, but the scaling properties 146 due to exponential growth in router adjacencies as the number of 147 nodes increases are undesirable for large networks. Finally, some 148 subnet technologies allow for a "layer-2 routing" that masks the 149 underlying multi-hop nature of the subnet, allowing a traditional 150 broadcast-based OSPF to operate over it at layer-3, but such 151 operation can lead to extra overhead unless neighbor discovery 152 operations are coordinated across layers and partitioning of the 153 layer-2 network is prevented. Although the IETF MANET working group 154 has been working on a set of routing protocols for multi-hop wireless 155 networks, the protocols are not yet comprehensive enough for 156 operation in heterogeneous IP networks. Therefore, if a legacy 157 routing protocol can be adapted to operate over wireless networks, it 158 may speed the path to deployment [Bak03]. 160 This draft defines a new OSPF "wireless" interface type for a network 161 that has the following characteristics: the medium supports true 162 broadcast transmission, link layer messages can be either multicast 163 or unicast, and the pairwise transmission reachability between nodes 164 can be time-varying (sometimes within one hop, and sometimes 165 requiring more than one hop). Mobile ad hoc networks (MANET) are one 166 example of this type of network. 168 The "wireless" interface type has the following characteristics: i) 169 is multicast capable, and uses multicast for an unreliable flooding 170 of Link State Advertisements (LSAs), ii) does not elect a designated 171 router, and iii) does not attempt database synchronization with 172 neighbors. The wireless interface type accomplishes this through the 173 use of a new OSPF message (Link State Flood) that permits a new 174 mechanism for flooding LSAs within a wireless subnet. The wireless 175 interface type also makes use of the concept of Multipoint Relays 176 (MPRs), introduced in the Optimized Link State Routing (OLSR) 177 protocol [OLSR], to reduce flooding overhead. When selected as an 178 MPR, a new LSF that is received is reflooded on the interface it was 179 received on [Bak02], and sequence numbers are used to avoid flooding 180 duplicates. This OSPFv2 wireless interface type was first described 181 in [Hen03]. 183 This draft is organized in parallel with the OSPFv2 RFC [OSPF], for 184 easy comparison. This document, read in conjunction with [OSPF], 185 completely specifies the wireless interface extension to the basic 186 OSPFv2 protocol. 188 1.1. Summary of Changes 190 Changes from version 00 to version 01 192 - Remove default route bit in the LSF for stub wireless net- 193 works. The OSPF totally stubby area can be used instead (Sec- 194 tion 13.1). 196 - Add a non-default option to flood an LSF in the duplicate ta- 197 ble that has not been previously flooded (Section 13.2). 199 Major changes from RFC 2328 to version 00 201 - defines a new Wireless Hello message. The new message will 202 add an MPR list and eliminate backup and designated router 203 fields; 205 - implements the MPR selection algorithm and rules for reflood- 206 ing LSAs; 208 - efficiently floods LSAs periodically using a Link State Flood 209 (LSF) message; 211 - eliminates the formation of full adjacencies on wireless 212 interfaces; all neighbor states beyond 2-Way are not reached, 213 and no database synchronization is performed; and 215 - includes a mechanism for suppressing the redundant flooding of 216 "outside" LSAs (LSAs originated external to the wireless sub- 217 net). 219 1.2. Wireless OSPF Terminology 221 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 222 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 223 document are to be interpreted as described in RFC2119 [5]. The OSPF 224 wireless interface protocol uses the following terminology: 226 multipoint relay (MPR) 228 A node which is selected by its one-hop neighbor, node X, 229 to re-transmit all the broadcast messages that it 230 receives from X, provided that the same message was not 231 already received, and the time to live field of the mes- 232 sage is greater than one. 234 multipoint relay selector (MPR selector) 236 A node which has selected its one-hop neighbor, node X, 237 as its multipoint relay, is called a multipoint relay 238 selector of node X. 240 edge router 242 A router that has more than one interface and at least 243 one of these interfaces is a wireless interface. 245 wireless router 247 A router that has at least one wireless interface. 249 outside LSAs 251 With respect to a wireless subnet, outside LSAs refer to 252 all LSAs flooded within the area that are not Type 1 LSAs 253 originated by a node with an active interface on that 254 wireless subnet. 256 2. The Link State Database 258 This section defines extensions to Section 2 of [OSPF]. 260 2.1. Representation of routers and networks 262 In wireless mode, OSPF treats all router-to-router connections over 263 the broadcast network similar to a multicast-capable Point-to- 264 MultiPoint network. No Designated Router is elected for the network, 265 nor is there an LSA generated for the network. A vertex for the 266 wireless network does not appear in the graph of the link-state 267 database. 269 Figure 2.1.1 illustrates the link-state database representation of a 270 wireless network. On the left side of the figure, a wireless network 271 is pictured. It is assumed that all routers can communicate directly 272 with their horizontal and vertical neighbors, but not those across 273 the diagonals. I3 through I6 indicate the routers' IP interface 274 addresses on the wireless network. In the graphical representation 275 of the link-state database, routers that can communicate directly 276 over the wireless network are joined by bi-directional edges, and 277 each router also has a stub connection to its own IP interface 278 address. 280 **FROM** 281 +---+ +---+ 282 |RT3| |RT4| |RT3|RT4|RT5|RT6| 283 +---+ +---+ * -------------------- 284 I3| |I4 * RT3| | X | X | | 285 +----------------------+ T RT4| X | | | X | 286 I5| |I6 O RT5| X | | | X | 287 +---+ +---+ * RT6| | X | X | | 288 |RT5| |RT6| * I3| X | | | | 289 +---+ +---+ I4| | X | | | 290 I5| | | X | | 291 I6| | | | X | 293 Figure 2.1.1: Network map components 295 2.2. The shortest-path tree 297 There is no change to the calculation of the shortest-path tree 298 described in Section 2.2 of [OSPF]. However, since topology 299 dissemination is unreliable, it is possible for two routers in the 300 same Autonomous system to generate dissimilar routing tables. 302 2.3. Use of external routing information 304 There are no changes to the use of external routing information 305 described in Section 2.3 of [OSPF]. 307 2.4. Equal-cost multipath 309 There are no changes to the equal-cost multipath described in Section 310 2.4 of [OSPF]. 312 3. Splitting the AS into Areas 314 There are no changes to the splitting the AS into areas described in 315 Section 3 of [OSPF]. 317 4. Functional Summary 319 This section defines extensions to Section 4 of [OSPF]. 321 A router with a wireless interface sends and receives Wireless Hello 322 packets to detect neighbors. A Wireless Hello packet is similar in 323 format to a normal Hello packet, the difference being that it lists 324 the sender\'s MPR selection, it distinguishes between 1-way and 2-way 325 neighbors, and it does not include fields for designated router or 326 backup designated router. The router dynamically detects its 327 neighboring routers by sending its Wireless Hello packets to the 328 multicast address AllSPFRouters. 330 OSPF adjacencies are not formed on wireless networks. Instead, 331 routers keep a table of neighbors who have selected them as a MPR 332 (MPR selectors). The distribution of topology information is 333 performed by flooding link state information (i.e., LSAs) 334 periodically on all wireless interfaces. MPRs are used to more 335 efficiently flood the information. LSAs are flooded in Link State 336 Flood packets, which are similar to Link State Update packets except 337 that they have a monotonically increasing sequence number for use in 338 duplicate detection. 340 4.1. Inter-area routing 342 There are no changes to the Inter-area routing described in Section 343 4.1 of [OSPF]. 345 4.2. AS external routes 347 There are no changes to the AS external routes described in Section 348 4.2 of [OSPF]. 350 4.3. Routing protocol packets 352 The additional OSPF packets used on wireless networks are listed 353 below in Table 4.3.1. Their formats are described in Appendix A. 355 Type Packet name Protocol function 356 ================================================================== 357 6 Wireless Hello Discover/maintain neighbors and MPRs 358 7 Link State Flood Database update 360 Table 4.3.1: OSPF packet types. 362 Wireless Hello packets are used to discover and maintain neighbor 363 relationships and inform neighbors of MPR selections. Wireless Hello 364 packets are never forwarded. Each Link State Flood (LSF) packet 365 carries a set of new or old link state advertisements (LSAs) one hop 366 further away from their point of origination. A single Link State 367 Flood packet may contain the LSAs of several routers. LSA types or 368 formats are not changed. 370 Wireless Hello and LSF packets are only sent and received on 371 interfaces configured as wireless. 373 4.4. Basic implementation requirements 375 There are no changes to the implementation requirements described in 376 Section 4.4 of [OSPF]. 378 4.5. Optional OSPF capabilities 380 There are no changes to the optional capabilities in Section 4.5 of 381 [OSPF]. 383 5. Protocol Data Structures 385 This section defines extensions to Section 5 of [OSPF]. 387 LSF duplicate table 389 The Link State Flood duplicate table keeps track of which 390 LSFs have been seen. Each tuple in the table consists of 391 the originator's Router ID, the flooding sequence number, 392 the time at which the entry expires, and a flag that 393 indicates whether the LSF has been flooded. The table 394 should be empty upon initialization. 396 6. The Area Data Structure 398 There are no changes to the area data structures described in Section 399 6 of [OSPF]. 401 7. Bringing Up Adjacencies 403 This section defines extensions to Section 7 of [OSPF]. 405 Two routers with wireless interface types, who discover that they can 406 communicate bi-directionally with one another over the wireless 407 interface, do not attempt to form an OSPF adjacency, nor do they 408 attempt to synchronize their link state databases over the wireless 409 interfaces. 411 The Hello protocol is used to establish bi-directional communication, 412 to move the routers into a neighbor state of 2-Way. Neighbor state 413 2-Way is the maximum neighbor state obtained on a wireless interface. 415 7.1. The Hello Protocol 417 The Hello Protocol is responsible for establishing and maintaining 418 neighbor relationships. It also verifies that communication between 419 neighbors is bi-directional. Wireless Hello packets are sent 420 periodically on all wireless interfaces while standard Hello packets 421 are sent on all other interface types. Bi-directional communication 422 is assumed when the router sees itself listed in the neighbor's 423 wireless Hello Packet. 425 Wireless Hello packets are also responsible for informing a node of 426 its 2-way and 1-way two-hop neighbors and neighbors that selected it 427 as MPR. If a router finds that it is selected as MPR then it begins 428 acting as an MPR for the originator of the Hello packet. The current 429 MPR selectors are stored in the MPR Selector table. The 2-way two- 430 hop neighbors found in Hello packet are stored in the Two Hop 431 Neighbor Table and used to select a node's MPR(s). 433 7.2. The Synchronization of Databases 435 Databases are synchronized in wireless networks by flooding the LSA 436 information periodically. Since the flooding process is unreliable, 437 there is no guarantee that the databases become identical. 439 7.3. The Designated Router 441 Designated routers are not elected on Wireless networks. 443 7.4. The Backup Designated Router 445 Backup designated routers are not elected on Wireless networks. 447 8. Protocol Packet Processing 449 This section defines extensions to Section 8 of [OSPF]. 451 There are no changes to the procedures for sending protocol packets 452 on existing interface types. Routing protocol packets sent on 453 Wireless interfaces are processed nearly the same. The major change 454 is that LSF packets are sent along bi-directional links as opposed to 455 sending LSUs along adjacencies. 457 8.1. Sending protocol packets 459 On Wireless networks, no adjacencies are formed and link state 460 advertisements are exchanged unreliably. Therefore, Database 461 Description (DD), Link State Requests (LSR), Link State Updates 462 (LSU), and Link State Acknowledgements (LSAck) are not necessary. DD 463 and LSR messages are not needed because they are used to create 464 adjacencies. LSFs are used in place of LSUs to carry LSAs on 465 wireless networks. LSAcks are not needed because routing packets no 466 longer require acknowledgment. 468 The Wireless protocol packet fields are filled in as standard OSPF 469 packets. The destination of Wireless Hello and LSF packets should be 470 AllSPFRouters. 472 For more information on the format of specific Wireless OSPF packet 473 types, consult the sections listed in Table 8.1.1. 475 Type Packet name detailed section (transmit) 476 ========================================================= 477 6 Wireless Hello Section 9.5 478 7 Link State Flood Section 13.1 480 Table 8.1.1 Sections describing Wireless OSPF protocol packet 481 transmission. 483 8.2. Receiving protocol packets 485 On wireless interfaces, only type 6 and 7 packets may be received. 486 If the packet type is Wireless Hello, it should be further processed 487 by the Hello Protocol (see Section 10.5). For more specific 488 information on processing specific Wireless OSPF packet types, 489 consult the sections listed in Table 8.2.1. 491 The sender of the LSF packet is identified by the IP source address 492 found in the packet's IP header. The originator address found in the 493 LSF packet is not necessarily the sender. If the packet type is LSF 494 then it should be further processed according to Section 13.2. 496 Type Packet name detailed section (receive) 497 ======================================================== 498 6 Wireless Hello Section 10.5 499 7 Link State Flood Section 13.2 501 Table 8.2.1 Sections describing Wireless OSPF protocol packet 502 reception. 504 9. Interface Data Structure 506 This section defines extensions to Section 9 of [OSPF]. 508 A new type and three additional data structure are added to the 509 interface. 511 Type 513 The Wireless interface type is added to the Type data 514 structure. 516 MPR List 518 Each wireless interface keeps a list of MPRs that were 519 elected. Each entry in the list is the router ID of the 520 selected MPR. 522 MPR Selector Table 524 The MPR Selector table consists of routers that have 525 selected the calculating router as MPR. These router IDs 526 are stored in the table each time a Wireless Hello mes- 527 sage has been received containing this router as a MPR. 528 Table entries have an expiration time that define when 529 the calculating router should remove the MPR Selector. 531 Outside LSA Table 533 A table of outside LSAs that have been received on the 534 interface within OUTSIDE_LSA_HOLD_TIME time. Each entry 535 in the table should contain the Router ID of the origina- 536 tor, the LSA sequence number, and the expiration time. 537 The table should initially be empty. 539 9.1. Interface States 541 There are no changes to the interface states in Section 9.1 of 542 [OSPF]. Wireless interfaces will reach a maximum state of point-to- 543 point. 545 9.2. Events causing interface state changes 547 There are no changes to the interface state changes in Section 9.2 of 548 [OSPF]. 550 9.3. The Interface state machine 552 The interface state machine has the following addition for the 553 wireless interfaces. 555 State(s): Down 557 Event: InterfaceUp 559 New state: Point-to-Point 561 Action: Start the interval Hello Timer, enabling the 562 periodic sending of Hello packets out the inter- 563 face. 564 Start the interval LSF Timer, enabling the 565 periodic sending of LSF packets out the interface. 567 9.4. Electing the Designated Router 569 A Designated Router is not elected on a Wireless interface. 571 9.5. Sending Hello packets 573 Hello messages are sent out of non-wireless interfaces with no 574 change. Wireless Hello messages are modified from standard Hello 575 messages as follows. Every HELLO_INTERVAL a Wireless Hello message 576 is sent out on all wireless interfaces. The format of the Wireless 577 Hello packet is detailed in Appendix A.1. When a Wireless Hello 578 message is sent it is necessary to calculate the neighbors (no change 579 from non-wireless interfaces) and the MPRs (a new step). The MPRs 580 are calculated if the neighbor state has changed since the last MPR 581 calculation by using the algorithm described below and taken from 582 [OLSR]. Otherwise, the MPRs are taken from MPR list. 584 9.5.1. Multipoint Relay Selection 586 MPRs are used to flood LSF messages from a node into the network 587 while reducing the number of retransmissions that will occur in a 588 region. Thus, the concept of MPR is an optimization of a classical 589 flooding mechanism. 591 Each node in the network selects, independently, its own set of MPRs 592 among its 2-way neighborhood. The MPR set MUST be calculated by a 593 node in such a way that it, through the neighbors in the MPR-set, can 594 reach all nodes, which have a 2-way neighbor relationship with the 595 2-way neighbors of the node (Notice that a node, A, that is a 2-way 596 neighbor of another node, B, cannot also be considered as a 2-way 597 neighbor of the 2-way neighbors of B during MPR selection). This 598 means that the union of the 2-way neighborhoods of the MPR nodes 599 contains the 2-way two-hop neighborhood. MPR set recalculation 600 should occur when changes are detected in the neighborhood or in the 601 two-hop neighborhood. 603 While it is not essential that the MPR set is minimal, it is 604 essential that all 2-way two-hop neighbors can be reached through the 605 selected MPR nodes. A node SHOULD select an MPR set such that any 606 2-way two-hop neighbor is covered by at least one MPR node. 608 By default, the MPR set can coincide with the entire 2-way neighbor 609 set. 611 The following specifies a proposed heuristic for selection of MPRs 612 [OLSR]. It constructs an MPR-set that enables it to reach any 2-way 613 two-hop interface (i.e. any interface of a two-hop neighbor having a 614 2-way link with a neighbor). The following terminology will be used 615 in describing this algorithm: 617 N: 619 The set of 2-way neighbors of the node. 621 N2: 623 The set made of the addresses of the 2-way neighbors of 624 N, excluding (i) all the nodes in N and (ii) the node 625 performing the computation. 627 D(y): 629 The degree of an one hop neighbor node y (where y is a 630 member of N), is defined as the number of 2-way neighbors 631 of node y, EXCLUDING all the members of N and EXCLUDING 632 the node performing the computation. 634 Poorly covered node: 636 A poorly covered node is a node in N2 which is covered by 637 only one node in N. 639 The proposed heuristic is as follows: 641 1 Start with an MPR set made of all members of N. 643 2 Calculate D(y), where y is a member of N, for all nodes in N. 645 3 Select as MPRs those nodes in N which cover the poorly cov- 646 ered nodes in N2. The nodes are then removed from N2 for the 647 rest of the computation. 649 4 While there exist nodes in N2 which are not covered by a node 650 in the in the MPR set: 652 4.1 For each node in N, calculate the reachability, i.e. the 653 number of nodes in N2 which are not yet covered by at 654 least one node in the MPR set, and which are reachable 655 through this 2-way neighbor; 657 4.2 Select as a MPR the node from the nodes in N which pro- 658 vides reachability to the maximum number of nodes in N2. 660 In case of multiple nodes providing the same amount of 661 reachability, an implementation MAY select the node as 662 MPR whose D(y) is greater. Remove the nodes from N2 663 which are now covered by a node in the MPR set. When the 664 MPR set has been computed, all the corresponding router 665 IDs are stored in the MPR Set. 667 10. Neighbor Data Structure 669 This section defines extensions to Section 10 of [OSPF]. 671 Two Hop Neighbor Table 673 The two hop neighbor table consists of nodes that are two 674 hops away from the calculating node. They are found by 675 tabulating the 2-way neighbors found in the Wireless 676 Hello of the one hop neighbors. The two hop neighbors 677 exclude the calculating node and those that are one hop 678 neighbors. The two hop neighbor table is used to 679 determine which nodes are used as MPRs. 681 10.1. Neighbor states 683 In an unreliable routing protocol there is no need to maintain 684 adjacencies between routers. Therefore, the number of neighbor 685 states is reduced when using the wireless interface. Neighbor states 686 consist of Down, Init, and 2-Way. The following reviews these states 687 on a wireless interface. 689 Down 691 A node in the Down state is sending Hello messages, but 692 it has not received any Hello messages. 694 Init 696 A node in the Init state is sending Hello messages, and 697 it has received Hello messages from a neighbor but its 698 own address is not seen in the Hello message. 700 2-Way 702 The 2-Way state is entered when a Hello is received 703 listing it as a neighbor. MPRs are chosen from among 704 nodes detected to be in this state. 706 10.2. Events causing neighbor state changes 708 The events causing neighbor state changes are the same as in [OSPF] 709 with one change on wireless interfaces. 711 2-WayReceived 713 Bi-directional communication has been realized between 714 the two neighboring routers. This is indicated by the 715 router seeing itself in the neighbor's Hello packet. 717 10.3. Neighbor Data Structure 719 There are no additions to the neighbor state machine. Since there 720 are fewer states on wireless interfaces, namely only the Down, Init, 721 and 2-Way states, many transitions will never occur. However, there 722 are additional steps that must be performed with the two-hop neighbor 723 table. 725 State(s): Init 727 Event: 2-WayReceived 729 New state: 2-Way 731 Action: The new neighbor state is set to 2-Way. The 2-way 732 neighbors of the neighbor should be added to the Two Hop 733 Neighbor Table if they are not already 2-way one-hop neighbors 734 of the calculating node. In addition, the neighbor should be 735 added to the MPR Selector Table if the calculating node is 736 found in the MPR list. If it is already in the table the 737 expiration time should be refreshed. 739 State(s): Any state 741 Event: KillNbr 743 New state: Down 745 Action: The corresponding entry in the two-hop neighbor 746 table should be cleared. The neighbor should be removed from 747 MPR Selector table if present. Also, the Inactivity Timer is 748 disabled. 750 State(s): Any state 752 Event: LLDown 754 New state: Down 756 Action: The corresponding entry in the two-hop neighbor 757 table should be cleared. The neighbor should be removed from 758 MPR Selector table if present. Also, the Inactivity Timer is 759 disabled. 761 State(s): Any state 763 Event: InactivityTimer 765 New state: Down 767 Action: The corresponding entry in the two-hop neighbor 768 table should be cleared. The neighbor should be removed from 769 MPR Selector table if present. 771 State(s): 2-Way 773 Event: 1-WayReceived 775 New state: Init 777 Action: The corresponding entry in the two-hop neighbor 778 table should be cleared. The neighbor should be removed from 779 MPR Selector table if present. 781 State(s): 2-Way 783 Event: 2-WayReceived 785 New state: No state change. 787 Action: The 2-way neighbors of the neighbor should be 788 added to the Two Hop Neighbor Table if they are not already 789 2-way one-hop neighbors of the calculating node. If they 790 already are in the table, no change is necessary. In 791 addition, the neighbor should be added to the MPR Selector Ta- 792 ble if the calculating node is found in the MPR list. If it 793 is already in the table the expiration time should be 794 refreshed. 796 10.4. Whether to become adjacent 798 No adjacencies are formed on wireless interfaces. 800 10.5. Receiving Hello Packets 802 The Wireless Hello message processing performs all of the same one- 803 hop neighbor calculations, using the 1-way and 2-way neighbors listed 804 in the Wireless Hello. 806 The 2-way two-hop neighbors found in the Wireless Hello that are not 807 one-hop and are not the calculating node MUST be stored in the two- 808 hop neighbor table. Each entry in the table consists of the two-hop 809 neighbor's Router ID and the receiving interface address. In 810 addition, if the 2-way two-hop neighbor is in the two-hop neighbor 811 table, but it is not found in the Wireless Hello it MUST be removed. 813 Also, the receiving node must look in the MPR list for its own 814 address. If the node finds its own address in the Wireless Hello it 815 enters the neighbor's Router ID into the MPR Selector table, and the 816 expiration time is set to MPR_SELECTOR_HOLD_TIME. 818 10.6. Receiving Database Description Packets 820 Database Description packets are not received in on wireless 821 interfaces. 823 10.7. Receiving Link State Request Packets 825 Link State Request packets are not received in on wireless 826 interfaces. 828 10.8. Sending Database Description Packets 830 Database Description packets are not sent on wireless interfaces. 832 10.9. Sending Link State Request Packets 834 Link State Request packets are not sent on wireless interfaces. 836 11. Routing Table Structure 838 There are no changes to the Routing Table Structure described in 839 Section 11 of [OSPF]. 841 12. Link State Advertisements 843 This section defines extensions to Section 12 of [OSPF]. 845 An LSA constructed for a wireless interface is constructed the same 846 as a LSA on a Point-to-MultiPoint interface. Network LSAs are not 847 generated on wireless interfaces because all nodes in the same subnet 848 are not necessarily one hop away (broadcast network). The only 849 difference between LSA generation for Point-to-Multipoint and 850 wireless interfaces is, that the neighbor state only needs to be in 851 neighbor state 2-way or above in order for an LSA to be generated on 852 a wireless interface. 854 13. The Flooding Procedure 856 This section defines extensions to Section 13 of [OSPF]. 858 Link State Flood packets provide the mechanism for flooding LSAs on 859 wireless interfaces. A Link State Flood packet may contain any of 860 the distinct LSAs. The LSF is used to flood each LSA one hop further 861 from its point of origination. Unreliable flooding requires a 862 mechanism to update the network periodically, since there is no 863 assurance that all nodes in the network receive the first flood. The 864 periodicity decreases the probability that a node will not receive 865 route information necessary to send data. Therefore, a router LSF is 866 flooded periodically on each wireless interface (no adjacencies are 867 required). 869 13.1. LSF message generation 871 Each wireless interface originates an LSF every LSF_INTERVAL. Each 872 time a node generates an LSF it MUST increment the flooding sequence 873 number and add the LSF to the duplicate table. In this table, the 874 node records a duplicate tuple: (originator address, flooding 875 sequence number, expiration time, and flooded flag). The flooded 876 flag is set to TRUE. The LSF MUST be removed from the duplicate ta- 877 ble after it expires. 879 LSFs are constructed differently for wireless and edge routers. The 880 two steps below explain the different construction. 882 1 A Type 1 router-LSA for the area associated with the wireless 883 or edge router is added to the LSF. If a router's neighbor 884 states have transitioned since the last LSF send (into or out 885 of state 2-Way), or the LS age field reaches the value LSRe- 886 freshTime, then a new instance of the router-LSA should be 887 originated. Otherwise, the existing instance of the router- 888 LSA in the Link State Database (LSDB) should be added to the 889 LSF. 891 2 In addition, edge routers must advertise LSAs originated out- 892 side of the wireless network on each wireless interface. 894 2.1 For stub wireless networks (only one edge router), a 895 large amount of overhead due to propagation of outside 896 LSAs can be avoided. The overhead can be reduced by 897 defining the stub wireless network as a totally stubby 898 area. The stub wireless network is defined in Section 899 12.4.3.1 of [OSPF]. The area border (edge router) will 900 originate a "default summary LSA" into the area to create 901 the default path out of the stub wireless network. 903 2.2 In transit wireless networks, any outside LSAs that are 904 self-originated by the router but within flooding scope 905 of the area should be appended to an LSF. Examples of 906 these self-originated outside LSAs include summary and 907 external LSAs. In addition, outside LSAs found in a 908 router's LSDB but originated by other routers should also 909 be appended to an LSF, provided that they are not found 910 in the Outside LSA Table maintained for that interface. 912 13.2. LSF message processing 914 Each incoming LSF is searched for in the duplicate table. 916 1 If the LSF is a duplicate, or if the LSF is older than the LSF 917 found in the table, the LSF packet is discarded. An LSF is 918 older if the sequence number of the LSF in the table is 919 greater than the received LSF's sequence number. Standard 920 modulo sequence number comparisons should be applied. 922 1.1 If the sender is in the MPR selector table, but the 923 flooded flag is FALSE in the duplicate table, then the 924 LSF MAY be reflooded out all MANET interfaces. The 925 flooded flag MUST then be set to TRUE in the duplicate 926 table. Note: Flooding when the flooded flag is FALSE 927 will severely decrease the efficiency of the MPR algo- 928 rithm. The flooded flag is only necessary to prevent 929 insufficient flooding when reordering of packets occurs. 930 Under normal operation, reordering due to layer-2 trans- 931 mission schedules is unlikely; therefore, the option 932 should normally be avoided to reduce flooding overhead. 934 2 Else, the LSF is added to the LSF duplicate table, and the 935 LSAs are processed according to section 13.3. 937 2.1 If the sender is in the MPR selector table, the LSF is 938 flooded out all MANET interfaces, and the flooded flag is 939 set to TRUE in the duplicate table. 941 2.2 Else, the flooded flag is set to FALSE in the duplicate 942 table. 944 13.3. LSA processing 946 LSAs received within an LSF message should be processed and installed 947 in the database in the same way as those received in an LSU, except 948 that they are not acknowledged, nor are they forwarded based on LSA 949 processing. LSAs are not forwarded based on LSA processing because 950 they are (re)flooded based on the LSF processing. See step 2 of LSF 951 message processing above. Outside LSAs MUST be installed in the Out- 952 side LSA table. In this table, the node records a LSA tuple, (origi- 953 nator address, LSA sequence number, and expiration time). The LSA 954 MUST be removed from the Outside LSA table after it expires. 956 If the LSA received within an LSF message is a network LSA, special 957 care should be taken to avoid having more than one LSA in the 958 database describing the same network. This situation could arise due 959 to a designated router change in an external network that resulted in 960 a MaxAge LSA not being successfully flooded through the wireless net- 961 work. Upon receiving a network LSA, if a network LSA already exists 962 in the database for that network, but from a different originator, 963 the router LSA of that originator should be consulted to determine if 964 that node is still listed as the designated router for that network. 965 If that router LSA does not exist or fails to list a designated 966 router, the router LSA of the originator of the new network LSA 967 should be consulted. In either case, if the network LSA in the 968 database is now incorrect, it should be removed from the database. 970 If a wireless node receives an outside LSA with a sequence number 971 lower than the LSA in the LSDB, and the age of the received LSA is 972 less than the age of the copy in the LSDB then the age of the LSDB 973 must be compared to the MAX_PACKET_LIFE. If the age of the LSA in 974 the LSDB is greater than MAX_PACKET_LIFE, then the received LSA is 975 added to the LSDB and the database copy is removed. 977 If an edge router receives an LSA on a wireless interface originated 978 by a router on the wireless network, the sequence number and age MUST 979 be checked as follows. If the sequence number of the received LSA 980 is lower than the LSA in the LSDB, and the age of the received LSA is 981 less than the age of the copy in the LSDB then the age of the LSA in 982 the LSDB must be compared to the MAX_PACKET_LIFE. If the age of the 983 LSA in the LSDB is greater than MAX_PACKET_LIFE then the LSA in the 984 LSDB MUST be immediately unicast back to the originator of the LSA in 985 an LSF. When the originator of the LSA receives the unicast LSF, it 986 should re-originate the LSA with a sequence number one greater than 987 the received LSA and install it in the LSDB. The new LSA is then 988 again flooded in an LSF packet at the next LSF_INTERVAL. 990 Max-aged LSAs received on an edge router's wired interfaces MUST be 991 flooded on all wireless interfaces in the LSAs scope. When a max- 992 aged LSA is received on a wired interface it should be stored for 993 flooding on the next LSF interval. Optionally, the LSA could be sent 994 out for the next N LSF intervals, so that the likelihood of reception 995 is increased. N can be any integer greater than or equal to one. 997 14. Aging the Link State Database 999 There are no changes to the procedures regarding aging of the link 1000 state database described in Section 14 of [OSPF]. 1002 15. Virtual Links 1004 There are no changes to the procedures regarding virtual links 1005 described in Section 15 of [OSPF]. 1007 16. Calculation of the routing table 1009 There are no changes to the procedures regarding calculation of the 1010 routing table described in Section 16 of [OSPF]. 1012 17. OSPF data formats 1014 This section defines extensions to Section A of [OSPF]. 1016 The wireless network introduces two new packet types-- the Wireless 1017 Hello and the Link State Flood (LSF) packet types. The OSPF packet 1018 types are as follows (only packet types 6 and 7 are used on the 1019 wireless interface): 1021 Type Description 1022 ---- ----------- 1023 1 Hello 1024 2 Database Description 1025 3 Link State Request 1026 4 Link State Update 1027 5 Link State Acknowledgment 1028 6 Wireless Hello 1029 7 Link State Flood 1031 17.1. Wireless Hello packet 1033 Wireless Hello packets are OSPF packet type 6. These packets are 1034 sent periodically on all wireless interfaces in order to establish 1035 and maintain neighbor relationships. 1037 The Wireless Hello packet has been changed from the Hello packet as 1038 follows. The version number is 6, the backup and designated router 1039 fields are eliminated, fields for the number of 1-way neighbors, 1040 2-way neighbors, and MPRs are added, the list of neighbors is split 1041 into 1-way followed by 2-way, and a list of MPRs is added. 1043 0 1 2 3 1044 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1046 | Version # | 6 | Packet length | 1047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 | Router ID | 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 | Area ID | 1051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1052 | Checksum | AuType | 1053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 | Authentication | 1055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1056 | Authentication | 1057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1058 | Network Mask | 1059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1060 | HelloInterval | Options | Rtr Pri | 1061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1062 | RouterDeadInterval | 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1064 | # 1way neighb | # 2way neighb | # of MPRS | RESERVED | 1065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1066 | 1way Neighbor 1 | 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 | ... | 1069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1070 | 1way Neighbor N | 1071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1072 | 2way Neighbor 1 | 1073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1074 | ... | 1075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 | 2way Neighbor N | 1077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1078 | MPR 1 | 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 | ... | 1081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1082 | MPR N | 1083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1085 17.2. Link State Flood (LSF) Packet Format 1087 LSF packets are OSPF packet type 7. The LSF message is used in place 1088 of the LSU message on wireless interfaces. A LSF contains all of the 1089 fields contained in an LSU, plus it has a flooding sequence number. 1090 The flooding sequence number is used to distinguish different 1091 instances of the LSF message. Each node keeps a table of LSF 1092 messages that have been seen. 1094 0 1 2 3 1095 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 | Version # | 7 | Packet length | 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 | Router ID | 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 | Area ID | 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 | Checksum | AuType | 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1105 | Authentication | 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1107 | Authentication | 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1109 | Reserved | Flooding Sequence Number | 1110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1111 | # advertisements | 1112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1113 | | 1114 +- +-+ 1115 | Link state advertisements | 1116 +- +-+ 1117 | ... | 1119 18. Architectural Constants 1121 This section defines changes to the architectural constants described 1122 in Section B of [OSPF]. 1124 There is one additional constant. 1126 MAX_PACKET_LIFE = 120 seconds 1128 19. Configurable Constants 1130 This section defines extensions to Section C of [OSPF]. All of the 1131 constants defined below are configurable wireless interface 1132 parameters. 1134 LSF_INTERVAL = 10 seconds 1136 WIRELESS_HELLO_INTERVAL = 10 seconds 1138 NEIGHBOR_HOLD_TIME = 3 * WIRELESS_HELLO_INTERVAL 1140 MPR_SELECTOR_HOLD_TIME = 3 * WIRELESS_HELLO_INTERVAL 1142 LSF_DUPLICATE_HOLD_TIME = 3 * LSF_INTERVAL 1144 OUTSIDE_LSA_HOLD_TIME = 2 * LSF_INTERVAL 1146 20. Authentication 1148 There are no changes to the authentication procedures described in 1149 Section D of [OSPF]. 1151 21. An algorithm for assigning Link State IDs 1153 There are no changes to the procedures for assigning Link State IDs 1154 described in Section E of [OSPF]. 1156 22. Multiple interfaces to the same network/subnet 1158 This section defines extensions to Section F of [OSPF]. 1160 23. Security Considerations 1162 There are no additional security considerations beyond those 1163 identified in [OSPF]. 1165 24. References 1167 [Bak02] Baker, F. et al., "An Outsider's View of MANET" Internet 1168 draft: draft-baker-manet-review-01.txt (expired), March 2002. 1170 [Bak03] Baker, F. et al., "Problem Statement for OSPF Extensions for 1171 Mobile Ad Hoc Routing," Internet draft, draft-baker-manet-ospf- 1172 problem-statement-00 (expired), October 2003. 1174 [Hen03] Henderson, T. et al., "A Wireless Interface Type for OSPF," 1175 Proceedings of 2003 IEEE MILCOM Conference, October 2003. 1177 [OLSR] Clausen, T. and P. Jacquet (ed), "Optimized Link State 1178 Routing Protocol,", RFC 3626, October 2003. 1180 [OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 1182 25. Authors' Addresses 1184 {Jeff Ahrenholz, Tom Henderson, Phil Spagnolo}, Boeing Phantom Works, 1185 2760 160th Avenue SE Bldg 33-07 Bellevue, WA 98008, USA, Email: 1186 {jeffrey.m.ahrenholz, thomas.r.henderson, 1187 phillip.a.spagnolo}@boeing.com 1189 {Emmanuel Baccelli, Thomas Heide Clausen, Philippe Jacquet}, HIPERCOM 1190 INRIA, Rocquencourt BP 105 78153 Le Chesnay Cedex, France, Email: 1191 Emmanuel.Baccelli@inria.fr, Thomas.Clausen@computer.org, 1192 Philippe.Jacquet@inria.fr 1194 26. IANA Considerations 1196 The following OSPF messages types must be allocated: 1198 Message Type Value 1199 ------------------------ ----- 1200 Wireless HELLO 6 1201 Link State Flood 7