[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04

Network Working Group                                         T. Clausen
Internet-Draft                                                A. Camacho
Intended status: Informational                                     J. Yi
Expires: April 29, 2012                             A. Colin de Verdiere
                                                LIX, Ecole Polytechnique
                                                             Y. Igarashi
                                                               SATOH. H.
                                                                Y. Morii
                                        Hitachi, Ltd., Yokohama Research
                                                              Laboratory
                                                        October 27, 2011


          Experience with the LOADng routing protocol for LLNs
           draft-lavenu-lln-loadng-interoperability-report-01

Abstract

   This document reports experience with the LOADng routing protocol for
   LLNs which is specified in the draft-clausen-lln-loadng internet
   draft.  This report is providing information resulting from
   interoperability testing performed at Hitachi YRL facilities in
   Yokohama, Japan, from october 17th to october 19th 2011.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 29, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents



Clausen, et al.          Expires April 29, 2012                 [Page 1]


Internet-Draft           Experience with LOADng             October 2011


   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.
































Clausen, et al.          Expires April 29, 2012                 [Page 2]


Internet-Draft           Experience with LOADng             October 2011


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Implementations  . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Interoperability Testing . . . . . . . . . . . . . . . . . . .  6
     4.1.  Testbed configuration  . . . . . . . . . . . . . . . . . .  7
     4.2.  1-hop bidirectional route establishment  . . . . . . . . .  7
       4.2.1.  Topology . . . . . . . . . . . . . . . . . . . . . . .  7
       4.2.2.  Forward Route and Reverse Route initial
               installation . . . . . . . . . . . . . . . . . . . . .  7
       4.2.3.  Forward Route and Reverse Route updating . . . . . . .  8
       4.2.4.  Obtained results . . . . . . . . . . . . . . . . . . .  9
     4.3.  2-hop bidirectional route establishment  . . . . . . . . .  9
       4.3.1.  Topology . . . . . . . . . . . . . . . . . . . . . . .  9
       4.3.2.  Forward Route and Reverse Route initial
               installation . . . . . . . . . . . . . . . . . . . . . 10
       4.3.3.  Forward Route and Reverse Route updating . . . . . . . 11
       4.3.4.  Link breakage handling . . . . . . . . . . . . . . . . 12
       4.3.5.  Obtained results . . . . . . . . . . . . . . . . . . . 13
     4.4.  4-hop bidirectional route establishment  . . . . . . . . . 13
       4.4.1.  Topology . . . . . . . . . . . . . . . . . . . . . . . 13
       4.4.2.  Forward Route and Reverse Route initial
               installation . . . . . . . . . . . . . . . . . . . . . 14
       4.4.3.  Forward Route and Reverse Route updating . . . . . . . 15
       4.4.4.  Link breakage handling . . . . . . . . . . . . . . . . 17
       4.4.5.  Obtained results . . . . . . . . . . . . . . . . . . . 18
     4.5.  4-hop bidirectional route establishment  . . . . . . . . . 19
       4.5.1.  Topology . . . . . . . . . . . . . . . . . . . . . . . 19
       4.5.2.  Forward Route and Reverse Route initial
               installation . . . . . . . . . . . . . . . . . . . . . 19
       4.5.3.  Link breakage handling . . . . . . . . . . . . . . . . 21
       4.5.4.  Obtained results . . . . . . . . . . . . . . . . . . . 22
     4.6.  Establishment of the best bidirectional route  . . . . . . 23
       4.6.1.  Topology . . . . . . . . . . . . . . . . . . . . . . . 23
       4.6.2.  Description  . . . . . . . . . . . . . . . . . . . . . 23
       4.6.3.  Obtained results . . . . . . . . . . . . . . . . . . . 24
     4.7.  Blacklisting . . . . . . . . . . . . . . . . . . . . . . . 25
       4.7.1.  Topology . . . . . . . . . . . . . . . . . . . . . . . 25
       4.7.2.  Description  . . . . . . . . . . . . . . . . . . . . . 25
       4.7.3.  Obtained results . . . . . . . . . . . . . . . . . . . 28
     4.8.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . 29
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 30
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 30
   7.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 31
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 31



Clausen, et al.          Expires April 29, 2012                 [Page 3]


Internet-Draft           Experience with LOADng             October 2011


     9.2.  Informative References . . . . . . . . . . . . . . . . . . 31


















































Clausen, et al.          Expires April 29, 2012                 [Page 4]


Internet-Draft           Experience with LOADng             October 2011


1.  Introduction

   This document reports about the interoperability tests carried out at
   Hitachi YRL facilities in Yokohama, Japan, from october 17th to
   october 19th 2011 for different implementations of the LOADng (LLN
   On-demand Ad hoc Distance-vector - Next Generation) routing protocol.

   Interoperability tests between LOADng Routers implemented on the
   basis of the draft-clausen-lln-loadng internet draft have been run
   mainly for the following purposes :

   o  Show evidence that interoperable LOADng implementations do exist.

   o  Clarify and improve the overall quality of the LOADng
      specification.

   o  Demonstrate that the final LOADng internet draft can be considered
      as a standalone specification allowing the development of
      interoperable implementations of LOADng.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119].

   Additionally, this document uses the following terminology:

   LOADng Router -  A router which implements this routing protocol.

   Destination -  The address of a router or host, to which a route is
      sought discovered and maintained.

   Originator -  The address of a router, which seeks to discover and
      maintain a route to a Destination.

   Forward Route -  A route set up so as to send data packets from the
      Originator to the Destination.  The Forward Route is set up when a
      LOADng Router forwards Route Reply (RREP) messages.

   Reverse Route -  A route set up so as to send data packets from the
      Destination to the Originator.  The Reverse Route is set up when a
      LOADng Router forwards Route Request (RREQ) messages.  It is used
      for forwarding RREP messages, as well as for forwarding data
      packets.





Clausen, et al.          Expires April 29, 2012                 [Page 5]


Internet-Draft           Experience with LOADng             October 2011


   Route Cost -  The sum of the Link Costs for the links that a RREQ or
      RREP has crossed.

   Weak Link -  A link which is marginally usable, i.e., MAY be used if
      no other links are available, but SHOULD be avoided if at all
      possible - even if it entails an ultimately longer path.  As an
      example, a Weak Link might be defined as a link with a significant
      loss-rate.

   This document employs the same notational conventions as in
   [RFC5444].

3.  Implementations

   Several LOADng implementations are currently available.  This section
   is listing the implementations that have been used to perform the
   interoperability tests this document is reporting about (listed in
   alphabetical order) :

   Ecole Polytechnique : "LIX" -  This implementation was jointly
      developed by Axel Colin de Verdiere, Jiazi Yi, Ulrich Herberg and
      Thomas Clausen of Ecole Ploytechnique's networking team.  It
      consists of approximately 6000 lines of JAVA code running in a Mac
      OS environment.  It supports RREQ, RREP, RREP-ACK and RERR
      generation, processing, forwarding and transmission.

   Hitachi YRL 1 : "Hitachi 1" -  This implementation was fully
      developed by Yuichi Igarashi of Hitachi YRL.  It consists of 1589
      lines of C code running in the Hitachi proprietary micro OS
      environment embedded in a 16MHz H8 micro processor.  It supports
      RREQ, RREP, RREP-ACK and RERR generation, processing, forwarding
      and transmission.

   Hitachi YRL 2 : "Hitachi 2" -  This implementation was jointly
      developed by Nobukatsu Inomata of Hitachi ULSI Systems and Yoko
      Morii of Hitachi YRL.  It consists of 1987 lines of C++ code
      running in a Mac OS environment.  It supports RREQ, RREP, RREP-ACK
      generation, processing, forwarding and transmission, and RERR
      processing.

