idnits 2.17.1 draft-lavenu-lln-loadng-interoperability-report-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to 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 (December 11, 2012) is 4154 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-clausen-lln-loadng-00 -- Duplicate reference: draft-clausen-lln-loadng, mentioned in 'LOADng-00', was also mentioned in 'LOADng'. == Outdated reference: A later version (-15) exists of draft-clausen-lln-loadng-03 -- Duplicate reference: draft-clausen-lln-loadng, mentioned in 'LOADng-03', was also mentioned in 'LOADng-00'. == Outdated reference: A later version (-15) exists of draft-clausen-lln-loadng-04 -- Duplicate reference: draft-clausen-lln-loadng, mentioned in 'LOADng-04', was also mentioned in 'LOADng-03'. == Outdated reference: A later version (-15) exists of draft-clausen-lln-loadng-05 -- Duplicate reference: draft-clausen-lln-loadng, mentioned in 'LOADng-05', was also mentioned in 'LOADng-04'. == Outdated reference: A later version (-15) exists of draft-clausen-lln-loadng-06 -- Duplicate reference: draft-clausen-lln-loadng, mentioned in 'LOADng-06', was also mentioned in 'LOADng-05'. Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Clausen 3 Internet-Draft A. Camacho 4 Intended status: Informational J. Yi 5 Expires: June 14, 2013 A. Colin de Verdiere 6 LIX, Ecole Polytechnique 7 Y. Igarashi 8 H. Satoh 9 Y. Morii 10 Hitachi, Ltd., Yokohama Research 11 Laboratory 12 U. Herberg 13 Fujitsu Laboratories of America 14 C. Lavenu 15 EDF R&D 16 December 11, 2012 18 Interoperability Report for the Lightweight On-demand Ad hoc Distance- 19 vector Routing Protocol - Next Generation (LOADng) 20 draft-lavenu-lln-loadng-interoperability-report-04 22 Abstract 24 This document reports experience with the LOADng routing protocol, as 25 obtained by way of a number of interoperability tests during the 26 protocol development. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on June 14, 2013. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 This document may contain material from IETF Documents or IETF 61 Contributions published or made publicly available before November 62 10, 2008. The person(s) controlling the copyright in some of this 63 material may not have granted the IETF Trust the right to allow 64 modifications of such material outside the IETF Standards Process. 65 Without obtaining an adequate license from the person(s) controlling 66 the copyright in such materials, this document may not be modified 67 outside the IETF Standards Process, and derivative works of it may 68 not be created outside the IETF Standards Process, except to format 69 it for publication as an RFC or to translate it into languages other 70 than English. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 3. Interoperability Scenarios . . . . . . . . . . . . . . . . . . 5 77 3.1. Scenario 01: 1-hop Bidirectional Route Establishment - 78 Forward Route and Reverse Route initial installation . . . 5 79 3.1.1. Scenario Topology . . . . . . . . . . . . . . . . . . 5 80 3.1.2. Expected Message Sequencing . . . . . . . . . . . . . 6 81 3.2. Scenario 02: 1-hop Bidirectional Route Establishment 82 -Forward Route and Reverse Route updating . . . . . . . . 6 83 3.2.1. Scenario Topology . . . . . . . . . . . . . . . . . . 6 84 3.2.2. Expected Message Sequencing . . . . . . . . . . . . . 7 85 3.3. Scenario 03: 2-hop bidirectional route establishment - 86 Forward Route and Reverse Route initial installation . . . 7 87 3.3.1. Scenario Topology . . . . . . . . . . . . . . . . . . 8 88 3.3.2. Expected Message Sequencing . . . . . . . . . . . . . 8 89 3.4. Scenario 04: 2-hop bidirectional route establishment - 90 Forward Route and Reverse Route updating . . . . . . . . . 9 91 3.4.1. Scenario Topology . . . . . . . . . . . . . . . . . . 9 92 3.4.2. Expected Message Sequencing . . . . . . . . . . . . . 9 93 3.5. Scenario 05: 2-hop bidirectional route establishment - 94 Link breakage handling . . . . . . . . . . . . . . . . . . 10 95 3.5.1. Scenario Topology . . . . . . . . . . . . . . . . . . 10 96 3.5.2. Expected Message Sequencing . . . . . . . . . . . . . 11 97 3.6. Scenario 06: 3-hop bidirectional route establishment - 98 Forward Route and Reverse Route initial installation . . . 11 99 3.6.1. Scenario Topology . . . . . . . . . . . . . . . . . . 12 100 3.6.2. Expected Message Sequencing . . . . . . . . . . . . . 12 101 3.7. Scenario 07: 3-hop bidirectional route establishment - 102 Forward Route and Reverse Route updating . . . . . . . . . 13 103 3.7.1. Scenario Topology . . . . . . . . . . . . . . . . . . 14 104 3.7.2. Expected Message Sequencing . . . . . . . . . . . . . 14 105 3.8. Scenario 08: 3-hop bidirectional route establishment - 106 Link breakage handling . . . . . . . . . . . . . . . . . . 15 107 3.8.1. Scenario Topology . . . . . . . . . . . . . . . . . . 15 108 3.8.2. Expected Message Sequencing . . . . . . . . . . . . . 16 109 3.9. Scenario 09: 4-hop bidirectional route establishment - 110 Forward Route and Reverse Route initial installation . . . 16 111 3.9.1. Scenario Topology . . . . . . . . . . . . . . . . . . 17 112 3.9.2. Expected Message Sequencing . . . . . . . . . . . . . 17 113 3.10. Scenario 10: 4-hop bidirectional route establishment - 114 Link breakage handling . . . . . . . . . . . . . . . . . . 19 115 3.10.1. Scenario Topology . . . . . . . . . . . . . . . . . . 19 116 3.10.2. Expected Message Sequencing . . . . . . . . . . . . . 20 117 3.11. Scenario 11: Establishment of the best bidirectional 118 route . . . . . . . . . . . . . . . . . . . . . . . . . . 21 119 3.11.1. Scenario Topology . . . . . . . . . . . . . . . . . . 21 120 3.11.2. Expected Message Sequencing . . . . . . . . . . . . . 21 121 3.12. Scenario 12: Blacklisting . . . . . . . . . . . . . . . . 22 122 3.12.1. Scenario Topology . . . . . . . . . . . . . . . . . . 23 123 3.12.2. Expected Message Sequencing . . . . . . . . . . . . . 23 124 4. Interop 01: Yokohama, Japan, October 2011 . . . . . . . . . . 26 125 4.1. Version of LOADng Specification Tested . . . . . . . . . . 26 126 4.2. Place and Date of Interoperability Test . . . . . . . . . 27 127 4.3. Participating Implementations . . . . . . . . . . . . . . 27 128 4.4. Scenarios Tested . . . . . . . . . . . . . . . . . . . . . 27 129 4.5. Additional Interoperability Test Considerations . . . . . 27 130 4.6. Results For Scenario 01 . . . . . . . . . . . . . . . . . 28 131 4.7. Results For Scenario 02 . . . . . . . . . . . . . . . . . 28 132 4.8. Results For Scenario 03 . . . . . . . . . . . . . . . . . 28 133 4.9. Results For Scenario 04 . . . . . . . . . . . . . . . . . 29 134 4.10. Results For Scenario 05 . . . . . . . . . . . . . . . . . 29 135 4.11. Results For Scenario 06 . . . . . . . . . . . . . . . . . 30 136 4.12. Results For Scenario 07 . . . . . . . . . . . . . . . . . 30 137 4.13. Results For Scenario 08 . . . . . . . . . . . . . . . . . 30 138 4.14. Results For Scenario 09 . . . . . . . . . . . . . . . . . 31 139 4.15. Results For Scenario 10 . . . . . . . . . . . . . . . . . 31 140 4.16. Results For Scenario 11 . . . . . . . . . . . . . . . . . 31 141 4.17. Results For Scenario 12 . . . . . . . . . . . . . . . . . 32 142 4.18. Conclusions . . . . . . . . . . . . . . . . . . . . . . . 32 143 5. Interop 02: San Jose, USA March 2012 . . . . . . . . . . . . . 34 144 5.1. LOADng version tested . . . . . . . . . . . . . . . . . . 34 145 5.2. Place and Date of Interoperability Test . . . . . . . . . 34 146 5.3. Participating Implementations . . . . . . . . . . . . . . 34 147 5.4. Interoperability Test Considerations . . . . . . . . . . . 35 148 5.5. Results For Scenario 01 . . . . . . . . . . . . . . . . . 35 149 5.6. Results For Scenrio 03 . . . . . . . . . . . . . . . . . . 35 150 5.7. Results For Scenario 05 . . . . . . . . . . . . . . . . . 35 151 6. Interop 03: Los Angeles, USA, June 2012 . . . . . . . . . . . 36 152 6.1. Version of LOADng Specification Tested . . . . . . . . . . 36 153 6.2. Place and Date of Interoperability Test . . . . . . . . . 36 154 6.3. Participating Implementations . . . . . . . . . . . . . . 36 155 6.4. Scenarios Tested . . . . . . . . . . . . . . . . . . . . . 36 156 6.5. Additional Interoperability Test Considerations . . . . . 36 157 6.6. Results For Scenario 01-02 . . . . . . . . . . . . . . . . 37 158 6.7. Results For Scenario 03-04-05 . . . . . . . . . . . . . . 37 159 6.8. Results For Scenario 06-07-08 . . . . . . . . . . . . . . 38 160 6.9. Results For Scenario 09-10 . . . . . . . . . . . . . . . . 39 161 6.10. Results For Scenario 11 . . . . . . . . . . . . . . . . . 39 162 6.11. Conclusions . . . . . . . . . . . . . . . . . . . . . . . 39 163 7. Interop 04: Vancouver, Canada, August, 2011 . . . . . . . . . 39 164 7.1. Version of LOADng Specifiation Tested . . . . . . . . . . 39 165 7.2. Place and Date of Interoperability Test . . . . . . . . . 40 166 7.3. Participating Implementations . . . . . . . . . . . . . . 40 167 7.4. Scenarios Tested . . . . . . . . . . . . . . . . . . . . . 40 168 7.5. Additional Interoperability Test Considerations . . . . . 40 169 7.6. Results for Scenario 01-02 . . . . . . . . . . . . . . . . 40 170 7.7. Results for Scenario 03-04-05 . . . . . . . . . . . . . . 41 171 7.8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . 43 172 8. Security Considerations . . . . . . . . . . . . . . . . . . . 43 173 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 174 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 43 175 11. Informative References . . . . . . . . . . . . . . . . . . . . 44 177 1. Introduction 179 This document reports experience with the LOADng [LOADng] routing 180 protocol, as obtained by way of a number of interoperability tests 181 during the protocol development. 183 Interoperability tests between LOADng Routers implemented on the 184 basis of the different versions of the protocol have been undertaken 185 mainly to: 187 o Show evidence that interoperable LOADng implementations do exist. 189 o Clarify and improve the overall quality of the LOADng 190 specification. 192 o Demonstrate that the final LOADng internet draft can be considered 193 as a standalone specification allowing the development of 194 interoperable implementations of LOADng. 196 2. Terminology 198 This document uses the terminology of [LOADng]. 200 3. Interoperability Scenarios 202 This section describes the various tests and scenarios carried out 203 between the implementations involved in the various interoperability 204 tests. 206 The testbed required is composed of up to five LOADng Routers, 207 connected according to the specific topology described for each test 208 scenario below. The LOADng routing protocol was run over UDP and 209 IPv4. Either Ethernet or 802.11 wireless network was used in the 210 test. 212 3.1. Scenario 01: 1-hop Bidirectional Route Establishment - Forward 213 Route and Reverse Route initial installation 215 For each implementation, this test aims to verify the initial 216 installation of a bidirectional route (Forward Route and Reverse 217 Route from A to B) within the LOADng Router routing tables (Routing 218 Sets) through the effective generation and processing of LOADng 219 control messages (RREQ, RREP, RREP-ACK). 221 3.1.1. Scenario Topology 223 The testbed is composed of two LOADng Routers: 225 +-------+ +-------+ 226 | A |________| B | 227 | | | | 228 +-------+ +-------+ 230 This test suite consists in establishing a bidirectional route 231 between LOADng Router A and LOADng Router B. 233 3.1.2. Expected Message Sequencing 235 The expected message sequencing is as follows: 237 o LOADng Router A generates an RREQ message intended for LOADng 238 Router B. 240 o Upon receiving the RREQ, LOADng Router B installs a new tuple in 241 its Routing Set towards LOADng Router A (Reverse Route from LOADng 242 Router B to LOADng Router A) and sends an unicast RREP message 243 intended for LOADng Router A, soliciting an RREP-ACK message. 245 o Upon receiving the RREP, LOADng Router A installs a new tuple in 246 its Routing Set towards LOADng Router B (Forward Route from LOADng 247 Router A to LOADng Router B) and sends an unicast RREP-ACK message 248 to LOADng Router B. 250 A B 251 | RREQ | 252 --------------------> 253 | RREP | 254 <-------------------- 255 | RREP-ACK | 256 --------------------> 257 | | 259 3.2. Scenario 02: 1-hop Bidirectional Route Establishment -Forward 260 Route and Reverse Route updating 262 For each implementation, this test aims to verify the refreshment of 263 a bidirectional route (Forward Route and Reverse Route from A to B) 264 already installed within the LOADng Router routing tables (Routing 265 Sets) through the effective generation and processing of LOADng 266 control messages (RREQ, RREP, RREP-ACK). 268 3.2.1. Scenario Topology 270 The testbed is composed of two LOADng Routers: 272 +-------+ +-------+ 273 | A |________| B | 274 | | | | 275 +-------+ +-------+ 277 This test suite consists in updating a bidirectional route between 278 LOADng Router A and LOADng Router B. 280 3.2.2. Expected Message Sequencing 282 The expected message sequencing is as follows: 284 o LOADng Router A generates an RREQ message intended for LOADng 285 Router B. 287 o Upon receiving the RREQ, LOADng Router B updates the corresponding 288 route (Reverse Route from LOADng Router B to LOADng Router A) 289 already installed within its Routing Set and sends an unicast RREP 290 message intended for LOADng Router A, soliciting an RREP-ACK 291 message. 293 o Upon receiving the RREP, LOADng Router A updates the corresponding 294 route (Forward Route from LOADng Router A to LOADng Router B) 295 already installed within its Routing Set and sends an unicast 296 RREP-ACK message to LOADng Router B. 298 A B 299 | RREQ | 300 --------------------> 301 | RREP | 302 <-------------------- 303 | RREP-ACK | 304 --------------------> 305 | | 307 3.3. Scenario 03: 2-hop bidirectional route establishment - Forward 308 Route and Reverse Route initial installation 310 This test aims to verify the initial installation of a bidirectional 311 route (Forward Route and Reverse Route from A to C) within the LOADng 312 Router routing tables (Routing Sets) through the effective forwarding 313 of LOADng control traffic by LOADng Router B which is located between 314 LOADng Router A and LOADng Router C. It is also verified that RREP- 315 ACK messages are not forwarded by the LOADng Routers these messages 316 are intended for. 318 3.3.1. Scenario Topology 320 The testbed is composed of three LOADng Routers. Control traffic 321 generated by either LOADng Router A towards LOADng Router C or LOADng 322 Router C towards LOADng Router A has to be forwarded by LOADng Router 323 B: 325 +-------+ +-------+ +-------+ 326 | A |________| B |________| C | 327 | | | | | | 328 +-------+ +-------+ +-------+ 330 This test suite consists in establishing a bidirectional route 331 between LOADng Router A and LOADng Router C. 333 3.3.2. Expected Message Sequencing 335 The expected message sequencing is as follows: 337 o LOADng Router A generates an RREQ message intended for LOADng 338 Router C. 340 o Upon receiving the RREQ, LOADng Router B installs a new tuple in 341 its Routing Set towards LOADng Router A (Reverse Route from LOADng 342 Router B to LOADng Router A) and forwards the received RREQ. 344 o Upon receiving the RREQ, LOADng Router C installs a new tuple in 345 its Routing Set towards LOADng Router A (Reverse Route from LOADng 346 Router C to LOADng Router A) and a new tuple towards LOADng Router 347 B (Reverse route from LOADng Router C to LOADng Router B). The 348 reception of the RREQ also triggers the generation of an unicast 349 RREP message intended for LOADng Router A, soliciting an RREP-ACK 350 message. 352 o Upon receiving the RREP, LOADng Router B installs a new tuple in 353 its Routing Set towards LOADng Router C (Forward Route from LOADng 354 Router B to LOADng Router C), sends an unicast RREP-ACK message to 355 LOADng Router C and forwards the RREP received previously. 357 o Upon receiving the RREP, LOADng Router A installs a new tuple in 358 its Routing Set towards LOADng Router B (Forward Route from LOADng 359 Router A to LOADng Router B) and a new tuple towards LOADng Router 360 C (Forward Route from LOADng Router A to LOADng Router C). The 361 reception of the RREP also triggers an unicast RREP-ACK message 362 intended for LOADng Router B. 364 A B C 365 | RREQ | | 366 --------------------> | 367 | | RREQ | 368 | --------------------> 369 | | RREP | 370 | <-------------------- 371 | | RREP-ACK | 372 | --------------------> 373 | RREP | | 374 <-------------------- | 375 | RREP-ACK | | 376 --------------------> | 377 | | | 379 3.4. Scenario 04: 2-hop bidirectional route establishment - Forward 380 Route and Reverse Route updating 382 This test aims to verify the refreshment of a bidirectional route 383 (Forward Route and Reverse Route from A to C) already installed 384 within the LOADng Router routing tables (Routing Sets) through the 385 effective forwarding of LOADng control traffic by LOADng Router B 386 which is located between LOADng Router A and LOADng Router C. 388 3.4.1. Scenario Topology 390 The testbed is composed of three LOADng Routers. Control traffic 391 generated by either LOADng Router A towards LOADng Router C or LOADng 392 Router C towards LOADng Router A has to be forwarded by LOADng Router 393 B: 395 +-------+ +-------+ +-------+ 396 | A |________| B |________| C | 397 | | | | | | 398 +-------+ +-------+ +-------+ 400 This test suite consists in updating a bidirectional route between 401 LOADng Router A and LOADng Router C. 403 3.4.2. Expected Message Sequencing 405 The expected message sequencing is as follows: 407 o LOADng Router A generates an RREQ message intended for LOADng 408 Router C. 410 o Upon receiving the RREQ, LOADng Router B updates the corresponding 411 route (Reverse Route from LOADng Router B to LOADng Router A) 412 already installed within its Routing Set and forwards the received 413 RREQ. 415 o Upon receiving the RREQ, LOADng Router C updates the corresponding 416 routes (Reverse Routes from LOADng Router C to LOADng Router A and 417 from LOADng Router C to LOADng Router B). The reception of the 418 RREQ also triggers the generation of an unicast RREP message 419 intended for LOADng Router A, soliciting an RREP-ACK message. 421 o Upon receiving the RREP, LOADng Router B updates the corresponding 422 route (Forward route from LOADng Router B to LOADng Router C), 423 sends an unicast RREP-ACK message to LOADng Router C and forwards 424 the RREP received previously. 426 o Upon receiving the RREP, LOADng Router A updates the corresponding 427 routes (Forward routes from LOADng Router A to LOADng Router B and 428 from LOADng Router A to LOADng Router C). The reception of the 429 RREP also triggers an unicast RREP-ACK message intended for LOADng 430 Router B. 432 A B C 433 | RREQ | | 434 --------------------> | 435 | | RREQ | 436 | --------------------> 437 | | RREP | 438 | <-------------------- 439 | | RREP-ACK | 440 | --------------------> 441 | RREP | | 442 <-------------------- | 443 | RREP-ACK | | 444 --------------------> | 445 | | | 447 3.5. Scenario 05: 2-hop bidirectional route establishment - Link 448 breakage handling 450 This test aims to verify the proper generation and processing of an 451 RERR message after an artificially created link breakage on an 452 previously established bidirectional route. 454 3.5.1. Scenario Topology 456 The testbed is composed of three LOADng Routers. Control traffic 457 generated by either LOADng Router A towards LOADng Router C or LOADng 458 Router C towards LOADng Router A has to be forwarded by LOADng Router 459 B: 461 +-------+ +-------+ +-------+ 462 | A |________| B |________| C | 463 | | | | | | 464 +-------+ +-------+ +-------+ 466 This test suite consists in handling link breakages between routers. 468 3.5.2. Expected Message Sequencing 470 The expected message sequencing is as follows: 472 o A bidirectional route is already established between LOADng 473 Routers A and C. 475 o At some time, link breakage is detected by LOADng Router B. 476 Consequently, an unicast RERR message intended for LOADng Router A 477 (here the assumption is made that the unsuccessful delivered data 478 traffic would have been generated by LOADng Router A) is 479 transmitted. 481 Note: link breakage is provoked artificially and its detection by 482 LOADng Router B is triggered manually (normally, this would be 483 triggered by failure in sending data traffic intended for LOADng 484 Router C). 486 o Upon receiving the RERR, LOADng Router A updates its Routing Set 487 by invalidating the existing Forward Route from LOADng Router A to 488 LOADng Router C. 490 A B C 491 | | | 492 | | B-C link breakage | 493 | | X 494 | RERR | X 495 <-------------------- X 496 | | X 498 3.6. Scenario 06: 3-hop bidirectional route establishment - Forward 499 Route and Reverse Route initial installation 501 This test aims to verify the initial installation of a bidirectional 502 route (Forward Route and Reverse Route from A to D) within the LOADng 503 Router routing tables (Routing Sets) through the effective forwarding 504 of LOADng control traffic by LOADng Routers B and C, which are 505 located between LOADng Router A and LOADng Router D. It is also 506 verified that RREP-ACK messages are not forwarded by the LOADng 507 Routers these messages are intended for. 509 3.6.1. Scenario Topology 511 The testbed is composed of four LOADng Routers. Control traffic 512 generated by either LOADng Router A towards LOADng Router D or LOADng 513 Router D towards LOADng Router A has to be forwarded by LOADng 514 Routers B and C: 516 +-------+ +-------+ +-------+ +-------+ 517 | A |________| B |________| C |________| D | 518 | | | | | | | | 519 +-------+ +-------+ +-------+ +-------+ 521 This test suite consists in establishing a bidirectional route 522 between LOADng Router A and LOADng Router D. 524 3.6.2. Expected Message Sequencing 526 The expected message sequencing is as follows: 528 o LOADng Router A generates an RREQ message intended for LOADng 529 Router D. 531 o Upon receiving the RREQ, LOADng Router B installs a new tuple in 532 its Routing Set towards LOADng Router A (Reverse Route from LOADng 533 Router B to LOADng Router A) and forwards the received RREQ. 535 o Upon receiving the RREQ, LOADng Router C installs a new tuple in 536 its Routing Set towards LOADng Router A (Reverse Route from LOADng 537 Router C to LOADng Router A) and a new tuple towards LOADng Router 538 B (Reverse route from LOADng Router C to LOADng Router B) and 539 forwards the received RREQ. 541 o Upon receiving the RREQ, LOADng Router D installs a new tuple in 542 its Routing Set towards LOADng Router A (Reverse Route from LOADng 543 Router D to LOADng Router A) and a new tuple towards LOADng Router 544 C (Reverse route from LOADng Router D to LOADng Router C). The 545 reception of the RREQ also triggers the generation of an unicast 546 RREP message intended for LOADng Router A, soliciting an RREP-ACK 547 message. 549 o Upon receiving the RREP, LOADng Router C installs a new tuple in 550 its Routing Set towards LOADng Router D (Forward Route from LOADng 551 Router C to LOADng Router D), sends an unicast RREP-ACK message to 552 LOADng Router D and forwards the RREP received previously. 554 o Upon receiving the RREP, LOADng Router B installs a new tuple in 555 its Routing Set towards LOADng Router D (Forward Route from LOADng 556 Router B to LOADng Router D) and a new tuple towards LOADng Router 557 C (Forward Route from LOADng Router B to LOADng Router C). An 558 unicast RREP-ACK message is also sent to LOADng Router C and the 559 RREP received previously is forwarded. 561 o Upon receiving the RREP, LOADng Router A installs a new tuple in 562 its Routing Set towards LOADng Router B (Forward Route from LOADng 563 Router A to LOADng Router B) and a new tuple towards LOADng Router 564 D (Forward Route from LOADng Router A to LOADng Router D). The 565 reception of the RREP also triggers an unicast RREP-ACK message 566 intended for LOADng Router B. 568 A B C D 569 | RREQ | | | 570 --------------------> | | 571 | | RREQ | | 572 | --------------------> | 573 | | | RREQ | 574 | | --------------------> 575 | | | RREP | 576 | | <-------------------- 577 | | | RREP-ACK | 578 | | --------------------> 579 | | RREP | | 580 | <-------------------- | 581 | | RREP-ACK | | 582 | --------------------> | 583 | RREP | | | 584 <-------------------- | | 585 | RREP-ACK | | | 586 --------------------> | | 587 | | | | 589 3.7. Scenario 07: 3-hop bidirectional route establishment - Forward 590 Route and Reverse Route updating 592 This test aims to verify the refreshment of a bidirectional route 593 (Forward Route and Reverse Route from A to D) already installed 594 within the LOADng Router routing tables (Routing Sets) through the 595 effective forwarding of LOADng control traffic by LOADng Routers B 596 and C which are located between LOADng Router A and LOADng Router D. 598 3.7.1. Scenario Topology 600 The testbed is composed of four LOADng Routers. Control traffic 601 generated by either LOADng Router A towards LOADng Router D or LOADng 602 Router D towards LOADng Router A has to be forwarded by LOADng 603 Routers B and C: 605 +-------+ +-------+ +-------+ +-------+ 606 | A |________| B |________| C |________| D | 607 | | | | | | | | 608 +-------+ +-------+ +-------+ +-------+ 610 This test suite consists in updating a bidirectional route between 611 LOADng Router A and LOADng Router D. 613 3.7.2. Expected Message Sequencing 615 The expected message sequencing is as follows: 617 o LOADng Router A generates an RREQ message intended for LOADng 618 Router D. 620 o Upon receiving the RREQ, LOADng Router B updates the corresponding 621 route (Reverse Route from LOADng Router B to LOADng Router A) 622 already installed within its Routing Set and forwards the received 623 RREQ. 625 o Upon receiving the RREQ, LOADng Router C updates the corresponding 626 routes (Reverse Routes from LOADng Router C to LOADng Router A and 627 from LOADng Router C to LOADng Router B) already installed within 628 its Routing Set and forwards the received RREQ. 630 o Upon receiving the RREQ, LOADng Router D updates the corresponding 631 routes (Reverse Routes from LOADng Router D to LOADng Router A and 632 from LOADng Router D to LOADng Router C) already installed within 633 its Routing Set. The reception of the RREQ also triggers the 634 generation of an unicast RREP message intended for LOADng Router 635 A, soliciting an RREP-ACK message. 637 o Upon receiving the RREP, LOADng Router C updates the corresponding 638 route (Forward Route from LOADng Router C to LOADng Router D), 639 sends an unicast RREP-ACK message to LOADng Router D and forwards 640 the RREP received previously. 642 o Upon receiving the RREP, LOADng Router B updates the corresponding 643 routes (Forward Route from LOADng Router B to LOADng Router D and 644 from LOADng Router B to LOADng Router C). An unicast RREP-ACK 645 message is also sent to LOADng Router C and the RREP received 646 previously is forwarded. 648 o Upon receiving the RREP, LOADng Router A updates the corresponding 649 routes (Forward Route from LOADng Router A to LOADng Router B and 650 from LOADng Router A to LOADng Router D). The reception of the 651 RREP also triggers an unicast RREP-ACK message intended for LOADng 652 Router B. 654 A B C D 655 | RREQ | | | 656 --------------------> | | 657 | | RREQ | | 658 | --------------------> | 659 | | | RREQ | 660 | | --------------------> 661 | | | RREP | 662 | | <-------------------- 663 | | | RREP-ACK | 664 | | --------------------> 665 | | RREP | | 666 | <-------------------- | 667 | | RREP-ACK | | 668 | --------------------> | 669 | RREP | | | 670 <-------------------- | | 671 | RREP-ACK | | | 672 --------------------> | | 673 | | | | 675 3.8. Scenario 08: 3-hop bidirectional route establishment - Link 676 breakage handling 678 This test aims to verify the proper generation, processing and 679 forwarding of a RERR message after an artificially created link 680 breakage on an previously established bidirectional route. 682 3.8.1. Scenario Topology 684 The testbed is composed of four LOADng Routers. Control traffic 685 generated by either LOADng Router A towards LOADng Router D or LOADng 686 Router D towards LOADng Router A has to be forwarded by LOADng 687 Routers B and C: 689 +-------+ +-------+ +-------+ +-------+ 690 | A |________| B |________| C |________| D | 691 | | | | | | | | 692 +-------+ +-------+ +-------+ +-------+ 694 This test suite consists in handling link breakages between LOADng 695 Routers. 697 3.8.2. Expected Message Sequencing 699 The expected message sequencing is as follows: 701 o A bidirectional route is already established between LOADng 702 Routers A and D. 704 o At some time, link breakage is detected by LOADng Router C. 705 Consequently, an unicast RERR message intended for LOADng Router A 706 (here the assumption is made that the unsuccessful delivered data 707 traffic would have been generated by LOADng Router A) is 708 transmitted to LOADng Router B according to the Reverse Route from 709 LOADng Router C to LOADng Router A computed previously. 711 Note: link breakage is provoked artificially and its detection by 712 LOADng Router C is triggered manually (normally, this would be 713 triggered by failure in sending data traffic intended for LOADng 714 Router D). 716 o Upon receiving the RERR, LOADng Router B updates its Routing Set 717 by invalidating the existing Forward Route from LOADng Router B to 718 LOADng Router D. Afterwards, the RERR message is forwarded 719 according to the existing Reverse Route from LOADng Router B to 720 LOADng Router A. 722 o Upon receiving the RERR, LOADng Router A updates its Routing Set 723 by invalidating the existing Forward Route from LOADng Router A to 724 LOADng Router D. 726 A B C D 727 | | | | 728 | | | C-D link breakage X 729 | | | X 730 | | RERR | X 731 | <-------------------- X 732 | RERR | | X 733 <-------------------- | X 734 | | | X 736 3.9. Scenario 09: 4-hop bidirectional route establishment - Forward 737 Route and Reverse Route initial installation 739 This test aims to verify the initial installation of a bidirectional 740 route (Forward Route and Reverse Route from A to E) within the LOADng 741 Router routing tables (Routing Sets) through the effective forwarding 742 of LOADng control traffic by LOADng Routers B, C and D, which are 743 located between LOADng Router A and LOADng Router E. It is also 744 verified that RREP-ACK messages are not forwarded by the LOADng 745 Routers these messages are intended for. 747 3.9.1. Scenario Topology 749 The testbed is composed of five LOADng Routers. Control traffic 750 generated by either LOADng Router A towards LOADng Router E or LOADng 751 Router E towards LOADng Router A has to be forwarded by LOADng 752 Routers B, C and D: 754 +-------+ +-------+ +-------+ +-------+ +-------+ 755 | A |______| B |______| C |______| D |______| E | 756 | | | | | | | | | | 757 +-------+ +-------+ +-------+ +-------+ +-------+ 759 This test suite consists in establishing a bidirectional route 760 between LOADng Router A and LOADng Router E. 762 3.9.2. Expected Message Sequencing 764 The expected message sequencing is as follows: 766 o LOADng Router A generates an RREQ message intended for LOADng 767 Router E. 769 o Upon receiving the RREQ, LOADng Router B installs a new tuple in 770 its Routing Set towards LOADng Router A (Reverse Route from LOADng 771 Router B to LOADng Router A) and forwards the received RREQ. 773 o Upon receiving the RREQ, LOADng Router C installs a new tuple in 774 its Routing Set towards LOADng Router A (Reverse Route from LOADng 775 Router C to LOADng Router A) and a new tuple towards LOADng Router 776 B (Reverse route from LOADng Router C to LOADng Router B) and 777 forwards the received RREQ. 779 o Upon receiving the RREQ, LOADng Router D installs a new tuple in 780 its Routing Set towards LOADng Router A (Reverse Route from LOADng 781 Router D to LOADng Router A) and a new tuple towards LOADng Router 782 C (Reverse route from LOADng Router D to LOADng Router C) and 783 forwards the received RREQ. 785 o Upon receiving the RREQ, LOADng Router E installs a new tuple in 786 its Routing Set towards LOADng Router A (Reverse Route from LOADng 787 Router E to LOADng Router A) and a new tuple towards LOADng Router 788 D (Reverse route from LOADng Router E to LOADng Router D). The 789 reception of the RREQ also triggers the generation of an unicast 790 RREP message intended for LOADng Router A, soliciting an RREP-ACK 791 message. 793 o Upon receiving the RREP, LOADng Router D installs a new tuple in 794 its Routing Set towards LOADng Router E (Forward Route from LOADng 795 Router D to LOADng Router E), sends an unicast RREP-ACK message to 796 LOADng Router E and forwards the RREP received previously. 798 o Upon receiving the RREP, LOADng Router C installs a new tuple in 799 its Routing Set towards LOADng Router E (Forward Route from LOADng 800 Router C to LOADng Router E) and a new tuple towards LOADng Router 801 D (Forward Route from LOADng Router C to LOADng Router D). An 802 unicast RREP-ACK message is also sent to LOADng Router D and the 803 RREP received previously is forwarded. 805 o Upon receiving the RREP, LOADng Router B installs a new tuple in 806 its Routing Set towards LOADng Router E (Forward Route from LOADng 807 Router B to LOADng Router E) and a new tuple towards LOADng Router 808 C (Forward Route from LOADng Router B to LOADng Router C). An 809 unicast RREP-ACK message is also sent to LOADng Router C and the 810 RREP received previously is forwarded. 812 o Upon receiving the RREP, LOADng Router A installs a new tuple in 813 its Routing Set towards LOADng Router B (Forward Route from LOADng 814 Router A to LOADng Router B) and a new tuple towards LOADng Router 815 E (Forward Route from LOADng Router A to LOADng Router E). The 816 reception of the RREP also triggers an unicast RREP-ACK message 817 intended for LOADng Router B. 819 A B C D E 820 | RREQ | | | | 821 ---------------> | | | 822 | | RREQ | | | 823 | ---------------> | | 824 | | | RREQ | | 825 | | ---------------> | 826 | | | | RREQ | 827 | | | ---------------> 828 | | | | RREP | 829 | | | <--------------- 830 | | | | RREP-ACK | 831 | | | ---------------> 832 | | | RREP | | 833 | | <--------------- | 834 | | | RREP-ACK | | 835 | | ---------------> | 836 | | RREP | | | 837 | <--------------- | | 838 | | RREP-ACK | | | 839 | ---------------> | | 840 | RREP | | | | 841 <--------------- | | | 842 | RREP-ACK | | | | 843 ---------------> | | | 844 | | | | | 846 3.10. Scenario 10: 4-hop bidirectional route establishment - Link 847 breakage handling 849 This test aims to verify the proper generation, processing and 850 forwarding of a RERR message after an artificially created link 851 breakage on an previously established bidirectional route. 853 3.10.1. Scenario Topology 855 The testbed is composed of five LOADng Routers. Control traffic 856 generated by either LOADng Router A towards LOADng Router E or LOADng 857 Router E towards LOADng Router A has to be forwarded by LOADng 858 Routers B, C and D: 860 +-------+ +-------+ +-------+ +-------+ +-------+ 861 | A |______| B |______| C |______| D |______| E | 862 | | | | | | | | | | 863 +-------+ +-------+ +-------+ +-------+ +-------+ 865 This test suite consists in handling link breakages between routers. 867 3.10.2. Expected Message Sequencing 869 The expected message sequencing is as follows: 871 o A bidirectional route is already established between LOADng 872 Routers A and E. 874 o At some time, a link breakage to E is detected by LOADng Router D. 875 Consequently, an unicast RERR message intended for LOADng Router A 876 (here the assumption is made that the unsuccessful delivered data 877 traffic would have been generated by LOADng Router A) is 878 transmitted to LOADng Router C according to the Reverse Route from 879 LOADng Router C to LOADng Router A computed previously. 881 Note: link breakage is provoked artificially and its detection by 882 LOADng Router D is triggered manually (normally, this would be 883 triggered by failure in sending data traffic intended for LOADng 884 Router E). 886 o Upon receiving the RERR, LOADng Router C updates its Routing Set 887 by invalidating the existing Forward Route from LOADng Router C to 888 LOADng Router E. Afterwards, the RERR message is forwarded 889 according to the existing Reverse Route from LOADng Router C to 890 LOADng Router A. 892 o Upon receiving the RERR, LOADng Router B updates its Routing Set 893 by invalidating the existing Forward Route from LOADng Router B to 894 LOADng Router E. Afterwards, the RERR message is forwarded 895 according to the existing Reverse Route from LOADng Router B to 896 LOADng Router A. 898 o Upon receiving the RERR, LOADng Router A updates its Routing Set 899 by invalidating the existing Forward Route from LOADng Router A to 900 LOADng Router E. 902 A B C D E 903 | | | | | 904 | | | D-E link breakage 905 | | | | X 906 | | | RERR | X 907 | | <--------------- X 908 | | RERR | | X 909 | <--------------- | X 910 | RERR | | | X 911 <--------------- | | X 912 | | | | X 914 3.11. Scenario 11: Establishment of the best bidirectional route 916 This test aims to verify the processing of multiple RREQs when 917 installing a bidirectional route (Forward Route and Reverse Route 918 from A to C) within the LOADng Router routing tables (Routing Sets). 920 3.11.1. Scenario Topology 922 The testbed is composed of three LOADng Routers. Control traffic 923 generated by either LOADng Router A towards LOADng Router C or LOADng 924 Router C towards LOADng Router A can be forwarded by LOADng Router B 925 or transmitted via the direct link between LOADng Routers A and C: 927 +-------+ +-------+ +-------+ 928 | A |________| B |________| C | 929 | | | | | | 930 +-------+ +-------+ +-------+ 931 |_________________________________| 933 This test consists in establishing a bidirectional route between 934 LOADng Router A and LOADng Router C. Hop count metric is used for 935 measuring differet routes. 937 3.11.2. Expected Message Sequencing 939 The expected message sequencing is as follows: 941 o LOADng Router A generates an RREQ message intended for LOADng 942 Router C. According to RREQ transmission rules, the generated RREQ 943 message is transmitted to all neighbor LOADng Routers. 945 o Upon receiving the RREQ, LOADng Router B installs a new tuple in 946 its Routing Set towards LOADng Router A (Reverse Route from LOADng 947 Router B to LOADng Router A) and forwards the received RREQ. 949 At the same time, upon receiving the same RREQ via its direct link 950 with LOADng Router A, LOADng Router C installs a new tuple in its 951 Routing Set (Reverse Route from LOADng Router C to LOADng Router 952 A). The reception of the RREQ also triggers the generation of an 953 unicast RREP message intended for LOADng Router A, requiring RREP- 954 ACK message. 956 o Upon receiving the same RREQ via LOADng Router B, LOADng Router C 957 compares the RREQ.route-metric information carried by the RREQ 958 with the already existing tuple within its Routing Set (Reverse 959 Route from LOADng Router C to LOADng Router A) according to the 960 comparison operator specified by the metric used (the "hop count" 961 metric was used). Thus, the best route is chosen considering only 962 the hop count: 964 Already existing tuple: 966 = 1 968 Tuple corresponding to the newly received RREQ: 970 = 2 972 According to the comparison operator specified by the metric used: 974 1 < 2 976 Consequently, the newly received RREQ message is discarded without 977 affecting the Routing Set or triggering the generation of any RREP 978 message. 980 o Upon receiving the RREP via its direct link with LOADng Router C, 981 LOADng Router A installs a new tuple in its Routing Set (Forward 982 Route from LOADng Router A to LOADng Router C). The reception of 983 the RREP also triggers an unicast RREP-ACK message intended for 984 LOADng Router C. 986 A B C 987 | RREQ | | 988 --------------------> RREQ | 989 ----------------------------------------> 990 | | RREQ | 991 | --------------------> 992 | | RREP | 993 <---------------------------------------- 994 | | RREP-ACK | 995 ----------------------------------------> 996 | | | 998 Note: the RREQ forwarded by LOADng Router B towards C is not 999 necessarily received before LOADng Router C generates the RREP 1000 message intended for LOADng Router A. Indeed, the order in which 1001 those messages are transmitted is dependent on the transmission 1002 delays of each single link between LOADng Routers A, B and C. 1004 3.12. Scenario 12: Blacklisting 1006 This test aims to verify the effectiveness of avoiding unidirectional 1007 links using blacklisting. 1009 3.12.1. Scenario Topology 1011 The testbed is composed of four LOADng Routers with a unidirectional 1012 link between LOADng Routers A and D (direct communication from D 1013 towards A is impossible). 1015 +-------+ +-------+ 1016 | A |_________| B | 1017 | | | | 1018 +-------+ +-------+ 1019 | | 1020 V | 1021 +-------+ +-------+ 1022 | D |_________| C | 1023 | | | | 1024 +-------+ +-------+ 1026 This test consists in establishing a bidirectional route between 1027 LOADng Router A and LOADng Router D. 1029 3.12.2. Expected Message Sequencing 1031 First attempt to establish a bidirectional route between LOADng 1032 Routers A and D: 1034 o LOADng Router A generates an RREQ message (RREQ.seq-num = 0, 1035 RREQ.originator = A) intended for LOADng Router D. 1037 o Upon receiving the RREQ, LOADng Router B installs a new tuple in 1038 its Routing Set towards LOADng Router A (Reverse Route from LOADng 1039 Router B to LOADng Router A) and forwards the received RREQ. 1041 At the same time, upon receiving the same RREQ via its direct 1042 (unidirectional) link with LOADng Router A, LOADng Router D 1043 installs a new tuple in its Routing Set towards LOADng Router A 1044 (Reverse Route from LOADng Router D to LOADng Router A). The 1045 reception of the RREQ also triggers the generation of an unicast 1046 RREP message intended for LOADng Router A. The RREP.ackrequired 1047 the sent RREP message is set ('1'). 1049 o Upon receiving the RREQ, LOADng Router C installs a new tuple in 1050 its Routing Set towards LOADng Router A (Reverse Route from LOADng 1051 Router C to LOADng Router A) and a new tuple towards LOADng Router 1052 B (Reverse route from LOADng Router C to LOADng Router B) and 1053 forwards the received RREQ. 1055 o Upon receiving the same RREQ (RREQ.seq-num = 0, RREQ.originator = 1056 A) again via LOADng Router C, LOADng Router D compares the 1057 RREQ.route-metric information carried by the RREQ with the already 1058 existing tuple within its Routing Set (Reverse Route from LOADng 1059 Router D to LOADng Router A) according to the comparison operator 1060 specified by the metric used (hop count): 1062 Already existing tuple: 1064 = 1 1066 Tuple corresponding to the newly received RREQ: 1068 = 2 1070 According to the comparison operator specified by the metric used: 1072 1 < 2 1074 Consequently, the newly received RREQ message is discarded without 1075 affecting the Routing Set or triggering the generation of any RREP 1076 message. 1078 o Due to the unidirectional nature of the existing link between 1079 LOADng Routers A and D, the RREP message previously sent by LOADng 1080 Router D intended for LOADng Router A did not reach its 1081 destination. After an elapsed time equaling RREP_ACK_TIMEOUT, 1082 LOADng Router D is not expecting an RREP-ACK message anymore. 1083 This results in recording LOADng Router A neighbor in LOADng 1084 Router D's Blacklist. 1086 Second attempt to establish a bidirectional route between LOADng 1087 Routers A and D: 1089 o LOADng Router A generates an RREQ message (RREQ.seq-num = 1, 1090 RREQ.originator = A) intended for LOADng Router D. 1092 o Upon receiving the RREQ, LOADng Router B installs a new tuple in 1093 its Routing Set towards LOADng Router A (Reverse Route from LOADng 1094 Router B to LOADng Router A) and forwards the received RREQ. 1096 At the same time, upon receiving the same RREQ via its blacklisted 1097 neighbor LOADng Router A, LOADng Router D discards the message. 1099 o Upon receiving the RREQ, LOADng Router C updates the corresponding 1100 routes (Reverse Routes from LOADng Router C to LOADng Router A and 1101 from LOADng Router C to LOADng Router B) and forwards the received 1102 RREQ. 1104 o Upon receiving the RREQ, LOADng Router D updates the already 1105 installed route (Reverse Route from LOADng Router C to LOADng 1106 Router A) and installs a new tuple towards LOADng Router C 1107 (Reverse route from LOADng Router D to LOADng Router C). The 1108 reception of the RREQ also triggers the generation of an unicast 1109 RREP message intended for LOADng Router A. The RREP.ackrequired of 1110 the sent RREP message is set ('1'). 1112 o Upon receiving the RREP, LOADng Router C installs a new tuple in 1113 its Routing Set towards LOADng Router D (Forward Route from LOADng 1114 Router C to LOADng Router D), sends an unicast RREP-ACK message to 1115 LOADng Router D and forwards the RREP received previously. 1117 o Upon receiving the RREP, LOADng Router B installs a new tuple in 1118 its Routing Set towards LOADng Router D (Forward Route from LOADng 1119 Router B to LOADng Router D) and a new tuple towards LOADng Router 1120 C (Forward Route from LOADng Router B to LOADng Router C). An 1121 unicast RREP-ACK message is also sent to LOADng Router C and the 1122 RREP received previously is forwarded. 1124 o Upon receiving the RREP, LOADng Router A installs a new tuple in 1125 its Routing Set towards LOADng Router D (Forward Route from LOADng 1126 Router A to LOADng Router D) and a new tuple towards LOADng Router 1127 B (Forward Route from LOADng Router A to LOADng Router B). The 1128 reception of the RREP also triggers an unicast RREP-ACK message 1129 intended for LOADng Router B. 1131 A B C D 1132 | | | | 1133 First attempt ///////////////////////////////////////// 1134 | RREQ | | | 1135 ------------------> RREQ | | 1136 ------------------------------------------------------> 1137 | | RREP | | 1138 |XXXXX <----------------------------------------------- 1139 | | RREQ | | 1140 | ------------------> | 1141 | | | RREQ | 1142 | | ----------------->X RREQ 1143 | | | | Discarded 1144 Second attempt //////////////////////////////////////// 1145 | RREQ | | | 1146 ------------------> RREQ | | 1147 ----------------------------------------------------->X RREQ 1148 | | RREQ | | Discarded 1149 | ------------------> | 1150 | | | RREQ | 1151 | | ------------------> 1152 | | | RREP | 1153 | | <------------------ 1154 | | | RREP-ACK | 1155 | | ------------------> 1156 | | RREP | | 1157 | <------------------ | 1158 | | RREP-ACK | | 1159 | ------------------> | 1160 | RREP | | | 1161 <------------------ | | 1162 | RREP-ACK | | | 1163 ------------------> | | 1165 4. Interop 01: Yokohama, Japan, October 2011 1167 4.1. Version of LOADng Specification Tested 1169 The interoperability tests were conducted according to the 1170 specification in [LOADng-00]. 1172 NOTE: Due to the evolution of [LOADng] and this document, ome of the 1173 conventions used in Section 3, such as routing metric and some fields 1174 of messages, may be different from the description in [LOADng-00]. 1176 4.2. Place and Date of Interoperability Test 1178 This section reports experience with the LOADng routing protocol, 1179 resulting from interoperability testing performed at Hitachi YRL in 1180 Yokohama, Japan, from october 17th to october 19th 2011. 1182 4.3. Participating Implementations 1184 The following implementations were used to perform the 1185 interoperability tests this section, listed alphabetically: 1187 Ecole Polytechnique: "LIX" - This implementation was jointly 1188 developed by Axel Colin de Verdiere, Jiazi Yi, Ulrich Herberg and 1189 Thomas Clausen of Ecole Ploytechnique's networking team. It 1190 consists of approximately 6000 lines of JAVA code running in a Mac 1191 OS environment. It supports RREQ, RREP, RREP-ACK and RERR 1192 generation, processing, forwarding and transmission. 1194 Hitachi YRL 1: "Hitachi 1" - This implementation was fully developed 1195 by Yuichi Igarashi of Hitachi YRL. It consists of 1589 lines of C 1196 code running in the Hitachi proprietary micro OS environment 1197 embedded in a 16MHz H8 micro processor. It supports RREQ, RREP, 1198 RREP-ACK and RERR generation, processing, forwarding and 1199 transmission. 1201 Hitachi YRL 2: "Hitachi 2" - This implementation was jointly 1202 developed by Nobukatsu Inomata of Hitachi ULSI Systems and Yoko 1203 Morii of Hitachi YRL. It consists of 1987 lines of C++ code 1204 running in a Mac OS environment. It supports RREQ, RREP, RREP-ACK 1205 generation, processing, forwarding and transmission, and RERR 1206 processing. 1208 4.4. Scenarios Tested 1210 This interoperability test includes all scenarios 01-12 (inclusive). 1212 4.5. Additional Interoperability Test Considerations 1214 Wireshark packet sniffers, modified to interpret LOADng control 1215 traffic, were used to monitor each link, so as to verify propper 1216 message sequencing. 1218 For each test, the initiation of the communication resulting in the 1219 generation of the first LOADng control traffic message is always 1220 triggered manually. In addition, RREP-ACK LOADng control messages 1221 were systematically expected from each LOADng Router upon reception 1222 of a RREP LOADng control message in order to allow the detection of 1223 unidirectional links. 1225 4.6. Results For Scenario 01 1227 The following table is summarizing the results obtained for the 1228 different combinations for which a 1-hop Forward Route and Reverse 1229 Route initial installation test was performed: 1231 +-----------+------+-----------+-----------+ 1232 | | LIX | Hitachi 1 | Hitachi 2 | 1233 +-----------+------+-----------+-----------+ 1234 | LIX | N/R | Pass | Pass | 1235 | Hitachi 1 | Pass | N/R | Pass | 1236 | Hitachi 2 | Pass | Pass | N/R | 1237 +-----------+------+-----------+-----------+ 1239 Table 1 1241 4.7. Results For Scenario 02 1243 The following table is summarizing the results obtained for the 1244 different combinations for which a 1-hop Forward Route and Reverse 1245 Route updating test was performed: 1247 +-----------+------+-----------+-----------+ 1248 | | LIX | Hitachi 1 | Hitachi 2 | 1249 +-----------+------+-----------+-----------+ 1250 | LIX | N/R | Pass | Pass | 1251 | Hitachi 1 | Pass | N/R | Pass | 1252 | Hitachi 2 | Pass | Pass | N/R | 1253 +-----------+------+-----------+-----------+ 1255 Table 2 1257 4.8. Results For Scenario 03 1259 The following table is summarizing the results obtained for the 1260 different combinations for which a 2-hop Forward Route and Reverse 1261 Route initial installation test was performed: 1263 +-----------+-----------+-----------+--------+ 1264 | A | B | C | Result | 1265 +-----------+-----------+-----------+--------+ 1266 | Hitachi 1 | LIX | Hitachi 2 | Pass | 1267 | Hitachi 2 | LIX | Hitachi 1 | Pass | 1268 | LIX | Hitachi 1 | Hitachi 2 | Pass | 1269 | Hitachi 2 | Hitachi 1 | LIX | Pass | 1270 | LIX | Hitachi 2 | Hitachi 1 | Pass | 1271 | Hitachi 1 | Hitachi 2 | LIX | Pass | 1272 +-----------+-----------+-----------+--------+ 1274 Table 3 1276 4.9. Results For Scenario 04 1278 The following table is summarizing the results obtained for the 1279 different combinations for which a 2-hop Forward Route and Reverse 1280 Route updating test was performed: 1282 +-----------+-----------+-----------+--------+ 1283 | A | B | C | Result | 1284 +-----------+-----------+-----------+--------+ 1285 | Hitachi 1 | LIX | Hitachi 2 | Pass | 1286 | Hitachi 2 | LIX | Hitachi 1 | Pass | 1287 | LIX | Hitachi 1 | Hitachi 2 | Pass | 1288 | Hitachi 2 | Hitachi 1 | LIX | Pass | 1289 | LIX | Hitachi 2 | Hitachi 1 | Pass | 1290 | Hitachi 1 | Hitachi 2 | LIX | Pass | 1291 +-----------+-----------+-----------+--------+ 1293 Table 4 1295 4.10. Results For Scenario 05 1297 The following table is summarizing the results obtained for the 1298 different combinations for which a Link breakage handling test was 1299 performed: 1301 +-----------+-----------+-----+--------+ 1302 | A | B | C | Result | 1303 +-----------+-----------+-----+--------+ 1304 | Hitachi 1 | LIX | LIX | Pass | 1305 | LIX | Hitachi 1 | LIX | Pass | 1306 +-----------+-----------+-----+--------+ 1308 Table 5 1310 4.11. Results For Scenario 06 1312 The following table is summarizing the results obtained for the 1313 different combinations for which a 3-hop Forward Route and Reverse 1314 Route initial installation test was performed: 1316 +-----------+-----------+-----------+-----------+--------+ 1317 | A | B | C | D | Result | 1318 +-----------+-----------+-----------+-----------+--------+ 1319 | Hitachi 1 | LIX | LIX | Hitachi 2 | Pass | 1320 | Hitachi 1 | LIX | Hitachi 2 | LIX | Pass | 1321 | LIX | Hitachi 2 | Hitachi 1 | LIX | Pass | 1322 +-----------+-----------+-----------+-----------+--------+ 1324 Table 6 1326 4.12. Results For Scenario 07 1328 The following table is summarizing the results obtained for the 1329 different combinations for which a 3-hop Forward Route and Reverse 1330 Route updating test was performed: 1332 +-----------+-----------+-----------+-----------+--------+ 1333 | A | B | C | D | Result | 1334 +-----------+-----------+-----------+-----------+--------+ 1335 | Hitachi 1 | LIX | LIX | Hitachi 2 | Pass | 1336 | Hitachi 1 | LIX | Hitachi 2 | LIX | Pass | 1337 | LIX | Hitachi 2 | Hitachi 1 | LIX | Pass | 1338 +-----------+-----------+-----------+-----------+--------+ 1340 Table 7 1342 4.13. Results For Scenario 08 1344 The following table is summarizing the results obtained for the 1345 different combinations for which a Link breakage handling test was 1346 performed: 1348 +-----------+-----------+-----+-----------+--------+ 1349 | A | B | C | D | Result | 1350 +-----------+-----------+-----+-----------+--------+ 1351 | Hitachi 1 | LIX | LIX | Hitachi 2 | Pass | 1352 | LIX | Hitachi 1 | LIX | Hitachi 2 | Pass | 1353 +-----------+-----------+-----+-----------+--------+ 1355 Table 8 1357 4.14. Results For Scenario 09 1359 The following table is summarizing the results obtained for the 1360 different combinations for which a 4-hop Forward Route and Reverse 1361 Route initial installation test was performed: 1363 +-----------+-----------+-----+-----------+-----+--------+ 1364 | A | B | C | D | E | Result | 1365 +-----------+-----------+-----+-----------+-----+--------+ 1366 | Hitachi 2 | Hitachi 1 | LIX | Hitachi 1 | LIX | Pass | 1367 +-----------+-----------+-----+-----------+-----+--------+ 1369 Table 9 1371 4.15. Results For Scenario 10 1373 The following table is summarizing the results obtained for the 1374 different combinations for which a Link breakage handling test was 1375 performed: 1377 +-----------+-----------+-----+-----------+-----+--------+ 1378 | A | B | C | D | E | Result | 1379 +-----------+-----------+-----+-----------+-----+--------+ 1380 | Hitachi 2 | Hitachi 1 | LIX | Hitachi 1 | LIX | Pass | 1381 +-----------+-----------+-----+-----------+-----+--------+ 1383 Table 10 1385 4.16. Results For Scenario 11 1387 The following table is summarizing the results obtained for the 1388 different combinations for which a test consisting in the 1389 establishment of the best bidirectional route was performed: 1391 +-----------+-----------+-----------+--------+ 1392 | A | B | C | Result | 1393 +-----------+-----------+-----------+--------+ 1394 | LIX | Hitachi 1 | Hitachi 2 | Pass | 1395 | LIX | Hitachi 2 | Hitachi 1 | Pass | 1396 | Hitachi 2 | Hitachi 1 | LIX | Pass | 1397 | Hitachi 1 | LIX | Hitachi 2 | Pass | 1398 +-----------+-----------+-----------+--------+ 1400 Table 11 1402 4.17. Results For Scenario 12 1404 The following table is summarizing the results obtained for the 1405 different combinations for which a Blacklisting test was performed: 1407 +-----------+-----+-----------+-----------+--------+ 1408 | A | B | C | D | Result | 1409 +-----------+-----+-----------+-----------+--------+ 1410 | Hitachi 2 | LIX | Hitachi 1 | LIX | Pass | 1411 | LIX | LIX | Hitachi 1 | Hitachi 2 | Pass | 1412 | Hitachi 2 | LIX | LIX | Hitachi 1 | Pass | 1413 +-----------+-----+-----------+-----------+--------+ 1415 Table 12 1417 4.18. Conclusions 1419 The different test scenarios carried that were carried out for 1420 different interoperable and independent implementations allowed to 1421 completely cover the [LOADng-00] specification by checking each 1422 technical feature one by one. In addition, the completion of this 1423 process permitted the improvement of the overall quality and accuracy 1424 of the [LOADng-00] specification. 1426 +------+----------------+-----------------------+-----------+ 1427 | | | |Test suites| 1428 |Chap. | Item | Technical feature +-----------+ 1429 | | | |A|B|C|D|E|F| 1430 +------+----------------+------------+----------+-+-+-+-+-+-+ 1431 |6.1 | | |Originator|X|X|X| |X|X| 1432 +------+ Information |Routing Set +----------+-+-+-+-+-+-+ 1433 |6.1 | Base | |Previous | |X|X|X| |X| 1434 +------+ +------------+----------+-+-+-+-+-+-+ 1435 |6.2 | |Blacklist Neighbor set | | | | | |X| 1436 +------+----------------+-----------------------+-+-+-+-+-+-+ 1437 |8.1 | |TLV |X|X|X|X|X|X| 1438 +------+ +-----------------------+-+-+-+-+-+-+ 1439 |8.2.1 | Packet |Route Request Message |X|X|X|X|X|X| 1440 +------+ Format +-----------------------+-+-+-+-+-+-+ 1441 |8.2.1 | |Route Reply Message |X|X|X|X|X|X| 1442 +------+ +-----------------------+-+-+-+-+-+-+ 1443 |8.2.2 | |Route Reply Ack Message|X|X|X|X|X|X| 1444 +------+ +-----------------------+-+-+-+-+-+-+ 1445 |8.2.3 | |Route Error Message | |X|X|X| | | 1446 +------+----------------+-----------------------+-+-+-+-+-+-+ 1447 |10.1 | Unidirectional |Blacklist | | | | | |X| 1448 | | link handling | | | | | | | | 1449 +------+----------------+-----------------------+-+-+-+-+-+-+ 1450 |11.1 | |Invalid RREQ, RREP |X|X|X|X|X|X| 1451 +------+ Common rules +-----------------------+-+-+-+-+-+-+ 1452 |11.2 | for RREQ, RREP |RREQ, RREP Processing |X|X|X|X|X|X| 1453 +------+ Message +-----------------------+-+-+-+-+-+-+ 1454 |11.3 | |Updating RREQ, RREP |X|X|X|X|X|X| 1455 +------+----------------+-----------------------+-+-+-+-+-+-+ 1456 |12.1 | |RREQ Generation |X|X|X|X|X|X| 1457 +------+ +-----------------------+-+-+-+-+-+-+ 1458 |12.2 | Route |RREQ Processing |X|X|X|X|X|X| 1459 +------+ Requests +-----------------------+-+-+-+-+-+-+ 1460 |12.3 | (RREQs) |RREQ Forwarding | |X|X|X|X|X| 1461 +------+ +-----------------------+-+-+-+-+-+-+ 1462 |12.4 | |RREQ Transmission |X|X|X|X|X|X| 1463 +------+----------------+-----------------------+-+-+-+-+-+-+ 1464 |13.1 | |RREP Generation |X|X|X|X|X|X| 1465 +------+ +-----------------------+-+-+-+-+-+-+ 1466 |13.2 | Route |RREP Processing |X|X|X|X|X|X| 1467 +------+ Replies +-----------------------+-+-+-+-+-+-+ 1468 |13.3 | (RREPs) |RREP Forwarding | |X|X|X|X|X| 1469 +------+ +-----------------------+-+-+-+-+-+-+ 1470 |13.4 | |RREP Transmission |X|X|X|X|X|X| 1471 +------+----------------+-----------------------+-+-+-+-+-+-+ 1472 |14.1 | |RERR Generation | |X|X|X| | | 1473 +------+ +-----------------------+-+-+-+-+-+-+ 1474 |14.2 | Route |RERR Processing | |X|X|X| | | 1475 +------+ Errors +-----------------------+-+-+-+-+-+-+ 1476 |14.3 | (RERRs) |RERR Forwarding | | |X|X| | | 1477 +------+ +-----------------------+-+-+-+-+-+-+ 1478 |14.4 | |RERR Transmission | |X|X|X| | | 1479 +------+----------------+-----------------------+-+-+-+-+-+-+ 1480 |15.1 | |RREP-ACK Generation |X|X|X|X|X|X| 1481 +------+ +-----------------------+-+-+-+-+-+-+ 1482 |15.2 | Route |RREQ-ACK Processing |X|X|X|X|X|X| 1483 +------+ Reply +-----------------------+-+-+-+-+-+-+ 1484 |15.3 | Acknowledgement|RREQ-ACK Forwarding |X|X|X|X|X|X| 1485 +------+ (RREP-ACKs) +-----------------------+-+-+-+-+-+-+ 1486 |15.4 | |RREQ-ACK Transmission |X|X|X|X|X|X| 1487 +------+----------------+-----------------------+-+-+-+-+-+-+ 1488 |16 | Metrics |Hop Count While |X|X|X|X|X|X| 1489 | | |Avoiding Weak Links | | | | | | | 1490 +------+----------------+-----------------------+-+-+-+-+-+-+ 1492 Test suite A : 1-hop bidirectional route establishment (scenarios 01, 1493 02) 1495 Test suite B : 2-hop bidirectional route establishment (scenarios 03, 1496 04, 05) 1497 Test suite C : 3-hop bidirectional route establishment (scenarios 06, 1498 07, 08) 1500 Test suite D : 4-hop bidirectional route establishment (scenarios 09, 1501 10) 1503 Test suite E : Establishment of the best bidirectional route 1504 (scenario 11) 1506 Test suite F : Blacklisting (scenario 12) 1508 5. Interop 02: San Jose, USA March 2012 1510 5.1. LOADng version tested 1512 The interoperability tests were conducted according to the 1513 specification in [LOADng-03]. 1515 NOTE: Due to the evolution of [LOADng] and this document, ome of the 1516 conventions used in Section 3, such as routing metric and some fields 1517 of messages, may be different from the description in [LOADng-03]. 1519 5.2. Place and Date of Interoperability Test 1521 This section reports experience with the LOADng routing protocol, 1522 resulting from interoperability testing performed at Fujitsu 1523 Laboratories of America (FLA), San Jose, USA, on April 13, 2012. 1525 5.3. Participating Implementations 1527 The following implementations were used to perform the 1528 interoperability tests this section, listed alphabetically: 1530 Ecole Polytechnique: "LIX" - This implementation was jointly 1531 developed by Axel Colin de Verdiere, Jiazi Yi, Ulrich Herberg and 1532 Thomas Clausen of Ecole Ploytechnique's networking team. It 1533 consists of approximately 6000 lines of JAVA code running in a Mac 1534 OS environment. It supports RREQ, RREP, RREP-ACK and RERR 1535 generation, processing, forwarding and transmission. 1537 Fujitsu Laboratories of America: "FLA" - This implementation was 1538 developed by Ulrich Herberg from Fujitsu Laboratories of America. 1539 It is a Java implementation, supporting basic features (RREQ, 1540 RREP, RREP-ACK generation, processing, forwarding and 1541 transmision). 1543 5.4. Interoperability Test Considerations 1545 As an intermediate test, only a subset of the scenarios described 1546 were tested (01, 03 and 05), for verifying interoperability bug- 1547 fixing the involved implementations. 1549 5.5. Results For Scenario 01 1551 The following table is summarizing the results obtained for the 1552 different combinations for which a 1-hop Forward Route and Reverse 1553 Route initial installation test was performed: 1555 +-----+------+------+ 1556 | | LIX | FLA | 1557 +-----+------+------+ 1558 | LIX | N/R | Pass | 1559 | FLA | Pass | N/R | 1560 +-----+------+------+ 1562 Table 13 1564 5.6. Results For Scenrio 03 1566 The following table is summarizing the results obtained for the 1567 different combinations for which a 2-hop Forward Route and Reverse 1568 Route initial installation test was performed: 1570 +-----+-----+-----+--------+ 1571 | A | B | C | Result | 1572 +-----+-----+-----+--------+ 1573 | LIX | FLA | LIX | Pass | 1574 | LIX | LIX | FLA | Pass | 1575 +-----+-----+-----+--------+ 1577 Table 14 1579 5.7. Results For Scenario 05 1581 The following table is summarizing the results obtained for the 1582 different combinations for which a Link breakage handling test was 1583 performed: 1585 +-----+-----+-----+--------+ 1586 | A | B | C | Result | 1587 +-----+-----+-----+--------+ 1588 | LIX | FLA | LIX | Pass | 1589 +-----+-----+-----+--------+ 1590 Table 15 1592 6. Interop 03: Los Angeles, USA, June 2012 1594 6.1. Version of LOADng Specification Tested 1596 The interoperability tests were conducted according to the 1597 specification in [LOADng-04]. 1599 NOTE: Due to the evolution of [LOADng] and this document, some of the 1600 conventions used in Section 3, such as routing metric and some fields 1601 of messages, may be different from the description in [LOADng-04]. 1603 6.2. Place and Date of Interoperability Test 1605 This section reports experience with the LOADng routing protocol, 1606 resulting from interoperability testing performed at the Los Angeles 1607 Airport Hilton, USA, on June 6, 2012. 1609 6.3. Participating Implementations 1611 The following implementations were used to perform the 1612 interoperability tests this section, listed alphabetically: 1614 Ecole Polytechnique: "LIX" - This implementation was jointly 1615 developed by Axel Colin de Verdiere, Jiazi Yi, Ulrich Herberg and 1616 Thomas Clausen of Ecole Ploytechnique's networking team. It 1617 consists of approximately 6000 lines of JAVA code running in a Mac 1618 OS environment. It supports RREQ, RREP, RREP-ACK and RERR 1619 generation, processing, forwarding and transmission. 1621 Fujitsu Laboratories of America: "FLA" - This implementation was 1622 developed by Ulrich Herberg from Fujitsu Laboratories of America. 1623 It is a Java implementation, supporting basic features (RREQ, 1624 RREP, RREP-ACK generation, processing, forwarding and 1625 transmision). 1627 6.4. Scenarios Tested 1629 This interoperability test includes scenarios 01-12 (inclusive). 1631 6.5. Additional Interoperability Test Considerations 1633 Wireshark packet sniffers, that have been modified to interpret 1634 LOADng control traffic, were used to monitor each single underlying 1635 link. 1637 For each test, the initiation of the communication resulting in the 1638 generation of the first LOADng control traffic message is always 1639 triggered manually. In addition, RREP-ACK LOADng control messages 1640 were systematically expected from each LOADng Router upon reception 1641 of a RREP LOADng control message in order to allow the detection of 1642 unidirectional links. 1644 6.6. Results For Scenario 01-02 1646 The following table is summarizing the results obtained for the 1647 different combinations for which test 1 (Forward Route and Reverse 1648 Route initial installation) was performed: 1650 +-----+------+------+ 1651 | | LIX | FLA | 1652 +-----+------+------+ 1653 | LIX | N/R | Pass | 1654 | FLA | Pass | N/R | 1655 +-----+------+------+ 1657 Table 16 1659 The following table is summarizing the results obtained for the 1660 different combinations for which test 2 (Forward Route and Reverse 1661 Route updating) was performed: 1663 +-----+------+------+ 1664 | | LIX | FLA | 1665 +-----+------+------+ 1666 | LIX | N/R | Pass | 1667 | FLA | Pass | N/R | 1668 +-----+------+------+ 1670 Table 17 1672 6.7. Results For Scenario 03-04-05 1674 The following table is summarizing the results obtained for the 1675 different combinations for which these test 1 (Forward Route and 1676 Reverse Route initial installation) and test 2 (Forward Route and 1677 Reverse Route updating) were performed: 1679 +-----+-----+-----+--------+--------+ 1680 | A | B | C | Test 1 | Test 2 | 1681 +-----+-----+-----+--------+--------+ 1682 | LIX | FLA | LIX | Pass | Pass | 1683 | LIX | LIX | FLA | Pass | Pass | 1684 +-----+-----+-----+--------+--------+ 1685 Table 18 1687 The following table is summarizing the results obtained for the 1688 different combinations for which these test 3 (Link breakage 1689 handling) was performed: 1691 +-----+-----+-----+--------+ 1692 | A | B | C | Test 3 | 1693 +-----+-----+-----+--------+ 1694 | FLA | LIX | LIX | Pass | 1695 | LIX | FLA | LIX | Pass | 1696 +-----+-----+-----+--------+ 1698 Table 19 1700 6.8. Results For Scenario 06-07-08 1702 The following table is summarizing the results obtained for the 1703 different combinations for which these test 1 (Forward Route and 1704 Reverse Route initial installation) and test 2 (Forward Route and 1705 Reverse Route updating) were performed: 1707 +-----+-----+-----+-----+--------+--------+ 1708 | A | B | C | D | Test 1 | Test 2 | 1709 +-----+-----+-----+-----+--------+--------+ 1710 | LIX | FLA | LIX | LIX | Pass | Pass | 1711 | LIX | LIX | FLA | LIX | Pass | Pass | 1712 | FLA | LIX | LIX | LIX | Pass | Pass | 1713 | LIX | LIX | LIX | FLA | Pass | Pass | 1714 +-----+-----+-----+-----+--------+--------+ 1716 Table 20 1718 The following table is summarizing the results obtained for the 1719 different combinations for which these test 3 (Link breakage 1720 handling) was performed: 1722 +-----+-----+-----+-----+--------+ 1723 | A | B | C | D | Test 3 | 1724 +-----+-----+-----+-----+--------+ 1725 | FLA | LIX | LIX | LIX | Pass | 1726 | LIX | LIX | LIX | FLA | Pass | 1727 +-----+-----+-----+-----+--------+ 1729 Table 21 1731 6.9. Results For Scenario 09-10 1733 The following table is summarizing the results obtained for the 1734 different combinations for which test 1 (Forward Route and Reverse 1735 Route initial installation) and test 2 (Link breakage handling) were 1736 performed: 1738 +-----+-----+-----+-----+-----+--------+--------+ 1739 | A | B | C | D | E | Test 1 | Test 2 | 1740 +-----+-----+-----+-----+-----+--------+--------+ 1741 | FLA | FLA | LIX | LIX | LIX | Pass | Pass | 1742 | LIX | LIX | LIX | FLA | FLA | Pass | Pass | 1743 +-----+-----+-----+-----+-----+--------+--------+ 1745 Table 22 1747 6.10. Results For Scenario 11 1749 The following table is summarizing the results obtained for the 1750 different combinations for which this test was performed: 1752 +-----+-----+-----+--------+ 1753 | A | B | C | Result | 1754 +-----+-----+-----+--------+ 1755 | LIX | FLA | LIX | Pass | 1756 | LIX | LIX | FLA | Pass | 1757 | FLA | LIX | LIX | Pass | 1758 +-----+-----+-----+--------+ 1760 Table 23 1762 6.11. Conclusions 1764 The different test scenarios that were carried out for different 1765 interoperable and independent implementations allowed to cover all 1766 major features of the LOADng specification by checking each technical 1767 feature one by one. In addition, the completion of this process 1768 permitted the improvement of the overall quality and accuracy of the 1769 [LOADng] specification. 1771 7. Interop 04: Vancouver, Canada, August, 2011 1773 7.1. Version of LOADng Specifiation Tested 1775 The interoperability tests were conducted according to the 1776 specification in [LOADng-05]. 1778 7.2. Place and Date of Interoperability Test 1780 This section reports experience with the LOADng routing protocol, 1781 resulting from interoperability testing performed at Hyatt Hotel, 1782 Vancouver, August 2nd, 2012. 1784 7.3. Participating Implementations 1786 The following implementations were used to perform the 1787 interoperability tests this section, listed alphabetically: 1789 Ecole Polytechnique: "LIX" - This implementation was jointly 1790 developed by Axel Colin de Verdiere, Jiazi Yi, Ulrich Herberg and 1791 Thomas Clausen of Ecole Ploytechnique's networking team. It 1792 consists of approximately 6000 lines of JAVA code running in a Mac 1793 OS environment. It supports RREQ, RREP, RREP-ACK and RERR 1794 generation, processing, forwarding and transmission. 1796 Fujitsu Laboratories of America: "FLA" - This implementation was 1797 developed by Ulrich Herberg from Fujitsu Laboratories of America. 1798 It is a Java implementation, supporting all LOADng features (RREQ, 1799 RREP, RREP-ACK generation, processing, forwarding and 1800 transmission). 1802 7.4. Scenarios Tested 1804 This interoperability test includes scenarios 01-05 (inclusive). 1806 7.5. Additional Interoperability Test Considerations 1808 For each test, the initiation of the communication resulting in the 1809 generation of the first LOADng control traffic message is always 1810 triggered manually. In addition, RREP-ACK LOADng control messages 1811 were systematically expected from each LOADng Router upon reception 1812 of an RREP LOADng control message in order to allow the detection of 1813 unidirectional links. 1815 In this interop event, the use of different metrics types in the 1816 protocol were specifically considered. 1818 7.6. Results for Scenario 01-02 1820 The following table summarizes the results obtained for the different 1821 combinations for which test 1 (Forward Route and Reverse Route 1822 initial installation) was performed: 1824 +-----+------+------+ 1825 | | LIX | FLA | 1826 +-----+------+------+ 1827 | LIX | N/R | Pass | 1828 | FLA | Pass | N/R | 1829 +-----+------+------+ 1831 Table 24 1833 The following table summarizes the results obtained for the different 1834 combinations for which test 2 (Forward Route and Reverse Route 1835 updating) was performed: 1837 +-----+------+------+ 1838 | | LIX | FLA | 1839 +-----+------+------+ 1840 | LIX | N/R | Pass | 1841 | FLA | Pass | N/R | 1842 +-----+------+------+ 1844 Table 25 1846 7.7. Results for Scenario 03-04-05 1848 The following table summarizes the results obtained for the different 1849 combinations for which these test 1 (Forward Route and Reverse Route 1850 initial installation) and test 2 (Forward Route and Reverse Route 1851 updating) were performed: 1853 +-----+-----+-----+--------+--------+ 1854 | A | B | C | Test 1 | Test 2 | 1855 +-----+-----+-----+--------+--------+ 1856 | LIX | FLA | LIX | Pass | Pass | 1857 | LIX | LIX | FLA | Pass | Pass | 1858 +-----+-----+-----+--------+--------+ 1860 Table 26 1862 The following table is summarizing the results obtained for the 1863 different combinations for which these test 3 (Link breakage 1864 handling) was performed: 1866 +-----+-----+-----+--------+ 1867 | A | B | C | Test 3 | 1868 +-----+-----+-----+--------+ 1869 | FLA | LIX | LIX | Pass | 1870 | LIX | FLA | LIX | Pass | 1871 +-----+-----+-----+--------+ 1873 Table 27 1875 In addition to conventional scenarios as described in Scenario 03 and 1876 Scenario 04 with the same metric type (HOP_COUNT, type 0), different 1877 metric types are tested in the same network. In the test, the 1878 originator of the RREQ initiates a route discovery using a metric 1879 type that the intermediate router does not understand (type 1). 1881 The following table summarizes the results obtained for the different 1882 combinations for which these test 1 (Forward Route and Reverse Route 1883 initial installation) and test 2 (Forward Route and Reverse Route 1884 updating), with different metric types: 1886 +-----+-----+-----+--------+--------+ 1887 | A | B | C | Test 1 | Test 2 | 1888 +-----+-----+-----+--------+--------+ 1889 | LIX | FLA | LIX | Pass | Pass | 1890 | LIX | LIX | FLA | Pass | Fail | 1891 +-----+-----+-----+--------+--------+ 1893 Table 28 1895 One of the tests failed because handling unknown metric types was not 1896 defined properly in [LOADng-05] (but corrected in [LOADng-06], as a 1897 direct result of this interop test). Some changes from [LOADng-05] 1898 to [LOADng-06] that were proposed (and integrated in [LOADng-06]): 1900 1. In section 13.1 ("RREP Generation"): 1902 o RREP.metric-type set to the same value as the RREQ.metric-type 1903 in the corresponding RREQ; 1905 is changed to 1907 o RREP.metric-type set to the same value as the RREQ.metric-type 1908 in the corresponding RREQ if the metric type is known to the 1909 router. Otherwise, RREP.metric-type is set to HOP_COUNT. 1911 Rationale: If a router that generates an RREP for an incoming 1912 RREQ does not know the metric from the RREQ, it will use the 1913 HOP_COUNT metric as fall-back. Per definition, all routers 1914 running LOADng support the HOP_COUNT metric. 1916 2. In section 12.3 ("RREQ forwarding"): 1918 3. RREQ.route-metric := received-route-metric + link-metric 1920 is changed to 1922 3. If used-metric-type is not HOP_COUNT, then RREQ.route-metric 1923 := route-metric + link-metric 1925 Rationale: When the HOP_COUNT metric is used, the metric TLV 1926 value should remain unchanged, and instead the hop count from the 1927 message header is used to calculate the distance. 1929 7.8. Conclusions 1931 As an intermediate test, and because of the limited time, only a 1932 subset of the scenarios (01, 02, 03, 04, 05) have been tested. In 1933 the performed tests, in addition to the conventional behaviors 1934 (regular message exchanges), different metric types, especially 1935 unknown metric types have been used in the network. 1937 The results show that for scenarios with only one metric type, the 1938 two implementations are able to interoperate with each other. 1939 However, when different metrics exist in the same network, the test 1940 failed in some scenarios. The problems are identified, and 1941 corresponding resolutions are proposed. The updates have been 1942 integrated in [LOADng-06]. 1944 8. Security Considerations 1946 This document does currently not specify any security considerations. 1948 9. IANA Considerations 1950 This document has no actions for IANA. 1952 10. Contributors 1954 This specification is the result of the joint efforts of the 1955 following contributors -- listed alphabetically. 1957 o Alberto Camacho, LIX, France, 1959 o Thomas Heide Clausen, LIX, France, 1960 o Axel Colin de Verdiere, LIX, France, 1962 o Ulrich Herberg, Fujitsu Laboratories of America, USA, 1963 1965 o Yuichi Igarashi, HITACHI YRL, Japan, 1966 1968 o Nobukatsu Inomata, HITACHI ULSI Systems, Japan, 1969 1971 o Yoko Morii, HITACHI YRL, Japan, 1973 o Hiroki Satoh, HITACHI YRL, Japan, 1975 o Jiazi Yi, LIX, France, 1977 11. Informative References 1979 [LOADng] Clausen, T., Colin de Verdiere, A., Yi, J., Niktash, A., 1980 Igarashi, Y., Satoh, H., Herberg, U., Lavenu, C., Lys, 1981 T., Perkins, C., and J. Dean, "The Lightweight On-demand 1982 Ad hoc Distance-vector Routing Protocol - Next 1983 Generation (LOADng)", draft-clausen-lln-loadng (work in 1984 progress), October 2012. 1986 [LOADng-00] Clausen, T., Colin de Verdiere, A., Yi, J., Lavenu, C., 1987 Lys, T., Niktash, A., Igarashi, Y., and H. Satoh, "The 1988 LLN On-demand Ad hoc Distance-vector Routing Protocol - 1989 Next Generation (LOADng)", draft-clausen-lln-loadng-00 1990 (work in progress), October 2011. 1992 [LOADng-03] Clausen, T., Colin de Verdiere, A., Yi, J., Niktash, A., 1993 Igarashi, Y., Satoh, H., Herberg, U., Lavenu, C., and T. 1994 Lys, "The LLN On-demand Ad hoc Distance-vector Routing 1995 Protocol - Next Generation (LOADng)", 1996 draft-clausen-lln-loadng-03 (work in progress), 1997 March 2012. 1999 [LOADng-04] Clausen, T., Colin de Verdiere, A., Yi, J., Niktash, A., 2000 Igarashi, Y., Satoh, H., Herberg, U., Lavenu, C., and T. 2001 Lys, "The LLN On-demand Ad hoc Distance-vector Routing 2002 Protocol - Next Generation (LOADng)", 2003 draft-clausen-lln-loadng-04 (work in progress), 2004 April 2012. 2006 [LOADng-05] Clausen, T., Colin de Verdiere, A., Yi, J., Niktash, A., 2007 Igarashi, Y., Satoh, H., Herberg, U., Lavenu, C., Lys, 2008 T., and C. Perkins, "The LLN On-demand Ad hoc Distance- 2009 vector Routing Protocol - Next Generation (LOADng)", 2010 draft-clausen-lln-loadng-05 (work in progress), 2011 July 2012. 2013 [LOADng-06] Clausen, T., Colin de Verdiere, A., Yi, J., Niktash, A., 2014 Igarashi, Y., Satoh, H., Herberg, U., Lavenu, C., Lys, 2015 T., Perkins, C., and J. Dean, "The Lightweight On-demand 2016 Ad hoc Distance-vector Routing Protocol - Next 2017 Generation (LOADng)", draft-clausen-lln-loadng-06 (work 2018 in progress), October 2012. 2020 Authors' Addresses 2022 Thomas Heide Clausen 2023 LIX, Ecole Polytechnique 2025 Phone: +33 6 6058 9349 2026 EMail: T.Clausen@computer.org 2027 URI: http://www.ThomasClausen.org/ 2029 Alberto Camacho 2030 LIX, Ecole Polytechnique 2032 Phone: +34 636 309 835 2033 EMail: alberto@albertocamacho.com 2034 URI: http://www.albertocamacho.com/ 2036 Jiazi Yi 2037 LIX, Ecole Polytechnique 2039 Phone: +33 1 6933 4031 2040 EMail: jiazi@jiaziyi.com 2041 URI: http://www.jiaziyi.com/ 2043 Axel Colin de Verdiere 2044 LIX, Ecole Polytechnique 2046 Phone: +33 6 1264 7119 2047 EMail: axel@axelcdv.com 2048 URI: http://www.axelcdv.com/ 2049 Yuichi Igarashi 2050 Hitachi, Ltd., Yokohama Research Laboratory 2052 Phone: +81 45 860 3083 2053 EMail: yuichi.igarashi.hb@hitachi.com 2054 URI: http://www.hitachi.com/rd/yrl/index.html 2056 Hiroki Satoh 2057 Hitachi, Ltd., Yokohama Research Laboratory 2059 Phone: +81 44 959 0205 2060 EMail: hiroki.satoh.yj@hitachi.com 2061 URI: http://www.hitachi.com/rd/yrl/index.html 2063 Yoko Morii 2064 Hitachi, Ltd., Yokohama Research Laboratory 2066 Phone: +81 45 860 3083 2067 EMail: yoko.morii.cs@hitachi.com 2068 URI: http://www.hitachi.com/rd/yrl/index.html 2070 Ulrich Herberg 2071 Fujitsu Laboratories of America 2073 Phone: +1 408 530 4528 2074 EMail: ulrich@herberg.name 2075 URI: http://www.herberg.name/ 2077 Cedric Lavenu 2078 EDF R&D 2080 Phone: +33 1 4765 2729 2081 EMail: cedric-2.lavenu@edf.fr 2082 URI: http://www.edf.fr/