idnits 2.17.1 draft-boot-manet-nemo-analysis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1271. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1282. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1289. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1295. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (June 26, 2007) is 6149 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-19) exists of draft-ietf-manet-olsrv2-03 == Outdated reference: A later version (-26) exists of draft-ietf-manet-dymo-09 == Outdated reference: A later version (-14) exists of draft-ietf-manet-smf-04 -- Obsolete informational reference (is this intentional?): RFC 3344 (ref. '13') (Obsoleted by RFC 5944) -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '14') (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 2740 (ref. '16') (Obsoleted by RFC 5340) -- Obsolete informational reference (is this intentional?): RFC 2461 (ref. '19') (Obsoleted by RFC 4861) == Outdated reference: A later version (-01) exists of draft-wakikawa-manemo-problem-statement-00 == Outdated reference: A later version (-08) exists of draft-thubert-tree-discovery-05 == Outdated reference: A later version (-03) exists of draft-thubert-nina-00 == Outdated reference: A later version (-10) exists of draft-ogier-manet-ospf-extension-09 == Outdated reference: A later version (-05) exists of draft-chandra-ospf-manet-ext-04 == Outdated reference: A later version (-15) exists of draft-ietf-manet-nhdp-03 Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MANET and NEMO Working Groups T. Boot 3 Internet-Draft Infinity Networks 4 Expires: December 28, 2007 June 26, 2007 6 Analysis of MANET and NEMO 7 draft-boot-manet-nemo-analysis-01.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 28, 2007. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2007). 38 Abstract 40 This document provides an overview of models for MANET and NEMO. It 41 descibes the MANET and the NEMO characteristics. It also also lists 42 problems using the MANET and NEMO technology, when problems are not 43 described in other documents. It is claimed that MANET suits small 44 mobile network topologies, providing optimal paths for communication 45 within a MANET cloud and towards the outside. It is also claimed 46 that NEMO suits small mobile subnets, providing sub-optimal paths for 47 to Internet connected nodes. This document is used for evaluating a 48 need for a MANET for NEMO, called MANEMO. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3. MANET classification and models for hierarchy . . . . . . . . 8 57 3.1. Sub-IP MANET . . . . . . . . . . . . . . . . . . . . . . . 8 58 3.2. Isolated MANET . . . . . . . . . . . . . . . . . . . . . . 8 59 3.3. Interconnected MANETs . . . . . . . . . . . . . . . . . . 9 60 3.4. Stub MANET . . . . . . . . . . . . . . . . . . . . . . . . 10 61 3.5. Layered MANETs . . . . . . . . . . . . . . . . . . . . . . 10 63 4. Fringe Stub models . . . . . . . . . . . . . . . . . . . . . . 12 64 4.1. Layer-2 Access . . . . . . . . . . . . . . . . . . . . . . 12 65 4.2. Layer-2 Meshing . . . . . . . . . . . . . . . . . . . . . 12 66 4.3. Node Mobility . . . . . . . . . . . . . . . . . . . . . . 13 67 4.4. Network Mobility . . . . . . . . . . . . . . . . . . . . . 14 68 4.5. Nested NEMO . . . . . . . . . . . . . . . . . . . . . . . 14 69 4.6. MANEMO . . . . . . . . . . . . . . . . . . . . . . . . . . 15 71 5. MANET and NEMO Characteristics . . . . . . . . . . . . . . . . 17 72 5.1. Scalability . . . . . . . . . . . . . . . . . . . . . . . 17 73 5.2. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 17 74 5.3. HA dependency . . . . . . . . . . . . . . . . . . . . . . 18 75 5.4. Route optimization . . . . . . . . . . . . . . . . . . . . 18 76 5.5. Interface type . . . . . . . . . . . . . . . . . . . . . . 18 77 5.6. Multicast support . . . . . . . . . . . . . . . . . . . . 19 79 6. Problems found in MANET and NEMO . . . . . . . . . . . . . . . 20 80 6.1. Worst Path First Syndrome . . . . . . . . . . . . . . . . 20 81 6.2. Break Before Make problem . . . . . . . . . . . . . . . . 21 82 6.3. Routing loops in proactive routing protocols . . . . . . . 22 83 6.4. Congested link avoidance . . . . . . . . . . . . . . . . . 23 84 6.5. MANET and NEMO at home problem . . . . . . . . . . . . . . 25 85 6.6. MANET scale to infinity problem when peering to 86 strangers . . . . . . . . . . . . . . . . . . . . . . . . 27 88 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 29 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 29 92 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 94 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 95 10.1. Normative reference . . . . . . . . . . . . . . . . . . . 29 96 10.2. Informative Reference . . . . . . . . . . . . . . . . . . 29 98 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 32 99 A.1. Changes from version 00 to 01 . . . . . . . . . . . . . . 32 101 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32 102 Intellectual Property and Copyright Statements . . . . . . . . . . 33 104 1. Introduction 106 IP technology is increasingly being used in mobile networks. Many 107 issues arise with mobility, for example wireless bandwidth and link 108 quality are typically low related to fixed, wired infrastructures. 109 Also routing protocols for mobile environments are faced with new 110 challenges; connectivity comes and goes when nodes move and link 111 quality increases and decreases instead of flapping between an OK and 112 an NOT-OK state. 114 Two IETF mobility technologies are available, that is Mobile Ad-hoc 115 NETworks (MANET) [1], [2] and Mobile IP (MIP). 117 The MANET workgroup is working on routing protocols, running on 118 mobile or fixed routers; either in small isolated topologies or at 119 edges of large IP infrastructures. Multiple types of MANET protocols 120 exist; OLSR [3] is a proactive MANET protocol populating the routing 121 table independent of any user traffic; DYMO [4] is a reactive 122 protocol, providing path information for traffic flows and SMF [5] is 123 a multicast flooding protocol. 125 The MIP4 and MIP6 workgroups are working on mobility support for 126 hosts, enabling session continuity while moving. Other workgroups 127 are working on improvements on MIP, for example MONAMI6 and MIPSHOP 128 are working on using multiple interfaces towards the IP 129 infrastructure. The NEMO workgroup extends MIP using the Mobile 130 Router concept, providing MIP services for MR attached nodes. With 131 NEMO, nesting can occur, introducing new challenges. 133 Currently, a number of communities are working on network 134 architectures for mobile domains. Different communities work on 135 different domains, all having their specific requirements. Work 136 within the IETF would comply with all those requirements. Sample 137 domains are military, public safety / emergency response networks, 138 mobile networks used by enterprises and non-governmental 139 organizations, provider based Internet access, license-free wireless 140 networks and networks for intelligent transport systems / vehicle 141 communication systems. Also combinations of multiple domains can be 142 used, for example a mobile network for a disaster relief organization 143 could use own licensed transmission means, provider based Internet 144 access and license-free wireless networks; all used in cars also 145 equipped with an inter-vehicle communication system / intelligent 146 transport system. 148 2. Terminology 150 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in RFC2119 [6] 154 Readers are expected to be familiar with all the terms defined in 155 RFC3753: Mobility Related Terminology [7] and the NEMO Terminology 156 draft [8] 158 MANET 160 Mobile Ad-hoc NETworks [7] 162 NEMO 164 NEtork MObility [8] 166 NEMO BS 168 Network Mobility Basic Support Protocol [9] 170 NEMO RO 172 NEMO Route Optimization [10] / [11] / [12] 174 MIP 176 Mobile IP [8] 178 MIP4 180 IP Mobility Support for IPv4 [13] 182 MIP6 184 Mobility Support in IPv6 [14] 186 OLSR 188 Optimized Link-State Routing Protocol [3] 190 DYMO 192 Dynamic MANET On-demand Routing [4] 194 SMF 196 Simplified Multicast Forwarding for MANET [5] 198 OSPF 200 Open Shortest Path First [15][16] 202 MONAMI6 204 Mobile Nodes and Multiple Interfaces in IPv6 206 MIPSHOP 208 Mobility for IP: Performance, Signaling and Handoff Optimization 210 HAHA 212 Global HA to HA protocol [17]; [18] 214 MNR 216 MANET Router [2] 218 MR 220 Mobile Router [7] [8] 222 MH 224 Mobile Host [7] 226 HA 228 Home Agent [8] 230 CN 232 Correspondent Node [8] 234 LFN 236 Local Fixed Node [8] 238 RA 239 Router Advertisement [19] 241 3. MANET classification and models for hierarchy 243 MANETs can be classified based on different deployment scenarios. 244 The classical MANET approach focused on a single, contiguous MANET 245 region. Now MANET technology is getting mature, focus is shifting 246 towards interfacing between different MANETs and MANETs connected to 247 the Internet. This section provides a classification of MANETs and 248 models for MANET hierarchy. 250 Deployed MANETs can inherit characteristics of different models. 252 3.1. Sub-IP MANET 254 MANET technology can be used below the IP layer. The MANET forms a 255 single IP subnet, where nodes can reach each other transparently. 256 The subnetwork provides full connectivity for unicast and multicast / 257 broadcast. RFC3819 [20] provides advice on subnetworks. 259 +-----------------------+ 260 | | 261 | Sub-IP MANET | 262 | | 263 +-----------------------+ 264 : : 265 : : : = Classic IP Interface 266 +-+-+ +-+-+ 267 | N | * * * * * | N | 268 +---+ +---+ 270 Figure 1: Sub-IP MANET 272 Sub-IP MANETs are transparent for the IP layer and do not introduce 273 special requirements. 275 3.2. Isolated MANET 277 An Isolated MANET is a single, contiguous MANET region. MANET 278 routers within the MANET region provide connectivity to attached 279 hosts. No Routers are attached to an Isolated MANET. 281 +-------------------------+ 282 | Isolated MANET | 283 | | 284 | ~MNR1 | ~ = MANET IP Interface 285 | ~ ~ ~MNR2 | 286 | MNR3 ~ ~ ~ | 287 | ~ ~~~MNR4 ~ | 288 | MNR5~~~~~ ~~~MNR6 | 289 +-:------------------:----+ 290 : : 291 : : 292 +-+-+ +-+-+ 293 | H | * * * * * * | H | 294 +---+ +---+ 296 Figure 2: Isolated MANET 298 3.3. Interconnected MANETs 300 MANETs can be connected to each other, forming a single network 301 infrastructure. 303 +-------------------------+ +-----------------------+ 304 | MANET1 | | MANET2 | 305 | | | | 306 | ~MNR1 | | | 307 | ~ ~ ~MNR2#############MNR7~~~~~~~~~~MNR8 | 308 | MNR3 ~ ~ ~ | | ~ ~~~ ~ | 309 | ~ ~~~~~~MNR4 ~ | | ~ ~~~ ~ | 310 | MNR5 ~~~MNR6 | | MNR9 ~~MNR10 | 311 +-:------------------:----+ +--:---------------:----+ 312 : : : : 313 : : : 314 +-+-+ +-+-+ +-+-+ 315 | H | * * * * * * | H | | H | # = MANET Border 316 +---+ +---+ +---+ Interface 318 Figure 3: Interconnected MANETs 320 The MANET Border Interface connects the two routing regions. Route 321 filtering and summarization can be configured. Border Interfaces are 322 typically not formed ad-hoc. 324 3.4. Stub MANET 326 Stub MANETs are connected to a Fixed Infrastructure or the Internet. 327 Connectivity to the Fixed Infrastructure is provided with default 328 routes. Connectivity to the Stub MANET can be provided with an 329 aggregated prefix. 331 +-------------------------------+ 332 | | 333 | Fixed Infrastructure | 334 | | 335 | R | 336 +-----------------------#-------+ 337 # 338 # 339 +--------------------#----+ 340 | Stub MANET # | 341 | # | 342 | ~MNR1 # | 343 | ~ ~ ~MNR2 | 344 | MNR3 ~ ~ ~ | 345 | ~ ~~~MNR4 ~ | 346 | MNR5~~~~~ ~~~MNR6 | 347 +-:------------------:----+ 348 : : 349 : : 350 +-+-+ +-+-+ 351 | H | * * * * * * | H | 352 +---+ +---+ 354 Figure 4: Stub MANET 356 A Stub MANET could have redundant MANET Border Interfaces. The Stub 357 MANET will not act as transit region. 359 3.5. Layered MANETs 361 MANETs can have a layered structure. Connection to the top level is 362 similar to a Fixed Infrastructure connection. The lowest level can 363 be configured as Stub MANETs. MANETs in the middle layers provide 364 transit services. 366 +---------------------------------------+ 367 | Top-level MANET | 368 | | 369 | :::::::R::::::::: | 370 | R R | 371 +----------------#---------------#------+ 372 # # 373 # # 374 +--------------------#----+ +---#---------------------+ 375 | Stub MANET2 # | | # MANET3 | 376 | # | | # (transit) | 377 | ~MNR1 # | | # | 378 | ~ ~ ~MNR2 | | MNR7~~~~~~~~~~~MNR8 | 379 | MNR3 ~ ~ ~ | | ~ ~~~ ~ | 380 | ~ ~~~~~~MNR4 ~ | | ~ ~~~~ ~ | 381 | MNR5 ~~~MNR6 | | MNR9 ~~MNR10 | 382 +-:------------------:----+ +--:---------------#------+ 383 : : : # 384 : : : # 385 +-+-+ +-+-+ +-+-+ +------#------+ 386 | H | * * * * * * | H | | H | | Stub MANET4 | 387 +---+ +---+ +---+ +-------------+ 389 Figure 5: Layered MANETs 391 Layered MANETs have a fixed structure. Mobility within the MANET is 392 supported. Dynamic border router formation between the MANETs is 393 currently not foreseen. 395 4. Fringe Stub models 397 In the (Wireless) Fringe Stub, an almost infinite wireless ad-hoc 398 topology is connected to a Fixed Infrastructure. The Fringe Stub is 399 not required to be continuous, the Fixed Infrastructure is used to 400 interconnect isolated segments. Mobile Routers can roam between 401 isolated segments without any reconfiguration. 403 In the Fringe Stub models, Layer-2 Access, Layer-2 Meshing, Mobile 404 IP, NEMO and MANET technologies are used. Deployed Fringe Stubs can 405 inherit characteristics of different models. 407 4.1. Layer-2 Access 409 Mobile nodes can use a layer-2 Access service provided by 410 telecommunication providers. Classical IP interfacing is used, so 411 special requirements are introduced. Depending on the provider or 412 the technology used, micro mobility or macro mobility is provided. 414 <--------------------------------------------------> 415 < > 416 < Fixed Infrastructure > 417 < > 418 < ::::::::::R:::::::::::::::::R:::::: > 419 < R R R > 420 <------BS----------------BS-------------BS---------> 421 : : : 422 : : : BS = Base Station 423 : : : 424 +-+-+ +-+-+ 425 | N | * * * * * * * * * * * * * | N | 426 +---+ +---+ 428 Figure 6: Layer-2 Access 430 4.2. Layer-2 Meshing 432 For reducing costs of the infrastructure or to extend area of reach, 433 Relay Stations can be used to enhance the Layer-2 Access model. This 434 provide also some kind of redundancy. When the Base Station is 435 isolated from the backbone, an alternative path via another Base 436 Station can be used. 438 <--------------------------------------------------> 439 < > 440 < Fixed Infrastructure > 441 < > 442 < ::::::::::R:::::::::::::::::R:::::: > 443 < R R R > 444 <------BS----------------BS-------------BS---------> 445 : : : 446 RN.. : : RN = Relay Node 447 : : : : 448 : ......RN : 449 : : 450 +-+-+ +-+-+ +-+-+ 451 | N | * * | N | * * * * * * * | N | 452 +---+ +---+ +---+ 454 Figure 7: Layer-2 Meshing 456 4.3. Node Mobility 458 MIP (MIP4 [13] and MIP6 [14]) provide mobility and handover 459 functionalities to mobile nodes. Mobile IP is targeted for providing 460 "macro mobility". It provides session continuity over different 461 heterogeneous network types and provides global roaming. "Micro 462 mobility" using link-layer mobility services would provide better 463 handover performance [13]. Optimizing handover using IP technology 464 is work-in-progress. 466 <--------------------------------------------------> 467 < > 468 < Fixed Infrastructure HA > 469 < CN > 470 < ::::::::::R:::::::::::::::::R:::::: > 471 < R R R > 472 <------:-----------------:--------------:----------> 473 : : : 474 : : : 475 : : : 476 +--+-+ +--+-+ 477 | MN | * * * * * * * * * * * * | MN | 478 +----+ +----+ 480 Figure 8: Node Mobility 482 The Home Agent (HA) takes care of reachability for served Mobile 483 Nodes. The Corresponding Nodes (CN) find the path to Mobile Nodes 484 via the HA. 486 4.4. Network Mobility 488 Network Mobility (NEMO basic, [9]) extends Mobile IP for roaming 489 subnets. Local Fixed Nodes (LFN) connected to the Mobile Router (MR) 490 benefit form the MR MIP service. 492 <--------------------------------------------------> 493 < > 494 < Fixed Infrastructure HA > 495 < CN > 496 < ::::::::::R:::::::::::::::::R:::::: > 497 < R R R > 498 <------:-----------------:--------------:----------> 499 : : : 500 : : : e: Egress Interface 501 : : : i: Ingress Interface 502 +--e-+ +----e----+ 503 | MR | * * * * * * * * | MR(s) | 504 +--i-+ +----i----+ 505 : : 506 ........... ................ 507 : : : : 508 +-+-+ +-+-+ +-+-+ +-+-+ 509 | H | | H | * | H | | R | 510 +---+ +---+ +---+ +-+-+ 511 : 512 +-+-+ 513 | H | 514 +---+ 516 Figure 9: Network Mobility 518 The MR serves local connected hosts and local connected routers, 519 called Local Fixed Nodes (LFN). The "Egress Interface" is used for 520 reaching the HA, either directly when at home or via the MIP tunnel 521 when the MR is at a foreign network. Mobility service is provided 522 via the "Ingress Interface" for a Mobile Subnet. 524 4.5. Nested NEMO 526 With NEMO, visiting mobile nodes are supported, this is because MRs 527 are able to connect to the Ingress interface of other MRs and 528 configure their CoAs/receive connectivity via the MR they are 529 temporarily attached to. Mobile Hosts are stubs, as they do not 530 provide forwarding. Nested Mobile Routers can form an arbitrary 531 level of nested HA tunnels. 533 <--------------------------------------------------> 534 < > 535 < Fixed Infrastructure HA > 536 < CN > 537 < ::::::::::R:::::::::::::::::R:::::: > 538 < R R R > 539 <------:-----------------:--------------:----------> 540 : : : 541 : : : 542 : : : 543 +--e-+ +----e----+ 544 | MR | * * * * * * * * | MR(s) | 545 +--i-+ +----i----+ 546 : : 547 ........... ................ 548 : : : : 549 +--+-+ +--e-+ +--e-+ +--+-+ 550 | MH | | MR | | MR | * * * * | MH | 551 +----+ +--i-+ +--i-+ +----+ 552 : : 553 +--+-+ ........ 554 | MH | : : 555 +----+ v v <-- Deeper nesting of MRs 557 Figure 10: Nested NEMO 559 Nested Mobile Routers form tree topologies. Pin-ball routing is 560 introduced, discussed in a section on Route Optimization below. 562 4.6. MANEMO 564 With MANEMO [21], [22], MANET technology is introduced in Nested 565 NEMO. The main goals are implementing NEMO Route Optimizing, 566 supporting floating Nested NEMO topologies and providing optimized 567 paths within the MANEMO Fringe Stub without using NEMO tunneling. 569 A suggested solution is using a tree discovery protocol [23]. The 570 tree structure is used for optimizing packet forwarding between 571 Mobile Nodes and the Exit Router [24], [25]. The tree can also be 572 used for inner-tree communication and multicast support. 574 Another suggested solution is to use direct communication between 575 1-hop neighbors by advertising the mobile subnet prefix using IPv6 576 Neighbor Discovery [25], [26]. 578 Also using MANET technology is suggested [22], [27]. 580 <-----------------------------------------------------> 581 < > 582 < Fixed Infrastructure HA > 583 < CN > 584 < ::::::::::R:::::::::::::::::::R:::::: > 585 < R ER R > 586 <------#--------------------#--------------#----------> 587 # # # 588 # # # 589 <-----#--------------------#--------------#----------> 590 < # MANEMO # # > 591 < # Fringe Stub # ER7 > 592 < ER1~ # ~ > 593 < ~ ~~ ~~~~~~MR2 ~ > 594 < MR3 ~ ~~~ ~~ MR8 > 595 < ~ ~~~MR4 ~~ ~ ~~ > 596 < MR5~~~~~ ~~~~MR6 MR9 MR10 > 597 <----:-----------------:--------------:--------:-----> 598 : : : : 599 : : : : 600 +-+-+ +-+-+ 601 | N | * * * * * * * * * * * * * * * * * | N | 602 +---+ +---+ 604 Figure 11: MANEMO 606 In MANEMO, the interface types Ingress, Egress and MANET could be 607 logical roles. Physical interfaces could have any role and policies 608 on MRs can limit the roles on particular interfaces. This relax the 609 definition of a NEMO MR [9]. 611 Exit Routers are Fixed Access routers running MANEMO protocols or top 612 level Mobile Routers. 614 MANEMO Fringe Stub is work in progress. MANET proactive, reactive 615 and source-routing technology is used in addition to Nested NEMO. 617 5. MANET and NEMO Characteristics 619 5.1. Scalability 621 MANET and NEMO have very different goals. MANET can provide 622 optimized paths within a limited topology, where NEMO provides 623 Internet scale end-to-end connectivity. Therefore, scalability 624 characteristics for MANET and NEMO are very different. 626 MANET scalability is researched and many improvements are proposed. 627 But still MANET networks have their limits, a large number (100 or 628 more) of Mobile Routers in a flat area is a topic for active research 629 [2]. Other technology must be used to provide Internet scale 630 deployment. 632 The OSPF MANET extension [28], [29] is applicable for a limited 633 number of routers interconnected with radio interfaces. Such a MANET 634 subnetwork would be part of an OSPF area, and OSPF (and BGP) routing 635 state flooding reduction mechanisms enable large scale deployment. 636 Many independent OSPF MANET subnetworks can de deployed, similar to 637 for example Ethernet segment scalability. 639 Other MANET protocols could use the same approach. A MANET domain 640 can be connected to a fixed infrastructure and route aggregation 641 hides routing state flooding. 643 NEMO makes use of the MIP tunnel overlay, hiding mobility on the 644 fixed Internet infrastructure. The number of mobile networks scales 645 with the number of home agents, and address aggregation enables huge 646 scale NEMO deployment. 648 5.2. Mobility 650 With MANET, a MNR can roam within an area where sufficient coverage 651 is available. When the number of MANs increase, coverage will 652 improve or the area will be enlarged. Scalability issues restrict 653 the number of MANs, which implies restrictions on mobility. Zoned or 654 hierarchical models are proposed, but world wide mobility would not 655 be provided by MANET. 657 With NEMO, "macro mobility" is inherited from Mobile IP. Worldwide 658 mobility can be provided for an almost unlimited number of MRs, all 659 having end-to-end connectivity. 661 For both MANET and NEMO, mobility is also related to radio coverage. 662 No coverage implies no connectivity. 664 5.3. HA dependency 666 MANET does not depend on Mobile IP and doesn't need a home agent. 668 NEMO extends Mobile IP using a Mobile Router. The Mobile Router 669 maintains a tunnel to its home agent. Traffic between LFN and CN 670 flows through the tunnel and thus the home agent is a critical 671 element for communication. HA dependency can be relaxed by HA 672 redundancy or new protocols, like Global HA to HA protocol (HAHA) 673 [17] / [18]. MIP and NEMO Route Optimization could also relax the HA 674 dependency. 676 For communication from a NEMO LFN to a far away CN, the HA dependency 677 may not be a problem. But for local communication, this could be 678 unacceptable, especially in military and public safety / emergency 679 response networks, where local communication availability is a 680 primary concern. 682 5.4. Route optimization 684 MANET protocols would select a shortest path (fewest hops, lowest 685 metric) or an optimized path based on cross-layer metrics. Problems 686 with optimized path selection based on fewest hop count are described 687 below in section Worst Path First Syndrome. 689 Currently, nested NEMO based on NEMO BS [9] lacks intelligent path 690 selection. RA sent by MR are equivalent to RA sent by a fixed Access 691 Router. Selecting an Attachement Router without any knowledge on 692 path metrics would select non-optimal paths. Nested NEMO has high 693 tunnel header overhead and a pinball route problem. Also route loops 694 can occur (NEMO RO) [10]. 696 5.5. Interface type 698 In the MANET architecture, a MANET-Interface is an interface with a 699 MANET protocol enabled. Typical behavior is the relay function, 700 incoming traffic on this interface can be relayed to serve other 701 nodes increasing connectivity in the MANET topology [30]. 703 In Mobility Related Terminology [7], The Ingress and Egress Interface 704 types are introduced. Terms are related to the NEMO mobile Router 705 model [9]. The Ingress Interface is the interface with the Mobile 706 Network Nodes connected to. The Egress Interface is the interface 707 the Mobile Router uses to attach to the fixed infrastructure. 709 When discussions started about integrating MANET and NEMO, the 710 difference between the MANET and Egress interface faded. Also a 711 discussion about the need for a MANEMO Ingress Interfaces started, as 712 in MANET there is no need for special handling, and in MANEMO any 713 router interface could be MANET enabled. For policy reasons, a 714 MANEMO router interface could be defined as Ingress only. 716 5.6. Multicast support 718 In MANET environment, classical multicast forwarding using a Reverse 719 Path Forwarding Check cannot be used. The MANET interface is used 720 for relaying IP packets, and a basic forwarding rule is broken, 721 specifying that an IP multicast packet is never sent back over the 722 incoming interface. 724 Multiple MANET multicast protocols are proposed, but many of them 725 showed large overhead for keeping state information. Currently the 726 MANET workgroup is working on SMF [5]. SMF use 2-hop neighbor state 727 provided by another protocol (currently NHDP [31]) for efficient 728 flooding combined with duplicate packet detection. 730 In NEMO, multicast service can be provided. Within the Mobile 731 Network itself, basic multicasting is used. Global multicast 732 supported can also be provided; the MR relays the multicast to the 733 HA, where the multicast flow is injected in the fixed infrastructure. 734 Receiving multicast from the fixed infrastructure is also supported, 735 the HA relays the multicast flow via the tunnel to the MR and the 736 FLNs. 738 Multicasting between nearby NEMO MRs would have large overhead, as 739 the multicast is lead over the HAs. Also multicast from the fixed 740 infrastructure to multiple nearby NEMO MRs is inefficient, as the 741 multicast flow is pseudo-broadcasted over multiple tunnels to these 742 MRs. Options for improved NEMO multicast support are proposed, e.g. 743 using MLD-proxy [32]. 745 6. Problems found in MANET and NEMO 747 This section is used as placeholder for problems in MANET or NEMO, 748 which are not maintained in separate IETF Problem Statement 749 documents. 751 6.1. Worst Path First Syndrome 753 Classic routing protocols use the hop-count as metric for best path 754 selecting. Hop-count is still used in modern MANET routing 755 protocols. For homogeneous topologies, where all links have similar 756 capabilities, this could be seen as sufficient. But when different 757 link types are used or link characteristics vary in time and on a 758 neighbor by neighbor basis, problems are introduced. Using cross- 759 layer information is seen as helpful for MANET environments[2]. 761 NEMO / nested NEMO do currently not select a path based on metrics. 763 The Worst Path First Syndrome is a name given to a behavior of a path 764 selection algorithm, selecting the path to a destination using the 765 fewest hops, but also the worst quality links. Using ad-hoc networks 766 with broadcast radios, link quality and data rate would be a function 767 of distance and influenced by obstacles. In the example below, a 768 high quality radio link uses a data rate of 11Mbps and has a packet 769 loss below 1%. A bad quality radio link uses a data rate of 1Mbps 770 and has a packet loss around 50%. 772 +----+ 773 | R1 | 774 +----+ 775 11Mbps / | 776 loss / | 777 <1% / | 1Mbps 778 +----+ | loss ~50% 779 | R2 | | 780 +----+ | 781 11Mbps \ | 782 loss \ | 783 <1% \ | 784 +----+ 785 | R3 | 786 +----+ 788 Figure 12: Worst Path First Syndrome Network Topology 790 R3 can select R1 or R2 as attachment router, router advertisements 791 from both R1 and R2 are received. A MANET protocol, selecting a path 792 based on hop-count, selects the direct path to R1. NEMO would select 793 R1 or R2, as it has no knowledge of the topology. 795 Selecting the direct path to R1 is the worst in terms of bandwidth 796 (1Mbps where 11Mbps is available), packet loss (50% where less than 797 2% is available) and used spectrum (single transmission over 1Mbps 798 takes more time for sending a packet than 2 times over 11Mbps). The 799 direct path to R1 would require more retransmissions if reliable data 800 transfer is supported. 802 In a heterogeneous topology, the problem becomes totally 803 unacceptable. Imagine that the three Rs are temporally "on the 804 pause" and R2 and R3 are near to each other. Because R3 has bad user 805 experience, it can be serviced by using cabling to R2 and the 806 bandwidth is increased to 100Mbps and the packet loss is zero. 807 Still, user experience is not enhanced at all, and R1 would be 808 selected. 810 Defining solutions for this problem is out of scope of this document. 811 A suggested approach is using path metrics based on cross layer 812 metrics. 814 6.2. Break Before Make problem 816 The Break Before Make (BBM) [7], problem occurs when links suddenly 817 fail and there is no pre-warning mechanism. Classic routing 818 protocols suffer from BBM, as problems in fixed infrastructures are 819 mostly caused by equipment failures and these problems are hard to 820 predict. Modern protocols have support for L2-triggers, speeding up 821 connection repair time. 823 Graceful shutdown is a mechanism that is for predicted outages. 824 Before the outage, neighbors are signaled the node or link is taken 825 out of service and an alternative path is selected, if available. In 826 a wireless infrastructure, especially when elements are moving, link 827 quality is varying and getting out-of-reach can be detected by 828 layer-2 mechanisms or by detecting packet loss, e.g. provided by a 829 hello protocol. The decreased link quality can be signaled to the 830 neighbors, and alternative paths can be selected before the link 831 breaks. Such concepts are called Make Before Break (MBB) [7]. 833 When hop count metrics are used, varying link quality is not taken 834 into account and links are used until the become really out of reach. 835 This is similar to the WPF syndrome described above. 837 Defining solutions for this problem is out of scope of this document. 838 A suggested approach is using path metrics based on cross layer link 839 metrics. 841 6.3. Routing loops in proactive routing protocols 843 Loops in classical unicast routing could take place when an interface 844 state changes. When an interface goes down, the routing table is 845 adjusted quickly for removing entries with a next hop via this 846 interface. Alternative routes could be used quickly also. Other 847 router routing tables are updated after routing protocol activity; 848 this could take milliseconds up to minutes, depending on protocol and 849 timer settings. During this convergence, routing loops can occur and 850 packet starvation is handled by TTL mechanism. 852 On wireless media, using TTL for starvation could have a high impact 853 on radio resources and spectrum utilization. 855 In the following scenario, a hop-count based metric is used. Routers 856 are located around an obstacle and a ring topology is formed due to 857 radio propagation. In the scenario, R5 is moving away from R4. 859 +----+ +----+ +----+ 860 | R1 |--------| R2 |--------| R3 | 861 +----+ +----+ +----+ 862 | | 863 | =+=+= obstacle =+=+ | 864 | | 865 +----+ +----+ 866 | R4 |----------------------| R5 | R5 moves this way ---> 867 +----+ +----+ 869 Figure 13: MANET routing loop scenario 871 When R5 is moved, the neighbor state for R4 and R5 goes down. 873 +----+ +----+ +----+ 874 | R1 |--------| R2 |--------| R3 | 875 +----+ +----+ +----+ 876 | \ 877 | =+=+= obstacle =+=+ \ 878 | \ 879 +----+ +----+ 880 | R4 | | R5 | R5 moves this way ---> 881 +----+ +----+ 882 Figure 14: Neighbor down detected 884 R4 and R5 detect the change due to the hello mechanism or L2 885 triggers. After R4 is aware of the failure, it immediately adjusts 886 its routing table. It uses R1 as next hop for traffic to R5. 887 However, R1 is still not aware of the topology change and still uses 888 R4 as next hop for traffic towards R5. Now the routing loop occurs: 890 +----+ +----+ +----+ 891 | R1 |--------| R2 |--------| R3 | 892 +----+ +----+ +----+ 893 ^ | \ 894 Loop: | | =+=+= obstacle =+=+ \ 895 | v \ 896 +----+ +----+ 897 | R4 | | R5 | R5 moved 898 +----+ +----+ 900 Figure 15: Transit during MANET convergence 902 The loop is solved as soon as R1 is aware of the new topology. Time 903 for convergence is caused by routing protocol packet transfer, timers 904 and processing time. Protocol timers that slow down packet transfer 905 or introduce jitter in SPF calculation increase convergence time and 906 thus loop duration. So jitter introduced by 907 draft-clausen-manet-jitter emphasizes the routing loop problem. 909 Defining solutions for this problem is out of scope of this document. 910 A suggested approach is using a) path metrics based on cross layer 911 metrics; b) implementing a reverse path check on the previous 912 forwarder address, when this address is available and c) implementing 913 a duplicate packet detection mechanism. 915 6.4. Congested link avoidance 917 In MANET environment, the shortest path mechanism can select a link 918 connecting two MANET islands for relaying all traffic flows between 919 these islands. This is also the case when many exit routers to a 920 high speed backbone are available. 922 <---------------------------------------------------> 923 < > 924 < Fixed Infrastructure > 925 < > 926 < ::::::::::R:::::::::::::::::::R:::::: > 927 < R ER R > 928 <------#--------------------#--------------#--------> 929 # # # 930 # # # 931 +-----#--------------------#--------------#--------+ 932 | # MANET # # | 933 | # # ER7 | 934 | ER1~ # ~ | 935 | ~ ~~ ~~~~~~MR2,,,, ~ | 936 | MR3 ~ ~~~ ~~ ,,,,,,,,MR8 | 937 | ~ ~~~MR4 ~~ ~ ~~ | 938 | MR5~~~~~ ~~~~MR6 MR9 MR10 | , = Congested 939 +----:-----------------:--------------:-------:----+ MANET Link 940 : : : : 941 : : : : 942 +-+-+ +-+-+ 943 | H | * * * * * * * * * * * * * * * * | H | 944 +---+ +---+ 946 Figure 16: Congested link in MANET 948 In (Nested) NEMO, low bandwidth paths to scarce exit routers can 949 become congested, also caused by local traffic. Unoptimized tree 950 topologies can also introduce congestion. 952 <----------------------------------------------------> 953 < > 954 < Fixed Infrastructure HA > 955 < CN > 956 < ::::::::::R:::::::::::::::::::R:::::: > 957 < R ER R > 958 <------#--------------------#--------------#---------> 959 # # # 960 ; # # 961 <-----;--------------------#--------------#--------> 962 < ; Nested # # > 963 < ; NEMO # ER7 > 964 < ER1. # : > 965 < : .. MR2 : > 966 < MR3 : MR8 > 967 < : ...MR4 : :. > 968 < MR5 :....MR6 MR9 MR10 > ; = Congested 969 <----:-----------------:--------------:--------:---> Nested NEMO 970 : : : : Link 971 : : : : 972 +-+-+ +-+-+ 973 | H | * * * * * * * * * * * * * * * * | H | 974 +---+ +---+ 976 Figure 17: Congested link in Nested NEMO 978 In wireless infrastructures, using bandwidth efficiently is a primary 979 concern. Advanced QoS mechanisms are needed, utilizing radio 980 interface characteristics. Call admission control mechanisms like 981 RSVP should be considered, especially for real-time traffic. 983 Attention is required for bridging layer-2 devices, where the router 984 and the layer-2 device are linked with a high speed interface. Flow 985 control and layer-2 metric transfer between router and the layer-2 986 device as described in "PPP Over Ethernet (PPPoE) Extensions for 987 Credit Flow and Link Metrics" [33] can solve introduced problems. 989 Also attention is required for an ad-hoc dense crowd of nodes 990 requiring lots of bandwidth. In such a scenario, available 991 transmission means will be overloaded. 993 6.5. MANET and NEMO at home problem 995 In MIP, a Mobile Node is at home when it is connected to the Home 996 Link. For wireless nodes in the home region, a MANET protocol could 997 be used for extending the home link, using the HA as exit router. 999 This introduces a problem, the node could be classified as "at home" 1000 because it can reach any CN using the MANET and its own HA as exit 1001 router, but it is also "far form home" because it is not on the home 1002 link, in the meaning that it does not receive HA RA with the Home 1003 Agent Information Option. 1005 <---------------------------------------> 1006 < CN > 1007 < Fixed Infrastructure > 1008 < > 1009 < HA > 1010 <------------------#----|---------------> 1011 # | 1012 ~ | 1013 +---------------~----|-------+ 1014 | MANET ~ | | 1015 | and ~ | HAIO received by MR1, not by MR2 1016 | Nested MR1 V | 1017 | NEMO ~ | 1018 | ~ | 1019 | MR2 | 1020 +----------------------------+ 1022 Figure 18: MANET and NEMO at home detection 1024 MR1 receives the HA RA with HAIO, thus MR1 is at home. MR2 is not 1025 receiving the HAIO and is thus far from home. But MR2 is able to 1026 communicate with the fixed infrastructure using MANET routing and the 1027 HA acting as MANET Border Router. 1029 Another problem is introduced when the MANET protocol is used on the 1030 NEMO tunnel. This introduces a routing shortcut, the native MANET 1031 route is in parallel with the MANET route via the NEMO tunnel. The 1032 next hop to the HA and thus to the NEMO tunnel endpoint could be 1033 learned through the tunnel, this introduces tunnel interface 1034 instability. 1036 <---------------------------------------> 1037 < CN > 1038 < Fixed Infrastructure > 1039 < > 1040 < ^ ^ HA > 1041 <-----------------|--|---#--------------> 1042 | | # 1043 n t ~ 1044 +--------------a--u---~----------+ 1045 | MANET t n ~ | 1046 | and i n ~ | 1047 | Nested v e MR1 | 1048 | NEMO e l ~ | 1049 | | | ~ | 1050 | v v MR2 | 1051 +--------------------------------+ 1053 Figure 19: MANET and NEMO at home routing shortcut 1055 The impact of the MANET and NEMO at home routing shortcut problem is 1056 to be analyzed. Problem areas are tunnel instability and multicast 1057 packets sent to HA via MANET and the tunnel. 1059 6.6. MANET scale to infinity problem when peering to strangers 1061 In a dense deployment of MANET routers, all configured for roaming in 1062 a large area and peering to all other routers, the MANET will melt 1063 down due to flooding topology information from any to all. A sample 1064 scenario is car to car communication in a metropolis with say a 1065 million cars. Current IETF MANET protocols provide a flat routing 1066 domain, where reachability is provided between ALL MANET routers. 1068 In a chain of MANET routers, where each router has two neighbors (or 1069 one neighbor on the end routers), there is no problem with neighbor 1070 discovery or 2-hop neighbor state maintenance. But prefix flooding 1071 (proactive routing) or route requests (reactive routing) are flooded 1072 over all routers in the MANET. 1074 This problem occurs independent of the existence of a fixed backbone 1075 infrastructure. 1077 +------+ +------+ +------+ +------+ +------+ +------+ 1078 | MNR1 |~~~| MNR2 |~~~| MNR3 |~~<> ~| MNRx |~~~| MNRy |~~~| MNRz | 1079 +------+ +------+ +------+ +------+ +------+ +------+ 1080 Figure 20: Infinite chain of MANET routers 1082 Some would suggest MANETs can be designed for using hierarchy. 1083 Current IETF MANET protocols do not support such. Others would 1084 suggest automatic hierarchy can be added in future extensions on the 1085 basic protocol. There is no evidence that options for such are 1086 realistic. 1088 7. IANA considerations 1090 This document does not require any IANA action. 1092 8. Security Considerations 1094 This document does not create any security threat. It discusses and 1095 analyses the concepts of MANET and NEMO. 1097 9. Acknowledgments 1099 I would like to thank all the people involved in MANET and NEMO 1100 technology. I would particularly like to thank (in alphabetical 1101 order) people involved in MANEMO: Jari Arkko, Thomas Clausen, Ian 1102 Chakeres, Ben McCarthy, Alexandru Petrescu, Pascal Thubert, Ryuji 1103 Wakikawa and all that I forgot. 1105 10. References 1107 10.1. Normative reference 1109 10.2. Informative Reference 1111 [1] Corson, M. and J. Macker, "Mobile Ad hoc Networking (MANET): 1112 Routing Protocol Performance Issues and Evaluation 1113 Considerations", RFC 2501, January 1999. 1115 [2] Chakeres, I., "Mobile Ad hoc Network Architecture", 1116 draft-chakeres-manet-arch-01 (work in progress), October 2006. 1118 [3] Clausen, T., "The Optimized Link State Routing Protocol version 1119 2", draft-ietf-manet-olsrv2-03 (work in progress), March 2007. 1121 [4] Perkins, C. and I. Chakeres, "Dynamic MANET On-demand (DYMO) 1122 Routing", draft-ietf-manet-dymo-09 (work in progress), 1123 May 2007. 1125 [5] Macker, J., "Simplified Multicast Forwarding for MANET", 1126 draft-ietf-manet-smf-04 (work in progress), March 2007. 1128 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1129 Levels", BCP 14, RFC 2119, March 1997. 1131 [7] Manner, J. and M. Kojo, "Mobility Related Terminology", 1132 RFC 3753, June 2004. 1134 [8] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 1135 draft-ietf-nemo-terminology-06 (work in progress), 1136 November 2006. 1138 [9] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 1139 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 1140 January 2005. 1142 [10] Ng, C., "Network Mobility Route Optimization Problem 1143 Statement", draft-ietf-nemo-ro-problem-statement-03 (work in 1144 progress), September 2006. 1146 [11] Ng, C., "Network Mobility Route Optimization Solution Space 1147 Analysis", draft-ietf-nemo-ro-space-analysis-03 (work in 1148 progress), September 2006. 1150 [12] Clausen, T., "NEMO Route Optimisation Problem Statement", 1151 draft-clausen-nemo-ro-problem-statement-01 (work in progress), 1152 March 2007. 1154 [13] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 1155 August 2002. 1157 [14] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1158 IPv6", RFC 3775, June 2004. 1160 [15] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1162 [16] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", 1163 RFC 2740, December 1999. 1165 [17] Thubert, P., "Global HA to HA protocol", 1166 draft-thubert-nemo-global-haha-02 (work in progress), 1167 September 2006. 1169 [18] Devarapalli, V., "Local HA to HA protocol", 1170 draft-devarapalli-mip6-nemo-local-haha-01 (work in progress), 1171 March 2006. 1173 [19] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 1174 for IP Version 6 (IPv6)", RFC 2461, December 1998. 1176 [20] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., 1177 Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice 1178 for Internet Subnetwork Designers", BCP 89, RFC 3819, 1179 July 2004. 1181 [21] Wakikawa, R., "MANEMO Problem Statement", 1182 draft-wakikawa-manemo-problem-statement-00 (work in progress), 1183 February 2007. 1185 [22] Wakikawa, R., "MANEMO Architecture", 1186 draft-wakikawa-manemoarch-00 (work in progress), June 2007. 1188 [23] Thubert, P., "Nested Nemo Tree Discovery", 1189 draft-thubert-tree-discovery-05 (work in progress), April 2007. 1191 [24] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and 1192 its application to Mobile Networks", 1193 draft-thubert-nemo-reverse-routing-header-07 (work in 1194 progress), February 2007. 1196 [25] Thubert, P., "Network In Node Advertisement", 1197 draft-thubert-nina-00 (work in progress), February 2007. 1199 [26] Petrescu, A. and C. Janneteau, "The NANO Draft (Scene Scenario 1200 for Mobile Routers and MNP in RA)", 1201 draft-petrescu-manemo-nano-00 (work in progress), March 2007. 1203 [27] Clausen, T., "A MANET Architecture Model", Rapport de 1204 Recherche, Technical Report, INRIA Institut National de 1205 Recherche en Informatique et en Automatique, ISSN 0249- 1206 6399 RR_MANET_Architectural_Model.pdf, March 2007. 1208 [28] Spagnolo, P. and R. Ogier, "MANET Extension of OSPF using CDS 1209 Flooding", draft-ogier-manet-ospf-extension-09 (work in 1210 progress), March 2007. 1212 [29] Roy, A. and M. Chandra, "Extensions to OSPF to Support Mobile 1213 Ad Hoc Networking", draft-chandra-ospf-manet-ext-04 (work in 1214 progress), January 2007. 1216 [30] Templin, F., "Observations on "Link" in MANET/Autoconf and 1217 Other Contexts", draft-templin-manet-autoconf-link-00 (work in 1218 progress), August 2006. 1220 [31] Clausen, T., "MANET Neighborhood Discovery Protocol (NHDP)", 1221 draft-ietf-manet-nhdp-03 (work in progress), May 2007. 1223 [32] Janneteau, C., "IPv6 Multicast for Mobile Networks with MLD- 1224 Proxy", draft-janneteau-nemo-multicast-mldproxy-00 (work in 1225 progress), April 2004. 1227 [33] Berry, B. and H. Holgate, "PPP Over Ethernet (PPPoE) Extensions 1228 for Credit Flow and Link Metrics", draft-bberry-pppoe-credit-06 1229 (work in progress), November 2006. 1231 Appendix A. Change Log 1233 A.1. Changes from version 00 to 01 1235 Added MANET and Fringe Stub models sections. 1237 Added Routing Loop problem in proactive protocols. 1239 Added Break Before Make problem. 1241 Added Congested Link problem. 1243 Added MANET and NEMO at home problem. 1245 Added MANET scale to infinity problem when peering to strangers. 1247 Author's Address 1249 Teco Boot 1250 Infinity Networks B.V. 1251 Elperstraat 4 1252 Schoonloo 9443TL 1253 Netherlands 1255 Email: teco@inf-net.nl 1257 Full Copyright Statement 1259 Copyright (C) The IETF Trust (2007). 1261 This document is subject to the rights, licenses and restrictions 1262 contained in BCP 78, and except as set forth therein, the authors 1263 retain all their rights. 1265 This document and the information contained herein are provided on an 1266 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1267 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1268 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1269 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1270 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1271 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1273 Intellectual Property 1275 The IETF takes no position regarding the validity or scope of any 1276 Intellectual Property Rights or other rights that might be claimed to 1277 pertain to the implementation or use of the technology described in 1278 this document or the extent to which any license under such rights 1279 might or might not be available; nor does it represent that it has 1280 made any independent effort to identify any such rights. Information 1281 on the procedures with respect to rights in RFC documents can be 1282 found in BCP 78 and BCP 79. 1284 Copies of IPR disclosures made to the IETF Secretariat and any 1285 assurances of licenses to be made available, or the result of an 1286 attempt made to obtain a general license or permission for the use of 1287 such proprietary rights by implementers or users of this 1288 specification can be obtained from the IETF on-line IPR repository at 1289 http://www.ietf.org/ipr. 1291 The IETF invites any interested party to bring to its attention any 1292 copyrights, patents or patent applications, or other proprietary 1293 rights that may cover technology that may be required to implement 1294 this standard. Please address the information to the IETF at 1295 ietf-ipr@ietf.org. 1297 Acknowledgment 1299 Funding for the RFC Editor function is provided by the IETF 1300 Administrative Support Activity (IASA).