4.  Interoperability Testing

   This section is describing all the tests carried out between the
   implementations that are previously considered in this document.







Clausen, et al.          Expires April 29, 2012                 [Page 6]


Internet-Draft           Experience with LOADng             October 2011


4.1.  Testbed configuration

   The testbed was composed of up to five LOADng Routers put together
   according to the different topologies described hereunder.  The
   LOADng routing protocol were run over UDP, IPv4 and Ethernet.
   Wireshark packet sniffers, that have been modified to interpret
   LOADng control traffic, were used to monitor each single underlying
   link.

   For each test, the initiation of the communication resulting in the
   generation of the first LOADng control traffic message is always
   triggered manually.  In addition, RREP-ACK LOADng control messages
   were systematically expected from each LOADng Router upon reception
   of a RREP LOADng control message in order to allow the detection of
   unidirectional links.

4.2.  1-hop bidirectional route establishment

4.2.1.  Topology

   The testbed is composed of two LOADng Routers :

                         +-------+        +-------+
                         |   A   |________|   B   |
                         |       |        |       |
                         +-------+        +-------+

   Routers A and B are embedding a different implementation of LOADng.
   This test was performed between all previously considered
   implementations.

   This test suite consists in establishing a bidirectional route
   between LOADng Router A and LOADng Router B.

4.2.2.  Forward Route and Reverse Route initial installation

   For each implementation, this test aims to verifiy the initial
   installation of a bidirectional route (Forward Route and Reverse
   Route from A to B) within the LOADng Router routing tables (Routing
   Sets) through the effective generation and processing of LOADng
   control messages (RREQ, RREP, RREP-ACK).

   The expected message sequencing is as follows :

   o  LOADng Router A generates a RREQ message intended for LOADng
      Router B.





Clausen, et al.          Expires April 29, 2012                 [Page 7]


Internet-Draft           Experience with LOADng             October 2011


   o  Upon receiving the RREQ, LOADng Router B installs a new entry in
      its Routing Set towards LOADng Router A (Reverse Route from LOADng
      Router B to LOADng Router A) and sends an unicast RREP message
      intended for LOADng Router A. The <flags> field of the sent RREP
      message is set to "ACK-REQUIRED".

   o  Upon receiving the RREP, LOADng Router A installs a new entry in
      its Routing Set towards LOADng Router B (Forward Route from LOADng
      Router A to LOADng Router B) and sends an unicast RREP-ACK message
      to LOADng Router B.


                           A                   B
                           |     RREQ          |
                           -------------------->
                           |     RREP          |
                           <--------------------
                           |     RREP-ACK      |
                           -------------------->
                           |                   |

4.2.3.  Forward Route and Reverse Route updating

   For each implementation, this test aims to verifiy the refreshment of
   a bidirectional route (Forward Route and Reverse Route from A to B)
   already installed within the LOADng Router routing tables (Routing
   Sets) through the effective generation and processing of LOADng
   control messages (RREQ, RREP, RREP-ACK).

   The expected message sequencing is as follows :

   o  LOADng Router A generates a RREQ message intended for LOADng
      Router B.

   o  Upon receiving the RREQ, LOADng Router B updates the corresponding
      route (Reverse Route from LOADng Router B to LOADng Router A)
      already installed within its Routing Set and sends an unicast RREP
      message intended for LOADng Router A. The <flags> field of the
      sent RREP message is set to "ACK-REQUIRED".

   o  Upon receiving the RREP, LOADng Router A updates the corresponding
      route (Forward Route from LOADng Router A to LOADng Router B)
      already installed within its Routing Set and sends an unicast
      RREP-ACK message to LOADng Router B.







Clausen, et al.          Expires April 29, 2012                 [Page 8]


Internet-Draft           Experience with LOADng             October 2011


                           A                   B
                           |     RREQ          |
                           -------------------->
                           |     RREP          |
                           <--------------------
                           |     RREP-ACK      |
                           -------------------->
                           |                   |

4.2.4.  Obtained results

   The following table is summarizing the results obtained for the
   different combinations for which test 1 (Forward Route and Reverse
   Route initial installation) was performed :

               +-----------+------+-----------+-----------+
               |           |  LIX | Hitachi 1 | Hitachi 2 |
               +-----------+------+-----------+-----------+
               |    LIX    |  N/R |    Pass   |    Pass   |
               | Hitachi 1 | Pass |    N/R    |    Pass   |
               | Hitachi 2 | Pass |    Pass   |    N/R    |
               +-----------+------+-----------+-----------+

                                  Table 1

   The following table is summarizing the results obtained for the
   different combinations for which test 2 (Forward Route and Reverse
   Route updating) was performed :

               +-----------+------+-----------+-----------+
               |           |  LIX | Hitachi 1 | Hitachi 2 |
               +-----------+------+-----------+-----------+
               |    LIX    |  N/R |    Pass   |    Pass   |
               | Hitachi 1 | Pass |    N/R    |    Pass   |
               | Hitachi 2 | Pass |    Pass   |    N/R    |
               +-----------+------+-----------+-----------+

                                  Table 2

4.3.  2-hop bidirectional route establishment

4.3.1.  Topology

   The testbed is composed of three LOADng Routers.  Control traffic
   generated by either LOADng Router A towards LOADng Router C or LOADng
   Router C towards LOADng Router A has to be forwarded by LOADng Router
   B :




Clausen, et al.          Expires April 29, 2012                 [Page 9]


Internet-Draft           Experience with LOADng             October 2011


                +-------+        +-------+        +-------+
                |   A   |________|   B   |________|   C   |
                |       |        |       |        |       |
                +-------+        +-------+        +-------+

   This test suite consists in establishing a bidirectional route
   between LOADng Router A and LOADng Router C.

4.3.2.  Forward Route and Reverse Route initial installation

   This test aims to verify the initial installation of a bidirectional
   route (Forward Route and Reverse Route from A to C) within the LOADng
   Router routing tables (Routing Sets) through the effective forwarding
   of LOADng control traffic by LOADng Router B which is located between
   LOADng Router A and LOADng Router C. It is also verified that RREP-
   ACK messages are not forwarded by the LOADng Routers these messages
   are intended for.

   The expected message sequencing is as follows :

   o  LOADng Router A generates a RREQ message intended for LOADng
      Router C.

   o  Upon receiving the RREQ, LOADng Router B installs a new entry in
      its Routing Set towards LOADng Router A (Reverse Route from LOADng
      Router B to LOADng Router A) and forwards the received RREQ.

   o  Upon receiving the RREQ, LOADng Router C installs a new entry in
      its Routing Set towards LOADng Router A (Reverse Route from LOADng
      Router C to LOADng Router A) and a new entry towards LOADng Router
      B (Reverse route from LOADng Router C to LOADng Router B).  The
      reception of the RREQ also triggers the generation of an unicast
      RREP message intended for LOADng Router A. The <flags> field of
      the sent RREP message is set to "ACK-REQUIRED".

   o  Upon receiving the RREP, LOADng Router B installs a new entry in
      its Routing Set towards LOADng Router C (Forward Route from LOADng
      Router B to LOADng Router C), sends an unicast RREP-ACK message to
      LOADng Router C and forwards the RREP received previously.

   o  Upon receiving the RREP, LOADng Router A installs a new entry in
      its Routing Set towards LOADng Router B (Forward Route from LOADng
      Router A to LOADng Router B) and a new entry towards LOADng Router
      C (Forward Route from LOADng Router A to LOADng Router C).  The
      reception of the RREP also triggers an unicast RREP-ACK message
      intended for LOADng Router B.





