idnits 2.17.00 (12 Aug 2021) /tmp/idnits5147/draft-shaio-manet-common-l3-interface-03.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 26, 2015) is 2613 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 132, but not defined == Unused Reference: 'RFC6320' is defined on line 667, but no explicit reference was found in the text == Unused Reference: 'MITRE' is defined on line 684, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 5620 (ref. 'RFC5820') (Obsoleted by RFC 6548, RFC 6635) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Jack Shaio 3 Intended Status: Experimental Caleb Lo 4 Expires: September 27, 2015 Don Broderick 5 The MITRE Corporation 6 March 26, 2015 8 A Common Layer 3 Interface for MANET 9 draft-shaio-manet-common-l3-interface-03 11 Abstract 13 This paper presents an approach that allows an algorithm to choose IP 14 routing peers intelligently among the nodes in a MANET but does not 15 involve any modifications to existing IP routing protocols. In 16 addition, our approach works as a pure interface between (any) MANET 17 radio terminal and any IP router, so nodes using our interface 18 interoperate with nodes that do not use this interface or with nodes 19 using different algorithms to select routing peers. This interface 20 was prototyped and this paper includes test results for two different 21 mobility patterns on a mobile network using OLSR for MANET routing 22 and OSPFv2 for IP routing. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as 32 Internet-Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/1id-abstracts.html 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 Copyright and License Notice 47 The MITRE Corporation Approved for Public Release; Distribution 48 Unlimited #12-2869 50 Copyright (c) 2014 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2 Assumptions and Reference Model . . . . . . . . . . . . . . . . 4 68 2.1 Definitions and Acronyms . . . . . . . . . . . . . . . . . 4 69 2.2 Reference Diagram . . . . . . . . . . . . . . . . . . . . . 4 70 3 Design Objectives . . . . . . . . . . . . . . . . . . . . . . . 5 71 4 IP Unicast Forwarding in the Common Layer 3 Interface . . . . . 6 72 5 Common Layer 3 Interface components . . . . . . . . . . . . . . 8 73 6 CL3 Tests and Results . . . . . . . . . . . . . . . . . . . . . 10 74 6.1 Mobility Patterns . . . . . . . . . . . . . . . . . . . . . 11 75 6.2 Test Results . . . . . . . . . . . . . . . . . . . . . . . 11 76 7 IP Multicast Forwarding in CL3 . . . . . . . . . . . . . . . . 12 77 8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 9 Security Considerations . . . . . . . . . . . . . . . . . . . . 14 79 10 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 80 11 References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 11.1 Normative References . . . . . . . . . . . . . . . . . . . 14 82 11.2 Informative References . . . . . . . . . . . . . . . . . . 14 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 85 1 Introduction 87 Many approaches to integrating a MANET network with IP routing have 88 focused on modifying a standard IP routing protocol, usually OSPF, to 89 reduce the number of IP routing peers selected. Key to these 90 modifications is an algorithm that will choose intelligently, among 91 all potential IP routing peers in the MANET, those that provide the 92 "best" set of IP routing adjacencies. This prevents a routing 93 protocol like OSPF from establishing too many routing adjacencies to 94 MANET nodes that are intermittently unreachable as they move, leading 95 to constant IP route changes. The key issue is to choose, from all 96 MANET nodes that OSPF would accept as routing peers, a smaller set 97 that provides good IP connectivity without too much route instability 98 as nodes and links in the MANET change state. Examples of these 99 approaches are in [RFC5614], [RFC5820] and [HEND1], with comparisons 100 in [HEND2]. 102 This paper presents an alternate approach to choosing IP routing 103 peers among the MANET nodes [CL3]; it still allows an algorithm to 104 choose routing peers intelligently but does not involve any 105 modifications to existing IP routing protocols. In addition, our 106 approach works as a pure interface between a MANET radio terminal and 107 an attached IP router comprising a single mobile node, so nodes using 108 our interface interoperate with nodes that do not use this interface 109 or with nodes using different algorithms to select routing peers. 111 We prototyped this interface and this paper includes test results for 112 two different mobility patterns on a mobile network using OLSR for 113 MANET routing and OSPFv2 for IP routing. These results show our 114 approach was effective on the cases we tested. 116 Since the Common Layer 3 interface approach presented here uses 117 unmodified IP routers, it allows a wide range of commercially 118 available IP routers to be used for the IP component of a MANET node. 119 Our approach is easily adaptable to any SNMP-manageable MANET routing 120 protocol. It can also be adapted, with more work, to MANET terminals 121 that are not SNMP manageable but have some other interface to export 122 their knowledge of the MANET. The key advantage of this approach is 123 that it does not depend either on the specific IP nor MANET routing 124 protocol, so these can be changed independently of each other and 125 integrated with this Common Layer 3 interface. 127 1.1 Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC 2119 [RFC2119]. 133 2 Assumptions and Reference Model 135 The mobile network consists of mobile nodes, each consisting of a 136 MANET terminal and an IP routing component. Users of the mobile 137 network attach to the IP routing component, possibly via a local 138 network. 140 For our prototype we used OSPFv2 [OSPFv2] as the IP routing 141 component, so the remainder of the paper is tailored to OSPF but a 142 different routing protocol could have been used with only minor 143 adjustments. 145 2.1 Definitions and Acronyms 147 The following definitions and acronyms are used in the remainder: 149 MANET Terminal: The terminal comprising only MANET routing and radio 150 access to the MANET, but not an IP routing component. 152 Mobile Node: A node consisting of a MANET terminal, an IP router and, 153 optionally, a Common Layer 3 interface joining the two. 155 CL3: The Common Layer 3 interface described in this paper. 157 CL3 Node: A mobile node that has a Common Layer 3 interface. 159 Non-CL3 Node: A mobile node that does not have a Common Layer 3 160 interface. 162 Stray OSPF HELLO: An incoming OSPF HELLO message from a node not 163 selected by the receiving CL3 node as a routing peer. 165 2.2 Reference Diagram 167 The remainder of this paper divides a mobile node into the three 168 components shown in the diagram below. 170 ------------------- 171 | [IP router] | 172 | | | 173 | [Common Layer 3] | 174 | | | 175 | [MANET terminal] | 176 ------------------- 177 | 178 Radio Network 180 The IP router is running standard, widely available protocols without 181 any MANET-specific extensions. The router must have PPP and an IP 182 routing protocol that is SNMP manageable (for example OSPFv2 used in 183 our tests). As described below, Common Layer 3 will setup PPP 184 sessions between itself and the router; for this it is convenient to 185 have VLANs and PPPoE available as well. 187 The Common Layer 3 interface is a separate logical entity through 188 which all packets between the router and the MANET terminal pass. 190 The MANET terminal runs the MANET routing protocol, which is assumed 191 to be SNMP manageable. In our tests this was OLSR, which is a link 192 state MANET protocol and its MIB provided a topology table. 194 3 Design Objectives 196 CL3 is a separate logical component that bridges the gap between the 197 mobile network formed by the MANET nodes and the IP routing 198 adjacencies created by its attached IP router. CL3 learns about the 199 MANET network (e.g. nodes present, link qualities, MANET topology) 200 from its attached MANET terminal, for example by making SNMP queries 201 to the MANET routing MIB. CL3 uses this knowledge as input to its 202 internal "network abstraction" algorithm which selects the set of IP 203 routing peers for the router to use. CL3 mechanisms described below 204 will make the router use this set of routing peers, and no others, 205 using standard features such as PPP and SNMP; no router modifications 206 are required. There were four design objectives for CL3. 208 The first design objective was to use only standard and widely- 209 available IP features on the IP router, motivated by the desire to be 210 able to choose the IP component of the mobile node from the largest 211 range of commercially-available routers. Our implementation of CL3 212 used OSPFv2 but a similar approach could instead have used OSPFv3, 213 IS-IS, RIP or BGP. Other capabilities we used were PPPoE, VLANs and 214 SNMP access to the table of OSPF neighbors, all widely-available 215 features. 217 An example of a standard but not widely-available feature that might 218 have been very useful is the access node control protocol [ANCP- 219 USAGE]. This protocol allows a broadband access IP router to learn 220 about the state of DSL lines from the DSLAM device that terminates 221 them. Although a similar capability might have been useful in this 222 context, this protocol is only available on a very limited set of IP 223 routers and we avoided it. 225 The second design objective was to be decoupled from the MANET 226 routing protocol as there are many of these and the field continues 227 to evolve. All CL3 requires is that they provide some information 228 about the MANET topology via SNMP or a comparable protocol; of course 229 CL3 has to be adapted to the specific MIB or protocol but otherwise 230 does not depend on special protocol messages to/from the MANET 231 terminal. In our tests we used Optimized Link State Routing [OLSR], a 232 link state routing protocol that includes a topology table in its 233 MIB. This additional information is used by our network abstraction 234 algorithm but CL3 can easily be modified to use a different algorithm 235 suitable for the many distance-vector MANET routing protocols in use. 237 The third design objective was that CL3 should not be a protocol, in 238 other words, a CL3 node does not exchange messages with other CL3 239 peers. CL3 uses only standard mechanisms, SNMP and PPP primarily, to 240 communicate with its attached IP router on one side and its attached 241 MANET terminal on the other. This allows CL3 nodes to interoperate 242 with non-CL3 nodes in the same MANET network. CL3 nodes can therefore 243 be added or upgraded incrementally in the MANET network. 245 The fourth design objective was to allow the network abstraction 246 algorithms in different CL3 nodes to work independently of each other 247 and not require their calculations to result in the same set of 248 routing peers. This means that if the network abstraction algorithm 249 at node A selects node B as a routing peer, it is not necessary for 250 the algorithm at node B to select node A in order for a routing 251 adjacency to be formed between A and B. This design goal allows CL3 252 nodes with different network abstraction algorithms to interoperate. 254 In our prototype we used OSPF as the IP routing protocol and we met 255 design goals 3 and 4 by passing "Stray OSPF HELLOs" (incoming OSPF 256 HELLO messages not sent by a selected routing peer) to the network 257 abstraction algorithm for consideration. The algorithm is not 258 required to accept the sending node as a new routing peer but it may 259 decide to do so. This allows a routing adjacency to be formed between 260 nodes A and B, even when node A selected node B as a routing peer but 261 B is not a CL3 node or the network abstraction algorithm at node B 262 did not originally select node A. 264 These four design objectives were met in the Common Layer 3 interface 265 architecture described below. We implemented a prototype of this 266 architecture and present test results on mobile 40 node networks in 267 Section 6. 269 4 IP Unicast Forwarding in the Common Layer 3 Interface 271 The function of each CL3 subcomponent can be derived from the way IP 272 unicast packet forwarding is done at the CL3 interface between the IP 273 router and the MANET terminal. The extension to IP multicast 274 forwarding is described in Section 7. 276 Every node A on the MANET reachable from a given CL3 node B is a 277 potential IP routing peer for the attached router. Now nodes A and B 278 might never establish a routing adjacency. For example, if OSPF is 279 the routing protocol and the nodes have different HELLO timer 280 settings, this difference in settings between nodes cannot be 281 discovered by CL3 before the nodes are selected as routing peers. It 282 can only be discovered after the routing adjacency fails to reach 283 FULL state (in the OSPF case). 285 If a remote node is selected as a routing peer (and the routing 286 adjacency forms), it will then be an IP next-hop for some IP routes 287 in the router's forwarding table. The problem for CL3 is to identify 288 the IP next-hop chosen by its attached IP router for each IP packet 289 it forwards on the CL3 interface towards the MANET. 291 CL3 solved this problem by assigning a separate PPP session for each 292 remote node selected as a routing peer. The endpoints of this PPP 293 session are the IP router and CL3; note that these PPP sessions do 294 not extend across the MANET to the remote node (unlike the approach 295 in [RFC5578]). At the router these PPP interfaces are unnumbered and 296 OSPF is enabled on them; as point to point interfaces their subnet 297 mask is not checked when setting up OSPF adjacencies, an important 298 benefit for a large MANET that cannot efficiently be in a single IP 299 subnet. 301 The CL3 rules for IP unicast packet forwarding are: 302 1. Outgoing (IP router to MANET): Every packet received on a PPP 303 session uses the remote MANET node associated with that 304 session as its IP next-hop. CL3 encapsulates the IP packet 305 into one or more MANET packets, as appropriate, and forwards 306 these to the attached MANET terminal for transmission. The 307 MANET destination is the remote node associated with the PPP 308 session; the MANET source is the MANET address of the 309 attached MANET terminal. 311 2. Incoming (MANET to node): The MANET source address of the 312 incoming packet is checked by CL3. If it matches a remote 313 node associated with a PPP session, the packet is forwarded 314 to the router on that PPP session. [There is a slight 315 modification to this rule for IP multicast to allow for IGMP 316 and PIM snooping, see Section 7.] 318 The packet is dropped if its MANET source address does not 319 match any PPP session. However, if the packet contained an 320 OSPF HELLO, this information is passed to the CL3 network 321 abstraction algorithm before dropping the packet. This gives 322 the network abstraction algorithm an opportunity to decide if 323 that remote node should be used as a routing peer; if so, the 324 remote node is associated with a new PPP session and further 325 forwarding of packets from that node proceeds as described 326 above, without generating exceptions for OSPF HELLO packets. 328 The special handling of OSPF HELLO packets that do not match a PPP 329 session allows CL3 nodes to setup adjacencies to nodes that selected 330 them, even when their own network abstraction algorithm did not 331 select those nodes when it analyzed the MANET topology. It means that 332 network abstraction algorithms running on CL3 nodes do not have to 333 produce the same result and therefore can be modified independently. 334 This meets the fourth CL3 design objective in Section 3. It also 335 allows non-CL3 nodes to setup routing adjacencies with CL3 nodes, 336 meeting the third design objective in Section 3. 338 Once the PPP interface is setup and associated with a specific remote 339 node in the MANET, the router's OSPF configuration for that interface 340 will cause it to send out OSPF HELLOs, which will be forwarded as 341 described above to that remote node. If the remote peer is also 342 configured to use OSPF on its MANET interface, it will send OSPF 343 packets and CL3, based on their MANET source address, will forward 344 them on the PPP interface to the router. Thus the router will have 345 discovered a potential routing peer on the MANET using the standard 346 OSPF HELLO mechanism, although the remote peer was selected for it by 347 the CL3 network abstraction algorithm. 349 OSPF processing of HELLO packets will now determine if an adjacency 350 can be setup between the two nodes; incompatible configurations of 351 Area IDs or Network Masks, for example, could prevent this. CL3 uses 352 SNMP to monitor the state of all the routing adjacencies it has 353 selected. If any of these is not in FULL state after some timeout 354 period, for example due to incompatible configuration or due to the 355 RouterDeadInterval expiring, CL3 will free the PPP session. This 356 allows CL3 nodes to work independently of each other, to 357 interoperate with non-CL3 nodes and does not require centrally 358 coordinated OSPF configurations in order to prevent leakage of 359 resources such as PPP sessions. 361 5 Common Layer 3 Interface components 363 The description of IP unicast forwarding described above leads to a 364 natural division of the Common Layer 3 interface into four components 365 with well-defined functions: 367 Network Observer: Obtains Information about the MANET network. At a 368 minimum includes all the nodes in the MANET reachable from the 369 MANET terminal. Each of these nodes is a potential routing peer. 371 This information is obtained primarily from SNMP queries to the 372 MANET terminal; of course different terminals and MANET routing 373 protocols will have different MIBs with different contents. Our 374 prototype used OLSR as the MANET protocol and its MIB included a 375 topology table describing the nodes and links in the MANET. 376 Additional information could be obtained from other sources, for 377 example an XML file mapping node IDs to capabilities, such as 378 being an airborne node or being a satellite entry point, that 379 could be useful in evaluating the node's suitability as a routing 380 peer. 382 Network Abstraction: This is the component that takes as input the 383 information on the MANET obtained by the network observer, 384 processes it with its network abstraction algorithm and outputs 385 the set of nodes in the MANET that should be used as IP routing 386 peers by the attached IP router. As the data from network 387 observer varies over time, network abstraction may decide to add 388 new routing peers, possibly dropping existing ones to make room 389 for them. It may also consider the network history of a remote 390 node (has it been consistently reachable or just intermittently?) 391 and apply approaches based on decision theory. 393 The network abstraction algorithm is key to the performance of 394 CL3; we tested 15 different variations. Different CL3 nodes can 395 use different algorithms and still setup routing adjacencies 396 between them because of the forwarding rules for incoming stray 397 OSPF HELLO messages. 399 Router Control: This component takes as input the list of routing 400 peers selected by network abstraction and configures the IP 401 router to use them, as described in Section 4 using PPP sessions. 402 It also notifies the forwarding component of the binding between 403 the PPP session and the MANET address of the routing peer. 405 To speed our prototype development, we used our router's 406 broadband access features to create PPP interfaces automatically 407 and apply a configuration template to them (which includes 408 enabling OSPF) but clearly these could be avoided and interfaces 409 configured directly by router control using SNMP or CLI scripts. 411 Router control monitors periodically, using [OSPFv2-MIB] in our 412 case, the state of each OSPF adjacency it has tried to setup and 413 tears down the PPP session if it is not in FULL state after an 414 initial timeout period. This prevents incompatible OSPF 415 configurations such as different Area IDs or Hello timers, from 416 consuming a PPP session. 418 Of course, the SNMP monitoring mechanism also detects when an 419 adjacency has been torn down by OSPF, as will happen if the peer 420 is no longer reachable on the MANET and RouterDeadInterval 421 seconds have passed without a HELLO message from it. This is what 422 we used in our prototype but clearly a more effective approach is 423 for CL3 to setup a BFD [BFD] session to its attached router and 424 proxy for the routing peer. CL3 can deduce if the routing peer is 425 up or down from the MANET information obtained by network 426 observer, which comes directly from the MANET terminal and its 427 MANET routing protocol. 429 Forwarding: This component implements the IP forwarding rules 430 described in Section 4. It passes stray HELLO information to 431 network abstraction and is told of routing peers to add or drop 432 by router control. 434 6 CL3 Tests and Results 436 A CL3 prototype based on the ideas presented above was developed and 437 tested on an emulated radio environment using a variety of network 438 abstraction algorithms. 440 Our testbed used EMANE, a modular open source radio emulation package 441 for the PHY and MAC layers that can be extended with models of 442 different radio waveforms, including commonly used commercial 443 waveforms and specialized military waveforms; see [EMANE] for 444 details. We modified the open source EMANE software to accept 445 mobility input from a script, allowing very long duration tests. The 446 mobility input describes the strength and loss properties of the 447 radio links at different points in time and must be precomputed based 448 on the radio propagation model for the MANET, the terrain 449 obstructions and node movements. With this information, EMANE can 450 deliver incoming packets to one or more receivers and generate the 451 correct levels of packet loss and delay. The EMANE model we used is a 452 multi-hop radio network. 454 The MANET terminals and CL3 run on a dedicated Linux/Xen machine 455 where each virtual machine (VM) corresponds to a MANET terminal plus 456 the CL3 interface. Each VM has two VLANs, one to its attached router 457 and another to its corresponding radio module on the EMANE machine. 458 PPPoE runs on the router VLAN. Great care was taken to prevent two 459 VMs on the same host from communicating directly via kernel routing 460 instead of going through the EMANE radio network. We did this by 461 blackholing outgoing packets to the other MANET nodes but listening 462 on the EMANE VLAN with a raw socket executable that sent the packets 463 to the EMANE interface directly. 465 One router was configured into multiple VRFs, one for each node. We 466 do not use any mechanism, including BGP, to share routes between 467 these VRFs. By running OSPF on the PPP interfaces setup by CL3, VRFs 468 can setup routing adjacencies with each other but all data packets 469 between them pass through their corresponding VM and its emulated 470 radio module on the EMANE machine. 472 Packets sent over the EMANE radio emulation are encapsulated as IP in 473 IP: the outer header has IP addresses known only to OLSR and the 474 EMANE environment while the inner header has IP addresses known to 475 the attached IP routers but not to the EMANE machine. This gave us an 476 easy way to apply IP policy tools to the packet flows on the emulated 477 radio network. 479 6.1 Mobility Patterns 481 We used two mobility patterns based on a mix of ground and airborne 482 nodes. The airborne nodes move at higher speeds, which affects their 483 radio propagation properties, and are within line of sight of each 484 other. The speeds chosen are compatible with a mix of ground vehicles 485 and helicopters. 487 The tethered mobility pattern has four groups of nine ground nodes, 488 where each group patrols a different local area. A separate airborne 489 node orbits the local area patrolled by each group so it can be 490 viewed as being tethered to its group of ground nodes. The airborne 491 nodes are always within line of sight of each other while at times 492 ground nodes in one group may not be in line of sight of some ground 493 nodes in other groups; this affects the radio links between them. 495 The orbiting mobility pattern has four groups of eight ground nodes 496 each, with each group patrolling a different local area. However, 497 there are also eight airborne nodes orbiting around the entire 498 region, so at different times an airborne node will be above a 499 different group of ground nodes, unlike the tethered mobility 500 pattern. 502 These two mobility patterns are more representative of a coordinated 503 deployment of mobile nodes than the random waypoint model often used 504 for MANET simulations. 506 6.2 Test Results 508 A baseline system was used to compare against CL3; this system did 509 not use the CL3 network abstraction algorithms but it did monitor the 510 state of its OSPF adjacencies and replaced the non-FULL ones with 511 others. It also accepted stray OSPF HELLO packets just as CL3. The 512 baseline system and CL3 were tested on both mobility patterns. 514 For measurements, software emulated users attached to each of the IP 515 routers in the CL3 nodes. Every 60 seconds each user selected a 516 random set of 10 users and sent 10 pings to each. Our software 517 collected the packet delivery ratio and at the end of the test 518 calculated the minimum and average packet delivery ratio as well as 519 its variance. It also identified "failed nodes" for each user, 520 defined as the nodes that did not receive any pings at all from it. A 521 node can be a failed node for one specific user but still receive 522 pings from different users and this was indeed observed. 524 The test results are in the table below: 526 Baseline CL3 Baseline CL3 527 Tethered Tethered Orbiting Orbiting 528 --------------------------------------------------------------------- 529 #failed nodes: 36 0 33 0 530 min packet delivery: 0 0.593 0 0.620 531 avg packet delivery: 0.1 0.781 0.175 0.794 533 As can be seen, without CL3 the baseline system provided very poor 534 connectivity despite its constant monitoring of OSPF adjacencies and 535 replacement of failed ones. The most important metric in this test is 536 the number of failed nodes: 33 or more out of a total of 40 nodes. 538 CL3 had no failed nodes in either test, its minimum packet delivery 539 ratio was near 60% and its average packet delivery ratio close to 540 80%. The same network abstraction algorithm, with the same algorithm 541 parameters, was used for both mobility patterns. The variance in 542 packet delivery between nodes was 0.20, and so the results are 543 sampled from a near-uniform distribution. 545 The key advantage of CL3 over the baseline system is that its network 546 abstraction algorithm can take a global look at all potential routing 547 peers and select them so that they are well distributed across the 548 MANET, rather than modifying the initial set of routing peers 549 haphazardly, as the adjacencies fail. 551 7 IP Multicast Forwarding in CL3 553 IP multicast forwarding in CL3 adds a slight modification to the 554 incoming forwarding rule in Section 4. The problem is that at the IP 555 layer the MANET appears as a mesh of point to point links so IP 556 multicast packets to a group of nodes in the MANET will be 557 replicated, at the IP layer, once for each receiver. If the MANET 558 technology allows some form of multicast, or is a broadcast network, 559 this will be highly inefficient. 561 Assume that CL3 learns, either from the MANET terminal or from 562 configuration data, that the MANET has a multicast address M that can 563 reach a set of nodes S. It can then setup a PPP session to the router 564 and associate it with the MANET address M. The outgoing forwarding 565 rule in Section 4 is not changed. The incoming rule is modified to: 567 2. Incoming (MANET to node): The MANET source address of the 568 incoming packet is checked by CL3. If the packet does not 569 contain a PIM or IGMP packet and its source address matches a 570 remote node associated with a PPP session, the packet is 571 forwarded to the router on that PPP session. 573 If the packet does contain PIM or IGMP and there is a PPP 574 session bound to a MANET multicast address that reaches the 575 MANET source address, the packet is forwarded to the router 576 on that PPP session. Otherwise, it is forwarded to the router 577 on the PPP session bound to the source MANET address of the 578 packet or dropped if there is no such PPP session. 580 As remote nodes join multicast groups or send PIM-JOIN requests 581 upstream, the CL3 nodes will be forwarding these to the router on the 582 PPP sessions associated with the MANET multicast address. When that 583 router needs to forward an IP multicast packet, it uses the PPP 584 session bound to the MANET multicast address which is used by CL3 as 585 the MANET destination address of the packet. Then the MANET multicast 586 delivers the packet to the set of receivers by transmitting it only 587 once over the air. 589 This is the reason for terminating the PPP sessions at the CL3 590 interface instead of extending them to the routing peer, as done in 591 [RFC5578]. 593 8 Summary 595 The Common Layer 3 interface described in this paper showed good 596 packet delivery during our prototype tests. Yet it achieved these 597 results using unmodified, widely-available, IP routers and did not 598 depend on any modifications to the MANET routing protocol, only on 599 SNMP access to it. 601 Use of CL3 will allow the IP routing components of a MANET to be 602 fully independent of the MANET routing protocol. Although MANET 603 protocols continue to evolve, CL3 enabled nodes will be able to adapt 604 to them without requiring change to their IP routing component. They 605 will also be able to change their IP routing protocol, for example 606 moving from OSPFv2 (IPv4) to OSPFv3 (IPv6) without requiring changes 607 to the MANET. This flexibility and modularity are the greatest 608 advantages of the Common Layer 3 interface described here. 610 9 Security Considerations 612 CL3 is an interface between a MANET terminal on one side and an IP 613 routing component on the other. These comprise a single mobile node 614 in the MANET. Provided access to the MANET is restricted, for example 615 by encrypting all packets entering it, the only entities that will 616 send data seen by CL3 will be entities with access to the MANET. 617 Therefore the security of a node with CL3 is as strong as the 618 security of the original MANET network. 620 An entity with access to the MANET can send OSPF HELLO packets to a 621 CL3 node; these packets will be examined by CL3. Depending on the 622 network abstraction algorithm used by CL3, the packets may cause it 623 to setup an OSPF routing adjacency with the CL3 node. This does not 624 pose a security risk provided only trusted entities have access to 625 the MANET. 627 10 IANA Considerations 629 CL3 does not define any code points requiring assigned numbers. 631 11 References 633 11.1 Normative References 635 [CL3] Shaio, J., "Common Layer 3 Interface for Mobile Networks", 636 MITRE Technical Report MTR090194, September 2009. 638 11.2 Informative References 640 [OSPFv2] J. Moy, "OSPF Version 2", RFC 2328, April 1998 642 [OLSR] T. Clausen, P. Jacquet, eds., "Optimized Link State Routing 643 Protocol (OLSR)", RFC 3626, October 2003 645 [OSPFv2-MIB] D. Joyal, P. Galecki, S. Giacalone, eds., "OSPF Version 646 2 Management Information Base", RFC 4750, December 2006 648 [RFC5614] R. Ogier, P. Spagnolo, "Mobile Ad-Hoc Network (MANET) 649 Extension of OSPF Using Connected Dominated Set (CDS) 650 Flooding", RFC 5614, August 2009 652 [RFC5820] A. Roy, M. Chandra, "Extensions to OSPF to Support Mobile 653 Ad-Hoc Networking", RFC 5620, March 2010 655 [ANCP-USAGE] S. Ooghe, N. Voigt, M. Platnic, T. Haag, S. Wadhwa, 656 "Framework and Requirements for an Access Control 657 Mechanism in Broadband Multi-Service Networks", RFC 5851, 658 May 2010 660 [BFD] D. Katz, D. Ward, "General Application of Bidirectional 661 Forwarding Detection (BFD)", RFC 5882, June 2010 663 [RFC5578] B. Berry, et.al., "PPP over Ethernet (PPPoE) Extensions 664 for Credit Flow Control and Link Metrics", RFC 5578, 665 February 2010 667 [RFC6320] J. Moisand, N. Voigt, T. Taylor, T. Haag, S. Wadhwa, 668 "Protocol for Access Control Mechanism in Broadband 669 Networks"", RFC 6320, October 2011 671 [EMANE] Cengen Labs, "Extendable Mobile Ad-hoc Network Emulator", 672 http://labs.cengen.com/emane/, June 2012. 674 [HEND1] Henderson, T., Spagnolo, P., Kim, J., "A Wireless 675 Interface Type for OSPF", IEEE Military Communications 676 Conference MILCOM, vol. 2, pages 1256-1261, IEEE, October 677 2003. 679 [HEND2] Henderson, T., Spagnolo, P., Pei, G., "Evaluation of OSPF 680 MANET Extensions", Boeing Technical Report: D950-10897-11, 681 http://hipserver.mct.phantomworks.org/ietf/ospf/reports, 682 July 2005. 684 [MITRE] MITRE, Common Layer 3 Prototype Source Code, 685 https://sourceforge.net/projects/commonlayer3/files/ 687 Authors' Addresses 689 Jack Shaio 690 MITRE Corporation 691 202 Burlington Road 692 Bedford, MA 01730 693 EMail: jshaio@yahoo.com 695 Caleb Lo 696 MITRE Corporation 697 202 Burlington Road 698 Bedford, MA 01730 699 EMail: clo03@alumni.caltech.edu 700 Don Broderick 701 MITRE Corporation 702 202 Burlington Road 703 Bedford, MA 01730 704 EMail: donb@mitre.org