idnits 2.17.1 draft-lavenu-lln-loadng-interoperability-report-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 24, 2011) is 4568 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Lavenu 3 Internet-Draft EDF R&D 4 Intended status: Informational T. Clausen 5 Expires: April 26, 2012 A. Camacho 6 J. Yi 7 A. Colin de Verdiere 8 LIX, Ecole Polytechnique 9 Y. Igarashi 10 SATOH. H. 11 Y. Morii 12 Hitachi, Ltd., Yokohama Research 13 Laboratory 14 October 24, 2011 16 Experience with the LOADng routing protocol for LLNs 17 draft-lavenu-lln-loadng-interoperability-report-00 19 Abstract 21 This document reports experience with the LOADng routing protocol for 22 LLNs which is specified in the draft-clausen-lln-loadng internet 23 draft. This report is providing information resulting from 24 interoperability testing performed at Hitachi YRL facilities in 25 Yokohama, Japan, from october 17th to october 19th 2011. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 26, 2012. 44 Copyright Notice 46 Copyright (c) 2011 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 This document may contain material from IETF Documents or IETF 60 Contributions published or made publicly available before November 61 10, 2008. The person(s) controlling the copyright in some of this 62 material may not have granted the IETF Trust the right to allow 63 modifications of such material outside the IETF Standards Process. 64 Without obtaining an adequate license from the person(s) controlling 65 the copyright in such materials, this document may not be modified 66 outside the IETF Standards Process, and derivative works of it may 67 not be created outside the IETF Standards Process, except to format 68 it for publication as an RFC or to translate it into languages other 69 than English. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 3. Implementations . . . . . . . . . . . . . . . . . . . . . . . 6 76 4. Interoperability Testing . . . . . . . . . . . . . . . . . . . 6 77 4.1. Testbed configuration . . . . . . . . . . . . . . . . . . 7 78 4.2. 1-hop bidirectional route establishment . . . . . . . . . 7 79 4.2.1. Topology . . . . . . . . . . . . . . . . . . . . . . . 7 80 4.2.2. Forward Route and Reverse Route initial 81 installation . . . . . . . . . . . . . . . . . . . . . 7 82 4.2.3. Forward Route and Reverse Route updating . . . . . . . 8 83 4.2.4. Obtained results . . . . . . . . . . . . . . . . . . . 9 84 4.3. 2-hop bidirectional route establishment . . . . . . . . . 9 85 4.3.1. Topology . . . . . . . . . . . . . . . . . . . . . . . 9 86 4.3.2. Forward Route and Reverse Route initial 87 installation . . . . . . . . . . . . . . . . . . . . . 10 88 4.3.3. Forward Route and Reverse Route updating . . . . . . . 11 89 4.3.4. Link breakage handling . . . . . . . . . . . . . . . . 12 90 4.3.5. Obtained results . . . . . . . . . . . . . . . . . . . 13 91 4.4. 4-hop bidirectional route establishment . . . . . . . . . 13 92 4.4.1. Topology . . . . . . . . . . . . . . . . . . . . . . . 13 93 4.4.2. Forward Route and Reverse Route initial 94 installation . . . . . . . . . . . . . . . . . . . . . 14 95 4.4.3. Forward Route and Reverse Route updating . . . . . . . 15 96 4.4.4. Link breakage handling . . . . . . . . . . . . . . . . 17 97 4.4.5. Obtained results . . . . . . . . . . . . . . . . . . . 18 98 4.5. 4-hop bidirectional route establishment . . . . . . . . . 19 99 4.5.1. Topology . . . . . . . . . . . . . . . . . . . . . . . 19 100 4.5.2. Forward Route and Reverse Route initial 101 installation . . . . . . . . . . . . . . . . . . . . . 19 102 4.5.3. Link breakage handling . . . . . . . . . . . . . . . . 21 103 4.5.4. Obtained results . . . . . . . . . . . . . . . . . . . 22 104 4.6. Establishment of the best bidirectional route . . . . . . 23 105 4.6.1. Topology . . . . . . . . . . . . . . . . . . . . . . . 23 106 4.6.2. Description . . . . . . . . . . . . . . . . . . . . . 23 107 4.6.3. Obtained results . . . . . . . . . . . . . . . . . . . 24 108 4.7. Blacklisting . . . . . . . . . . . . . . . . . . . . . . . 25 109 4.7.1. Topology . . . . . . . . . . . . . . . . . . . . . . . 25 110 4.7.2. Description . . . . . . . . . . . . . . . . . . . . . 25 111 4.7.3. Obtained results . . . . . . . . . . . . . . . . . . . 28 112 4.8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . 29 113 5. Security Considerations . . . . . . . . . . . . . . . . . . . 30 114 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 115 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31 116 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 117 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 118 9.1. Normative References . . . . . . . . . . . . . . . . . . . 31 119 9.2. Informative References . . . . . . . . . . . . . . . . . . 31 121 1. Introduction 123 This document reports about the interoperability tests carried out at 124 Hitachi YRL facilities in Yokohama, Japan, from october 17th to 125 october 19th 2011 for different implementations of the LOADng (LLN 126 On-demand Ad hoc Distance-vector - Next Generation) routing protocol. 128 Interoperability tests between LOADng Routers implemented on the 129 basis of the draft-clausen-lln-loadng internet draft have been run 130 mainly for the following purposes : 132 o Show evidence that interoperable LOADng implementations do exist. 134 o Clarify and improve the overall quality of the LOADng 135 specification. 137 o Demonstrate that the final LOADng internet draft can be considered 138 as a standalone specification allowing the development of 139 interoperable implementations of LOADng. 141 2. Terminology 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 145 "OPTIONAL" in this document are to be interpreted as described in 146 [RFC2119]. 148 Additionally, this document uses the following terminology: 150 LOADng Router - A router which implements this routing protocol. 152 Destination - The address of a router or host, to which a route is 153 sought discovered and maintained. 155 Originator - The address of a router, which seeks to discover and 156 maintain a route to a Destination. 158 Forward Route - A route set up so as to send data packets from the 159 Originator to the Destination. The Forward Route is set up when a 160 LOADng Router forwards Route Reply (RREP) messages. 162 Reverse Route - A route set up so as to send data packets from the 163 Destination to the Originator. The Reverse Route is set up when a 164 LOADng Router forwards Route Request (RREQ) messages. It is used 165 for forwarding RREP messages, as well as for forwarding data 166 packets. 168 Route Cost - The sum of the Link Costs for the links that a RREQ or 169 RREP has crossed. 171 Weak Link - A link which is marginally usable, i.e., MAY be used if 172 no other links are available, but SHOULD be avoided if at all 173 possible - even if it entails an ultimately longer path. As an 174 example, a Weak Link might be defined as a link with a significant 175 loss-rate. 177 This document employs the same notational conventions as in 178 [RFC5444]. 180 3. Implementations 182 Several LOADng implementations are currently available. This section 183 is listing the implementations that have been used to perform the 184 interoperability tests this document is reporting about (listed in 185 alphabetical order) : 187 Ecole Polytechnique : "LIX" - This implementation was jointly 188 developed by Axel Colin de Verdiere, Jiazi Yi, Ulrich Herberg and 189 Thomas Clausen of Ecole Ploytechnique's networking team. It 190 consists of approximately 6000 lines of JAVA code running in a Mac 191 OS environment. It supports RREQ, RREP, RREP-ACK and RERR 192 generation, processing, forwarding and transmission. 194 Hitachi YRL 1 : "Hitachi 1" - This implementation was fully 195 developed by Yuichi Igarashi of Hitachi YRL. It consists of 1589 196 lines of C code running in the Hitachi proprietary micro OS 197 environment embedded in a 16MHz H8 micro processor. It supports 198 RREQ, RREP, RREP-ACK and RERR generation, processing, forwarding 199 and transmission. 201 Hitachi YRL 2 : "Hitachi 2" - This implementation was jointly 202 developed by Nobukatsu Inomata of Hitachi ULSI Systems and Yoko 203 Morii of Hitachi YRL. It consists of 1987 lines of C++ code 204 running in a Mac OS environment. It supports RREQ, RREP, RREP-ACK 205 generation, processing, forwarding and transmission, and RERR 206 processing. 208 4. Interoperability Testing 210 This section is describing all the tests carried out between the 211 implementations that are previously considered in this document. 213 4.1. Testbed configuration 215 The testbed was composed of up to five LOADng Routers put together 216 according to the different topologies described hereunder. The 217 LOADng routing protocol were run over UDP, IPv4 and Ethernet. 218 Wireshark packet sniffers, that have been modified to interpret 219 LOADng control traffic, were used to monitor each single underlying 220 link. 222 For each test, the initiation of the communication resulting in the 223 generation of the first LOADng control traffic message is always 224 triggered manually. In addition, RREP-ACK LOADng control messages 225 were systematically expected from each LOADng Router upon reception 226 of a RREP LOADng control message in order to allow the detection of 227 unidirectional links. 229 4.2. 1-hop bidirectional route establishment 231 4.2.1. Topology 233 The testbed is composed of two LOADng Routers : 235 +-------+ +-------+ 236 | A |________| B | 237 | | | | 238 +-------+ +-------+ 240 Routers A and B are embedding a different implementation of LOADng. 241 This test was performed between all previously considered 242 implementations. 244 This test suite consists in establishing a bidirectional route 245 between LOADng Router A and LOADng Router B. 247 4.2.2. Forward Route and Reverse Route initial installation 249 For each implementation, this test aims to verifiy the initial 250 installation of a bidirectional route (Forward Route and Reverse 251 Route from A to B) within the LOADng Router routing tables (Routing 252 Sets) through the effective generation and processing of LOADng 253 control messages (RREQ, RREP, RREP-ACK). 255 The expected message sequencing is as follows : 257 o LOADng Router A generates a RREQ message intended for LOADng 258 Router B. 260 o Upon receiving the RREQ, LOADng Router B installs a new entry in 261 its Routing Set towards LOADng Router A (Reverse Route from LOADng 262 Router B to LOADng Router A) and sends an unicast RREP message 263 intended for LOADng Router A. The field of the sent RREP 264 message is set to "ACK-REQUIRED". 266 o Upon receiving the RREP, LOADng Router A installs a new entry in 267 its Routing Set towards LOADng Router B (Forward Route from LOADng 268 Router A to LOADng Router B) and sends an unicast RREP-ACK message 269 to LOADng Router B. 271 A B 272 | RREQ | 273 --------------------> 274 | RREP | 275 <-------------------- 276 | RREP-ACK | 277 --------------------> 278 | | 280 4.2.3. Forward Route and Reverse Route updating 282 For each implementation, this test aims to verifiy the refreshment of 283 a bidirectional route (Forward Route and Reverse Route from A to B) 284 already installed within the LOADng Router routing tables (Routing 285 Sets) through the effective generation and processing of LOADng 286 control messages (RREQ, RREP, RREP-ACK). 288 The expected message sequencing is as follows : 290 o LOADng Router A generates a RREQ message intended for LOADng 291 Router B. 293 o Upon receiving the RREQ, LOADng Router B updates the corresponding 294 route (Reverse Route from LOADng Router B to LOADng Router A) 295 already installed within its Routing Set and sends an unicast RREP 296 message intended for LOADng Router A. The field of the 297 sent RREP message is set to "ACK-REQUIRED". 299 o Upon receiving the RREP, LOADng Router A updates the corresponding 300 route (Forward Route from LOADng Router A to LOADng Router B) 301 already installed within its Routing Set and sends an unicast 302 RREP-ACK message to LOADng Router B. 304 A B 305 | RREQ | 306 --------------------> 307 | RREP | 308 <-------------------- 309 | RREP-ACK | 310 --------------------> 311 | | 313 4.2.4. Obtained results 315 The following table is summarizing the results obtained for the 316 different combinations for which test 1 (Forward Route and Reverse 317 Route initial installation) was performed : 319 +-----------+------+-----------+-----------+ 320 | | LIX | Hitachi 1 | Hitachi 2 | 321 +-----------+------+-----------+-----------+ 322 | LIX | N/R | Pass | Pass | 323 | Hitachi 1 | Pass | N/R | Pass | 324 | Hitachi 2 | Pass | Pass | N/R | 325 +-----------+------+-----------+-----------+ 327 Table 1 329 The following table is summarizing the results obtained for the 330 different combinations for which test 2 (Forward Route and Reverse 331 Route updating) was performed : 333 +-----------+------+-----------+-----------+ 334 | | LIX | Hitachi 1 | Hitachi 2 | 335 +-----------+------+-----------+-----------+ 336 | LIX | N/R | Pass | Pass | 337 | Hitachi 1 | Pass | N/R | Pass | 338 | Hitachi 2 | Pass | Pass | N/R | 339 +-----------+------+-----------+-----------+ 341 Table 2 343 4.3. 2-hop bidirectional route establishment 345 4.3.1. Topology 347 The testbed is composed of three LOADng Routers. Control traffic 348 generated by either LOADng Router A towards LOADng Router C or LOADng 349 Router C towards LOADng Router A has to be forwarded by LOADng Router 350 B : 352 +-------+ +-------+ +-------+ 353 | A |________| B |________| C | 354 | | | | | | 355 +-------+ +-------+ +-------+ 357 This test suite consists in establishing a bidirectional route 358 between LOADng Router A and LOADng Router C. 360 4.3.2. Forward Route and Reverse Route initial installation 362 This test aims to verify the initial installation of a bidirectional 363 route (Forward Route and Reverse Route from A to C) within the LOADng 364 Router routing tables (Routing Sets) through the effective forwarding 365 of LOADng control traffic by LOADng Router B which is located between 366 LOADng Router A and LOADng Router C. It is also verified that RREP- 367 ACK messages are not forwarded by the LOADng Routers these messages 368 are intended for. 370 The expected message sequencing is as follows : 372 o LOADng Router A generates a RREQ message intended for LOADng 373 Router C. 375 o Upon receiving the RREQ, LOADng Router B installs a new entry in 376 its Routing Set towards LOADng Router A (Reverse Route from LOADng 377 Router B to LOADng Router A) and forwards the received RREQ. 379 o Upon receiving the RREQ, LOADng Router C installs a new entry in 380 its Routing Set towards LOADng Router A (Reverse Route from LOADng 381 Router C to LOADng Router A) and a new entry towards LOADng Router 382 B (Reverse route from LOADng Router C to LOADng Router B). The 383 reception of the RREQ also triggers the generation of an unicast 384 RREP message intended for LOADng Router A. The field of 385 the sent RREP message is set to "ACK-REQUIRED". 387 o Upon receiving the RREP, LOADng Router B installs a new entry in 388 its Routing Set towards LOADng Router C (Forward Route from LOADng 389 Router B to LOADng Router C), sends an unicast RREP-ACK message to 390 LOADng Router C and forwards the RREP received previously. 392 o Upon receiving the RREP, LOADng Router A installs a new entry in 393 its Routing Set towards LOADng Router B (Forward Route from LOADng 394 Router A to LOADng Router B) and a new entry towards LOADng Router 395 C (Forward Route from LOADng Router A to LOADng Router C). The 396 reception of the RREP also triggers an unicast RREP-ACK message 397 intended for LOADng Router B. 399 A B C 400 | RREQ | | 401 --------------------> | 402 | | RREQ | 403 | --------------------> 404 | | RREP | 405 | <-------------------- 406 | | RREP-ACK | 407 | --------------------> 408 | RREP | | 409 <-------------------- | 410 | RREP-ACK | | 411 --------------------> | 412 | | | 414 4.3.3. Forward Route and Reverse Route updating 416 This test aims to verify the refreshment of a bidirectional route 417 (Forward Route and Reverse Route from A to C) already installed 418 within the LOADng Router routing tables (Routing Sets) through the 419 effective forwarding of LOADng control traffic by LOADng Router B 420 which is located between LOADng Router A and LOADng Router C. 422 The expected message sequencing is as follows : 424 o LOADng Router A generates a RREQ message intended for LOADng 425 Router C. 427 o Upon receiving the RREQ, LOADng Router B updates the corresponding 428 route (Reverse Route from LOADng Router B to LOADng Router A) 429 already installed within its Routing Set and forwards the received 430 RREQ. 432 o Upon receiving the RREQ, LOADng Router C updates the corresponding 433 routes (Reverse Routes from LOADng Router C to LOADng Router A and 434 from LOADng Router C to LOADng Router B). The reception of the 435 RREQ also triggers the generation of an unicast RREP message 436 intended for LOADng Router A. The field of the sent RREP 437 message is set to "ACK-REQUIRED". 439 o Upon receiving the RREP, LOADng Router B updates the corresponding 440 route (Forward route from LOADng Router B to LOADng Router C), 441 sends an unicast RREP-ACK message to LOADng Router C and forwards 442 the RREP received previously. 444 o Upon receiving the RREP, LOADng Router A updates the corresponding 445 routes (Forward routes from LOADng Router A to LOADng Router B and 446 from LOADng Router A to LOADng Router C). The reception of the 447 RREP also triggers an unicast RREP-ACK message intended for LOADng 448 Router B. 450 A B C 451 | RREQ | | 452 --------------------> | 453 | | RREQ | 454 | --------------------> 455 | | RREP | 456 | <-------------------- 457 | | RREP-ACK | 458 | --------------------> 459 | RREP | | 460 <-------------------- | 461 | RREP-ACK | | 462 --------------------> | 463 | | | 465 4.3.4. Link breakage handling 467 This test aims to verify the proper generation and processing of a 468 RERR message after an artificially created link breakage on an 469 previously established bidirectional route. 471 The expected message sequencing is as follows : 473 o A bidirectional route is already established between LOADng 474 Routers A and C. 476 o At some time, link breakage is detected by LOADng Router B. 477 Consequently, an unicast RERR message intended for LOADng Router A 478 (here the assumption is made that the unsuccessful delivered data 479 traffic would have been generated by LOADng Router A) is 480 transmitted. 482 Note : link breakage is provoked artificially and its detection by 483 LOADng Router B is triggered manually (normally, this would be 484 triggered by failure in sending data traffic intended for LOADng 485 Router C). 487 o Upon receiving the RERR, LOADng Router A updates its Routing Set 488 by invalidating the existing Forward Route from LOADng Router A to 489 LOADng Router C. 491 A B C 492 | | | 493 | | B-C link breakage | 494 | | X 495 | RERR | X 496 <-------------------- X 497 | | X 499 4.3.5. Obtained results 501 The following table is summarizing the results obtained for the 502 different combinations for which these test 1 (Forward Route and 503 Reverse Route initial installation) and test 2 (Forward Route and 504 Reverse Route updating) were performed : 506 +-----------+-----------+-----------+--------+--------+ 507 | A | B | C | Test 1 | Test 2 | 508 +-----------+-----------+-----------+--------+--------+ 509 | Hitahci 1 | LIX | Hitachi 2 | Pass | Pass | 510 | Hitachi 2 | LIX | Hitachi 1 | Pass | Pass | 511 | LIX | Hitachi 1 | Hitachi 2 | Pass | Pass | 512 | Hitachi 2 | Hitachi 1 | LIX | Pass | Pass | 513 | LIX | Hitachi 2 | Hitachi 1 | Pass | Pass | 514 | Hitachi 1 | Hitachi 2 | LIX | Pass | Pass | 515 +-----------+-----------+-----------+--------+--------+ 517 Table 3 519 The following table is summarizing the results obtained for the 520 different combinations for which these test 3 (Link breakage 521 handling) was performed : 523 +-----------+-----------+-----+--------+ 524 | A | B | C | Test 3 | 525 +-----------+-----------+-----+--------+ 526 | Hitachi 1 | LIX | LIX | Pass | 527 | LIX | Hitachi 1 | LIX | Pass | 528 +-----------+-----------+-----+--------+ 530 Table 4 532 4.4. 4-hop bidirectional route establishment 534 4.4.1. Topology 536 The testbed is composed of four LOADng Routers. Control traffic 537 generated by either LOADng Router A towards LOADng Router D or LOADng 538 Router D towards LOADng Router A has to be forwarded by LOADng 539 Routers B and C : 541 +-------+ +-------+ +-------+ +-------+ 542 | A |________| B |________| C |________| D | 543 | | | | | | | | 544 +-------+ +-------+ +-------+ +-------+ 546 This test suite consists in establishing a bidirectional route 547 between LOADng Router A and LOADng Router D. 549 4.4.2. Forward Route and Reverse Route initial installation 551 This test aims to verify the initial installation of a bidirectional 552 route (Forward Route and Reverse Route from A to D) within the LOADng 553 Router routing tables (Routing Sets) through the effective forwarding 554 of LOADng control traffic by LOADng Routers B and C, which are 555 located between LOADng Router A and LOADng Router D. It is also 556 verified that RREP-ACK messages are not forwarded by the LOADng 557 Routers these messages are intended for. 559 The expected message sequencing is as follows : 561 o LOADng Router A generates a RREQ message intended for LOADng 562 Router D. 564 o Upon receiving the RREQ, LOADng Router B installs a new entry in 565 its Routing Set towards LOADng Router A (Reverse Route from LOADng 566 Router B to LOADng Router A) and forwards the received RREQ. 568 o Upon receiving the RREQ, LOADng Router C installs a new entry in 569 its Routing Set towards LOADng Router A (Reverse Route from LOADng 570 Router C to LOADng Router A) and a new entry towards LOADng Router 571 B (Reverse route from LOADng Router C to LOADng Router B) and 572 forwards the received RREQ. 574 o Upon receiving the RREQ, LOADng Router D installs a new entry in 575 its Routing Set towards LOADng Router A (Reverse Route from LOADng 576 Router D to LOADng Router A) and a new entry towards LOADng Router 577 C (Reverse route from LOADng Router D to LOADng Router C). The 578 reception of the RREQ also triggers the generation of an unicast 579 RREP message intended for LOADng Router A. The field of 580 the sent RREP message is set to "ACK-REQUIRED". 582 o Upon receiving the RREP, LOADng Router C installs a new entry in 583 its Routing Set towards LOADng Router D (Forward Route from LOADng 584 Router C to LOADng Router D), sends an unicast RREP-ACK message to 585 LOADng Router D and forwards the RREP received previously. 587 o Upon receiving the RREP, LOADng Router B installs a new entry in 588 its Routing Set towards LOADng Router D (Forward Route from LOADng 589 Router B to LOADng Router D) and a new entry towards LOADng Router 590 C (Forward Route from LOADng Router B to LOADng Router C). An 591 unicast RREP-ACK message is also sent to LOADng Router C and the 592 RREP received previously is forwarded. 594 o Upon receiving the RREP, LOADng Router A installs a new entry in 595 its Routing Set towards LOADng Router B (Forward Route from LOADng 596 Router A to LOADng Router B) and a new entry towards LOADng Router 597 D (Forward Route from LOADng Router A to LOADng Router D). The 598 reception of the RREP also triggers an unicast RREP-ACK message 599 intended for LOADng Router B. 601 A B C D 602 | RREQ | | | 603 --------------------> | | 604 | | RREQ | | 605 | --------------------> | 606 | | | RREQ | 607 | | --------------------> 608 | | | RREP | 609 | | <-------------------- 610 | | | RREP-ACK | 611 | | --------------------> 612 | | RREP | | 613 | <-------------------- | 614 | | RREP-ACK | | 615 | --------------------> | 616 | RREP | | | 617 <-------------------- | | 618 | RREP-ACK | | | 619 --------------------> | | 620 | | | | 622 4.4.3. Forward Route and Reverse Route updating 624 This test aims to verify the refreshment of a bidirectional route 625 (Forward Route and Reverse Route from A to D) already installed 626 within the LOADng Router routing tables (Routing Sets) through the 627 effective forwarding of LOADng control traffic by LOADng Routers B 628 and C which are located between LOADng Router A and LOADng Router D. 630 The expected message sequencing is as follows : 632 o LOADng Router A generates a RREQ message intended for LOADng 633 Router D. 635 o Upon receiving the RREQ, LOADng Router B updates the corresponding 636 route (Reverse Route from LOADng Router B to LOADng Router A) 637 already installed within its Routing Set and forwards the received 638 RREQ. 640 o Upon receiving the RREQ, LOADng Router C updates the corresponding 641 routes (Reverse Routes from LOADng Router C to LOADng Router A and 642 from LOADng Router C to LOADng Router B) already installed within 643 its Routing Set and forwards the received RREQ. 645 o Upon receiving the RREQ, LOADng Router D updates the corresponding 646 routes (Reverse Routes from LOADng Router D to LOADng Router A and 647 from LOADng Router D to LOADng Router C) already installed within 648 its Routing Set. The reception of the RREQ also triggers the 649 generation of an unicast RREP message intended for LOADng Router 650 A. The field of the sent RREP message is set to "ACK- 651 REQUIRED". 653 o Upon receiving the RREP, LOADng Router C updates the corresponding 654 route (Forward Route from LOADng Router C to LOADng Router D), 655 sends an unicast RREP-ACK message to LOADng Router D and forwards 656 the RREP received previously. 658 o Upon receiving the RREP, LOADng Router B updates the corresponding 659 routes (Forward Route from LOADng Router B to LOADng Router D and 660 from LOADng Router B to LOADng Router C). An unicast RREP-ACK 661 message is also sent to LOADng Router C and the RREP received 662 previously is forwarded. 664 o Upon receiving the RREP, LOADng Router A updates the corresponding 665 routes (Forward Route from LOADng Router A to LOADng Router B and 666 from LOADng Router A to LOADng Router D). The reception of the 667 RREP also triggers an unicast RREP-ACK message intended for LOADng 668 Router B. 670 A B C D 671 | RREQ | | | 672 --------------------> | | 673 | | RREQ | | 674 | --------------------> | 675 | | | RREQ | 676 | | --------------------> 677 | | | RREP | 678 | | <-------------------- 679 | | | RREP-ACK | 680 | | --------------------> 681 | | RREP | | 682 | <-------------------- | 683 | | RREP-ACK | | 684 | --------------------> | 685 | RREP | | | 686 <-------------------- | | 687 | RREP-ACK | | | 688 --------------------> | | 689 | | | | 691 4.4.4. Link breakage handling 693 This test aims to verify the proper generation, processing and 694 forwarding of a RERR message after an artificially created link 695 breakage on an previously established bidirectional route. 697 The expected message sequencing is as follows : 699 o A bidirectional route is already established between LOADng 700 Routers A and D. 702 o At some time, link breakage is detected by LOADng Router C. 703 Consequently, an unicast RERR message intended for LOADng Router A 704 (here the assumption is made that the unsuccessful delivered data 705 traffic would have been generated by LOADng Router A) is 706 transmitted to LOADng Router B according to the Reverse Route from 707 LOADng Router C to LOADng Router A computed previously. 709 Note : link breakage is provoked artificially and its detection by 710 LOADng Router C is triggered manually (normally, this would be 711 triggered by failure in sending data traffic intended for LOADng 712 Router D). 714 o Upon receiving the RERR, LOADng Router B updates its Routing Set 715 by invalidating the existing Forward Route from LOADng Router B to 716 LOADng Router D. Afterwards, the RERR message is forwarded 717 according to the existing Reverse Route from LOADng Router B to 718 LOADng Router A. 720 o Upon receiving the RERR, LOADng Router A updates its Routing Set 721 by invalidating the existing Forward Route from LOADng Router A to 722 LOADng Router D. 724 A B C D 725 | | | | 726 | | | C-D link breakage X 727 | | | X 728 | | RERR | X 729 | <-------------------- X 730 | RERR | | X 731 <-------------------- | X 732 | | | X 734 4.4.5. Obtained results 736 The following table is summarizing the results obtained for the 737 different combinations for which these test 1 (Forward Route and 738 Reverse Route initial installation) and test 2 (Forward Route and 739 Reverse Route updating) were performed : 741 +-----------+-----------+-----------+-----------+--------+--------+ 742 | A | B | C | D | Test 1 | Test 2 | 743 +-----------+-----------+-----------+-----------+--------+--------+ 744 | Hitachi 1 | LIX | LIX | Hitachi 2 | Pass | Pass | 745 | Hitachi 1 | LIX | Hitachi 2 | LIX | Pass | Pass | 746 | LIX | Hitachi 2 | Hitachi 1 | LIX | Pass | Pass | 747 +-----------+-----------+-----------+-----------+--------+--------+ 749 Table 5 751 The following table is summarizing the results obtained for the 752 different combinations for which these test 3 (Link breakage 753 handling) was performed : 755 +-----------+-----------+-----+-----------+--------+ 756 | A | B | C | D | Test 3 | 757 +-----------+-----------+-----+-----------+--------+ 758 | Hitachi 1 | LIX | LIX | Hitachi 2 | Pass | 759 | LIX | Hitachi 1 | LIX | Hitachi 2 | Pass | 760 +-----------+-----------+-----+-----------+--------+ 762 Table 6 764 4.5. 4-hop bidirectional route establishment 766 4.5.1. Topology 768 The testbed is composed of five LOADng Routers. Control traffic 769 generated by either LOADng Router A towards LOADng Router E or LOADng 770 Router E towards LOADng Router A has to be forwarded by LOADng 771 Routers B, C and D : 773 +-------+ +-------+ +-------+ +-------+ +-------+ 774 | A |______| B |______| C |______| D |______| E | 775 | | | | | | | | | | 776 +-------+ +-------+ +-------+ +-------+ +-------+ 778 This test suite consists in establishing a bidirectional route 779 between LOADng Router A and LOADng Router E. 781 4.5.2. Forward Route and Reverse Route initial installation 783 This test aims to verify the initial installation of a bidirectional 784 route (Forward Route and Reverse Route from A to E) within the LOADng 785 Router routing tables (Routing Sets) through the effective forwarding 786 of LOADng control traffic by LOADng Routers B, C and D, which are 787 located between LOADng Router A and LOADng Router E. It is also 788 verified that RREP-ACK messages are not forwarded by the LOADng 789 Routers these messages are intended for. 791 The expected message sequencing is as follows : 793 o LOADng Router A generates a RREQ message intended for LOADng 794 Router E. 796 o Upon receiving the RREQ, LOADng Router B installs a new entry in 797 its Routing Set towards LOADng Router A (Reverse Route from LOADng 798 Router B to LOADng Router A) and forwards the received RREQ. 800 o Upon receiving the RREQ, LOADng Router C installs a new entry in 801 its Routing Set towards LOADng Router A (Reverse Route from LOADng 802 Router C to LOADng Router A) and a new entry towards LOADng Router 803 B (Reverse route from LOADng Router C to LOADng Router B) and 804 forwards the received RREQ. 806 o Upon receiving the RREQ, LOADng Router D installs a new entry in 807 its Routing Set towards LOADng Router A (Reverse Route from LOADng 808 Router D to LOADng Router A) and a new entry towards LOADng Router 809 C (Reverse route from LOADng Router D to LOADng Router C) and 810 forwards the received RREQ. 812 o Upon receiving the RREQ, LOADng Router E installs a new entry in 813 its Routing Set towards LOADng Router A (Reverse Route from LOADng 814 Router E to LOADng Router A) and a new entry towards LOADng Router 815 D (Reverse route from LOADng Router E to LOADng Router D). The 816 reception of the RREQ also triggers the generation of an unicast 817 RREP message intended for LOADng Router A. The field of 818 the sent RREP message is set to "ACK-REQUIRED". 820 o Upon receiving the RREP, LOADng Router D installs a new entry in 821 its Routing Set towards LOADng Router E (Forward Route from LOADng 822 Router D to LOADng Router E), sends an unicast RREP-ACK message to 823 LOADng Router E and forwards the RREP received previously. 825 o Upon receiving the RREP, LOADng Router C installs a new entry in 826 its Routing Set towards LOADng Router E (Forward Route from LOADng 827 Router C to LOADng Router E) and a new entry towards LOADng Router 828 D (Forward Route from LOADng Router C to LOADng Router D). An 829 unicast RREP-ACK message is also sent to LOADng Router D and the 830 RREP received previously is forwarded. 832 o Upon receiving the RREP, LOADng Router B installs a new entry in 833 its Routing Set towards LOADng Router E (Forward Route from LOADng 834 Router B to LOADng Router E) and a new entry towards LOADng Router 835 C (Forward Route from LOADng Router B to LOADng Router C). An 836 unicast RREP-ACK message is also sent to LOADng Router C and the 837 RREP received previously is forwarded. 839 o Upon receiving the RREP, LOADng Router A installs a new entry in 840 its Routing Set towards LOADng Router B (Forward Route from LOADng 841 Router A to LOADng Router B) and a new entry towards LOADng Router 842 E (Forward Route from LOADng Router A to LOADng Router E). The 843 reception of the RREP also triggers an unicast RREP-ACK message 844 intended for LOADng Router B. 846 A B C D E 847 | RREQ | | | | 848 ---------------> | | | 849 | | RREQ | | | 850 | ---------------> | | 851 | | | RREQ | | 852 | | ---------------> | 853 | | | | RREQ | 854 | | | ---------------> 855 | | | | RREP | 856 | | | <--------------- 857 | | | | RREP-ACK | 858 | | | ---------------> 859 | | | RREP | | 860 | | <--------------- | 861 | | | RREP-ACK | | 862 | | ---------------> | 863 | | RREP | | | 864 | <--------------- | | 865 | | RREP-ACK | | | 866 | ---------------> | | 867 | RREP | | | | 868 <--------------- | | | 869 | RREP-ACK | | | | 870 ---------------> | | | 871 | | | | | 873 4.5.3. Link breakage handling 875 This test aims to verify the proper generation, processing and 876 forwarding of a RERR message after an artificially created link 877 breakage on an previously established bidirectional route. 879 The expected message sequencing is as follows : 881 o A bidirectional route is already established between LOADng 882 Routers A and E. 884 o At some time, link breakage is detected by LOADng Router D. 885 Consequently, an unicast RERR message intended for LOADng Router A 886 (here the assumption is made that the unsuccessful delivered data 887 traffic would have been generated by LOADng Router A) is 888 transmitted to LOADng Router C according to the Reverse Route from 889 LOADng Router C to LOADng Router A computed previously. 891 Note : link breakage is provoked artificially and its detection by 892 LOADng Router D is triggered manually (normally, this would be 893 triggered by failure in sending data traffic intended for LOADng 894 Router E). 896 o Upon receiving the RERR, LOADng Router C updates its Routing Set 897 by invalidating the existing Forward Route from LOADng Router C to 898 LOADng Router E. Afterwards, the RERR message is forwarded 899 according to the existing Reverse Route from LOADng Router C to 900 LOADng Router A. 902 o Upon receiving the RERR, LOADng Router B updates its Routing Set 903 by invalidating the existing Forward Route from LOADng Router B to 904 LOADng Router E. Afterwards, the RERR message is forwarded 905 according to the existing Reverse Route from LOADng Router B to 906 LOADng Router A. 908 o Upon receiving the RERR, LOADng Router A updates its Routing Set 909 by invalidating the existing Forward Route from LOADng Router A to 910 LOADng Router E. 912 A B C D E 913 | | | | | 914 | | | D-E link breakage 915 | | | | X 916 | | | RERR | X 917 | | <--------------- X 918 | | RERR | | X 919 | <--------------- | X 920 | RERR | | | X 921 <--------------- | | X 922 | | | | X 924 4.5.4. Obtained results 926 The following table is summarizing the results obtained for the 927 different combinations for which test 1 (Forward Route and Reverse 928 Route initial installation) and test 2 (Link breakage handling) were 929 performed : 931 +-----------+-----------+-----+-----------+-----+--------+--------+ 932 | A | B | C | D | E | Test 1 | Test 2 | 933 +-----------+-----------+-----+-----------+-----+--------+--------+ 934 | Hitachi 2 | Hitachi 1 | LIX | Hitachi 1 | LIX | Pass | Pass | 935 +-----------+-----------+-----+-----------+-----+--------+--------+ 937 Table 7 939 4.6. Establishment of the best bidirectional route 941 4.6.1. Topology 943 The testbed is composed of three LOADng Routers. Control traffic 944 generated by either LOADng Router A towards LOADng Router C or LOADng 945 Router C towards LOADng Router A can be forwarded by LOADng Router B 946 or transmitted via the direct link between LOADng Routers A and C : 948 +-------+ +-------+ +-------+ 949 | A |________| B |________| C | 950 | | | | | | 951 +-------+ +-------+ +-------+ 952 |_________________________________| 954 This test consists in establishing a bidirectional route between 955 LOADng Router A and LOADng Router C. 957 4.6.2. Description 959 This test aims to verify the processing of multiple RREQs when 960 installing a bidirectional route (Forward Route and Reverse Route 961 from A to C) within the LOADng Router routing tables (Routing Sets). 963 The expected message sequencing is as follows : 965 o LOADng Router A generates a RREQ message intended for LOADng 966 Router C. According to RREQ transmission rules, the generated RREQ 967 message is transmitted to all neighbor LOADng Routers. 969 o Upon receiving the RREQ, LOADng Router B installs a new entry in 970 its Routing Set towards LOADng Router A (Reverse Route from LOADng 971 Router B to LOADng Router A) and forwards the received RREQ. 973 At the same time, upon receiving the same RREQ via its direct link 974 with LOADng Router A, LOADng Router C installs a new entry in its 975 Routing Set (Reverse Route from LOADng Router C to LOADng Router 976 A). The reception of the RREQ also triggers the generation of an 977 unicast RREP message intended for LOADng Router A. The 978 field of the sent RREP message is set to "ACK-REQUIRED". 980 o Upon receiving the same RREQ via LOADng Router B, LOADng Router C 981 compares the Route Cost and Weak Link information carried by the 982 RREQ with the already existing entry within its Routing Set 983 (Reverse Route from LOADng Router C to LOADng Router A) according 984 to the comparison operator specified by the metric used (the "hop 985 count while avoiding Weak Links" metric was used). No Weak Links 986 are emulated. Thus, the best route is chosen considering the 987 Route Cost information only : 989 Already existing entry : 991 = (Weak Link, Route Cost) = (0, 1) 993 Tuple corresponding to the newly received RREQ : 995 = (Weak Link, Route Cost) = (0, 2) 997 According to the comparison operator specified by the metric used : 999 (0, 1) < (0,2) 1001 Consequently, the newly received RREQ message is discarded without 1002 affecting the Routing Set or triggering the generation of any RREP 1003 message. 1005 o Upon receiving the RREP via its direct link with LOADng Router C, 1006 LOADng Router A installs a new entry in its Routing Set (Forward 1007 Route from LOADng Router A to LOADng Router C). The reception of 1008 the RREP also triggers an unicast RREP-ACK message intended for 1009 LOADng Router C. 1011 A B C 1012 | RREQ | | 1013 --------------------> RREQ | 1014 ----------------------------------------> 1015 | | RREQ | 1016 | --------------------> 1017 | | RREP | 1018 <---------------------------------------- 1019 | | RREP-ACK | 1020 ----------------------------------------> 1021 | | | 1023 Note : the RREQ forwarded by LOADng Router B towards C is not 1024 necessarily received before LOADng Router C generates the RREP 1025 message intended for LOADng Router A. Indeed, the order in which 1026 those messages are transmitted is dependent on the transmission 1027 delays of each single link between LOADng Routers A, B and C. 1029 4.6.3. Obtained results 1031 The following table is summarizing the results obtained for the 1032 different combinations for which this test was performed : 1034 +-----------+-----------+-----------+--------+ 1035 | A | B | C | Result | 1036 +-----------+-----------+-----------+--------+ 1037 | LIX | Hitachi 1 | Hitachi 2 | Pass | 1038 | LIX | Hitachi 2 | Hitachi 1 | Pass | 1039 | Hitachi 2 | Hitachi 1 | LIX | Pass | 1040 | Hitachi 1 | LIX | Hitachi 2 | Pass | 1041 +-----------+-----------+-----------+--------+ 1043 Table 8 1045 4.7. Blacklisting 1047 4.7.1. Topology 1049 The testbed is composed of four LOADng Routers with a unidirectional 1050 link between LOADng Routers A and D (direct communication from D 1051 towards A is impossible). 1053 +-------+ +-------+ 1054 | A |_________| B | 1055 | | | | 1056 +-------+ +-------+ 1057 | | 1058 V | 1059 +-------+ +-------+ 1060 | D |_________| C | 1061 | | | | 1062 +-------+ +-------+ 1064 This test consists in establishing a bidirectional route between 1065 LOADng Router A and LOADng Router D. 1067 4.7.2. Description 1069 This test aims to verify the effectiveness of avoiding unidirectional 1070 links using blacklisting. 1072 First attempt to establish a bidirectional route between LOADng 1073 Routers A and D : 1075 o LOADng Router A generates a RREQ message ( = 0, 1076 = A) intended for LOADng Router D. 1078 o Upon receiving the RREQ, LOADng Router B installs a new entry in 1079 its Routing Set towards LOADng Router A (Reverse Route from LOADng 1080 Router B to LOADng Router A) and forwards the received RREQ. 1082 At the same time, upon receiving the same RREQ via its direct 1083 (unidirectional) link with LOADng Router A, LOADng Router D 1084 installs a new entry in its Routing Set towards LOADng Router A 1085 (Reverse Route from LOADng Router D to LOADng Router A). The 1086 reception of the RREQ also triggers the generation of an unicast 1087 RREP message intended for LOADng Router A. The field of 1088 the sent RREP message is set to "ACK-REQUIRED". 1090 o Upon receiving the RREQ, LOADng Router C installs a new entry in 1091 its Routing Set towards LOADng Router A (Reverse Route from LOADng 1092 Router C to LOADng Router A) and a new entry towards LOADng Router 1093 B (Reverse route from LOADng Router C to LOADng Router B) and 1094 forwards the received RREQ. 1096 o Upon receiving the same RREQ ( = 0, = A) 1097 again via LOADng Router C, LOADng Router D compares the Route Cost 1098 and Weak Link information carried by the RREQ with the already 1099 existing entry within its Routing Set (Reverse Route from LOADng 1100 Router D to LOADng Router A) according to the comparison operator 1101 specified by the metric used (the "hop count while avoiding Weak 1102 Links" metric was used). No Weak Links are emulated. Thus, the 1103 best route is chosen considering the Route Cost information only : 1105 Already existing entry : 1107 = (Weak Link, Route Cost) = (0, 1) 1109 Tuple corresponding to the newly received RREQ : 1111 = (Weak Link, Route Cost) = (0, 2) 1113 According to the comparison operator specified by the metric used : 1115 (0, 1) < (0,2) 1117 Consequently, the newly received RREQ message is discarded without 1118 affecting the Routing Set or triggering the generation of any RREP 1119 message. 1121 o Due to the unidirectional nature of the existing link between 1122 LOADng Routers A and D, the RREP message previously sent by LOADng 1123 Router D intended for LOADng Router A did not reach its 1124 destination. After an elapsed time equaling ack_timeout, LOADng 1125 Router D is not expecting an RREP-ACK message anymore. This 1126 results in recording LOADng Router A neighbor in LOADng Router D's 1127 Blacklist. 1129 Second attempt to establish a bidirectional route between LOADng 1130 Routers A and D : 1132 o LOADng Router A generates a RREQ message ( = 1, 1133 = A) intended for LOADng Router D. 1135 o Upon receiving the RREQ, LOADng Router B installs a new entry in 1136 its Routing Set towards LOADng Router A (Reverse Route from LOADng 1137 Router B to LOADng Router A) and forwards the received RREQ. 1139 At the same time, upon receiving the same RREQ via its blacklisted 1140 neighbor LOADng Router A, LOADng Router D discards the message. 1142 o Upon receiving the RREQ, LOADng Router C updates the corresponding 1143 routes (Reverse Routes from LOADng Router C to LOADng Router A and 1144 from LOADng Router C to LOADng Router B) and forwards the received 1145 RREQ. 1147 o Upon receiving the RREQ, LOADng Router D updates the already 1148 installed route (Reverse Route from LOADng Router C to LOADng 1149 Router A) and installs a new entry towards LOADng Router C 1150 (Reverse route from LOADng Router D to LOADng Router C). The 1151 reception of the RREQ also triggers the generation of an unicast 1152 RREP message intended for LOADng Router A. The field of 1153 the sent RREP message is set to "ACK-REQUIRED". 1155 o Upon receiving the RREP, LOADng Router C installs a new entry in 1156 its Routing Set towards LOADng Router D (Forward Route from LOADng 1157 Router C to LOADng Router D), sends an unicast RREP-ACK message to 1158 LOADng Router D and forwards the RREP received previously. 1160 o Upon receiving the RREP, LOADng Router B installs a new entry in 1161 its Routing Set towards LOADng Router D (Forward Route from LOADng 1162 Router B to LOADng Router D) and a new entry towards LOADng Router 1163 C (Forward Route from LOADng Router B to LOADng Router C). An 1164 unicast RREP-ACK message is also sent to LOADng Router C and the 1165 RREP received previously is forwarded. 1167 o Upon receiving the RREP, LOADng Router A installs a new entry in 1168 its Routing Set towards LOADng Router D (Forward Route from LOADng 1169 Router A to LOADng Router D) and a new entry towards LOADng Router 1170 B (Forward Route from LOADng Router A to LOADng Router B). The 1171 reception of the RREP also triggers an unicast RREP-ACK message 1172 intended for LOADng Router B. 1174 A B C D 1175 | | | | 1176 First attempt ///////////////////////////////////////// 1177 | RREQ | | | 1178 ------------------> RREQ | | 1179 ------------------------------------------------------> 1180 | | RREP | | 1181 |XXXXX <----------------------------------------------- 1182 | | RREQ | | 1183 | ------------------> | 1184 | | | RREQ | 1185 | | ----------------->X RREQ 1186 | | | | Discarded 1187 Second attempt //////////////////////////////////////// 1188 | RREQ | | | 1189 ------------------> RREQ | | 1190 ----------------------------------------------------->X RREQ 1191 | | RREQ | | Discarded 1192 | ------------------> | 1193 | | | RREQ | 1194 | | ------------------> 1195 | | | RREP | 1196 | | <------------------ 1197 | | | RREP-ACK | 1198 | | ------------------> 1199 | | RREP | | 1200 | <------------------ | 1201 | | RREP-ACK | | 1202 | ------------------> | 1203 | RREP | | | 1204 <------------------ | | 1205 | RREP-ACK | | | 1206 ------------------> | | 1208 4.7.3. Obtained results 1210 The following table is summarizing the results obtained for the 1211 different combinations for which this test was performed : 1213 +-----------+-----+-----------+-----------+--------+ 1214 | A | B | C | D | Result | 1215 +-----------+-----+-----------+-----------+--------+ 1216 | Hitachi 2 | LIX | Hitachi 1 | LIX | Pass | 1217 | LIX | LIX | Hitachi 1 | Hitachi 2 | Pass | 1218 | Hitachi 2 | LIX | LIX | Hitachi 1 | Pass | 1219 +-----------+-----+-----------+-----------+--------+ 1221 Table 9 1223 4.8. Conclusions 1225 The different test scenarios carried that were carried out for 1226 different interoperable and independent implementations allowed to 1227 completely cover the LOADng specification by checking each technical 1228 feature one by one. In addition, the completion of this process 1229 permitted the improvement of the overall quality and accuracy of the 1230 LOADng specification (draft-clausen-lln-loadng). 1232 +------+----------------+-----------------------+-----------+ 1233 | | | | Scenario | 1234 |Chap. | Item | Technical feature +-----------+ 1235 | | | |1|2|3|4|5|6| 1236 +------+----------------+------------+----------+-+-+-+-+-+-+ 1237 |6.1 | | |Originator|X|X|X| |X|X| 1238 +------+ Information |Routing Set +----------+-+-+-+-+-+-+ 1239 |6.1 | Base | |Previous | |X|X|X| |X| 1240 +------+ +------------+----------+-+-+-+-+-+-+ 1241 |6.2 | |Blacklist Neighbor set | | | | | |X| 1242 +------+----------------+-----------------------+-+-+-+-+-+-+ 1243 |8.1 | |TLV |X|X|X|X|X|X| 1244 +------+ +-----------------------+-+-+-+-+-+-+ 1245 |8.2.1 | Packet |Route Request Message |X|X|X|X|X|X| 1246 +------+ Format +-----------------------+-+-+-+-+-+-+ 1247 |8.2.1 | |Route Reply Message |X|X|X|X|X|X| 1248 +------+ +-----------------------+-+-+-+-+-+-+ 1249 |8.2.2 | |Route Reply Ack Message|X|X|X|X|X|X| 1250 +------+ +-----------------------+-+-+-+-+-+-+ 1251 |8.2.3 | |Route Error Message | |X|X|X| | | 1252 +------+----------------+-----------------------+-+-+-+-+-+-+ 1253 |10.1 | Unidirectional |Blacklist | | | | | |X| 1254 | | link handling | | | | | | | | 1255 +------+----------------+-----------------------+-+-+-+-+-+-+ 1256 |11.1 | |Invalid RREQ, RREP |X|X|X|X|X|X| 1257 +------+ Common rules +-----------------------+-+-+-+-+-+-+ 1258 |11.2 | for RREQ, RREP |RREQ, RREP Processing |X|X|X|X|X|X| 1259 +------+ Message +-----------------------+-+-+-+-+-+-+ 1260 |11.3 | |Updating RREQ, RREP |X|X|X|X|X|X| 1261 +------+----------------+-----------------------+-+-+-+-+-+-+ 1262 |12.1 | |RREQ Generation |X|X|X|X|X|X| 1263 +------+ +-----------------------+-+-+-+-+-+-+ 1264 |12.2 | Route |RREQ Processing |X|X|X|X|X|X| 1265 +------+ Requests +-----------------------+-+-+-+-+-+-+ 1266 |12.3 | (RREQs) |RREQ Forwarding | |X|X|X|X|X| 1267 +------+ +-----------------------+-+-+-+-+-+-+ 1268 |12.4 | |RREQ Transmission |X|X|X|X|X|X| 1269 +------+----------------+-----------------------+-+-+-+-+-+-+ 1270 |13.1 | |RREP Generation |X|X|X|X|X|X| 1271 +------+ +-----------------------+-+-+-+-+-+-+ 1272 |13.2 | Route |RREP Processing |X|X|X|X|X|X| 1273 +------+ Replies +-----------------------+-+-+-+-+-+-+ 1274 |13.3 | (RREPs) |RREP Forwarding | |X|X|X|X|X| 1275 +------+ +-----------------------+-+-+-+-+-+-+ 1276 |13.4 | |RREP Transmission |X|X|X|X|X|X| 1277 +------+----------------+-----------------------+-+-+-+-+-+-+ 1278 |14.1 | |RERR Generation | |X|X|X| | | 1279 +------+ +-----------------------+-+-+-+-+-+-+ 1280 |14.2 | Route |RERR Processing | |X|X|X| | | 1281 +------+ Errors +-----------------------+-+-+-+-+-+-+ 1282 |14.3 | (RERRs) |RERR Forwarding | | |X|X| | | 1283 +------+ +-----------------------+-+-+-+-+-+-+ 1284 |14.4 | |RERR Transmission | |X|X|X| | | 1285 +------+----------------+-----------------------+-+-+-+-+-+-+ 1286 |15.1 | |RREP-ACK Generation |X|X|X|X|X|X| 1287 +------+ +-----------------------+-+-+-+-+-+-+ 1288 |15.2 | Route |RREQ-ACK Processing |X|X|X|X|X|X| 1289 +------+ Reply +-----------------------+-+-+-+-+-+-+ 1290 |15.3 | Acknowledgement|RREQ-ACK Forwarding |X|X|X|X|X|X| 1291 +------+ (RREP-ACKs) +-----------------------+-+-+-+-+-+-+ 1292 |15.4 | |RREQ-ACK Transmission |X|X|X|X|X|X| 1293 +------+----------------+-----------------------+-+-+-+-+-+-+ 1294 |16 | Metrics |Hop Count While |X|X|X|X|X|X| 1295 | | |Avoiding Weak Links | | | | | | | 1296 +------+----------------+-----------------------+-+-+-+-+-+-+ 1298 Scenario 1: 1-hop bidirectional route establishment 1300 Scenario 2: 2-hop bidirectional route establishment 1302 Scenario 3: 3-hop bidirectional route establishment 1304 Scenario 4: 4-hop bidirectional route establishment 1306 Scenario 5: Establishment of the best bidirectional route 1308 Scenario 6: Blacklisting 1310 5. Security Considerations 1312 This document does currently not specify any security considerations. 1314 6. IANA Considerations 1316 This document has no actions for IANA. 1318 7. Contributors 1320 This specification is the result of the joint efforts of the 1321 following contributors -- listed alphabetically. 1323 o Thomas Heide Clausen, LIX, France, 1325 o Alberto Camacho, LIX, France, 1327 o Axel Colin de Verdiere, LIX, France, 1329 o Yuichi Igarashi, HITACHI YRL, Japan, 1330 1332 o Nobukatsu Inomata, HITACHI ULSI Systems, Japan, 1333 1335 o Cedric Lavenu, EDF R&D, France, 1337 o Yoko Morii, HITACHI YRL, Japan, 1339 o SATOH, Hiroki, HITACHI YRL, Japan, 1341 o Jiazi Yi, LIX, France, 1343 8. Acknowledgments 1345 TBD 1347 9. References 1349 9.1. Normative References 1351 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1352 Requirement Levels", RFC 2119, BCP 14, March 1997. 1354 9.2. Informative References 1356 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 1357 "Generalized MANET Packet/Message Format", RFC 5444, 1358 February 2009. 1360 Authors' Addresses 1362 Cedric Lavenu 1363 EDF R&D 1365 Phone: +33 1 4765 2729 1366 EMail: cedric-2.lavenu@edf.fr 1367 URI: http://www.edf.fr/ 1369 Thomas Heide Clausen 1370 LIX, Ecole Polytechnique 1372 Phone: +33 6 6058 9349 1373 EMail: T.Clausen@computer.org 1374 URI: http://www.ThomasClausen.org/ 1376 Alberto Camacho 1377 LIX, Ecole Polytechnique 1379 Phone: +34 636 309 835 1380 EMail: alberto@albertocamacho.com 1381 URI: http://www.albertocamacho.com/ 1383 Jiazi Yi 1384 LIX, Ecole Polytechnique 1386 Phone: +33 1 6933 4031 1387 EMail: jiazi@jiaziyi.com 1388 URI: http://www.jiaziyi.com/ 1390 Axel Colin de Verdiere 1391 LIX, Ecole Polytechnique 1393 Phone: +33 6 1264 7119 1394 EMail: axel@axelcdv.com 1395 URI: http://www.axelcdv.com/ 1396 Yuichi Igarashi 1397 Hitachi, Ltd., Yokohama Research Laboratory 1399 Phone: +81 45 860 3083 1400 EMail: yuichi.igarashi.hb@hitachi.com 1401 URI: http://www.hitachi.com/rd/yrl/index.html 1403 SATOH, Hiroki 1404 Hitachi, Ltd., Yokohama Research Laboratory 1406 Phone: +81 44 959 0205 1407 EMail: hiroki.satoh.yj@hitachi.com 1408 URI: http://www.hitachi.com/rd/yrl/index.html 1410 Yoko Morii 1411 Hitachi, Ltd., Yokohama Research Laboratory 1413 Phone: +81 45 860 3083 1414 EMail: yoko.morii.cs@hitachi.com 1415 URI: http://www.hitachi.com/rd/yrl/index.html