Clausen, et al.          Expires April 29, 2012                [Page 10]


Internet-Draft           Experience with LOADng             October 2011


                 A                   B                   C
                 |     RREQ          |                   |
                 -------------------->                   |
                 |                   |     RREQ          |
                 |                   -------------------->
                 |                   |     RREP          |
                 |                   <--------------------
                 |                   |     RREP-ACK      |
                 |                   -------------------->
                 |     RREP          |                   |
                 <--------------------                   |
                 |     RREP-ACK      |                   |
                 -------------------->                   |
                 |                   |                   |

4.3.3.  Forward Route and Reverse Route updating

   This test aims to verify the refreshment of a bidirectional route
   (Forward Route and Reverse Route from A to C) already installed
   within the LOADng Router routing tables (Routing Sets) through the
   effective forwarding of LOADng control traffic by LOADng Router B
   which is located between LOADng Router A and LOADng Router C.

   The expected message sequencing is as follows :

   o  LOADng Router A generates a RREQ message intended for LOADng
      Router C.

   o  Upon receiving the RREQ, LOADng Router B updates the corresponding
      route (Reverse Route from LOADng Router B to LOADng Router A)
      already installed within its Routing Set and forwards the received
      RREQ.

   o  Upon receiving the RREQ, LOADng Router C updates the corresponding
      routes (Reverse Routes from LOADng Router C to LOADng Router A and
      from LOADng Router C to LOADng Router B).  The reception of the
      RREQ also triggers the generation of an unicast RREP message
      intended for LOADng Router A. The <flags> field of the sent RREP
      message is set to "ACK-REQUIRED".

   o  Upon receiving the RREP, LOADng Router B updates the corresponding
      route (Forward route from LOADng Router B to LOADng Router C),
      sends an unicast RREP-ACK message to LOADng Router C and forwards
      the RREP received previously.

   o  Upon receiving the RREP, LOADng Router A updates the corresponding
      routes (Forward routes from LOADng Router A to LOADng Router B and
      from LOADng Router A to LOADng Router C).  The reception of the



Clausen, et al.          Expires April 29, 2012                [Page 11]


Internet-Draft           Experience with LOADng             October 2011


      RREP also triggers an unicast RREP-ACK message intended for LOADng
      Router B.


                 A                   B                   C
                 |     RREQ          |                   |
                 -------------------->                   |
                 |                   |     RREQ          |
                 |                   -------------------->
                 |                   |     RREP          |
                 |                   <--------------------
                 |                   |     RREP-ACK      |
                 |                   -------------------->
                 |     RREP          |                   |
                 <--------------------                   |
                 |     RREP-ACK      |                   |
                 -------------------->                   |
                 |                   |                   |


4.3.4.  Link breakage handling

   This test aims to verify the proper generation and processing of a
   RERR message after an artificially created link breakage on an
   previously established bidirectional route.

   The expected message sequencing is as follows :

   o  A bidirectional route is already established between LOADng
      Routers A and C.

   o  At some time, link breakage is detected by LOADng Router B.
      Consequently, an unicast RERR message intended for LOADng Router A
      (here the assumption is made that the unsuccessful delivered data
      traffic would have been generated by LOADng Router A) is
      transmitted.

      Note : link breakage is provoked artificially and its detection by
      LOADng Router B is triggered manually (normally, this would be
      triggered by failure in sending data traffic intended for LOADng
      Router C).

   o  Upon receiving the RERR, LOADng Router A updates its Routing Set
      by invalidating the existing Forward Route from LOADng Router A to
      LOADng Router C.






Clausen, et al.          Expires April 29, 2012                [Page 12]


Internet-Draft           Experience with LOADng             October 2011


                 A                   B                   C
                 |                   |                   |
                 |                   | B-C link breakage |
                 |                   |                   X
                 |     RERR          |                   X
                 <--------------------                   X
                 |                   |                   X


4.3.5.  Obtained results

   The following table is summarizing the results obtained for the
   different combinations for which these test 1 (Forward Route and
   Reverse Route initial installation) and test 2 (Forward Route and
   Reverse Route updating) were performed :

          +-----------+-----------+-----------+--------+--------+
          |     A     |     B     |     C     | Test 1 | Test 2 |
          +-----------+-----------+-----------+--------+--------+
          | Hitahci 1 |    LIX    | Hitachi 2 |  Pass  |  Pass  |
          | Hitachi 2 |    LIX    | Hitachi 1 |  Pass  |  Pass  |
          |    LIX    | Hitachi 1 | Hitachi 2 |  Pass  |  Pass  |
          | Hitachi 2 | Hitachi 1 |    LIX    |  Pass  |  Pass  |
          |    LIX    | Hitachi 2 | Hitachi 1 |  Pass  |  Pass  |
          | Hitachi 1 | Hitachi 2 |    LIX    |  Pass  |  Pass  |
          +-----------+-----------+-----------+--------+--------+

                                  Table 3

   The following table is summarizing the results obtained for the
   different combinations for which these test 3 (Link breakage
   handling) was performed :

                 +-----------+-----------+-----+--------+
                 |     A     |     B     |  C  | Test 3 |
                 +-----------+-----------+-----+--------+
                 | Hitachi 1 |    LIX    | LIX |  Pass  |
                 |    LIX    | Hitachi 1 | LIX |  Pass  |
                 +-----------+-----------+-----+--------+

                                  Table 4

4.4.  4-hop bidirectional route establishment

4.4.1.  Topology

   The testbed is composed of four LOADng Routers.  Control traffic
   generated by either LOADng Router A towards LOADng Router D or LOADng



Clausen, et al.          Expires April 29, 2012                [Page 13]


Internet-Draft           Experience with LOADng             October 2011


   Router D towards LOADng Router A has to be forwarded by LOADng
   Routers B and C :

        +-------+        +-------+        +-------+        +-------+
        |   A   |________|   B   |________|   C   |________|   D   |
        |       |        |       |        |       |        |       |
        +-------+        +-------+        +-------+        +-------+

   This test suite consists in establishing a bidirectional route
   between LOADng Router A and LOADng Router D.

4.4.2.  Forward Route and Reverse Route initial installation

   This test aims to verify the initial installation of a bidirectional
   route (Forward Route and Reverse Route from A to D) within the LOADng
   Router routing tables (Routing Sets) through the effective forwarding
   of LOADng control traffic by LOADng Routers B and C, which are
   located between LOADng Router A and LOADng Router D. It is also
   verified that RREP-ACK messages are not forwarded by the LOADng
   Routers these messages are intended for.

   The expected message sequencing is as follows :

   o  LOADng Router A generates a RREQ message intended for LOADng
      Router D.

   o  Upon receiving the RREQ, LOADng Router B installs a new entry in
      its Routing Set towards LOADng Router A (Reverse Route from LOADng
      Router B to LOADng Router A) and forwards the received RREQ.

   o  Upon receiving the RREQ, LOADng Router C installs a new entry in
      its Routing Set towards LOADng Router A (Reverse Route from LOADng
      Router C to LOADng Router A) and a new entry towards LOADng Router
      B (Reverse route from LOADng Router C to LOADng Router B) and
      forwards the received RREQ.

   o  Upon receiving the RREQ, LOADng Router D installs a new entry in
      its Routing Set towards LOADng Router A (Reverse Route from LOADng
      Router D to LOADng Router A) and a new entry towards LOADng Router
      C (Reverse route from LOADng Router D to LOADng Router C).  The
      reception of the RREQ also triggers the generation of an unicast
      RREP message intended for LOADng Router A. The <flags> field of
      the sent RREP message is set to "ACK-REQUIRED".

   o  Upon receiving the RREP, LOADng Router C installs a new entry in
      its Routing Set towards LOADng Router D (Forward Route from LOADng
      Router C to LOADng Router D), sends an unicast RREP-ACK message to
      LOADng Router D and forwards the RREP received previously.



Clausen, et al.          Expires April 29, 2012                [Page 14]


Internet-Draft           Experience with LOADng             October 2011


   o  Upon receiving the RREP, LOADng Router B installs a new entry in
      its Routing Set towards LOADng Router D (Forward Route from LOADng
      Router B to LOADng Router D) and a new entry towards LOADng Router
      C (Forward Route from LOADng Router B to LOADng Router C).  An
      unicast RREP-ACK message is also sent to LOADng Router C and the
      RREP received previously is forwarded.

   o  Upon receiving the RREP, LOADng Router A installs a new entry in
      its Routing Set towards LOADng Router B (Forward Route from LOADng
      Router A to LOADng Router B) and a new entry towards LOADng Router
      D (Forward Route from LOADng Router A to LOADng Router D).  The
      reception of the RREP also triggers an unicast RREP-ACK message
      intended for LOADng Router B.


       A                   B                   C                   D
       |     RREQ          |                   |                   |
       -------------------->                   |                   |
       |                   |     RREQ          |                   |
       |                   -------------------->                   |
       |                   |                   |     RREQ          |
       |                   |                   -------------------->
       |                   |                   |     RREP          |
       |                   |                   <--------------------
       |                   |                   |     RREP-ACK      |
       |                   |                   -------------------->
       |                   |     RREP          |                   |
       |                   <--------------------                   |
       |                   |     RREP-ACK      |                   |
       |                   -------------------->                   |
       |     RREP          |                   |                   |
       <--------------------                   |                   |
       |     RREP-ACK      |                   |                   |
       -------------------->                   |                   |
       |                   |                   |                   |

4.4.3.  Forward Route and Reverse Route updating

   This test aims to verify the refreshment of a bidirectional route
   (Forward Route and Reverse Route from A to D) already installed
   within the LOADng Router routing tables (Routing Sets) through the
   effective forwarding of LOADng control traffic by LOADng Routers B
   and C which are located between LOADng Router A and LOADng Router D.

   The expected message sequencing is as follows :

   o  LOADng Router A generates a RREQ message intended for LOADng
      Router D.



Clausen, et al.          Expires April 29, 2012                [Page 15]


Internet-Draft           Experience with LOADng             October 2011


   o  Upon receiving the RREQ, LOADng Router B updates the corresponding
      route (Reverse Route from LOADng Router B to LOADng Router A)
      already installed within its Routing Set and forwards the received
      RREQ.

   o  Upon receiving the RREQ, LOADng Router C updates the corresponding
      routes (Reverse Routes from LOADng Router C to LOADng Router A and
      from LOADng Router C to LOADng Router B) already installed within
      its Routing Set and forwards the received RREQ.

   o  Upon receiving the RREQ, LOADng Router D updates the corresponding
      routes (Reverse Routes from LOADng Router D to LOADng Router A and
      from LOADng Router D to LOADng Router C) already installed within
      its Routing Set. The reception of the RREQ also triggers the
      generation of an unicast RREP message intended for LOADng Router
      A. The <flags> field of the sent RREP message is set to "ACK-
      REQUIRED".

   o  Upon receiving the RREP, LOADng Router C updates the corresponding
      route (Forward Route from LOADng Router C to LOADng Router D),
      sends an unicast RREP-ACK message to LOADng Router D and forwards
      the RREP received previously.

   o  Upon receiving the RREP, LOADng Router B updates the corresponding
      routes (Forward Route from LOADng Router B to LOADng Router D and
      from LOADng Router B to LOADng Router C).  An unicast RREP-ACK
      message is also sent to LOADng Router C and the RREP received
      previously is forwarded.

   o  Upon receiving the RREP, LOADng Router A updates the corresponding
      routes (Forward Route from LOADng Router A to LOADng Router B and
      from LOADng Router A to LOADng Router D).  The reception of the
      RREP also triggers an unicast RREP-ACK message intended for LOADng
      Router B.

















Clausen, et al.          Expires April 29, 2012                [Page 16]


Internet-Draft           Experience with LOADng             October 2011


       A                   B                   C                   D
       |     RREQ          |                   |                   |
       -------------------->                   |                   |
       |                   |     RREQ          |                   |
       |                   -------------------->                   |
       |                   |                   |     RREQ          |
       |                   |                   -------------------->
       |                   |                   |     RREP          |
       |                   |                   <--------------------
       |                   |                   |     RREP-ACK      |
       |                   |                   -------------------->
       |                   |     RREP          |                   |
       |                   <--------------------                   |
       |                   |     RREP-ACK      |                   |
       |                   -------------------->                   |
       |     RREP          |                   |                   |
       <--------------------                   |                   |
       |     RREP-ACK      |                   |                   |
       -------------------->                   |                   |
       |                   |                   |                   |

4.4.4.  Link breakage handling

   This test aims to verify the proper generation, processing and
   forwarding of a RERR message after an artificially created link
   breakage on an previously established bidirectional route.

   The expected message sequencing is as follows :

   o  A bidirectional route is already established between LOADng
      Routers A and D.

   o  At some time, link breakage is detected by LOADng Router C.
      Consequently, an unicast RERR message intended for LOADng Router A
      (here the assumption is made that the unsuccessful delivered data
      traffic would have been generated by LOADng Router A) is
      transmitted to LOADng Router B according to the Reverse Route from
      LOADng Router C to LOADng Router A computed previously.

      Note : link breakage is provoked artificially and its detection by
      LOADng Router C is triggered manually (normally, this would be
      triggered by failure in sending data traffic intended for LOADng
      Router D).

   o  Upon receiving the RERR, LOADng Router B updates its Routing Set
      by invalidating the existing Forward Route from LOADng Router B to
      LOADng Router D. Afterwards, the RERR message is forwarded
      according to the existing Reverse Route from LOADng Router B to



Clausen, et al.          Expires April 29, 2012                [Page 17]


Internet-Draft           Experience with LOADng             October 2011


      LOADng Router A.

   o  Upon receiving the RERR, LOADng Router A updates its Routing Set
      by invalidating the existing Forward Route from LOADng Router A to
      LOADng Router D.


       A                   B                   C                   D
       |                   |                   |                   |
       |                   |                   | C-D link breakage X
       |                   |                   |                   X
       |                   |     RERR          |                   X
       |                   <--------------------                   X
       |     RERR          |                   |                   X
       <--------------------                   |                   X
       |                   |                   |                   X

4.4.5.  Obtained results

   The following table is summarizing the results obtained for the
   different combinations for which these test 1 (Forward Route and
   Reverse Route initial installation) and test 2 (Forward Route and
   Reverse Route updating) were performed :

    +-----------+-----------+-----------+-----------+--------+--------+
    |     A     |     B     |     C     |     D     | Test 1 | Test 2 |
    +-----------+-----------+-----------+-----------+--------+--------+
    | Hitachi 1 |    LIX    |    LIX    | Hitachi 2 |  Pass  |  Pass  |
    | Hitachi 1 |    LIX    | Hitachi 2 |    LIX    |  Pass  |  Pass  |
    |    LIX    | Hitachi 2 | Hitachi 1 |    LIX    |  Pass  |  Pass  |
    +-----------+-----------+-----------+-----------+--------+--------+

                                  Table 5

   The following table is summarizing the results obtained for the
   different combinations for which these test 3 (Link breakage
   handling) was performed :

           +-----------+-----------+-----+-----------+--------+
           |     A     |     B     |  C  |     D     | Test 3 |
           +-----------+-----------+-----+-----------+--------+
           | Hitachi 1 |    LIX    | LIX | Hitachi 2 |  Pass  |
           |    LIX    | Hitachi 1 | LIX | Hitachi 2 |  Pass  |
           +-----------+-----------+-----+-----------+--------+

                                  Table 6





Clausen, et al.          Expires April 29, 2012                [Page 18]


Internet-Draft           Experience with LOADng             October 2011


4.5.  4-hop bidirectional route establishment

4.5.1.  Topology

   The testbed is composed of five LOADng Routers.  Control traffic
   generated by either LOADng Router A towards LOADng Router E or LOADng
   Router E towards LOADng Router A has to be forwarded by LOADng
   Routers B, C and D :

   +-------+      +-------+      +-------+      +-------+      +-------+
   |   A   |______|   B   |______|   C   |______|   D   |______|   E   |
   |       |      |       |      |       |      |       |      |       |
   +-------+      +-------+      +-------+      +-------+      +-------+

   This test suite consists in establishing a bidirectional route
   between LOADng Router A and LOADng Router E.

4.5.2.  Forward Route and Reverse Route initial installation

   This test aims to verify the initial installation of a bidirectional
   route (Forward Route and Reverse Route from A to E) within the LOADng
   Router routing tables (Routing Sets) through the effective forwarding
   of LOADng control traffic by LOADng Routers B, C and D, which are
   located between LOADng Router A and LOADng Router E. It is also
   verified that RREP-ACK messages are not forwarded by the LOADng
   Routers these messages are intended for.

   The expected message sequencing is as follows :

   o  LOADng Router A generates a RREQ message intended for LOADng
      Router E.

   o  Upon receiving the RREQ, LOADng Router B installs a new entry in
      its Routing Set towards LOADng Router A (Reverse Route from LOADng
      Router B to LOADng Router A) and forwards the received RREQ.

   o  Upon receiving the RREQ, LOADng Router C installs a new entry in
      its Routing Set towards LOADng Router A (Reverse Route from LOADng
      Router C to LOADng Router A) and a new entry towards LOADng Router
      B (Reverse route from LOADng Router C to LOADng Router B) and
      forwards the received RREQ.

   o  Upon receiving the RREQ, LOADng Router D installs a new entry in
      its Routing Set towards LOADng Router A (Reverse Route from LOADng
      Router D to LOADng Router A) and a new entry towards LOADng Router
      C (Reverse route from LOADng Router D to LOADng Router C) and
      forwards the received RREQ.




Clausen, et al.          Expires April 29, 2012                [Page 19]


Internet-Draft           Experience with LOADng             October 2011


   o  Upon receiving the RREQ, LOADng Router E installs a new entry in
      its Routing Set towards LOADng Router A (Reverse Route from LOADng
      Router E to LOADng Router A) and a new entry towards LOADng Router
      D (Reverse route from LOADng Router E to LOADng Router D).  The
      reception of the RREQ also triggers the generation of an unicast
      RREP message intended for LOADng Router A. The <flags> field of
      the sent RREP message is set to "ACK-REQUIRED".

   o  Upon receiving the RREP, LOADng Router D installs a new entry in
      its Routing Set towards LOADng Router E (Forward Route from LOADng
      Router D to LOADng Router E), sends an unicast RREP-ACK message to
      LOADng Router E and forwards the RREP received previously.

   o  Upon receiving the RREP, LOADng Router C installs a new entry in
      its Routing Set towards LOADng Router E (Forward Route from LOADng
      Router C to LOADng Router E) and a new entry towards LOADng Router
      D (Forward Route from LOADng Router C to LOADng Router D).  An
      unicast RREP-ACK message is also sent to LOADng Router D and the
      RREP received previously is forwarded.

   o  Upon receiving the RREP, LOADng Router B installs a new entry in
      its Routing Set towards LOADng Router E (Forward Route from LOADng
      Router B to LOADng Router E) and a new entry towards LOADng Router
      C (Forward Route from LOADng Router B to LOADng Router C).  An
      unicast RREP-ACK message is also sent to LOADng Router C and the
      RREP received previously is forwarded.

   o  Upon receiving the RREP, LOADng Router A installs a new entry in
      its Routing Set towards LOADng Router B (Forward Route from LOADng
      Router A to LOADng Router B) and a new entry towards LOADng Router
      E (Forward Route from LOADng Router A to LOADng Router E).  The
      reception of the RREP also triggers an unicast RREP-ACK message
      intended for LOADng Router B.


















Clausen, et al.          Expires April 29, 2012                [Page 20]


Internet-Draft           Experience with LOADng             October 2011


       A              B              C              D              E
       |     RREQ     |              |              |              |
       --------------->              |              |              |
       |              |     RREQ     |              |              |
       |              --------------->              |              |
       |              |              |     RREQ     |              |
       |              |              --------------->              |
       |              |              |              |     RREQ     |
       |              |              |              --------------->
       |              |              |              |     RREP     |
       |              |              |              <---------------
       |              |              |              |     RREP-ACK |
       |              |              |              --------------->
       |              |              |     RREP     |              |
       |              |              <---------------              |
       |              |              |     RREP-ACK |              |
       |              |              --------------->              |
       |              |     RREP     |              |              |
       |              <---------------              |              |
       |              |     RREP-ACK |              |              |
       |              --------------->              |              |
       |     RREP     |              |              |              |
       <---------------              |              |              |
       |     RREP-ACK |              |              |              |
       --------------->              |              |              |
       |              |              |              |              |

4.5.3.  Link breakage handling

   This test aims to verify the proper generation, processing and
   forwarding of a RERR message after an artificially created link
   breakage on an previously established bidirectional route.

   The expected message sequencing is as follows :

   o  A bidirectional route is already established between LOADng
      Routers A and E.

   o  At some time, link breakage is detected by LOADng Router D.
      Consequently, an unicast RERR message intended for LOADng Router A
      (here the assumption is made that the unsuccessful delivered data
      traffic would have been generated by LOADng Router A) is
      transmitted to LOADng Router C according to the Reverse Route from
      LOADng Router C to LOADng Router A computed previously.

      Note : link breakage is provoked artificially and its detection by
      LOADng Router D is triggered manually (normally, this would be
      triggered by failure in sending data traffic intended for LOADng



Clausen, et al.          Expires April 29, 2012                [Page 21]


Internet-Draft           Experience with LOADng             October 2011


      Router E).

   o  Upon receiving the RERR, LOADng Router C updates its Routing Set
      by invalidating the existing Forward Route from LOADng Router C to
      LOADng Router E. Afterwards, the RERR message is forwarded
      according to the existing Reverse Route from LOADng Router C to
      LOADng Router A.

   o  Upon receiving the RERR, LOADng Router B updates its Routing Set
      by invalidating the existing Forward Route from LOADng Router B to
      LOADng Router E. Afterwards, the RERR message is forwarded
      according to the existing Reverse Route from LOADng Router B to
      LOADng Router A.

   o  Upon receiving the RERR, LOADng Router A updates its Routing Set
      by invalidating the existing Forward Route from LOADng Router A to
      LOADng Router E.


       A              B              C              D              E
       |              |              |              |              |
       |              |              |              D-E link breakage
       |              |              |              |              X
       |              |              |     RERR     |              X
       |              |              <---------------              X
       |              |     RERR     |              |              X
       |              <---------------              |              X
       |     RERR     |              |              |              X
       <---------------              |              |              X
       |              |              |              |              X

4.5.4.  Obtained results

   The following table is summarizing the results obtained for the
   different combinations for which test 1 (Forward Route and Reverse
   Route initial installation) and test 2 (Link breakage handling) were
   performed :

    +-----------+-----------+-----+-----------+-----+--------+--------+
    |     A     |     B     |  C  |     D     |  E  | Test 1 | Test 2 |
    +-----------+-----------+-----+-----------+-----+--------+--------+
    | Hitachi 2 | Hitachi 1 | LIX | Hitachi 1 | LIX |  Pass  |  Pass  |
    +-----------+-----------+-----+-----------+-----+--------+--------+

                                  Table 7






Clausen, et al.          Expires April 29, 2012                [Page 22]


Internet-Draft           Experience with LOADng             October 2011


4.6.  Establishment of the best bidirectional route

4.6.1.  Topology

   The testbed is composed of three LOADng Routers.  Control traffic
   generated by either LOADng Router A towards LOADng Router C or LOADng
   Router C towards LOADng Router A can be forwarded by LOADng Router B
   or transmitted via the direct link between LOADng Routers A and C :

                +-------+        +-------+        +-------+
                |   A   |________|   B   |________|   C   |
                |       |        |       |        |       |
                +-------+        +-------+        +-------+
                    |_________________________________|

   This test consists in establishing a bidirectional route between
   LOADng Router A and LOADng Router C.

4.6.2.  Description

   This test aims to verify the processing of multiple RREQs when
   installing a bidirectional route (Forward Route and Reverse Route
   from A to C) within the LOADng Router routing tables (Routing Sets).

   The expected message sequencing is as follows :

   o  LOADng Router A generates a RREQ message intended for LOADng
      Router C. According to RREQ transmission rules, the generated RREQ
      message is transmitted to all neighbor LOADng Routers.

   o  Upon receiving the RREQ, LOADng Router B installs a new entry in
      its Routing Set towards LOADng Router A (Reverse Route from LOADng
      Router B to LOADng Router A) and forwards the received RREQ.

      At the same time, upon receiving the same RREQ via its direct link
      with LOADng Router A, LOADng Router C installs a new entry in its
      Routing Set (Reverse Route from LOADng Router C to LOADng Router
      A).  The reception of the RREQ also triggers the generation of an
      unicast RREP message intended for LOADng Router A. The <flags>
      field of the sent RREP message is set to "ACK-REQUIRED".

   o  Upon receiving the same RREQ via LOADng Router B, LOADng Router C
      compares the Route Cost and Weak Link information carried by the
      RREQ with the already existing entry within its Routing Set
      (Reverse Route from LOADng Router C to LOADng Router A) according
      to the comparison operator specified by the metric used (the "hop
      count while avoiding Weak Links" metric was used).  No Weak Links
      are emulated.  Thus, the best route is chosen considering the



Clausen, et al.          Expires April 29, 2012                [Page 23]


Internet-Draft           Experience with LOADng             October 2011


      Route Cost information only :

    Already existing entry :

            <R_dist> = (Weak Link, Route Cost) = (0, 1)

    Tuple corresponding to the newly received RREQ :

            <R_dist> = (Weak Link, Route Cost) = (0, 2)

    According to the comparison operator specified by the metric used :

            (0, 1) < (0,2)

      Consequently, the newly received RREQ message is discarded without
      affecting the Routing Set or triggering the generation of any RREP
      message.

   o  Upon receiving the RREP via its direct link with LOADng Router C,
      LOADng Router A installs a new entry in its Routing Set (Forward
      Route from LOADng Router A to LOADng Router C).  The reception of
      the RREP also triggers an unicast RREP-ACK message intended for
      LOADng Router C.


                 A                   B                   C
                 |     RREQ          |                   |
                 -------------------->     RREQ          |
                 ---------------------------------------->
                 |                   |     RREQ          |
                 |                   -------------------->
                 |                   |     RREP          |
                 <----------------------------------------
                 |                   |     RREP-ACK      |
                 ---------------------------------------->
                 |                   |                   |

   Note : the RREQ forwarded by LOADng Router B towards C is not
   necessarily received before LOADng Router C generates the RREP
   message intended for LOADng Router A. Indeed, the order in which
   those messages are transmitted is dependent on the transmission
   delays of each single link between LOADng Routers A, B and C.

4.6.3.  Obtained results

   The following table is summarizing the results obtained for the
   different combinations for which this test was performed :




Clausen, et al.          Expires April 29, 2012                [Page 24]


Internet-Draft           Experience with LOADng             October 2011


              +-----------+-----------+-----------+--------+
              |     A     |     B     |     C     | Result |
              +-----------+-----------+-----------+--------+
              |    LIX    | Hitachi 1 | Hitachi 2 |  Pass  |
              |    LIX    | Hitachi 2 | Hitachi 1 |  Pass  |
              | Hitachi 2 | Hitachi 1 |    LIX    |  Pass  |
              | Hitachi 1 |    LIX    | Hitachi 2 |  Pass  |
              +-----------+-----------+-----------+--------+

                                  Table 8

4.7.  Blacklisting

4.7.1.  Topology

   The testbed is composed of four LOADng Routers with a unidirectional
   link between LOADng Routers A and D (direct communication from D
   towards A is impossible).

                        +-------+         +-------+
                        |   A   |_________|   B   |
                        |       |         |       |
                        +-------+         +-------+
                            |                 |
                            V                 |
                        +-------+         +-------+
                        |   D   |_________|   C   |
                        |       |         |       |
                        +-------+         +-------+

   This test consists in establishing a bidirectional route between
   LOADng Router A and LOADng Router D.

4.7.2.  Description

   This test aims to verify the effectiveness of avoiding unidirectional
   links using blacklisting.

   First attempt to establish a bidirectional route between LOADng
   Routers A and D :

   o  LOADng Router A generates a RREQ message (<seq-num> = 0,
      <originator> = A) intended for LOADng Router D.

   o  Upon receiving the RREQ, LOADng Router B installs a new entry in
      its Routing Set towards LOADng Router A (Reverse Route from LOADng
      Router B to LOADng Router A) and forwards the received RREQ.




Clausen, et al.          Expires April 29, 2012                [Page 25]


Internet-Draft           Experience with LOADng             October 2011


      At the same time, upon receiving the same RREQ via its direct
      (unidirectional) link with LOADng Router A, LOADng Router D
      installs a new entry in its Routing Set towards LOADng Router A
      (Reverse Route from LOADng Router D to LOADng Router A).  The
      reception of the RREQ also triggers the generation of an unicast
      RREP message intended for LOADng Router A. The <flags> field of
      the sent RREP message is set to "ACK-REQUIRED".

   o  Upon receiving the RREQ, LOADng Router C installs a new entry in
      its Routing Set towards LOADng Router A (Reverse Route from LOADng
      Router C to LOADng Router A) and a new entry towards LOADng Router
      B (Reverse route from LOADng Router C to LOADng Router B) and
      forwards the received RREQ.

   o  Upon receiving the same RREQ (<seq-num> = 0, <originator> = A)
      again via LOADng Router C, LOADng Router D compares the Route Cost
      and Weak Link information carried by the RREQ with the already
      existing entry within its Routing Set (Reverse Route from LOADng
      Router D to LOADng Router A) according to the comparison operator
      specified by the metric used (the "hop count while avoiding Weak
      Links" metric was used).  No Weak Links are emulated.  Thus, the
      best route is chosen considering the Route Cost information only :

    Already existing entry :

            <R_dist> = (Weak Link, Route Cost) = (0, 1)

    Tuple corresponding to the newly received RREQ :

            <R_dist> = (Weak Link, Route Cost) = (0, 2)

    According to the comparison operator specified by the metric used :

            (0, 1) < (0,2)

      Consequently, the newly received RREQ message is discarded without
      affecting the Routing Set or triggering the generation of any RREP
      message.

   o  Due to the unidirectional nature of the existing link between
      LOADng Routers A and D, the RREP message previously sent by LOADng
      Router D intended for LOADng Router A did not reach its
      destination.  After an elapsed time equaling ack_timeout, LOADng
      Router D is not expecting an RREP-ACK message anymore.  This
      results in recording LOADng Router A neighbor in LOADng Router D's
      Blacklist.

   Second attempt to establish a bidirectional route between LOADng



Clausen, et al.          Expires April 29, 2012                [Page 26]


Internet-Draft           Experience with LOADng             October 2011


   Routers A and D :

   o  LOADng Router A generates a RREQ message (<seq-num> = 1,
      <originator> = A) intended for LOADng Router D.

   o  Upon receiving the RREQ, LOADng Router B installs a new entry in
      its Routing Set towards LOADng Router A (Reverse Route from LOADng
      Router B to LOADng Router A) and forwards the received RREQ.

      At the same time, upon receiving the same RREQ via its blacklisted
      neighbor LOADng Router A, LOADng Router D discards the message.

   o  Upon receiving the RREQ, LOADng Router C updates the corresponding
      routes (Reverse Routes from LOADng Router C to LOADng Router A and
      from LOADng Router C to LOADng Router B) and forwards the received
      RREQ.

   o  Upon receiving the RREQ, LOADng Router D updates the already
      installed route (Reverse Route from LOADng Router C to LOADng
      Router A) and installs a new entry towards LOADng Router C
      (Reverse route from LOADng Router D to LOADng Router C).  The
      reception of the RREQ also triggers the generation of an unicast
      RREP message intended for LOADng Router A. The <flags> field of
      the sent RREP message is set to "ACK-REQUIRED".

   o  Upon receiving the RREP, LOADng Router C installs a new entry in
      its Routing Set towards LOADng Router D (Forward Route from LOADng
      Router C to LOADng Router D), sends an unicast RREP-ACK message to
      LOADng Router D and forwards the RREP received previously.

   o  Upon receiving the RREP, LOADng Router B installs a new entry in
      its Routing Set towards LOADng Router D (Forward Route from LOADng
      Router B to LOADng Router D) and a new entry towards LOADng Router
      C (Forward Route from LOADng Router B to LOADng Router C).  An
      unicast RREP-ACK message is also sent to LOADng Router C and the
      RREP received previously is forwarded.

   o  Upon receiving the RREP, LOADng Router A installs a new entry in
      its Routing Set towards LOADng Router D (Forward Route from LOADng
      Router A to LOADng Router D) and a new entry towards LOADng Router
      B (Forward Route from LOADng Router A to LOADng Router B).  The
      reception of the RREP also triggers an unicast RREP-ACK message
      intended for LOADng Router B.








Clausen, et al.          Expires April 29, 2012                [Page 27]


Internet-Draft           Experience with LOADng             October 2011


     A                 B                 C                 D
     |                 |                 |                 |
     First attempt /////////////////////////////////////////
     |     RREQ        |                 |                 |
     ------------------>     RREQ        |                 |
     ------------------------------------------------------>
     |                 |     RREP        |                 |
     |XXXXX <-----------------------------------------------
     |                 |     RREQ        |                 |
     |                 ------------------>                 |
     |                 |                 |     RREQ        |
     |                 |                 ----------------->X RREQ
     |                 |                 |                 | Discarded
     Second attempt ////////////////////////////////////////
     |     RREQ        |                 |                 |
     ------------------>     RREQ        |                 |
     ----------------------------------------------------->X RREQ
     |                 |     RREQ        |                 | Discarded
     |                 ------------------>                 |
     |                 |                 |     RREQ        |
     |                 |                 ------------------>
     |                 |                 |     RREP        |
     |                 |                 <------------------
     |                 |                 |     RREP-ACK    |
     |                 |                 ------------------>
     |                 |     RREP        |                 |
     |                 <------------------                 |
     |                 |     RREP-ACK    |                 |
     |                 ------------------>                 |
     |     RREP        |                 |                 |
     <------------------                 |                 |
     |     RREP-ACK    |                 |                 |
     ------------------>                 |                 |

4.7.3.  Obtained results

   The following table is summarizing the results obtained for the
   different combinations for which this test was performed :

           +-----------+-----+-----------+-----------+--------+
           |     A     |  B  |     C     |     D     | Result |
           +-----------+-----+-----------+-----------+--------+
           | Hitachi 2 | LIX | Hitachi 1 |    LIX    |  Pass  |
           |    LIX    | LIX | Hitachi 1 | Hitachi 2 |  Pass  |
           | Hitachi 2 | LIX |    LIX    | Hitachi 1 |  Pass  |
           +-----------+-----+-----------+-----------+--------+

                                  Table 9



Clausen, et al.          Expires April 29, 2012                [Page 28]


Internet-Draft           Experience with LOADng             October 2011


4.8.  Conclusions

   The different test scenarios carried that were carried out for
   different interoperable and independent implementations allowed to
   completely cover the LOADng specification by checking each technical
   feature one by one.  In addition, the completion of this process
   permitted the improvement of the overall quality and accuracy of the
   LOADng specification (draft-clausen-lln-loadng).

       +------+----------------+-----------------------+-----------+
       |      |                |                       | Scenario  |
       |Chap. |      Item      |   Technical feature   +-----------+
       |      |                |                       |1|2|3|4|5|6|
       +------+----------------+------------+----------+-+-+-+-+-+-+
       |6.1   |                |            |Originator|X|X|X| |X|X|
       +------+ Information    |Routing Set +----------+-+-+-+-+-+-+
       |6.1   | Base           |            |Previous  | |X|X|X| |X|
       +------+                +------------+----------+-+-+-+-+-+-+
       |6.2   |                |Blacklist Neighbor set | | | | | |X|
       +------+----------------+-----------------------+-+-+-+-+-+-+
       |8.1   |                |TLV                    |X|X|X|X|X|X|
       +------+                +-----------------------+-+-+-+-+-+-+
       |8.2.1 | Packet         |Route Request Message  |X|X|X|X|X|X|
       +------+ Format         +-----------------------+-+-+-+-+-+-+
       |8.2.1 |                |Route Reply Message    |X|X|X|X|X|X|
       +------+                +-----------------------+-+-+-+-+-+-+
       |8.2.2 |                |Route Reply Ack Message|X|X|X|X|X|X|
       +------+                +-----------------------+-+-+-+-+-+-+
       |8.2.3 |                |Route Error Message    | |X|X|X| | |
       +------+----------------+-----------------------+-+-+-+-+-+-+
       |10.1  | Unidirectional |Blacklist              | | | | | |X|
       |      | link handling  |                       | | | | | | |
       +------+----------------+-----------------------+-+-+-+-+-+-+
       |11.1  |                |Invalid RREQ, RREP     |X|X|X|X|X|X|
       +------+ Common rules   +-----------------------+-+-+-+-+-+-+
       |11.2  | for RREQ, RREP |RREQ, RREP Processing  |X|X|X|X|X|X|
       +------+ Message        +-----------------------+-+-+-+-+-+-+
       |11.3  |                |Updating RREQ, RREP    |X|X|X|X|X|X|
       +------+----------------+-----------------------+-+-+-+-+-+-+
       |12.1  |                |RREQ Generation        |X|X|X|X|X|X|
       +------+                +-----------------------+-+-+-+-+-+-+
       |12.2  | Route          |RREQ Processing        |X|X|X|X|X|X|
       +------+ Requests       +-----------------------+-+-+-+-+-+-+
       |12.3  | (RREQs)        |RREQ Forwarding        | |X|X|X|X|X|
       +------+                +-----------------------+-+-+-+-+-+-+
       |12.4  |                |RREQ Transmission      |X|X|X|X|X|X|
       +------+----------------+-----------------------+-+-+-+-+-+-+
       |13.1  |                |RREP Generation        |X|X|X|X|X|X|



Clausen, et al.          Expires April 29, 2012                [Page 29]


Internet-Draft           Experience with LOADng             October 2011


       +------+                +-----------------------+-+-+-+-+-+-+
       |13.2  | Route          |RREP Processing        |X|X|X|X|X|X|
       +------+ Replies        +-----------------------+-+-+-+-+-+-+
       |13.3  | (RREPs)        |RREP Forwarding        | |X|X|X|X|X|
       +------+                +-----------------------+-+-+-+-+-+-+
       |13.4  |                |RREP Transmission      |X|X|X|X|X|X|
       +------+----------------+-----------------------+-+-+-+-+-+-+
       |14.1  |                |RERR Generation        | |X|X|X| | |
       +------+                +-----------------------+-+-+-+-+-+-+
       |14.2  | Route          |RERR Processing        | |X|X|X| | |
       +------+ Errors         +-----------------------+-+-+-+-+-+-+
       |14.3  | (RERRs)        |RERR Forwarding        | | |X|X| | |
       +------+                +-----------------------+-+-+-+-+-+-+
       |14.4  |                |RERR Transmission      | |X|X|X| | |
       +------+----------------+-----------------------+-+-+-+-+-+-+
       |15.1  |                |RREP-ACK Generation    |X|X|X|X|X|X|
       +------+                +-----------------------+-+-+-+-+-+-+
       |15.2  | Route          |RREQ-ACK Processing    |X|X|X|X|X|X|
       +------+ Reply          +-----------------------+-+-+-+-+-+-+
       |15.3  | Acknowledgement|RREQ-ACK Forwarding    |X|X|X|X|X|X|
       +------+ (RREP-ACKs)    +-----------------------+-+-+-+-+-+-+
       |15.4  |                |RREQ-ACK Transmission  |X|X|X|X|X|X|
       +------+----------------+-----------------------+-+-+-+-+-+-+
       |16    | Metrics        |Hop Count While        |X|X|X|X|X|X|
       |      |                |Avoiding Weak Links    | | | | | | |
       +------+----------------+-----------------------+-+-+-+-+-+-+

   Scenario 1: 1-hop bidirectional route establishment

   Scenario 2: 2-hop bidirectional route establishment

   Scenario 3: 3-hop bidirectional route establishment

   Scenario 4: 4-hop bidirectional route establishment

   Scenario 5: Establishment of the best bidirectional route

   Scenario 6: Blacklisting

5.  Security Considerations

   This document does currently not specify any security considerations.

6.  IANA Considerations

   This document has no actions for IANA.





Clausen, et al.          Expires April 29, 2012                [Page 30]


Internet-Draft           Experience with LOADng             October 2011


7.  Contributors

   This specification is the result of the joint efforts of the
   following contributors -- listed alphabetically.

   o  Thomas Heide Clausen, LIX, France, <T.Clausen@computer.org>

   o  Alberto Camacho, LIX, France, <alberto@albertocamacho.com>

   o  Axel Colin de Verdiere, LIX, France, <axel@axelcdv.com>

   o  Yuichi Igarashi, HITACHI YRL, Japan,
      <yuichi.igarashi.hb@hitachi.com>

   o  Nobukatsu Inomata, HITACHI ULSI Systems, Japan,
      <nobukatsu.inomata.rf@hitachi.com>

   o  Yoko Morii, HITACHI YRL, Japan, <yoko.morii.cs@hitachi.com>

   o  SATOH, Hiroki, HITACHI YRL, Japan, <hiroki.satoh.yj@hitachi.com>

   o  Jiazi Yi, LIX, France, <jiazi@jiaziyi.com>

8.  Acknowledgments

   TBD

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, BCP 14, March 1997.

9.2.  Informative References

   [RFC5444]  Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
              "Generalized MANET Packet/Message Format", RFC 5444,
              February 2009.












Clausen, et al.          Expires April 29, 2012                [Page 31]


Internet-Draft           Experience with LOADng             October 2011


Authors' Addresses

   Thomas Heide Clausen
   LIX, Ecole Polytechnique

   Phone: +33 6 6058 9349
   EMail: T.Clausen@computer.org
   URI:   http://www.ThomasClausen.org/


   Alberto Camacho
   LIX, Ecole Polytechnique

   Phone: +34 636 309 835
   EMail: alberto@albertocamacho.com
   URI:   http://www.albertocamacho.com/


   Jiazi Yi
   LIX, Ecole Polytechnique

   Phone: +33 1 6933 4031
   EMail: jiazi@jiaziyi.com
   URI:   http://www.jiaziyi.com/


   Axel Colin de Verdiere
   LIX, Ecole Polytechnique

   Phone: +33 6 1264 7119
   EMail: axel@axelcdv.com
   URI:   http://www.axelcdv.com/


   Yuichi Igarashi
   Hitachi, Ltd., Yokohama Research Laboratory

   Phone: +81 45 860 3083
   EMail: yuichi.igarashi.hb@hitachi.com
   URI:   http://www.hitachi.com/rd/yrl/index.html











Clausen, et al.          Expires April 29, 2012                [Page 32]


Internet-Draft           Experience with LOADng             October 2011


   SATOH, Hiroki
   Hitachi, Ltd., Yokohama Research Laboratory

   Phone: +81 44 959 0205
   EMail: hiroki.satoh.yj@hitachi.com
   URI:   http://www.hitachi.com/rd/yrl/index.html


   Yoko Morii
   Hitachi, Ltd., Yokohama Research Laboratory

   Phone: +81 45 860 3083
   EMail: yoko.morii.cs@hitachi.com
   URI:   http://www.hitachi.com/rd/yrl/index.html





































Clausen, et al.          Expires April 29, 2012                [Page 33]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/