idnits 2.17.1 

draft-clausen-lln-loadng-08.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

  -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(i)
     Publication Limitation clause.


  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 :
  ----------------------------------------------------------------------------

  ** The document seems to lack an IANA Considerations section.  (See Section
     2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
     when there are no actions for IANA.)


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the IETF Trust and authors Copyright Line does not
     match the current year

  == Line 658 has weird spacing: '...-length  is an...'

  == Line 663 has weird spacing: '...seq-num  is an...'

  == Line 667 has weird spacing: '...ic-type  is an...'

  == Line 670 has weird spacing: '...-metric  is a ...'

  == Line 675 has weird spacing: '...p-count  is an...'

  == (30 more instances...)

  == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
     or 'RECOMMENDED' is not an accepted usage according to RFC 2119.  Please
     use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
     mean).
     
     Found 'MUST not' in this paragraph:
     
    
     +-------------------+-------------------+---------------------------+ |  
      RREQ Element   |  RFC5444-Element  | Considerations            |
     +-------------------+-------------------+---------------------------+ | 
     RREQ.addr-length | <msg-addr-length> | Supports addresses from   | |     
                  |                   | 1-16 octets               | |   
     RREQ.seq-num   |   <msg-seq-num>   | 16 bits, hence MAXVALUE   | |       
                |                   | (Section 8) is 65535.     | |           
            |                   | MUST be included          | | 
     RREQ.metric-type |   METRIC Message  | Encoded by way of the     | |     
                  |        TLV        | Type-Extension of a       | |         
              |                   | Message-Type-specific     | |             
          |                   | Message TLV of type       | |                 
      |                   | METRIC, defined in        | |                   | 
                      | Table 8.  A LOADng Router | |                   |     
                  | generating an RREQ (as    | |                   |         
              | specified in              | |                   |             
          | Section 12.1) when using  | |                   |                 
      | the HOP_COUNT metric,     | |                   |                   |
     MUST NOT add the METRIC   | |                   |                   |
     Message TLV to the RREQ   | |                   |                   | (in
     order to reduce       | |                   |                   |
     overhead, as the hop      | |                   |                   |
     count value is already    | |                   |                   |
     encoded in                | |                   |                   |
     RREQ.hop-count).  LOADng  | |                   |                   |
     Routers receiving an RREQ | |                   |                   |
     without METRIC Message    | |                   |                   | TLV
     assume that           | |                   |                   |
     RREQ.metric-type is       | |                   |                   |
     HOP_COUNT, and MUST not   | |                   |                   | add
     the METRIC Message    | |                   |                   | TLV
     when forwarding the   | |                   |                   |
     message.  Otherwise,      | |                   |                   |
     exactly one METRIC TLV    | |                   |                   |
     MUST be included in each  | |                   |                   |
     RREQ message.             | | RREQ.route-metric |   METRIC Message  |
     Encoded as the value      | |                   |     TLV value     |
     field of the METRIC TLV.  | |                   |                   |
     (LOADng Routers           | |                   |                   |
     generating RREQs when     | |                   |                   |
     using the HOP_COUNT       | |                   |                   |
     metric do not need need   | |                   |                   | to
     add the METRIC Message | |                   |                   | TLV,
     as specified above   | |                   |                   | for the
     RREQ.metric-type  | |                   |                   | field.)    
                   | |   RREQ.hop-limit  |  <msg-hop-limit>  | 8 bits.  MUST
     be included | |                   |                   | in an RREQ
     message        | |   RREQ.hop-count  |  <msg-hop-count>  | 8 bits, hence 
                | |                   |                   | MAX_HOP_COUNT is
     255.     | |                   |                   | MUST be included in
     an    | |                   |                   | RREQ message.          
       | |  RREQ.originator  |  <msg-orig-addr>  | MUST be included in an    |
     |                   |                   | RREQ message.             | | 
     RREQ.destination |     Address in    | Encoded by way of an      | |     
                  |   Address-Block   | address in an address     | |         
              |       w/TLV       | block, with which a       | |             
          |                   | Message-Type-specific     | |                 
      |                   | Address Block TLV of type | |                   | 
                      | ADDR-TYPE and with        | |                   |     
                  | Type-Extension            | |                   |         
              | DESTINATION is            | |                   |             
          | associated, defined in    | |                   |                 
      | Table 9.  An RREQ MUST    | |                   |                   |
     contain exactly one       | |                   |                   |
     address with a TLV of     | |                   |                   |
     type ADDR-TYPE and with   | |                   |                   |
     Type-Extension            | |                   |                   |
     DESTINATION associated.   |
     +-------------------+-------------------+---------------------------+

  == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
     or 'RECOMMENDED' is not an accepted usage according to RFC 2119.  Please
     use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
     mean).
     
     Found 'MUST not' in this paragraph:
     
    
     +-------------------+-------------------+---------------------------+ |  
      RREP Element   |  RFC5444-Element  | Considerations            |
     +-------------------+-------------------+---------------------------+ | 
     RREP.addr-length | <msg-addr-length> | Supports addresses from   | |     
                  |                   | 1-16 octets               | |   
     RREP.seq-num   |   <msg-seq-num>   | 16 bits, hence MAXVALUE   | |       
                |                   | (Section 8) is 65535.     | |           
            |                   | MUST be included          | | 
     RREP.metric-type |   METRIC Message  | Encoded by way of the     | |     
                  |        TLV        | Type-Extension of a       | |         
              |                   | Message-Type-specific     | |             
          |                   | Message TLV of type       | |                 
      |                   | METRIC, defined in        | |                   | 
                      | Table 12.  A LOADng       | |                   |     
                  | Router generating an RREP | |                   |         
              | (as specified in          | |                   |             
          | Section 13.1) when using  | |                   |                 
      | the HOP_COUNT metric,     | |                   |                   |
     MUST NOT add the METRIC   | |                   |                   |
     Message TLV to the RREP   | |                   |                   | (in
     order to reduce       | |                   |                   |
     overhead, as the hop      | |                   |                   |
     count value is already    | |                   |                   |
     encoded in                | |                   |                   |
     RREP.hop-count).  LOADng  | |                   |                   |
     Routers receiving an RREP | |                   |                   |
     without METRIC Message    | |                   |                   | TLV
     assume that           | |                   |                   |
     RREP.metric-type is       | |                   |                   |
     HOP_COUNT, and MUST not   | |                   |                   | add
     the METRIC Message    | |                   |                   | TLV
     when forwarding the   | |                   |                   |
     message.  Otherwise,      | |                   |                   |
     exactly one METRIC TLV    | |                   |                   |
     MUST be included in each  | |                   |                   |
     RREP message.             | | RREP.route-metric |   METRIC Message  |
     Encoded as the value      | |                   |     TLV value     |
     field of the METRIC TLV.  | |                   |                   |
     (LOADng Routers           | |                   |                   |
     generating RREPs when     | |                   |                   |
     using the HOP_COUNT       | |                   |                   |
     metric do not need need   | |                   |                   | to
     add the METRIC Message | |                   |                   | TLV,
     as specified above   | |                   |                   | for the
     RREP.metric-type  | |                   |                   | field.)    
                   | |  RREP.ackrequired | FLAGS Message TLV | Encoded by way
     of a       | |                   |                   |
     Message-Type-specific     | |                   |                   |
     Message TLV of type       | |                   |                   |
     FLAGS, defined in         | |                   |                   |
     Table 13.  A TLV of type  | |                   |                   |
     FLAGS MUST always be      | |                   |                   |
     included in an RREP       | |                   |                   |
     message.                  | |   RREP.hop-limit  |  <msg-hop-limit>  | 8
     bits.  MUST be included | |                   |                   | in an
     RREQ message        | |   RREP.hop-count  |  <msg-hop-count>  | 8 bits,
     hence             | |                   |                   |
     MAX_HOP_COUNT is 255.     | |                   |                   |
     MUST be included in an    | |                   |                   |
     RREP message.             | |  RREP.originator  |  <msg-orig-addr>  |
     MUST be included in an    | |                   |                   |
     RREP message.             | |  RREP.destination |     Address in    |
     Encoded by way of an      | |                   |   Address-Block   |
     address in an address     | |                   |       w/TLV       |
     block, with which a       | |                   |                   |
     Message-Type-specific     | |                   |                   |
     Address Block TLV of type | |                   |                   |
     ADDR-TYPE and with        | |                   |                   |
     Type-Extension            | |                   |                   |
     DESTINATION is            | |                   |                   |
     associated, defined in    | |                   |                   |
     Table 14.  An RREP MUST   | |                   |                   |
     contain exactly one       | |                   |                   |
     address with a TLV of     | |                   |                   |
     type ADDR-TYPE and with   | |                   |                   |
     Type-Extension            | |                   |                   |
     DESTINATION associated.   |
     +-------------------+-------------------+---------------------------+

  -- The document date (January 11, 2013) is 4113 days in the past.  Is this
     intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  == Outdated reference: A later version (-06) exists of
     draft-sheffer-running-code-01


     Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 2 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. Colin de Verdiere
4	Intended status: Standards Track                                   J. Yi
5	Expires: July 15, 2013                          LIX, Ecole Polytechnique
6	                                                              A. Niktash
7	                                               Maxim Integrated Products
8	                                                             Y. Igarashi
9	                                                                H. Satoh
10	                                        Hitachi, Ltd., Yokohama Research
11	                                                              Laboratory
12	                                                              U. Herberg
13	                                         Fujitsu Laboratories of America
14	                                                               C. Lavenu
15	                                                                 EDF R&D
16	                                                                  T. Lys
17	                                                                    ERDF
18	                                                              C. Perkins
19	                                                          Futurewei Inc.
20	                                                                 J. Dean
21	                                               Naval Research Laboratory
22	                                                        January 11, 2013

24	The Lightweight On-demand Ad hoc Distance-vector Routing Protocol - Next
25	                          Generation (LOADng)
26	                      draft-clausen-lln-loadng-08

28	Abstract

30	   This document describes the Lightweight Ad hoc On-Demand - Next
31	   Generation (LOADng) distance vector routing protocol, a reactive
32	   routing protocol intended for use in Mobile Ad hoc NETworks (MANETs).

34	Status of This Memo

36	   This Internet-Draft is submitted in full conformance with the
37	   provisions of BCP 78 and BCP 79.  This document may not be modified,
38	   and derivative works of it may not be created, except to format it
39	   for publication as an RFC or to translate it into languages other
40	   than English.

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

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

52	   This Internet-Draft will expire on July 15, 2013.

54	Copyright Notice

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

59	   This document is subject to BCP 78 and the IETF Trust's Legal
60	   Provisions Relating to IETF Documents
61	   (http://trustee.ietf.org/license-info) in effect on the date of
62	   publication of this document.  Please review these documents
63	   carefully, as they describe your rights and restrictions with respect
64	   to this document.  Code Components extracted from this document must
65	   include Simplified BSD License text as described in Section 4.e of
66	   the Trust Legal Provisions and are provided without warranty as
67	   described in the Simplified BSD License.

69	Table of Contents

71	   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
72	   2.  Terminology and Notation . . . . . . . . . . . . . . . . . . .  6
73	     2.1.  Message and Message Field Notation . . . . . . . . . . . .  6
74	     2.2.  Variable Notation  . . . . . . . . . . . . . . . . . . . .  7
75	     2.3.  Other Notation . . . . . . . . . . . . . . . . . . . . . .  7
76	     2.4.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  7
77	   3.  Applicability Statement  . . . . . . . . . . . . . . . . . . .  8
78	   4.  Protocol Overview and Functioning  . . . . . . . . . . . . . .  9
79	     4.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .  9
80	     4.2.  LOADng Routers and LOADng Interfaces . . . . . . . . . . . 10
81	     4.3.  Information Base Overview  . . . . . . . . . . . . . . . . 11
82	     4.4.  Signaling Overview . . . . . . . . . . . . . . . . . . . . 12
83	   5.  Protocol Parameters  . . . . . . . . . . . . . . . . . . . . . 13
84	     5.1.  Protocol and Port Numbers  . . . . . . . . . . . . . . . . 13
85	     5.2.  Router Parameters  . . . . . . . . . . . . . . . . . . . . 13
86	     5.3.  Interface Parameters . . . . . . . . . . . . . . . . . . . 14
87	     5.4.  Constants  . . . . . . . . . . . . . . . . . . . . . . . . 14
88	   6.  Protocol Message Content . . . . . . . . . . . . . . . . . . . 15
89	     6.1.  Route Request (RREQ) Messages  . . . . . . . . . . . . . . 15
90	     6.2.  Route Reply (RREP) Messages  . . . . . . . . . . . . . . . 16
91	     6.3.  Route Reply Acknowledgement (RREP_ACK) Messages  . . . . . 17
92	     6.4.  Route Error (RERR) Messages  . . . . . . . . . . . . . . . 18
93	   7.  Information Base . . . . . . . . . . . . . . . . . . . . . . . 19
94	     7.1.  Routing Set  . . . . . . . . . . . . . . . . . . . . . . . 19
95	     7.2.  Local Interface Set  . . . . . . . . . . . . . . . . . . . 20
96	     7.3.  Blacklisted Neighbor Set . . . . . . . . . . . . . . . . . 20
97	     7.4.  Destination Address Set  . . . . . . . . . . . . . . . . . 21
98	     7.5.  Pending Acknowledgment Set . . . . . . . . . . . . . . . . 21
99	   8.  LOADng Router Sequence Numbers . . . . . . . . . . . . . . . . 22
100	   9.  Route Maintenance  . . . . . . . . . . . . . . . . . . . . . . 22
101	   10. Unidirectional Link Handling . . . . . . . . . . . . . . . . . 24
102	     10.1. Blacklist Usage  . . . . . . . . . . . . . . . . . . . . . 24
103	   11. Common Rules for RREQ and RREP Messages  . . . . . . . . . . . 25
104	     11.1. Identifying Invalid RREQ or RREP Messages  . . . . . . . . 26
105	     11.2. RREQ and RREP Message Processing . . . . . . . . . . . . . 26
106	   12. Route Requests (RREQs) . . . . . . . . . . . . . . . . . . . . 30
107	     12.1. RREQ Generation  . . . . . . . . . . . . . . . . . . . . . 30
108	     12.2. RREQ Processing  . . . . . . . . . . . . . . . . . . . . . 31
109	     12.3. RREQ Forwarding  . . . . . . . . . . . . . . . . . . . . . 31
110	     12.4. RREQ Transmission  . . . . . . . . . . . . . . . . . . . . 32
111	   13. Route Replies (RREPs)  . . . . . . . . . . . . . . . . . . . . 32
112	     13.1. RREP Generation  . . . . . . . . . . . . . . . . . . . . . 32
113	     13.2. RREP Processing  . . . . . . . . . . . . . . . . . . . . . 33
114	     13.3. RREP Forwarding  . . . . . . . . . . . . . . . . . . . . . 34
115	     13.4. RREP Transmission  . . . . . . . . . . . . . . . . . . . . 34
116	   14. Route Errors (RERRs) . . . . . . . . . . . . . . . . . . . . . 35
117	     14.1. Identifying Invalid RERR Messages  . . . . . . . . . . . . 36
118	     14.2. RERR Generation  . . . . . . . . . . . . . . . . . . . . . 36
119	     14.3. RERR Processing  . . . . . . . . . . . . . . . . . . . . . 37
120	     14.4. RERR Forwarding  . . . . . . . . . . . . . . . . . . . . . 38
121	     14.5. RERR Transmission  . . . . . . . . . . . . . . . . . . . . 38
122	   15. Route Reply Acknowledgments (RREP_ACKs)  . . . . . . . . . . . 39
123	     15.1. Identifying Invalid RREP_ACK Messages  . . . . . . . . . . 39
124	     15.2. RREP_ACK Generation  . . . . . . . . . . . . . . . . . . . 39
125	     15.3. RREP_ACK Processing  . . . . . . . . . . . . . . . . . . . 40
126	     15.4. RREP_ACK Forwarding  . . . . . . . . . . . . . . . . . . . 41
127	     15.5. RREP_ACK Transmission  . . . . . . . . . . . . . . . . . . 41
128	   16. Metrics  . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
129	     16.1. Specifying New Metrics . . . . . . . . . . . . . . . . . . 41
130	   17. Implementation Status  . . . . . . . . . . . . . . . . . . . . 41
131	     17.1. Implementation of Ecole Polytechnique  . . . . . . . . . . 41
132	     17.2. Implementation of Fujitsu Laboratories of America  . . . . 42
133	     17.3. Implementation of Hitachi Yokohama Research Laboratory
134	           - 1  . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
135	     17.4. Implementation of Hitachi Yokohama Research Laboratory
136	           -2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
137	   18. Security Considerations  . . . . . . . . . . . . . . . . . . . 43
138	     18.1. Confidentiality  . . . . . . . . . . . . . . . . . . . . . 43
139	     18.2. Integrity  . . . . . . . . . . . . . . . . . . . . . . . . 44
140	     18.3. Channel Jamming and State Explosion  . . . . . . . . . . . 46
141	     18.4. Interaction with External Routing Domains  . . . . . . . . 47
142	   19. LOADng Specific IANA Considerations  . . . . . . . . . . . . . 47
143	     19.1. Error Codes  . . . . . . . . . . . . . . . . . . . . . . . 47
144	   20. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 48
145	   21. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 48
146	   22. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49
147	     22.1. Normative References . . . . . . . . . . . . . . . . . . . 49
148	     22.2. Informative References . . . . . . . . . . . . . . . . . . 49
149	   Appendix A.  LOADng Control Messages using RFC5444 . . . . . . . . 50
150	     A.1.  RREQ-Specific Message Encoding Considerations  . . . . . . 51
151	     A.2.  RREP-Specific Message Encoding Considerations  . . . . . . 52
152	     A.3.  RREP_ACK Message Encoding  . . . . . . . . . . . . . . . . 54
153	     A.4.  RERR Message Encoding  . . . . . . . . . . . . . . . . . . 55
154	     A.5.  RFC5444-Specific IANA Considerations . . . . . . . . . . . 56
155	       A.5.1.  Expert Review: Evaluation Guidelines . . . . . . . . . 57
156	       A.5.2.  Message Types  . . . . . . . . . . . . . . . . . . . . 57
157	     A.6.  RREQ Message-Type-Specific TLV Type Registries . . . . . . 57
158	     A.7.  RREP Message-Type-Specific TLV Type Registries . . . . . . 59
159	     A.8.  RREP_ACK Message-Type-Specific TLV Type Registries . . . . 61
160	     A.9.  RERR Message-Type-Specific TLV Type Registries . . . . . . 61
161	   Appendix B.  LOADng Control Packet Illustrations . . . . . . . . . 62
162	     B.1.  RREQ . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
163	     B.2.  RREP . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
164	     B.3.  RREP_ACK . . . . . . . . . . . . . . . . . . . . . . . . . 65
165	     B.4.  RERR . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

167	1.  Introduction

169	   The Lightweight On-demand Ad hoc Distance-vector Routing Protocol -
170	   Next Generation (LOADng) is a routing protocol, derived from AODV
171	   [RFC3561] and extended for use in Mobile Ad hoc NETworks (MANETs).
172	   As a reactive protocol, the basic operations of LOADng include
173	   generation of Route Requests (RREQs) by a LOADng Router (originator)
174	   for when discovering a route to a destination, forwarding of such
175	   RREQs until they reach the destination LOADng Router, generation of
176	   Route Replies (RREPs) upon receipt of an RREQ by the indicated
177	   destination, and unicast hop-by-hop forwarding of these RREPs towards
178	   the originator.  If a route is detected to be broken, e.g., if
179	   forwarding of a data packet to the recorded next hop on the route
180	   towards the intended destination is detected to fail, a Route Error
181	   (RERR) message is returned to the originator of that data packet to
182	   inform the originator about the route breakage.

184	   Compared to [RFC3561], LOADng is simplified as follows:

186	   o  Only the destination is permitted to respond to an RREQ;
187	      intermediate LOADng Routers are explicitly prohibited from
188	      responding to RREQs, even if they may have active routes to the
189	      sought destination, and RREQ/RREP messages generated by a given
190	      LOADng Router share a single unique, monotonically increasing
191	      sequence number.  This also eliminates Gratuitous RREPs while
192	      ensuring loop freedom.  The rationale for this simplification is
193	      reduced complexity of protocol operation and reduced message
194	      sizes.

196	   o  A LOADng Router does not maintain a precursor list, thus when
197	      forwarding of a data packet to the recorded next hop on the route
198	      to the destination fails, an RERR is sent only to the originator
199	      of that data packet.  The rationale for this simplification is an
200	      assumption that few overlapping routes are in use concurrently in
201	      a given network.

203	   Compared to [RFC3561], LOADng is extended as follows:

205	   o  Optimized flooding is supported, reducing the overhead incurred by
206	      RREQ generation and flooding.  If no optimized flooding operation
207	      is specified for a given deployment, classical flooding is used by
208	      default.

210	   o  Different address lengths are supported - from full 16 octet IPv6
211	      addresses over 8 octet EUI64 addresss [EUI64], 6 octet MAC
212	      addresses and 4 octet IPv4 addresses to shorter 1 and 2 octet
213	      addresses such as [RFC4944].  The only requirement is, that within
214	      a given routing domain, all addresses are of the same address
215	      length.

217	   o  Control messages are carried by way of the Generalized MANET
218	      Packet/Message Format [RFC5444].

220	   o  Using [RFC5444], control messages can include TLV (Type-Length-
221	      Value) elements, permitting protocol extensions to be developed.

223	   o  LOADng supports routing using arbitrary additive metrics, which
224	      can be specified as extensions to this protocol.

226	2.  Terminology and Notation

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

233	   Additionally, this document uses the notations in Section 2.1,
234	   Section 2.2, and Section 2.3 and the terminology defined in
235	   Section 2.4.

237	2.1.  Message and Message Field Notation

239	   LOADng Routers generate and process messages, each of which has a
240	   number of distinct fields.  For describing the protocol operation,
241	   specifically the generation and processing of such messages, the
242	   following notation is employed:

244	                   MsgType.field

246	   where:

248	   MsgType -  is the type of message (e.g., RREQ or RREP);

250	   field -  is the field in the message (e.g., originator).

252	   The different messages, their fields and their meaning are described
253	   in Section 6.  The encoding of messages for transmission by way of
254	   [RFC5444] packets/messages is described in Appendix A, and Appendix B
255	   illustrates the bit layout of LOADng control messages.

257	   The motivation for separating the high-level messages and their
258	   content from the low-level encoding and frame format for transmission
259	   is to allow discussions of the protocol logic to be separated from
260	   the message encoding and frame format - and, to support different
261	   frame formats.

263	2.2.  Variable Notation

265	   Variables are introduced into the specification solely as a means to
266	   clarify the description.  The following notation is used:

268	   MsgType.field -  If "field" is a field in the message MsgType, then
269	      MsgType.field is also used to represent the value of that field.

271	   bar -  A variable (not prepended by MsgType), usually obtained
272	      through calculations based on the value(s) of element(s).

274	2.3.  Other Notation

276	   This document uses the following additional notational conventions:

278	   a := b   An assignment operator, whereby the left side (a) is
279	      assigned the value of the right side (b).

281	   c = d   A comparison operator, returning TRUE if the value of the
282	      left side (c) is equal to the value of the right side (d).

284	2.4.  Terminology

286	   This document uses the following terminology:

288	   LOADng Router -  A router that implements this routing protocol.  A
289	      LOADng Router is equipped with at least one, and possibly more,
290	      LOADng Interfaces.

292	   LOADng Interface -  A LOADng Router's attachment to a communications
293	      medium, over which it receives and generates control messages,
294	      according to this specification.  A LOADng Interface is assigned
295	      one or more addresses.

297	   Link -  A link between two LOADng Interfaces exists if either can
298	      receive control messages, according to this specification, from
299	      the other.

301	   Message -  The fundamental entity carrying protocol information, in
302	      the form of address objects and TLVs.

304	   Link Metric -  The cost (weight) of a link between a pair of LOADng
305	      Interfaces.

307	   Route Metric -  The sum of the Link Metrics for the links that an
308	      RREQ or RREP has crossed.

310	3.  Applicability Statement

312	   LOADng is a reactive MANET protocol, i.e., routes are discovered only
313	   when a data packet is sent by a router (e.g., on behalf of an
314	   attached host), and when the router has no route for this
315	   destination.  In that case, the router floods Route Requests (RREQ)
316	   throughout the network for discovering the destination.  Reactive
317	   protocols require state only for the routes currently in use,
318	   contrary to proactive protocols, which periodically send control
319	   traffic and store routes to all destinations in the network.  As
320	   MANETs are often operated on wireless channels, flooding RREQs may
321	   lead to frame collisions and therefore data loss.  Moreover, each
322	   transmission on a network interface consumes energy, reducing the
323	   life-time of battery-driven routers.  Consequently, in order to
324	   reduce the amount of control traffic, LOADng (and in general reactive
325	   protocols) are most suitable under the following constraints:

327	   o  Few concurrent traffic flows in the network (i.e., traffic flows
328	      only between few sources and destinations);

330	   o  Little data traffic overall, and therefore the traffic load from
331	      periodic signaling (for proactive protocols) is greater than the
332	      traffic load from flooding RREQs (for reactive protocols);

334	   o  State requirements on the router are very stringent, i.e., it is
335	      beneficial to store only few routes on a router.

337	   In these specific use cases, reactive MANET protocols have shown to
338	   be beneficial, and may be preferable over the more general use case
339	   of proactive MANET protocols.

341	   Specifically, the applicability of LOADng is determined by its
342	   characteristics, which are that this protocol:

344	   o  Is a reactive routing protocol for Mobile Ad hoc NETworks
345	      (MANETs).

347	   o  Is designed to work in networks with dynamic topology in which the
348	      links may be lossy due to collisions, channel instability, or
349	      movement of routers.

351	   o  Supports the use of optimized flooding for RREQs.

353	   o  Enables any LOADng Router to discover bi-directional routes to
354	      destinations in the routing domain, i.e., to any other LOADng
355	      Router, as well as hosts or networks attached to that LOADng
356	      Router, in the same routing domain.

358	   o  Supports addresses of any length with integral number of octets,
359	      from 16 octets to a single octet.

361	   o  Is layer-agnostic, i.e., may be used at layer 3 as a "route over"
362	      routing protocol, or at layer 2 as a "mesh under" routing
363	      protocol.

365	   o  Supports per-destination route maintenance; if a destination
366	      becomes unreachable, rediscovery of that single (bi-directional)
367	      route is performed, without need for global topology
368	      recalculation.

370	4.  Protocol Overview and Functioning

372	   The objective of this protocol is for each LOADng Router to,
373	   independently:

375	   o  Discover a bi-directional route to any destination in the network.

377	   o  Establish a route only when there is data traffic to be sent along
378	      that route.

380	   o  Maintain a route only for as long as there is data traffic being
381	      sent along that route.

383	   o  Generate control traffic based on network events only: when a new
384	      route is required, or when an active route is detected broken.
385	      Specifically, this protocol does not require periodic signaling.

387	4.1.  Overview

389	   These objectives are achieved, for each LOADng Router, by performing
390	   the following tasks:

392	   o  When having a data packet to deliver to a destination, for which
393	      no tuple in the routing set exists and where the data packet
394	      source is local to that LOADng Router (i.e., is an address in the
395	      Local Interface Set or Destination Address Set of that LOADng
396	      Router), generate a Route Request (RREQ) encoding the destination
397	      address, and transmit this RREQ over all of its LOADng Interfaces.

399	   o  Upon receiving an RREQ, insert or refresh a tuple in the Routing
400	      Set, recording a route towards the originator address from the
401	      RREQ, as well as to the neighbor LOADng Router from which the RREQ
402	      was received.  This will install the Reverse Route (towards the
403	      originator address from the RREQ).

405	   o  Upon receiving an RREQ, inspect the indicated destination address:

407	      *  If that address is an address in the Destination Address Set or
408	         in the Local Interface Set of the LOADng Router, generate a
409	         Route Reply (RREP), which is unicast in a hop-by-hop fashion
410	         along the installed Reverse Route.

412	      *  If that address is not an address in the Destination Address
413	         Set or in the Local Interface Set of the LOADng Router,
414	         consider the RREQ as a candidate for forwarding.

416	   o  When an RREQ is considered a candidate for forwarding, retransmit
417	      it according to the flooding operation, specified for the network.

419	   o  Upon receiving an RREP, insert or refresh a tuple in the Routing
420	      Set, recording a route towards the originator address from the
421	      RREP, as well as to the neighbor LOADng Router, from which that
422	      RREP was received.  This will install the Forward Route (towards
423	      the originator address from the RREP).  The originator address is
424	      either an address from the Local Interface Set of the LOADng
425	      Router, or an address from its Destination Address Set (i.e., an
426	      address of a host attached to that LOADng Router).

428	   o  Upon receiving an RREP, forward it, as unicast, to the recorded
429	      next hop along the corresponding Reverse Route until the RREP
430	      reaches the LOADng Router that has the destination address from
431	      the RREP in its Local Interface Set or Destination Address Set.

433	   o  When forwarding an RREQ or RREP, update the route metric, as
434	      contained in that RREQ or RREP message.

436	   A LOADng Router generating an RREQ specifies which metric type it
437	   desires.  Routers receiving an RREQ will process it and update route
438	   metric information in the RREQ according to that metric, if they can.
439	   All LOADng Routers, however, will update information in the RREQ so
440	   as to be able to support a "hop-count" default metric.  If a LOADng
441	   Router is not able to understand the metric type, specified in an
442	   RREQ, it will update the route metric value to its maximum value, so
443	   as to ensure that this is indicated to the further recipients of the
444	   RREQ.  Once the route metric value is set to its maximum value, no
445	   LOADng Router along the path towards the destination may change the
446	   value.

448	4.2.  LOADng Routers and LOADng Interfaces

450	   A LOADng Router has a set of at least one, and possibly more, LOADng
451	   Interfaces.  Each LOADng Interface:

453	   o  Is configured with one or more addresses.

455	   o  Has a number of interface parameters.

457	   In addition to a set of LOADng Interfaces as described above, each
458	   LOADng Router:

460	   o  Has a number of router parameters.

462	   o  Has an Information Base.

464	   o  Generates and processes RREQ, RREP, RREP_ACK and RERR messages,
465	      according to this specification.

467	4.3.  Information Base Overview

469	   Necessary protocol state is recorded by way of five information sets:
470	   the "Routing Set", the "Local Interface Set", the "Blacklisted
471	   Neighbor Set", the "Destination Address Set", and the "Pending
472	   Acknowledgment Set".

474	   The Routing Set contains tuples, each representing the next-hop on,
475	   and the metric of, a route towards a destination address.
476	   Additionally, the Routing Set records the sequence number of the last
477	   message, received from the destination.  This information is
478	   extracted from the message (RREQ or RREP) that generated the tuple so
479	   as to enable routing.  The routing table is to be updated using this
480	   Routing Set. (A LOADng Router may choose to use any or all
481	   destination addresses in the Routing Set to update the routing table,
482	   this selection is outside the scope of this specification.)

484	   The Local Interface Set contains tuples, each representing a local
485	   LOADng Interface of the LOADng Router.  Each tuple contains a list of
486	   one or more addresses of that LOADng Interface.

488	   The Blacklisted Neighbor Set contains tuples representing neighbor
489	   LOADng Interface addresses of a LOADng Router with which
490	   unidirectional connectivity has been recently detected.

492	   The Destination Address Set contains tuples representing addresses,
493	   for which the LOADng Router is responsible, i.e., addresses of this
494	   LOADng Router, or of hosts and networks directly attached to this
495	   LOADng Router and which use it to connect to the routing domain.
496	   These addresses may in particular belong to devices which do not
497	   implement LOADng, and thus cannot process LOADng messages.  A LOADng
498	   Router provides connectivity to these addresses by generating RREPs
499	   in response to RREQs directed towards them.

501	   The Pending Acknowledgment Set contains tuples, representing
502	   transmitted RREPs for which an RREP_ACK is expected, but where this
503	   RREP_ACK has not yet been received.

505	   The Routing Set, the Blacklisted Neighbor Set and the Pending
506	   Acknowledgment Set are updated by this protocol.  The Local Interface
507	   Set and the Destination Address Set are used, but not updated by this
508	   protocol.

510	4.4.  Signaling Overview

512	   This protocol generates and processes the following routing messages:

514	   Route Request (RREQ) -  Generated by a LOADng Router when it has a
515	      data packet to deliver to a given destination, where the data
516	      packet source is local to that LOADng Router (i.e., is an address
517	      in the Local Interface Set or Destination Address Set of that
518	      LOADng Router), but where it does not have an available tuple in
519	      its Routing Set indicating a route to that destination.  An RREQ
520	      contains:

522	      *  The (destination) address to which a Forward Route is to be
523	         discovered by way of soliciting the LOADng Router with that
524	         destination address in its Local Interface Set or in its
525	         Destination Address Set to generate an RREP.

527	      *  The (originator) address for which a Reverse Route is to be
528	         installed by RREQ forwarding and processing, i.e., the source
529	         address of the data packet which triggered the RREQ generation.

531	      *  The sequence number of the LOADng Router, generating the RREQ.

533	      An RREQ is flooded through the network, according to the flooding
534	      operation specified for the network.

536	   Route Reply (RREP) -  Generated as a response to an RREQ by the
537	      LOADng Router which has the address (destination) from the RREQ in
538	      its Local Interface Set or in its Destination Address Set. An RREP
539	      is sent in unicast towards the originator of that RREQ.  An RREP
540	      contains:

542	      *  The (originator) address to which a Forward Route is to be
543	         installed when forwarding the RREP.

545	      *  The (destination) address towards which the RREP is to be sent.
546	         More precisely, the destination address determines the unicast
547	         route which the RREP follows.

549	      *  The sequence number of the LOADng Router, generating the RREP.

551	   Route Reply Acknowledgment (RREP_ACK) -  Generated by a LOADng Router
552	      as a response to an RREP, in order to signal to the neighbor that
553	      transmitted the RREP that the RREP was successfully received.
554	      Receipt of an RREP_ACK indicates that the link between these two
555	      neighboring LOADng Routers is bidirectional.  An RREP_ACK is
556	      unicast to the neighbor from which the RREP has arrived, and is
557	      not forwarded.  RREP_ACKs are generated only in response to an
558	      RREP which, by way of a flag, has explicitly indicated that an
559	      RREP_ACK is desired.

561	   Route Error (RERR) -  Generated by a LOADng Router when a link on an
562	      active route to a destination is detected as broken by way of
563	      inability to forward a data packet towards that destination.  An
564	      RERR is unicast to the source of the undeliverable data packet.

566	5.  Protocol Parameters

568	   The following parameters and constants are used in this
569	   specification.

571	5.1.  Protocol and Port Numbers

573	   When using LOADng as an IP routing protocol, the considerations of
574	   [RFC5498] apply.

576	5.2.  Router Parameters

578	   NET_TRAVERSAL_TIME -  is the maximum time that a packet is expected
579	      to take when traversing from one end of the network to the other.

581	   RREQ_RETRIES -  is the maximum number of subsequent RREQs that a
582	      particular LOADng Router may generate in order to discover a route
583	      to a destination, before declaring that destination unreachable.

585	   RREQ_MIN_INTERVAL -  is the minimal interval (in milliseconds) of
586	      RREQs that a particular LOADng Router is allowed to send.

588	   R_HOLD_TIME -  is the minimum time a Routing Tuple SHOULD be kept in
589	      the Routing Set after it was last refreshed.

591	   MAX_DIST -  is the value representing the maximum possible metric
592	      (R_metric field).

594	   B_HOLD_TIME -  is the time during which the link between the neighbor
595	      LOADng Router and this LOADng Router MUST be considered as non-
596	      bidirectional, and that therefore RREQs received from that
597	      neighbor LOADng Router MUST be ignored during that time
598	      (B_HOLD_TIME).  B_HOLD_TIME should be greater than 2 x
599	      NET_TRAVERSAL_TIME x RREQ_RETRIES, to ensure that subsequent RREQs
600	      will reach the destination via a route, excluding the link to the
601	      blacklisted neighbor.

603	   MAX_HOP_LIMIT -  is the maximum limit of the number of hops that
604	      LOADng routing messages are allowed to traverse.

606	5.3.  Interface Parameters

608	   Different LOADng Interfaces (on the same or on different LOADng
609	   Routers) MAY employ different interface parameter values and MAY
610	   change their interface parameter values dynamically.  A particular
611	   case is where all LOADng Interfaces on all LOADng Routers within a
612	   given LOADng routing domain employ the same set of interface
613	   parameter values.

615	   RREQ_MAX_JITTER -  is the default value of MAXJITTER used in
616	      [RFC5148] for RREQ messages forwarded by this LOADng Router on
617	      this interface.

619	   RREP_ACK_REQUIRED -  is a boolean flag, which indicates (if set) that
620	      the LOADng Router is configured to expect that each RREP it sends
621	      be confirmed by an RREP_ACK, or, (if cleared) that no RREP_ACK is
622	      expected for this interface.

624	   USE_BIDIRECTIONAL_LINK_ONLY -  is a boolean flag, which indicates if
625	      the LOADng Router only uses verified bi-directional links for data
626	      packet forwarding on this interface.  It is set by default.  If
627	      cleared, then the LOADng Router can use links which have not been
628	      verified to be bi-directional on this interface.

630	   RREP_ACK_TIMEOUT -  is the minimum amount of time after transmission
631	      of an RREP, that a LOADng Router SHOULD wait for an RREP_ACK from
632	      a neighbor LOADng Router, before considering the link to this
633	      neighbor to be unidirectional.

635	5.4.  Constants

637	   MAX_HOP_COUNT -  is the maximum number of hops as representable by
638	      the encoding that is used (e.g., 255 when using [RFC5444]).  It
639	      SHOULD NOT be used to limit the scope of a message; the router
640	      parameter MAX_HOP_LIMIT can be used to limit the scope of a LOADng
641	      routing message.

643	6.  Protocol Message Content

645	   The protocol messages, generated and processed by LOADng, are
646	   described in this section using the notational conventions described
647	   in Section 2.  The encoding of messages for transmission by way of
648	   [RFC5444] packets/messages is described in Appendix A, and Appendix B
649	   illustrates the bit layout of a selection of LOADng control messages.
650	   Unless stated otherwise, the message fields described below are set
651	   by the LOADng Router that generates the message, and MUST NOT be
652	   changed by intermediate LOADng Routers.

654	6.1.  Route Request (RREQ) Messages

656	   A Route Request (RREQ) message has the following fields:

658	   RREQ.addr-length  is an unsigned integer field, encoding the length
659	      of the originator and destination addresses as follows:

661	      RREQ.addr-length := the length of an address in octets - 1

663	   RREQ.seq-num  is an unsigned integer field, containing the sequence
664	      number (see Section 8) of the LOADng Router, generating the RREQ
665	      message.

667	   RREQ.metric-type  is an unsigned integer field and specifies the type
668	      of metric requested by this RREQ.

670	   RREQ.route-metric  is a unsigned integer field, of length defined by
671	      RREQ.metric-type, which specifies the route metric of the route
672	      (the sum of the link metrics of the links), through which this
673	      RREQ has traveled.

675	   RREQ.hop-count  is an unsigned integer field and specifies the total
676	      number of hops which the message has traversed from the
677	      RREQ.originator.

679	   RREQ.hop-limit  is an unsigned integer field and specifies the number
680	      of hops that the message is allowed to traverse.

682	   RREQ.originator  is an identifier of RREQ.addr-length + 1 octets,
683	      specifying the address of the LOADng Interface over which this
684	      RREQ was generated, and to which a route (the "reverse route") is
685	      supplied by this RREQ.  In case the message is generated by a
686	      LOADng Router on behalf of an attached host, RREQ.originator
687	      corresponds to an address of that host, otherwise it corresponds
688	      to an address of the sending LOADng Interface of the LOADng
689	      Router.

691	   RREQ.destination  is an identifier of RREQ.addr-length + 1 octets,
692	      specifying the address to which the RREQ should be sent, i.e., the
693	      destination address for which a route is sought.

695	   The following fields of an RREQ message are immutable, i.e., they
696	   MUST NOT be changed during processing or forwarding of the message:
697	   RREQ.addr-length, RREQ.seq-num, RREQ.originator, and
698	   RREQ.destination.

700	   The following fields of an RREQ message are mutable, i.e., they will
701	   be changed by intermediate routers during processing or forwarding,
702	   as specified in Section 12.2 and Section 12.3: RREQ.metric-type,
703	   RREQ.route-metric, RREQ.hop-limit, and RREQ.hop-count.

705	   Any additional field that is added to the message by an extension to
706	   this protocol, e.g., by way of TLVs, MUST be considered immutable,
707	   unless the extension specifically defines the field as mutable.

709	6.2.  Route Reply (RREP) Messages

711	   A Route Reply (RREP) message has the following fields:

713	   RREP.addr-length  is an unsigned integer field, encoding the length
714	      of the originator and destination addresses as follows:

716	      RREP.addr-length := the length of an address in octets - 1

718	   RREP.seq-num  is an unsigned integer field, containing the sequence
719	      number (see Section 8) of the LOADng Router, generating the RREP
720	      message.

722	   RREP.metric-type  is an unsigned integer field and specifies the type
723	      of metric, requested by this RREP.

725	   RREP.route-metric  is a unsigned integer field, of length defined by
726	      RREP.metric-type, which specifies the route metric of the route
727	      (the sum of the link metrics of the links) through which this RREP
728	      has traveled.

730	   RREP.ackrequired  is a boolean flag which, when set ('1'), at least
731	      one RREP_ACK MUST be generated by the recipient of an RREP if the
732	      RREP is successfully processed.  When cleared ('0'), an RREP_ACK
733	      MUST NOT be generated in response to processing of the RREP.

735	   RREP.hop-count  is an unsigned integer field and specifies the total
736	      number of hops which the message has traversed from
737	      RREP.originator to RREP.destination.

739	   RREP.hop-limit  is an unsigned integer field and specifies the number
740	      of hops that the message is allowed to traverse.

742	   RREP.originator  is an identifier of RREP.addr-length + 1 octets,
743	      specifying the address for which this RREP was generated, and to
744	      which a route (the "forward route") is supplied by this RREP.  In
745	      case the message is generated on a LOADng Router on behalf of an
746	      attached host, RREP.originator corresponds to an address of that
747	      host, otherwise it corresponds to an address of the LOADng
748	      Interface of the LOADng Router, over which the RREP was generated.

750	   RREP.destination  is an identifier of RREP.addr-length + 1 octets,
751	      specifying the address to which the RREP should be sent.  (I.e.,
752	      this address is equivalent to RREQ.originator of the RREQ that
753	      triggered the RREP.)

755	   The following fields of an RREP message are immutable, i.e., they
756	   MUST NOT be changed during processing or forwarding of the message:
757	   RREP.addr-length, RREP.seq-num, RREP.originator, and
758	   RREP.destination.

760	   The following fields of an RREP message are mutable, i.e., they will
761	   be changed by intermediate routers during processing or forwarding,
762	   as specified in Section 13.2 and Section 13.3: RREP.metric-type,
763	   RREP.route-metric, RREP.ackrequired, RREP.hop-limit, and RREP.hop-
764	   count.

766	   Any additional field that is added to the message by an extension to
767	   this protocol, e.g., by way of TLVs, MUST be considered immutable,
768	   unless the extension specifically defines the field as mutable.

770	6.3.  Route Reply Acknowledgement (RREP_ACK) Messages

772	   A Route Reply Acknowledgement (RREP_ACK) message has the following
773	   fields:

775	   RREP_ACK.addr-length  is an unsigned integer field, encoding the
776	      length of the destination and originator addresses as follows:

778	      RREP_ACK.addr-length := the length of an address in octets - 1

780	   RREP_ACK.seq-num  is an unsigned integer field and contains the value
781	      of RREP.seq-num from the RREP for which this RREP_ACK is sent.

783	   RREP_ACK.destination  is an identifier of RREP_ACK.addr-length + 1
784	      octets and contains the value of the RREP.originator field from
785	      the RREP for which this RREP_ACK is sent.

787	   RREP_ACK messages are sent only across a single link and are never
788	   forwarded.

790	6.4.  Route Error (RERR) Messages

792	   A Route Error (RERR) message has the following fields:

794	   RERR.addr-length  is an unsigned integer field, encoding the length
795	      of RERR.destination and RERR.unreachableAddress, as follows:

797	      RERR.addr-length := the length of an address in octets - 1

799	   RERR.errorcode  is an unsigned integer field and specifies the reason
800	      for the error message being generated, according to Table 1.

802	   RERR.unreachableAddress  is an identifier of RERR.addr-length + 1
803	      octets, specifying an address, which has become unreachable, and
804	      for which an error is reported by way of this RERR message.

806	   RERR.originator  is an identifier of RERR.addr-length + 1 octets,
807	      specifying the address of the LOADng Interface over which this
808	      RERR was generated by a LOADng Router.

810	   RERR.destination  is an identifier of RERR.address-length + 1 octets,
811	      specifying the destination address of this RERR message.
812	      RERR.destination is, in general, the source address of a data
813	      packet, for which delivery to RERR.unreachableAddress failed, and
814	      the unicast destination of the RERR message is the LOADng Router
815	      which has RERR.destination listed in a Local Interface Tuple or in
816	      a Destination Address Tuple.

818	   RERR.hop-limit  is an unsigned integer field and specifies the number
819	      of hops that the message is allowed to traverse.

821	   The following fields of an RERR message are immutable, i.e., they
822	   MUST NOT be changed during processing or forwarding of the message:
823	   RERR.addr-length, RERR.errorcode, RERR.unreachableAddress,
824	   RERR.originator and RERR.destination.

826	   The following fields of an RERR message are mutable, i.e., they will
827	   be changed by intermediate routers during processing or forwarding,
828	   as specified in Section 14.3 and Section 14.4: RERR.hop-limit.

830	   Any additional field that is added to the message by an extension to
831	   this protocol, e.g., by way of TLVs, MUST be considered immutable,
832	   unless the extension specifically defines the field as mutable.

834	7.  Information Base

836	   Each LOADng Router maintains an Information Base, containing the
837	   information sets necessary for protocol operation, as described in
838	   the following sections.  The organization of information into these
839	   information sets is non-normative, given so as to facilitate
840	   description of message generation, forwarding and processing rules in
841	   this specification.  An implementation may choose any representation
842	   or structure for when maintaining this information.

844	7.1.  Routing Set

846	   The Routing Set records the next hop on the route to each known
847	   destination, when such a route is known.  It consists of Routing
848	   Tuples:

850	   (R_dest_addr, R_next_addr, R_metric, R_metric_type, R_hop_count,
851	      R_seq_num, R_bidirectional, R_local_iface_addr, R_valid_time)

853	   where:

855	   R_dest_addr -  is the address of the destination, either an address
856	      of a LOADng Interface of a destination LOADng Router, or an
857	      address of an interface reachable via the destination LOADng
858	      Router, but which is outside the routing domain.

860	   R_next_addr -  is the address of the "next hop" on the selected route
861	      to the destination.

863	   R_metric -  is the metric associated with the selected route to the
864	      destination with address R_dest_addr.

866	   R_metric_type -  specifies the metric type for this Routing Tuple -
867	      in other words, how R_metric is defined and calculated.

869	   R_hop_count -  is the hop count of the selected route to the
870	      destination with address R_dest_addr.

872	   R_seq_num -  is the value of the RREQ.seq-num or RREP.seq-num field
873	      of the RREQ or RREP which installed or last updated this tuple.
874	      For the Routing Tuples installed by previous hop information of
875	      RREQ or RREP, R_seq_num MUST be set to -1.

877	   R_bidirectional -  is a boolean flag, which specifies if the Routing
878	      Tuple is verified as representing a bi-directional route.  Data
879	      traffic SHOULD only be routed through a routing tuple with
880	      R_bidirectional flag equals TRUE, unless the LOADng Router is
881	      configured as accepting routes without bi-directionality
882	      verification explicitly by setting USE_BIDIRECTIONAL_LINK_ONLY to
883	      FALSE of the interface with R_local_iface_address.

885	   R_local_iface_addr -  is an address of the local LOADng Interface,
886	      through which the destination can be reached.

888	   R_valid_time -  specifies the time until which the information
889	      recorded in this Routing Tuple is considered valid.

891	7.2.  Local Interface Set

893	   A LOADng Router's Local Interface Set records its local LOADng
894	   Interfaces.  It consists of Local Interface Tuples, one per LOADng
895	   Interface:

897	               (I_local_iface_addr_list)

899	   where:

901	   I_local_iface_addr_list -  is an unordered list of the network
902	      addresses of this LOADng Interface.

904	   The implementation MUST initialize the Local Interface Set with at
905	   least one tuple containing at least one address of an LOADng
906	   Interface.  The Local Interface Set MUST be updated if there is a
907	   change of the LOADng Interfaces of a LOADng Router (i.e., a LOADng
908	   Interface is added, removed or changes addresses).

910	7.3.  Blacklisted Neighbor Set

912	   The Blacklisted Neighbor Set records the neighbor LOADng Interface
913	   addresses of a LOADng Router, with which connectivity has been
914	   detected to be unidirectional.  Specifically, the Blacklisted
915	   Neighbor Set records neighbors from which an RREQ has been received
916	   (i.e., through which a Forward Route would possible) but to which it
917	   has been determined that it is not possible to communicate (i.e.,
918	   forwarding Route Replies via this neighbor fails, rendering
919	   installing the Forward Route impossible).  It consists of Blacklisted
920	   Neighbor Tuples:

922	               (B_neighbor_address, B_valid_time)

924	   where:

926	   B_neighbor_address -  is the address of the blacklisted neighbor
927	      LOADng Interface.

929	   B_valid_time -  specifies the time until which the information
930	      recorded in this tuple is considered valid.

932	7.4.  Destination Address Set

934	   The Destination Address Set records addresses, for which a LOADng
935	   Router will generate RREPs in response to received RREQs, in addition
936	   to its own LOADng Interface addresses (as listed in the Local
937	   Interface Set).  The Destination Address Set thus represents those
938	   destinations (i.e., hosts), for which this LOADng Router is providing
939	   connectivity.  It consists of Destination Address Tuples:

941	               (D_address)

943	   where:

945	   D_address -  is the address of a destination (a host or a network),
946	      attached to this LOADng Router and for which this LOADng Router
947	      provides connectivity through the routing domain.

949	   The Destination Address Set is used for generating signaling, but is
950	   not itself updated by signaling specified in this document.  Updates
951	   to the Destination Address Set are due to changes of the environment
952	   of a LOADng Router - hosts or external networks being connected to or
953	   disconnected from a LOADng Router.  The Destination Address Set may
954	   be administrationally provisioned, or provisioned by external
955	   protocols.

957	7.5.  Pending Acknowledgment Set

959	   The Pending Acknowledgment Set contains information about RREPs which
960	   have been transmitted with the RREP.ackrequired flag set, and for
961	   which an RREP_ACK has not yet been received.  It consists of Pending
962	   Acknowledgment Tuples:

964	               (P_next_hop, P_originator, P_seq_num,
965	                P_ack_received, P_ack_timeout)

967	   where:

969	   P_next_hop -  is the address of the neighbor LOADng Interface to
970	      which the RREP was sent.

972	   P_originator -  is the address of the originator of the RREP.

974	   P_seq_num -  is the RREP.seq-num field of the sent RREP.

976	   P_ack_received -  is a boolean flag, which specifies the tuple has
977	      been acknowledged by a corresponding RREP_ACK message.  The
978	      default value is FALSE.

980	   P_ack_timeout -  is the time after which the tuple MUST be expired.

982	8.  LOADng Router Sequence Numbers

984	   Each LOADng Router maintains a single sequence number, which must be
985	   included in each RREQ or RREP message it generates.  Each LOADng
986	   Router MUST make sure that no two messages (both RREQ and RREP) are
987	   generated with the same sequence number, and MUST generate sequence
988	   numbers such that these are monotonically increasing.  This sequence
989	   number is used as freshness information for when comparing routes to
990	   the LOADng Router having generated the message.

992	   However, with a limited number of bits for representing sequence
993	   numbers, wrap-around (that the sequence number is incremented from
994	   the maximum possible value to zero) can occur.  To prevent this from
995	   interfering with the operation of the protocol, the following MUST be
996	   observed.  The term MAXVALUE designates in the following the largest
997	   possible value for a sequence number.  The sequence number S1 is said
998	   to be "greater than" (denoted '>') the sequence number S2 if:

1000	      S2 < S1 AND S1 - S2 <= MAXVALUE/2 OR

1002	      S1 < S2 AND S2 - S1 > MAXVALUE/2

1004	9.  Route Maintenance

1006	   Tuples in the Routing Set are maintained by way of five different
1007	   mechanisms:

1009	   o  RREQ/RREP exchange, specified in Section 12 and Section 13.

1011	   o  Data traffic delivery success.

1013	   o  Data traffic delivery failure.

1015	   o  External signals indicating that a tuple in the Routing Set needs
1016	      updating.

1018	   o  Information expiration.

1020	   Routing Tuples in the Routing Set contain a validity time, which
1021	   specifies the time until which the information recorded in this tuple
1022	   is considered valid.  After this time, the information in such tuples
1023	   is to be considered as invalid, for the processing specified in this
1024	   document.

1026	   Routing Tuples for actively used routes (i.e., routes via which
1027	   traffic is currently transiting) SHOULD NOT be removed, unless there
1028	   is evidence that they no longer provide connectivity - i.e., unless a
1029	   link on that route has broken.

1031	   To this end, one or more of the following mechanisms (non-exhaustive
1032	   list) MAY be used:

1034	   o  If a lower layer mechanism provides signals, such as when delivery
1035	      to a presumed neighbor LOADng Router fails, this signal MAY be
1036	      used to indicate that a link has broken, trigger early expiration
1037	      of a Routing Tuple from the Routing Set, and to initiate Route
1038	      Error Signaling (see Section 14).  Conversely, absence of such a
1039	      signal when attempting delivery MAY be interpreted as validation
1040	      that the corresponding Routing Tuple(s) are valid, and their
1041	      R_valid_time refreshed correspondingly.  Note that when using such
1042	      a mechanism, care should be taken to prevent that an intermittent
1043	      error (e.g., an incidental wireless collision) triggers corrective
1044	      action and signaling.  This depends on the nature of the signals,
1045	      provided by the lower layer, but can include the use of a
1046	      hysteresis function or other statistical mechanisms.

1048	   o  Conversely, for each successful delivery of a packet to a neighbor
1049	      or a destination, if signaled by a lower layer or a transport
1050	      mechanism, or each positive confirmation of the presence of a
1051	      neighbor by way of an external neighbor discovery protocol, MAY be
1052	      interpreted as validation that the corresponding Routing Tuple(s)
1053	      are valid, and their R_valid_time refreshed correspondingly.  Note
1054	      that when refreshing a Routing Tuple corresponding to a
1055	      destination of a data packet, the Routing Tuple corresponding to
1056	      the next hop toward that destination SHOULD also be refreshed.

1058	   Furthermore, a LOADng Router may experience that a route currently
1059	   used for forwarding data packets is no longer operational, and must
1060	   act to either rectify this situation locally (Section 13) or signal
1061	   this situation to the source of the data packets for which delivery
1062	   was unsuccessful (Section 14).

1064	   If a LOADng Router fails to deliver a data packet to a next-hop, it
1065	   MUST generate an RERR message, as specified in Section 14.

1067	10.  Unidirectional Link Handling

1069	   Each LOADng Router MUST monitor the bidirectionality of the links to
1070	   its neighbors and set the R_bidirectional flag of related routing
1071	   tuples when processing Route Replies (RREP).  To this end, one or
1072	   more of the following mechanisms MAY be used (non exhaustive list):

1074	   o  If a lower layer mechanism provides signals, such as when delivery
1075	      to a presumed neighbor LOADng Router fails, this signal MAY be
1076	      used to detect that a link to this neighbor is broken or is
1077	      unidirectional; the LOADng Router MUST then blacklist the neighbor
1078	      (see Section 10.1).

1080	   o  If a mechanism such as NDP [RFC4861] is available, the LOADng
1081	      Router MAY use it.

1083	   o  A LOADng Router MAY use a neighborhood discovery mechanism with
1084	      bidirectionality verification, such as NHDP [RFC6130].

1086	   o  RREP_ACK message exchange, as described in Section 15.

1088	   o  Upper-layer mechanisms, such as transport-layer acknowledgments,
1089	      MAY be used to detect unidirectional or broken links.

1091	   When a LOADng Router detects, via one of these mechanisms, that a
1092	   link to a neighbor LOADng Router is unidirectional or broken, the
1093	   LOADng Router MUST blacklist this neighbor (see Section 10.1).
1094	   Conversely, if a LOADng Router detects via one of these mechanisms
1095	   that a previously blacklisted LOADng Router has a bidirectional link
1096	   to this LOADng Router, it MAY remove it from the blacklist before the
1097	   B_valid_time of the corresponding tuple.

1099	10.1.  Blacklist Usage

1101	   The Blacklist is maintained according to Section 7.3.  When an
1102	   interface of neighbor LOADng Router is detected to have a
1103	   unidirectional link to the LOADng Router, it is blacklisted, i.e., a
1104	   tuple (B_neighbor_address, B_valid_time) is created thus:

1106	   o  B_neighbor_address := the address of the blacklisted neighbor
1107	      LOADng Router interface

1109	   o  B_valid_time := current_time + B_HOLD_TIME

1111	   When a neighbor LOADng Router interface is blacklisted, i.e., when
1112	   there is a corresponding (B_neighbor_address, B_valid_time) tuple in
1113	   the Blacklisted Neighbor Set, it is temporarily not considered as a
1114	   neighbor, and thus:

1116	   o  Every RREQ received from this neighbor LOADng Router interface
1117	      MUST be discarded;

1119	11.  Common Rules for RREQ and RREP Messages

1121	   RREQ and RREP messages, both, supply routes between their recipients
1122	   and the originator of the RREQ or RREP message.  The two message
1123	   types therefore share common processing rules, and differ only in the
1124	   following:

1126	   o  RREQ messages are multicast or broadcast, intended to be received
1127	      by all LOADng Routers in the network, whereas RREP messages are
1128	      all unicast, intended to be received only by LOADng Routers on a
1129	      specific route towards a specific destination.

1131	   o  Receipt of an RREQ message by a LOADng router, which has the
1132	      RREQ.destination address in its Local Interface Set or Destination
1133	      Address Set MUST trigger the procedures for generation of an RREP
1134	      message.

1136	   o  Receipt of an RREP message with RREP.ackrequired set MUST trigger
1137	      generation of an RREP_ACK message.

1139	   For the purpose of the processing description in this section, the
1140	   following additional notation is used:

1142	   received-route-metric  is a variable, representing the route metric,
1143	      as included in the received RREQ or RREP message, see Section 16.

1145	   used-metric-type  is a variable, representing the type of metric used
1146	      for calculating received-route-metric, see Section 16.

1148	   previous-hop  is the address of the LOADng Router, from which the
1149	      RREQ or RREP message was received.

1151	   >  is the comparison operator for sequence numbers, as specified in
1152	      Section 8.

1154	   MSG  is a shorthand for either an RREQ or RREP message, used for when
1155	      accessing message fields in the description of the common RREQ and
1156	      RREP message processing in the following subsections.

1158	   hop-count  is a variable, representing the hop-count, as included in
1159	      the received RREQ or RREP message.

1161	   hop-limit  is a variable, representing the hop-limit, as included in
1162	      the received RREQ or RREP message.

1164	   link-metric  is a variable, representing the link metric between this
1165	      LOADng Router and the LOADng Router from which the RREQ or RREP
1166	      message was received, as calculated by the receiving LOADng
1167	      Router, see Section 16.

1169	   route-metric  is a variable, representing the route metric, as
1170	      included in the received RREQ or RREP message, plus the link-
1171	      metric for the link, over which the RREQ or RREP was received,
1172	      i.e., the total route cost from the originator to this LOADng
1173	      Router.

1175	11.1.  Identifying Invalid RREQ or RREP Messages

1177	   A received RREQ or RREP message is invalid, and MUST be discarded
1178	   without further processing, if any of the following conditions are
1179	   true:

1181	   o  The address length specified by this message (i.e., MSG.addr-
1182	      length + 1) differs from the length of the address(es) of this
1183	      LOADng Router.

1185	   o  The address contained in MSG.originator is an address of this
1186	      LOADng Router.

1188	   o  There is a tuple in the Routing Set where:

1190	      *  R_dest_addr = MSG.originator

1192	      *  R_seq_num > MSG.seq-num

1194	   o  For RREQ messages only, an RREQ MUST be considered invalid if the
1195	      previous-hop is blacklisted (i.e., its address is in a tuple in
1196	      the Blacklisted Neighbor Set, see Section 10.1).

1198	   A LOADng Router MAY recognize additional reasons for identifying that
1199	   an RREQ or RREP message is invalid for processing, e.g., to allow a
1200	   security protocol to perform verification of integrity check values
1201	   and prevent processing of unverifiable RREQ or RREP message by this
1202	   protocol.

1204	11.2.  RREQ and RREP Message Processing

1206	   A received, and valid, RREQ or RREP message is processed as follows:

1208	   1.  Included TLVs are processed/updated according to their
1209	       specification.

1211	   2.  Set the variable hop-count to MSG.hop-count + 1.

1213	   3.  Set the variable hop-limit to MSG.hop-limit - 1.

1215	   4.  If MSG.metric-type is known to this LOADng Router, and if
1216	       MSG.metric-type is not HOP_COUNT, then:

1218	       *  Set the variable used-metric-type to the value of MSG.metric-
1219	          type.

1221	       *  Determine the link metric over the link over which the message
1222	          was received, according to used-metric-type, and set the
1223	          variable link-metric to the calculated value.

1225	       *  Compute the route metric to MSG.originator according to used-
1226	          metric-type by adding link-metric to the received-route-metric
1227	          advertised by the received message, and set the variable
1228	          route-metric to the calculated value.

1230	   5.  Otherwise:

1232	       *  Set the variable used-metric-type to HOP_COUNT.

1234	       *  Set the variable route-metric to MAX_DIST, see Section 16.

1236	       *  Set the variable link-metric to MAX_DIST.

1238	   6.  Find the Routing Tuple (henceforth, Matching Routing Tuple)
1239	       where:

1241	       *  R_dest_addr = MSG.originator

1243	   7.  If no Matching Routing Tuple is found, then create a new Matching
1244	       Routing Tuple (the "reverse route" for RREQ messages or "forward
1245	       route" for RREP messages) with:

1247	       *  R_dest_addr := MSG.originator

1249	       *  R_next_addr := previous-hop

1251	       *  R_metric_type := used-metric-type

1253	       *  R_metric := MAX_DIST
1254	       *  R_hop_count := hop-count

1256	       *  R_seq_num := -1

1258	       *  R_valid_time := current time + R_HOLD_TIME

1260	       *  R_bidirectional := FALSE

1262	       *  R_local_iface_addr := the address of the LOADng Interface
1263	          through which the message was received.

1265	   8.  The Matching Routing Tuple, existing or new, is compared to the
1266	       received RREQ or RREP message:

1268	       1.  If

1270	           +  R_seq_num = MSG.seq-num; AND

1272	           +  R_metric_type = used-metric-type; AND

1274	           +  R_metric > route-metric

1276	           OR

1278	           +  R_seq_num = MSG.seq-num; AND

1280	           +  R_metric_type = used-metric-type; AND

1282	           +  R_metric = route-metric; AND

1284	           +  R_hop_count > hop-count

1286	           OR

1288	           +  R_seq_num = MSG.seq-num; AND

1290	           +  R_metric_type does not equal to used-metric-type; AND

1292	           +  R_metric_type = HOP_COUNT

1294	           OR

1296	           +  R_seq_num < MSG.seq-num

1298	           Then:

1300	           1.  The message is used for updating the Routing Set. The
1301	                Routing Tuple, where:

1303	                -  R_dest_addr = MSG.originator;

1305	                is updated thus:

1307	                -  R_next_addr := previous-hop

1309	                -  R_metric_type = used-metric-type

1311	                -  R_metric := route-metric

1313	                -  R_hop_count := hop-count

1315	                -  R_seq_num := MSG.seq-num

1317	                -  R_valid_time := current time + R_HOLD_TIME

1319	                -  R_bidirectional := TRUE, if the message being
1320	                   processed is an RREP.

1322	           2.  If previous-hop is not equal to MSG.originator, and if
1323	                there is no Matching Routing Tuple in the Routing Set
1324	                with R_dest_addr = previous-hop, create a new Matching
1325	                Routing Tuple with:

1327	                -  R_dest_addr := previous-hop

1329	                -  R_next_addr := previous-hop

1331	           3.  The Routing Tuple with R_dest_addr = previous-hop,
1332	                existing or new, is updated as follows

1334	                -  R_metric_type := used-metric-type

1336	                -  R_metric := link-metric

1338	                -  R_hop_count := 1

1340	                -  R_seq_num := -1

1342	                -  R_valid_time := current time + R_HOLD_TIME

1344	                -  R_bidirectional := TRUE, if the processed message is
1345	                   an RREP, otherwise FALSE.

1347	                -  R_local_iface_addr := the address of the LOADng
1348	                   Interface through which the message was received.

1350	       2.  Otherwise, if the message is an RREQ, it is not processed
1351	           further and is not considered for forwarding.  If it is an
1352	           RREP and if RREP.ackrequired is set, an RREP_ACK message MUST
1353	           be sent to the previous-hop, according to Section 15.2.  The
1354	           RREP is not considered for forwarding.

1356	12.  Route Requests (RREQs)

1358	   Route Requests (RREQs) are generated by a LOADng Router when it has
1359	   data packets to deliver to a destination, where the data packet
1360	   source is local to that LOADng Router (i.e., is an address in the
1361	   Local Interface Set or Destination Address Set of that LOADng
1362	   Router), but for which the LOADng router has no matching tuple in the
1363	   Routing Set. Furthermore, if there is a matching tuple in the Routing
1364	   Set with the R_bidirectional set to FALSE, and the parameter
1365	   USE_BIDIRECTIONAL_LINK_ONLY of the interface with
1366	   R_local_iface_address equals TRUE, an RREQ MUST be generated.

1368	   After originating an RREQ, a LOADng Router waits for a corresponding
1369	   RREP.  If no such RREP is received within 2*NET_TRAVERSAL_TIME
1370	   milliseconds, the LOADng Router MAY issue a new RREQ for the sought
1371	   destination (with an incremented seq_num) up to a maximum of
1372	   RREQ_RETRIES times.  Two consequent RREQs generated on an interface
1373	   of a LOADng Router SHOULD be separated at least RREQ_MIN_INTERVAL.

1375	12.1.  RREQ Generation

1377	   An RREQ message is generated according to Section 6 with the
1378	   following content:

1380	   o  RREQ.addr-length set to the length of the address, as specified in
1381	      Section 6;

1383	   o  RREQ.metric-type set to the desired metric type;

1385	   o  RREQ.route-metric := 0.

1387	   o  RREQ.seq-num set to the next unused sequence number, maintained by
1388	      this LOADng Router;

1390	   o  RREQ.hop-count := 0;

1392	   o  RREQ.hop-limit := MAX_HOP_LIMIT;

1394	   o  RREQ.destination := the address to which a route is sought;

1396	   o  RREQ.originator := one address of the LOADng Interface of the
1397	      LOADng Router that generates the RREQ.  If the LOADng Router is
1398	      generating RREQ on behalf of a host connected to this LOADng
1399	      Router, the source address of the data packet, generated by that
1400	      host, is used;

1402	12.2.  RREQ Processing

1404	   The variables hop-count and hop-limit have been updated in
1405	   Section 11.2 (when processing the message) and are used in this
1406	   section.  On receiving an RREQ message, a LOADng Router MUST process
1407	   the message according to this section:

1409	   1.  If the message is invalid for processing, as defined in
1410	       Section 11.1, the message MUST be discarded without further
1411	       processing.  The message is not considered for forwarding.

1413	   2.  Otherwise, the message is processed according to Section 11.2.

1415	   3.  If RREQ.destination is listed in I_local_iface_addr_list of any
1416	       Local Interface Tuple, or corresponds to D_address of any
1417	       Destination Address Tuple of this LOADng Router, the RREP
1418	       generation process in Section 13.1 MUST be applied.  The RREQ is
1419	       not considered for forwarding.

1421	   4.  Otherwise, if hop-count is less than MAX_HOP_COUNT and hop-limit
1422	       is greater than 0, the message is considered for forwarding
1423	       according to Section 12.3.

1425	12.3.  RREQ Forwarding

1427	   The variables used-metric type, hop-count, hop-limit and route-metric
1428	   have been updated in Section 11.2 (when processing the message) and
1429	   are used in this section to update the content of the message to be
1430	   forwarded.  An RREQ, considered for forwarding, MUST be updated as
1431	   follows, prior to it being transmitted:

1433	   1.  RREQ.metric-type := used-metric-type (as set in Section 11.2)

1435	   2.  RREQ.route-metric := route-metric (as set in Section 11.2)

1437	   3.  RREQ.hop-count := hop-count (as set in Section 11.2)

1439	   4.  RREQ.hop-limit := hop-limit (as set in Section 11.2)

1441	   An RREQ MUST be forwarded according to the flooding operation,
1442	   specified for the network.  This MAY be by way of classic flooding, a
1443	   reduced relay set mechanism such as [RFC6621], or any other
1444	   information diffusion mechanism such as [RFC6206].  Care must be
1445	   taken that NET_TRAVERSAL_TIME is chosen so as to accommodate for the
1446	   maximum time that may take for an RREQ to traverse the network,
1447	   accounting for in-router delays incurring due to or imposed by such
1448	   algorithms.

1450	12.4.  RREQ Transmission

1452	   RREQs, whether initially generated or forwarded, are sent to all
1453	   neighbor LOADng Routers through all interfaces in the Local Interface
1454	   Set.

1456	   When an RREQ is transmitted, all receiving LOADng Routers will
1457	   process the RREQ message and as a consequence consider the RREQ
1458	   message for forwarding at the same, or at almost the same, time.  If
1459	   using data link and physical layers that are subject to packet loss
1460	   due to collisions, such RREQ messages SHOULD be jittered as described
1461	   in [RFC5148], using RREQ_MAX_JITTER, in order to avoid such losses.

1463	13.  Route Replies (RREPs)

1465	   Route Replies (RREPs) are generated by a LOADng Router in response to
1466	   an RREQ (henceforth denoted "corresponding RREQ"), and are sent by
1467	   the LOADng Router which has, in either its Destination Address Set or
1468	   in its Local Interface Set, the address from RREQ.destination.  RREPs
1469	   are sent, hop by hop, in unicast towards the originator of the RREQ,
1470	   in response to which the RREP was generated, along the Reverse Route
1471	   installed by that RREQ.  A LOADng Router, upon forwarding an RREP,
1472	   installs the Forward Route towards the RREP.destination.

1474	   Thus, with forwarding of RREQs installing the Reverse Route and
1475	   forwarding of RREPs installing the Forward Route, bi-directional
1476	   routes are provided between the RREQ.originator and RREQ.destination.

1478	13.1.  RREP Generation

1480	   At least one RREP MUST be generated in response to a (set of)
1481	   received RREQ messages with identical (RREP.originator, RREP.seq-
1482	   num).  An RREP MAY be generated immediately as a response to each
1483	   RREQ processed, in order to provide shortest possible route
1484	   establishment delays, or MAY be generated after a certain delay after
1485	   the arrival of the first RREQ, in order to use the "best" received
1486	   RREQ (e.g., received over the lowest-cost route) but at the expense
1487	   of longer route establishment delays.  A LOADng Router MAY generate
1488	   further RREPs for subsequent RREQs received with the same
1489	   (RREP.originator, RREP.seq-num) pairs, if these indicate a better
1490	   route, at the expense of additional control traffic being generated.
1491	   In all cases, however, the content of an RREP is as follows:

1493	   o  RREP.addr-length set to the length of the address, as specified in
1494	      Section 6;

1496	   o  RREP.seq-num set to the next unused sequence number, maintained by
1497	      this LOADng Router;

1499	   o  RREP.metric-type set to the same value as the RREQ.metric-type in
1500	      the corresponding RREQ if the metric type is known to the router.
1501	      Otherwise, RREP.metric-type is set to HOP_COUNT;

1503	   o  RREP.route-metric := 0

1505	   o  RREP.hop-count := 0;

1507	   o  RREP.hop-limit := MAX_HOP_LIMIT;

1509	   o  RREP.destination := the address to which this RREP message is to
1510	      be sent; this corresponds to the RREQ.originator from the RREQ
1511	      message, in response to which this RREP message is generated;

1513	   o  RREP.originator := the address of the LOADng Router, generating
1514	      the RREP.  If the LOADng Router is generating an RREP on behalf of
1515	      the hosts connected to it, or on behalf of one of the addresses
1516	      contained in the LOADng Routers Destination Address Set, the host
1517	      address is used.

1519	   The RREP so generated is transmitted according to Section 13.4.

1521	13.2.  RREP Processing

1523	   The variables hop-count and hop-limit have been updated in
1524	   Section 11.2 (when processing the message) and are used in this
1525	   section.  On receiving an RREP message, a LOADng Router MUST process
1526	   the message according to this section:

1528	   1.  If the message is invalid for processing, as defined in
1529	       Section 11.1, the message MUST be discarded without further
1530	       processing.  The message is not considered for forwarding.

1532	   2.  Otherwise, the message is processed according to Section 11.2.

1534	   3.  If RREP.ackrequired is set, an RREP_ACK message MUST be sent to
1535	       the previous-hop, according to Section 15.2.

1537	   4.  If hop-count is equal to MAX_HOP_COUNT or hop-limit is equal to
1538	       0, the message is not considered for forwarding.

1540	   5.  Otherwise, if RREP.destination is not listed in
1541	       I_local_iface_addr_list of any Local Interface Tuple and does not
1542	       correspond to D_address of any Destination Address Tuple of this
1543	       LOADng Router, the RREP message is considered for forwarding
1544	       according to Section 13.3.

1546	13.3.  RREP Forwarding

1548	   The variables used-metric type, hop-count, hop-limit and route-metric
1549	   have been updated in Section 11.2 (when processing the message) and
1550	   are used in this section to update the content of the message to be
1551	   forwarded.  An RREP message, considered for forwarding, MUST be
1552	   updated as follows, prior to it being transmitted:

1554	   1.  RREP.metric-type := used-metric-type (as set in Section 11.2)

1556	   2.  RREP.route-metric := route-metric (as set in Section 11.2)

1558	   3.  RREP.hop-count := hop-count (as set in Section 11.2)

1560	   4.  RREP.hop-limit := hop-limit (as set in Section 11.2)

1562	   5.  The RREP is transmitted, according to Section 13.4.

1564	   The RREP message is then unicast to the next hop towards
1565	   RREP.destination.

1567	13.4.  RREP Transmission

1569	   An RREP is, ultimately, destined for the LOADng Router which has the
1570	   address listed in the RREP.destination field in either of its Local
1571	   Interface Set, or in its Destination Address Set. The RREP is
1572	   forwarded in unicast towards that LOADng Router.  The RREP MUST,
1573	   however, be transmitted so as to allow it to be processed in each
1574	   intermediate LOADng Router to:

1576	   o  Install proper forward routes; AND

1578	   o  Permit that RREP.hop-count be updated to reflect the route.

1580	   RREP Transmission is accomplished by the following procedure:

1582	   1.  Find the Routing Tuple (henceforth, the "Matching Routing Tuple")
1583	       in the Routing Set, where:

1585	       *  R_dest_addr = RREP.destination

1587	   2.  Find the Local Interface Tuple (henceforth, "Matching Interface
1588	       Tuple), where:

1590	       *  I_local_iface_addr_list contains R_local_iface_addr from the
1591	          Matching Routing Tuple

1593	   3.  If RREP_ACK_REQUIRED is set for the LOADng Interface, identified
1594	       by the Matching Interface Tuple:

1596	       *  Create a new Pending Acknowledgment Tuple with:

1598	          +  P_next_hop := R_next_addr from the Matching Routing Tuple

1600	          +  P_originator := RREP.originator

1602	          +  P_seq_num := RREP.seq-num

1604	          +  P_ack_received := FALSE

1606	          +  P_ack_timeout := current_time + RREP_ACK_TIMEOUT

1608	       *  Set RREP.ackrequired to true

1610	   4.  Otherwise:

1612	       *  Set RREP.ackrequired to false.

1614	   5.  The RREP is transmitted over the LOADng Interface, identified by
1615	       the Matching Interface Tuple to the neighbor LOADng Router,
1616	       identified by R_next_addr from the Matching Routing Tuple.

1618	   When a Pending Acknowledgement Tuple expires, if P_ack_received =
1619	   FALSE, the P_next_hop address MUST be blacklisted by creating a
1620	   Blacklisted Neighbor Tuple according to Section 7.3

1622	14.  Route Errors (RERRs)

1624	   If a LOADng Router fails to deliver a data packet to a next hop or a
1625	   destination, and if neither the source nor destination address of
1626	   that data packet belongs to the Destination Address Set of that
1627	   LOADng Router, it MUST generate a Route Error (RERR).  This RERR MUST
1628	   be sent along the Reverse Route towards the source of the data packet
1629	   for which delivery was unsuccessful (to the last LOADng Router along
1630	   the Reverse Route, if the data packet was originated by a host behind
1631	   that LOADng Router).

1633	   The following definition is used in this section:

1635	   o  "EXPIRED" indicates that a timer is set to a value clearly
1636	      preceding the current time (e.g., current time - 1).

1638	14.1.  Identifying Invalid RERR Messages

1640	   A received RERR is invalid, and MUST be discarded without further
1641	   processing, if any of the following conditions are true:

1643	   o  The address length specified by this message (i.e., RERR.addr-
1644	      length + 1) differs from the length of the address(es) of this
1645	      LOADng Router.

1647	   o  The address contained in RERR.originator is an address of this
1648	      LOADng Router.

1650	   A LOADng Router MAY recognize additional reasons, external to this
1651	   specification, for identifying that an RERR message is invalid for
1652	   processing, e.g., to allow a security protocol to perform
1653	   verification of signatures and prevent processing of unverifiable
1654	   RERR message by this protocol.

1656	14.2.  RERR Generation

1658	   A packet with an RERR message is generated by the LOADng Router,
1659	   detecting the link breakage, with the following content:

1661	   o  RERR.error-code := the error code corresponding to the event
1662	      causing the RERR to be generated, from among those recorded in
1663	      Table 1;

1665	   o  RERR.addr-length := the length of the address, as specified in
1666	      Section 6;

1668	   o  RERR.unreachableAddress := the destination address from the
1669	      unsuccessfully delivered data packet.

1671	   o  RERR.originator := one address of the LOADng Interface of the
1672	      LOADng Router that generates the RERR.

1674	   o  RERR.destination := the source address from the unsuccessfully
1675	      delivered data packet, towards which the RERR is to be sent.

1677	   o  RERR.hop-limit := MAX_HOP_LIMIT;

1679	14.3.  RERR Processing

1681	   For the purpose of the processing description below, the following
1682	   additional notation is used:

1684	   previous-hop  is the address of the LOADng Router, from which the
1685	      RERR was received.

1687	   hop-limit  is a variable, representing the hop-limit, as included in
1688	      the received RERR message.

1690	   Upon receiving an RERR, a LOADng Router MUST perform the following
1691	   steps:

1693	   1.  If the RERR is invalid for processing, as defined in
1694	       Section 14.1, the RERR MUST be discarded without further
1695	       processing.  The message is not considered for forwarding.

1697	   2.  Included TLVs are processed/updated according to their
1698	       specification.

1700	   3.  Set the variable hop-limit to RERR.hop-limit - 1.

1702	   4.  Find the Routing Tuple (henceforth "matching Routing Tuple") in
1703	       the Routing Set where:

1705	       *  R_dest_addr = RERR.unreachableAddress

1707	       *  R_next_addr = previous-hop

1709	   5.  If no matching Routing Tuple is found, the RERR is not processed
1710	       further, and is not considered for forwarding.

1712	   6.  Otherwise, if one matching Routing Tuple is found:

1714	       1.  If RERR.errorcode is 0 ("No available route", as specified in
1715	           Section 19.1), this matching Routing Tuple is updated as
1716	           follows:

1718	           +  R_valid_time := EXPIRED

1720	           Extensions to this specification MAY define additional error
1721	           codes in the Error Code IANA registry, and MAY insert
1722	           processing rules here for RERRs with that error code.

1724	       2.  If hop-limit is greater than 0, the RERR message is
1725	           considered for forwarding, as specified in Section 14.4

1727	14.4.  RERR Forwarding

1729	   An RERR is, ultimately, destined for the LOADng Router which has, in
1730	   either its Destination Address Set or in its Local Interface Set, the
1731	   address from RERR.originator.

1733	   An RERR, considered for forwarding is therefore processed as follows:

1735	   1.  RERR.hop-limit := hop-limit (as set in Section 14.3)

1737	   2.  Find the Destination Address Tuple (henceforth, matching
1738	       Destination Address Tuple) in the Destination Address Set where:

1740	       *  D_address = RERR.destination

1742	   3.  If one or more matching Destination Address Tuples are found, the
1743	       RERR message is discarded and not retransmitted, as it has
1744	       reached the final destination.

1746	   4.  Otherwise, find the Local Interface Tuple (henceforth, matching
1747	       Local Interface Tuple) in the Local Interface Set where:

1749	       *  I_local_iface_addr_list contains RERR.destination.

1751	   5.  If a matching Local Interface Tuple is found, the RERR message is
1752	       discarded and not retransmitted, as it has reached the final
1753	       destination.

1755	   6.  Otherwise, if no matching Destination Address Tuples or Local
1756	       Interface Tuples are found, the RERR message is transmitted
1757	       according to Section 14.5.

1759	14.5.  RERR Transmission

1761	   An RERR is, ultimately, destined for the LOADng Router which has the
1762	   address listed in the RERR.destination field in either of its Local
1763	   Interface Set, or in its Destination Address Set. The RERR is
1764	   forwarded in unicast towards that LOADng Router.  The RERR MUST,
1765	   however, be transmitted so as to allow it to be processed in each
1766	   intermediate LOADng Router to:

1768	   o  Allow intermediate LOADng Routers to update their Routing Sets,
1769	      i.e., remove tuples for this destination.

1771	   RERR Transmission is accomplished by the following procedure:

1773	   1.  Find the Routing Tuple (henceforth, the "Matching Routing Tuple")
1774	       in the Routing Set, where:

1776	       *  R_dest_addr = RERR.destination

1778	   2.  Find the Local Interface Tuple (henceforth, "Matching Interface
1779	       Tuple), where:

1781	       *  I_local_iface_addr_list contains R_local_iface_addr from the
1782	          Matching Routing Tuple

1784	   3.  The RERR is transmitted over the LOADng Interface, identified by
1785	       the Matching Interface Tuple to the neighbor LOADng Router,
1786	       identified by R_next_addr from the Matching Routing Tuple.

1788	15.  Route Reply Acknowledgments (RREP_ACKs)

1790	   A LOADng Router MUST signal in a transmitted RREP that it is
1791	   expecting an RREP_ACK, by setting RREP.ackrequired flag in the RREP.
1792	   When doing so, the LOADng Router MUST also add a tuple (P_next_hop,
1793	   P_originator, P_seq_num, P_ack_timeout) to the Pending Acknowledgment
1794	   Set, and set P_ack_timeout to current_time + RREP_ACK_TIMEOUT, as
1795	   described in Section 13.4.

1797	   The following definition is used in this section:

1799	   o  "EXPIRED" indicates that a timer is set to a value clearly
1800	      preceding the current time (e.g., current_time - 1).

1802	15.1.  Identifying Invalid RREP_ACK Messages

1804	   A received RREP_ACK is invalid, and MUST be discarded without further
1805	   processing, if any of the following conditions are true:

1807	   o  The address length specified by this message (i.e., RREP_ACK.addr-
1808	      length + 1) differs from the length of the address(es) of this
1809	      LOADng Router.

1811	   A LOADng Router MAY recognize additional reasons, external to this
1812	   specification, for identifying that an RREP_ACK message is invalid
1813	   for processing, e.g., to allow a security protocol to perform
1814	   verification of signatures and prevent processing of unverifiable
1815	   RREP_ACK message by this protocol.

1817	15.2.  RREP_ACK Generation

1819	   Upon reception of an RREP message with the RREP.ackrequired flag set,
1820	   a LOADng Router MUST generate at least one RREP_ACK and send this
1821	   RREP_ACK in unicast to the neighbor which originated the RREP.

1823	   An RREP_ACK message is generated by a LOADng Router with the
1824	   following content:

1826	   o  RREP_ACK.addr-length := the length of the address, as specified in
1827	      Section 6;

1829	   o  RREP_ACK.seq-num := the value of the RREP.seq-num field of the
1830	      received RREP;

1832	   o  RREP_ACK.destination := RREP.originator of the received RREP.

1834	15.3.  RREP_ACK Processing

1836	   On receiving an RREP_ACK from a LOADng neighbor LOADng Router, a
1837	   LOADng Router MUST do the following:

1839	   1.  If the RREP_ACK is invalid for processing, as defined in
1840	       Section 15.1, the RREP_ACK MUST be discarded without further
1841	       processing.

1843	   2.  Find the Routing Tuple (henceforth, Matching Routing Tuple)
1844	       where:

1846	       *  R_dest_addr = previous-hop;

1848	       The Matching Routing Tuple is updated as follows:

1850	       *  R_bidirectional := TRUE

1852	   3.  If a Pending Acknowledgement Tuple (henceforth, Matching Pending
1853	       Acknowledgement Tuple) exists, where:

1855	       *  P_next_hop is the address of the LOADng Router from which the
1856	          RREP_ACK was received.

1858	       *  P_originator = RREP_ACK.destination

1860	       *  P_seq_num = RREP_ACK.seq-num

1862	       Then the RREP has been acknowledged.  The Matching Pending
1863	       Acknowledgement Tuple is updated as follows:

1865	       *  P_ack_received := TRUE

1867	       *  P_ack_timeout := EXPIRED

1869	15.4.  RREP_ACK Forwarding

1871	   An RREP_ACK is intended only for a specific direct neighbor, and MUST
1872	   NOT be forwarded.

1874	15.5.  RREP_ACK Transmission

1876	   An RREP_ACK is transmitted, in unicast, to the neighbor LOADng Router
1877	   from which the RREP was received.

1879	16.  Metrics

1881	   This specification enables the use of different metrics for when
1882	   calculating route metrics.

1884	   Metrics as defined in LOADng are additive, and the routes that are to
1885	   be created are those with the minimum sum of the metrics along that
1886	   route.

1888	16.1.  Specifying New Metrics

1890	   When defining a metric, the following considerations SHOULD be taken
1891	   into consideration:

1893	   o  The definition of the R_metric field, as well as the value of
1894	      MAX_DIST.

1896	17.  Implementation Status

1898	   This section records the status of known implementations of the
1899	   protocol defined by this specification, and is based on a proposal
1900	   described in [I-D.sheffer-running-code].  According to
1901	   [I-D.sheffer-running-code], "this will allow reviewers and working
1902	   groups to assign due consideration to documents that have the benefit
1903	   of running code and potentially reward the documented protocols by
1904	   treating the documents with implementations preferentially".

1906	   In the following subsections, each publicly-known implementation of
1907	   LOADng is listed.  There are currently four publicly-known
1908	   implementations of LOADng.  These have been tested for
1909	   interoperability in at least three interop events, as described in
1910	   [I-D.loadng-interop-report].

1912	17.1.  Implementation of Ecole Polytechnique

1914	   This implementation is developed by the Networking Group at Ecole
1915	   Polytechnique.  It can run over real network interfaces, and can also
1916	   be integrated with the network simulator NS2.  It is a Java
1917	   implementation, and can be used on any platform that includes a Java
1918	   virtual machine.

1920	   The implementation has been maintained since the 00 revision of
1921	   LOADng, and is quite mature.  It has been tested in interoperability
1922	   events with other implementations (as described in
1923	   [I-D.loadng-interop-report]), and in large-scale network simulations
1924	   with up to 1000 routers.  There have been several scientific
1925	   publications based on this implementation, such as [IEEE_VTC2012]
1926	   [IEEE_WiCom2012] [IEEE_ICWITS2012].

1928	   All the protocol functions of this revision (-08) of the
1929	   specification, including RREQ/RREP/RREP-ACK/RERR generation,
1930	   processing, forwarding and transmission, as well as blacklisting, are
1931	   implemented.

1933	   The latest implementation conforms to the LOADng-07 revision as
1934	   documented in this specification.  This software is currently closed
1935	   source.

1937	17.2.  Implementation of Fujitsu Laboratories of America

1939	   This implementation is developed by Fujitsu Laboratories of America.
1940	   It is a Java implementation, structured in multiple separate modules,
1941	   notably a [RFC5444] generator and parser, and integration module in
1942	   the network simulator Ns-2, a kernel module for integrating the
1943	   implementation in a Linux kernel (not yet completed), and the
1944	   protocol core.

1946	   The implementation is mature and has been tested both in
1947	   interoperability tests with other implementations
1948	   [I-D.loadng-interop-report], as well as large-scale simulations with
1949	   hundreds of routers.  The implementation is not currently used in
1950	   deployments.  The implementation supports all LOADng functions (RREQ,
1951	   RREP, RREP-ACK generation, processing, forwarding and transmission),
1952	   and conforms to the LOADng-06 specification.  The software is
1953	   currently closed source.

1955	17.3.  Implementation of Hitachi Yokohama Research Laboratory - 1

1957	   This implementation is developed by Hitachi, Ltd. Yokohama Research
1958	   Laboratory.  It can run over real embedded devices.  It is a C
1959	   implementation.  The implementation is maintained since the 00
1960	   revision of LOADng.  It was tested in the first interoperability
1961	   event with other implementations, as described in
1962	   [I-D.loadng-interop-report].

1964	   This implementation is alpha version, mainly for performance test and
1965	   evaluations.  All the functions of the protocol, including RREQ/RREP/
1966	   RREP-ACK/RERR generation, processing, forwarding and transmission,
1967	   blacklisting, have been implemented.  Also a RFC5444 generator and
1968	   parser have been implemented.  The latest implementation conforms to
1969	   LOADng-06 revision.  This software is currently closed source.

1971	17.4.  Implementation of Hitachi Yokohama Research Laboratory -2

1973	   This implementation is developed by Hitachi, Ltd. Yokohama Research
1974	   Laboratory.  It can run over real network interface, and can also be
1975	   integrated with network simulator NS2.  It is a C++ implementation.

1977	   The implementation is mature and maintained since the 00 revision of
1978	   LOADng.  It was tested in large-scale network simulations up to 500
1979	   routers.

1981	   All the functions of the protocol, including RREQ/RREP/RREP-ACK/RERR
1982	   generation, processing, forwarding and transmission, blacklisting,
1983	   have been implemented.  The latest implementation conforms to the
1984	   LOADng-05 revision.  This software is currently closed source.

1986	18.  Security Considerations

1988	   Currently, this protocol does not specify any special security
1989	   measures.  As a reactive routing protocol, this protocol is a
1990	   potential target for various attacks.  Various possible
1991	   vulnerabilities are discussed in this section.

1993	   By way of (i) enabling inclusion of TLVs and (ii) permitting that
1994	   LOADng recognizes external reasons for rejecting RREQ, RREP, RREP_ACK
1995	   and RERR messages, development of security measures, appropriate for
1996	   a given deployment, is however supported.  This architecture is a
1997	   result of the observation that with respect to security in LOADng
1998	   routed networks, "one size rarely fits all".  This, as LOADng
1999	   deployment domains have varying security requirements ranging from
2000	   "unbreakable" to "virtually none", depending on, e.g., physical
2001	   access to the network, or on security available on other layers.  The
2002	   virtue of this approach is that LOADng routing protocol
2003	   specifications (and implementations) can remain "generic", with
2004	   extensions providing proper deployment-domain specific security
2005	   mechanisms.

2007	18.1.  Confidentiality

2009	   This protocol floods Route Requests (RREQs) to all the LOADng Routers
2010	   in the network, when there is traffic to deliver to a given
2011	   destination.  Hence, if used in an unprotected network (such as an
2012	   unprotected wireless network):

2014	   o  Part of the network topology is revealed to anyone who listens,
2015	      specifically (i) the identity (and existence) of the source LOADng
2016	      Router; (ii) the identity of the destination; and (iii) the fact
2017	      that a path exists between the source LOADng Router and the LOADng
2018	      Router from which the RREQ was received.

2020	   o  The network traffic patterns are revealed to anyone who listens to
2021	      the LOADng control traffic, specifically which pairs of devices
2022	      communicate.  If, for example, a majority of traffic originates
2023	      from or terminates in a specific LOADng Router, this may indicate
2024	      that this LOADng Router has a central role in the network.

2026	   This protocol also unicasts Route Replies (RREPs) from the
2027	   destination of an RREQ to the originator of that same RREQ.  Hence,
2028	   if used in an unprotected network (such as an unprotected wireless
2029	   network):

2031	   o  Part of the network topology is revealed to anyone who is near or
2032	      on the unicast path of the RREP (such as within radio range of
2033	      LOADng Routers on the unicast path in an unprotected wireless
2034	      network), specifically that a path from the originator (of the
2035	      RREP) to the destination (of the RREP) exists.

2037	   Finally, this protocol unicasts Route Errors (RERRs) when an
2038	   intermediate LOADng Router detects that the path from a source to a
2039	   destination is no longer available.  Hence, if used in an unprotected
2040	   network (such as an unprotected wireless network):

2042	   o  A disruption of the network topology is revealed to anyone who is
2043	      near or on the unicast path of the RERR (such as within radio
2044	      range of LOADng Routers on the unicast path in an unprotected
2045	      wireless network), specifically that a path from the originator
2046	      (of the RERR) to the destination (of the RERR) has been disrupted.

2048	   This protocol signaling behavior enables, for example, an attacker to
2049	   identify central devices in the network (by monitoring RREQs) so as
2050	   to target an attack, and (by way of monitoring RERRs) to measure the
2051	   success of an attack.

2053	18.2.  Integrity

2055	   A LOADng Router injects topological information into the network by
2056	   way of transmitting RREQ and RREP messages, and removes installed
2057	   topological information by way of transmitting RERR messages.  If
2058	   some LOADng Routers for some reason, malice or malfunction, inject
2059	   invalid control traffic, network integrity may be compromised.
2060	   Therefore, message authentication is recommended.

2062	   Different such situations may occur, for instance:

2064	   1.  A LOADng Router generates RREQ messages, pretending to be another
2065	       LOADng Router;

2067	   2.  A LOADng Router generates RREP messages, pretending to be another
2068	       LOADng Router;

2070	   3.  A LOADng Router generates RERR messages, pretending to be another
2071	       LOADng Router;

2073	   4.  A LOADng Router generates RERR messages, indicating that a link
2074	       on a path to a destination is broken;

2076	   5.  A LOADng Router forwards altered control messages;

2078	   6.  A LOADng Router does not forward control messages;

2080	   7.  A LOADng Router forwards RREPs and RREQs, but does not forward
2081	       unicast data traffic;

2083	   8.  A LOADng Router "replays" previously recorded control messages
2084	       from another LOADng Router.

2086	   Authentication of the originator LOADng Router for control messages
2087	   (for situations 1, 2 and 3) and on individual links announced in the
2088	   control message (for situation 2 and 4) may be used as a
2089	   countermeasure.  However, to prevent routers from repeating old (and
2090	   correctly authenticated) information (situation 8), temporal
2091	   information is required, requiring a router to positively identify
2092	   such a delayed message.

2094	   In general, integrity check values and other required security
2095	   information may be transmitted as a separate Message Type, or
2096	   signatures and security information may be transmitted within the
2097	   control messages, using the TLV mechanism.  Either option permits
2098	   that "secured" and "unsecured" routers can coexist in the same
2099	   network, if desired.

2101	   Specifically, if LOADng is used on the IP layer, the authenticity of
2102	   entire control messages can be established through employing IPsec
2103	   authentication headers, whereas authenticity of individual links
2104	   (situations 2 and 4) require additional security information to be
2105	   distributed.

2107	18.3.  Channel Jamming and State Explosion

2109	   A reactive protocol, LOADng control messages are generated in
2110	   response to network events.  For RREQs, such an event is that a data
2111	   packet is present in a router which does not have a route to the
2112	   destination of the data packet, or that the router receives an RERR
2113	   message, invalidating a route.  For RREPs, such an event is receipt
2114	   of an RREQ corresponding to a destination owned by the LOADng Router.
2115	   A router, forwarding an RREQ or an RREP records state, for the
2116	   reverse and forward routes, respectively.  If some routers for some
2117	   reason, malice or malfunction, generates excessive RREQ, RREP or
2118	   RERRs, otherwise correctly functioning LOADng Routers may fall victim
2119	   to either "indirect jamming" (being "tricked" into generating
2120	   excessive control traffic) or an explosion in the state necessary for
2121	   maintaining protocol state (potentially, exhausting the available
2122	   memory resources).

2124	   Different such situations may occur, for instance:

2126	   1.  A router, within a short time, generates RREQs to an excessive
2127	       amount of destinations in the network (possibly all destinations,
2128	       possibly even destinations not present in the network), causing
2129	       intermediate routers to allocate state for the forward routes.

2131	   2.  A router generates excessively frequent RREQs to the same
2132	       (existing) destination, causing the corresponding LOADng Router
2133	       to generate excessive RREPs.

2135	   3.  A router generates RERRs for a destination to the source LOADng
2136	       Router for traffic to that destination, causing that LOADng
2137	       Router to flood renewed RREQs.

2139	   For situation 1, the state required for recording forward and/or
2140	   reverse routes may exceed the memory available in the intermediate
2141	   LOADng Routers - to the detriment of being able of recording state
2142	   for other routes.  This, in particular, if a LOADng Router generates
2143	   RREQs for destinations "not present in the network".

2145	   A router which, within a short time, generates RREPs to an excessive
2146	   amount of destinations in the network (possibly all destinations,
2147	   possibly even destinations not present in the network), will not have
2148	   the same network-wide effect: an intermediate router receiving an
2149	   RREP for a destination for which no reverse route exists will neither
2150	   attempt forwarding the RREP nor allocate state for the forward route.

2152	   For situations 1, 2, and 3, a possible countermeasure is to rate-
2153	   limit the number of control messages that a LOADng Router forwards on
2154	   behalf of another LOADng Router.  Such a rate limit should take into
2155	   consideration the expected normal traffic for a given LOADng
2156	   deployment.  Authentication may furthermore be used so as to prohibit
2157	   a LOADng Router from forwarding control traffic from any non-
2158	   authenticated router (with the assumption being that an authenticated
2159	   router is not expected to exhibit such rogue behavior).

2161	18.4.  Interaction with External Routing Domains

2163	   This protocol does provide a basic mechanism for a LOADng Router to
2164	   be able to discover routes to external routing domains: a LOADng
2165	   Router configured to "own" a given set of addresses will respond to
2166	   RREQs for destinations with these addresses, and can - by whatever
2167	   protocols governing the routing domain wherein these addresses exist
2168	   - provide paths to these addresses.

2170	   When operating routers connecting a LOADng domain to an external
2171	   routing domain, destinations inside the LOADng domain can be injected
2172	   into the external domain, if the routing protocol governing that
2173	   domain so permits.  Care MUST be taken to not allow potentially
2174	   insecure and untrustworthy information to be injected into the
2175	   external domain.

2177	   In case LOADng is used on the IP layer, a RECOMMENDED way of
2178	   extending connectivity from an external routing domain to a LOADng
2179	   routed domain is to assign an IP prefix (under the authority of the
2180	   routers/gateways connecting the LOADng routing domain with the
2181	   external routing domain) exclusively to that LOADng routing domain,
2182	   and to statically configure gateways to advertise routes for that
2183	   prefix into the external domain.  Within the LOADng domain, gateways
2184	   SHOULD only generate RREPs for destinations which are not part of
2185	   that prefix; this is in particularly important if a gateway otherwise
2186	   provides connectivity to "a default route".

2188	19.  LOADng Specific IANA Considerations

2190	19.1.  Error Codes

2192	   IANA is requested to create a new registry for Error Codes, with
2193	   initial assignments and allocation policies as specified in Table 1.

2195	           +---------+--------------------+-------------------+
2196	           |   Code  | Description        | Allocation Policy |
2197	           +---------+--------------------+-------------------+
2198	           |    0    | No available route |                   |
2199	           |  1-251  | Unassigned         | Expert Review     |
2200	           | 252-255 | Unassigned         | Experimental Use  |
2201	           +---------+--------------------+-------------------+
2202	                           Table 1: Error Codes

2204	20.  Contributors

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

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

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

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

2215	   o  Kenneth Garey, Maxim Integrated Products, USA,
2216	      <kenneth.garey@maxim-ic.com>

2218	   o  Ulrich Herberg, Fujitsu Laboratories of America, USA
2219	      <ulrich.herberg@us.fujitsu.com>

2221	   o  Yuichi Igarashi, Hitachi Ltd, Yokohama Research Laboratory, Japan,
2222	      <yuichi.igarashi.hb@hitachi.com>

2224	   o  Cedric Lavenu, EDF R&D, France, <cedric-2.lavenu@edf.fr>

2226	   o  Afshin Niktash, Maxim Integrated Products, USA,
2227	      <afshin.niktash@maxim-ic.com>

2229	   o  Charles E. Perkins, Futurewei Inc, USA, <charliep@computer.org>

2231	   o  Hiroki Satoh, Hitachi Ltd, Yokohama Research Laboratory, Japan,
2232	      <hiroki.satoh.yj@hitachi.com>

2234	   o  Thierry Lys, ERDF, France, <thierry.lys@erdfdistribution.fr>

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

2238	21.  Acknowledgments

2240	   The authors would like to acknowledge the team behind AODV [RFC3561].
2241	   The authors would also like to acknowledge the efforts of K. Kim
2242	   (picosNet Corp/Ajou University), S. Daniel Park (Samsung
2243	   Electronics), G. Montenegro (Microsoft Corporation), S. Yoo (Ajou
2244	   University) and N. Kushalnagar (Intel Corp.) for their work on an
2245	   initial version of a specification, from which this protocol is
2246	   derived.

2248	22.  References
2249	22.1.  Normative References

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

2255	   [RFC5444]                    Clausen, T., Dean, J., Dearlove, C., and
2256	                                C. Adjih, "Generalized Mobile Ad Hoc
2257	                                Network (MANET) Packet/Message Format",
2258	                                RFC 5444, February 2009.

2260	   [RFC5498]                    Chakeres, I., "IANA Allocations for
2261	                                Mobile Ad Hoc Network (MANET)
2262	                                Protocols", RFC 5498, March 2009.

2264	22.2.  Informative References

2266	   [I-D.sheffer-running-code]   Sheffer, Y. and A. Farrel, "Improving
2267	                                "Rough Consensus" with Running Code",
2268	                                draft-sheffer-running-code-01 (work in
2269	                                progress), December 2012.

2271	   [I-D.loadng-interop-report]  Clausen, T., Camacho, A., Yi, J., Colin
2272	                                de Verdiere, A., Igarashi, Y., Satoh,
2273	                                H., Morii, Y., Heropberg, U., and C.
2274	                                Lavenu, "Interoperability Report for the
2275	                                Lightweight On-demand Ad hoc Distance-
2276	                                vector Routing Protocol - Next
2277	                                Generation (LOADng)", draft-lavenu-lln-
2278	                                loadng-interoperability-report-04 (work
2279	                                in progress), December 2012.

2281	   [RFC3561]                    Perkins, C., Belding-Royer, E., and S.
2282	                                Das, "Ad hoc On-Demand Distance Vector
2283	                                (AODV) Routing", RFC 3561, July 2003.

2285	   [RFC4861]                    Narten, T., Nordmark, E., Simpson, W.,
2286	                                and H. Soliman, "Neighbor Discovery for
2287	                                IP version 6 (IPv6)", RFC 4861,
2288	                                September 2007.

2290	   [RFC4944]                    Montenegro, G., Kushalnagar, N., Hui,
2291	                                J., and D. Culler, "Transmission of IPv6
2292	                                Packets over IEEE 802.15.4 Networks",
2293	                                RFC 4944, September 2007.

2295	   [RFC5148]                    Clausen, T., Dearlove, C., and B.
2296	                                Adamson, "Jitter Considerations in
2297	                                Mobile Ad Hoc Networks (MANETs)",
2298	                                RFC 5148, February 2008.

2300	   [RFC6130]                    Clausen, T., Dean, J., and C. Dearlove,
2301	                                "MANET Neighborhood Discovery Protocol
2302	                                (NHDP)", RFC 6130, April 2011.

2304	   [RFC6206]                    Levis, P., Clausen, T., Gnawali, O., and
2305	                                J. Ko, "The Trickle Algorithm",
2306	                                RFC 6206, March 2011.

2308	   [RFC6621]                    Macker, J., "Simplified Multicast
2309	                                Forwarding", RFC 6621, May 2012.

2311	   [EUI64]                      IEEE, "Guidelines for 64-bit Global
2312	                                Identifier (EUI-64) Registration
2313	                                Authority".

2315	   [IEEE754-2008]               IEEE, "IEEE 754-2008: IEEE Standard for
2316	                                Floating-Point Arithmetic", 2008.

2318	   [IEEE_VTC2012]               Clausen, T., Yi, J., and A. Coline de
2319	                                Verdiere, "Towards AODV Version 2",
2320	                                Proceedings of IEEE VTC 2012 Fall, IEEE
2321	                                76th Vehicular Technology Conference,
2322	                                2012.

2324	   [IEEE_WiCom2012]             Yi, J., Clausen, T., and A. Coline de
2325	                                Verdiere, "Efficient Data Acquisition in
2326	                                Sensor Networks:Introducing (the) LOADng
2327	                                Collection Tree Protocol",
2328	                                Proceedings of IEEE WiCom 2012, The 8th
2329	                                IEEE International Conference on
2330	                                Wireless Communications, Networking and
2331	                                Mobile Computing., 2012.

2333	   [IEEE_ICWITS2012]            Yi, J., Clausen, T., and A. Bas, "Smart
2334	                                Route Request for On-demand Route
2335	                                Discovery in Constrained Environments",
2336	                                Proceedings of IEEE ICWITS 2012, IEEE
2337	                                International Conference on Wireless
2338	                                Information Technology and Systems.,
2339	                                2012.

2341	Appendix A.  LOADng Control Messages using RFC5444

2343	   This section presents how the abstract LOADng messages, used
2344	   throughout this specification, are mapped into [RFC5444] messages.

2346	A.1.  RREQ-Specific Message Encoding Considerations

2348	   This protocol defines, and hence owns, the RREQ Message Type.  Thus,
2349	   as specified in [RFC5444], this protocol generates and transmits all
2350	   RREQ messages, receives all RREQ messages and is responsible for
2351	   determining whether and how each RREQ message is to be processed
2352	   (updating the Information Base) and/or forwarded, according to this
2353	   specification.  Table 2 specifies how RREQ messages are mapped into
2354	   [RFC5444]-elements.

2356	   +-------------------+-------------------+---------------------------+
2357	   |    RREQ Element   |  RFC5444-Element  | Considerations            |
2358	   +-------------------+-------------------+---------------------------+
2359	   |  RREQ.addr-length | <msg-addr-length> | Supports addresses from   |
2360	   |                   |                   | 1-16 octets               |
2361	   |    RREQ.seq-num   |   <msg-seq-num>   | 16 bits, hence MAXVALUE   |
2362	   |                   |                   | (Section 8) is 65535.     |
2363	   |                   |                   | MUST be included          |
2364	   |  RREQ.metric-type |   METRIC Message  | Encoded by way of the     |
2365	   |                   |        TLV        | Type-Extension of a       |
2366	   |                   |                   | Message-Type-specific     |
2367	   |                   |                   | Message TLV of type       |
2368	   |                   |                   | METRIC, defined in        |
2369	   |                   |                   | Table 8.  A LOADng Router |
2370	   |                   |                   | generating an RREQ (as    |
2371	   |                   |                   | specified in              |
2372	   |                   |                   | Section 12.1) when using  |
2373	   |                   |                   | the HOP_COUNT metric,     |
2374	   |                   |                   | MUST NOT add the METRIC   |
2375	   |                   |                   | Message TLV to the RREQ   |
2376	   |                   |                   | (in order to reduce       |
2377	   |                   |                   | overhead, as the hop      |
2378	   |                   |                   | count value is already    |
2379	   |                   |                   | encoded in                |
2380	   |                   |                   | RREQ.hop-count).  LOADng  |
2381	   |                   |                   | Routers receiving an RREQ |
2382	   |                   |                   | without METRIC Message    |
2383	   |                   |                   | TLV assume that           |
2384	   |                   |                   | RREQ.metric-type is       |
2385	   |                   |                   | HOP_COUNT, and MUST not   |
2386	   |                   |                   | add the METRIC Message    |
2387	   |                   |                   | TLV when forwarding the   |
2388	   |                   |                   | message.  Otherwise,      |
2389	   |                   |                   | exactly one METRIC TLV    |
2390	   |                   |                   | MUST be included in each  |
2391	   |                   |                   | RREQ message.             |
2392	   | RREQ.route-metric |   METRIC Message  | Encoded as the value      |
2393	   |                   |     TLV value     | field of the METRIC TLV.  |
2394	   |                   |                   | (LOADng Routers           |
2395	   |                   |                   | generating RREQs when     |
2396	   |                   |                   | using the HOP_COUNT       |
2397	   |                   |                   | metric do not need need   |
2398	   |                   |                   | to add the METRIC Message |
2399	   |                   |                   | TLV, as specified above   |
2400	   |                   |                   | for the RREQ.metric-type  |
2401	   |                   |                   | field.)                   |
2402	   |   RREQ.hop-limit  |  <msg-hop-limit>  | 8 bits.  MUST be included |
2403	   |                   |                   | in an RREQ message        |
2404	   |   RREQ.hop-count  |  <msg-hop-count>  | 8 bits, hence             |
2405	   |                   |                   | MAX_HOP_COUNT is 255.     |
2406	   |                   |                   | MUST be included in an    |
2407	   |                   |                   | RREQ message.             |
2408	   |  RREQ.originator  |  <msg-orig-addr>  | MUST be included in an    |
2409	   |                   |                   | RREQ message.             |
2410	   |  RREQ.destination |     Address in    | Encoded by way of an      |
2411	   |                   |   Address-Block   | address in an address     |
2412	   |                   |       w/TLV       | block, with which a       |
2413	   |                   |                   | Message-Type-specific     |
2414	   |                   |                   | Address Block TLV of type |
2415	   |                   |                   | ADDR-TYPE and with        |
2416	   |                   |                   | Type-Extension            |
2417	   |                   |                   | DESTINATION is            |
2418	   |                   |                   | associated, defined in    |
2419	   |                   |                   | Table 9.  An RREQ MUST    |
2420	   |                   |                   | contain exactly one       |
2421	   |                   |                   | address with a TLV of     |
2422	   |                   |                   | type ADDR-TYPE and with   |
2423	   |                   |                   | Type-Extension            |
2424	   |                   |                   | DESTINATION associated.   |
2425	   +-------------------+-------------------+---------------------------+

2427	                      Table 2: RREQ Message Elements

2429	A.2.  RREP-Specific Message Encoding Considerations

2431	   This protocol defines, and hence owns, the RREP Message Type.  Thus,
2432	   as specified in [RFC5444], this protocol generates and transmits all
2433	   RREP messages, receives all RREP messages and is responsible for
2434	   determining whether and how each RREP message is to be processed
2435	   (updating the Information Base) and/or forwarded, according to this
2436	   specification.  Table 3 describes how RREP messages are mapped into
2437	   [RFC5444]-elements.

2439	   +-------------------+-------------------+---------------------------+
2440	   |    RREP Element   |  RFC5444-Element  | Considerations            |
2441	   +-------------------+-------------------+---------------------------+
2442	   |  RREP.addr-length | <msg-addr-length> | Supports addresses from   |
2443	   |                   |                   | 1-16 octets               |
2444	   |    RREP.seq-num   |   <msg-seq-num>   | 16 bits, hence MAXVALUE   |
2445	   |                   |                   | (Section 8) is 65535.     |
2446	   |                   |                   | MUST be included          |
2447	   |  RREP.metric-type |   METRIC Message  | Encoded by way of the     |
2448	   |                   |        TLV        | Type-Extension of a       |
2449	   |                   |                   | Message-Type-specific     |
2450	   |                   |                   | Message TLV of type       |
2451	   |                   |                   | METRIC, defined in        |
2452	   |                   |                   | Table 12.  A LOADng       |
2453	   |                   |                   | Router generating an RREP |
2454	   |                   |                   | (as specified in          |
2455	   |                   |                   | Section 13.1) when using  |
2456	   |                   |                   | the HOP_COUNT metric,     |
2457	   |                   |                   | MUST NOT add the METRIC   |
2458	   |                   |                   | Message TLV to the RREP   |
2459	   |                   |                   | (in order to reduce       |
2460	   |                   |                   | overhead, as the hop      |
2461	   |                   |                   | count value is already    |
2462	   |                   |                   | encoded in                |
2463	   |                   |                   | RREP.hop-count).  LOADng  |
2464	   |                   |                   | Routers receiving an RREP |
2465	   |                   |                   | without METRIC Message    |
2466	   |                   |                   | TLV assume that           |
2467	   |                   |                   | RREP.metric-type is       |
2468	   |                   |                   | HOP_COUNT, and MUST not   |
2469	   |                   |                   | add the METRIC Message    |
2470	   |                   |                   | TLV when forwarding the   |
2471	   |                   |                   | message.  Otherwise,      |
2472	   |                   |                   | exactly one METRIC TLV    |
2473	   |                   |                   | MUST be included in each  |
2474	   |                   |                   | RREP message.             |
2475	   | RREP.route-metric |   METRIC Message  | Encoded as the value      |
2476	   |                   |     TLV value     | field of the METRIC TLV.  |
2477	   |                   |                   | (LOADng Routers           |
2478	   |                   |                   | generating RREPs when     |
2479	   |                   |                   | using the HOP_COUNT       |
2480	   |                   |                   | metric do not need need   |
2481	   |                   |                   | to add the METRIC Message |
2482	   |                   |                   | TLV, as specified above   |
2483	   |                   |                   | for the RREP.metric-type  |
2484	   |                   |                   | field.)                   |
2485	   |  RREP.ackrequired | FLAGS Message TLV | Encoded by way of a       |
2486	   |                   |                   | Message-Type-specific     |
2487	   |                   |                   | Message TLV of type       |
2488	   |                   |                   | FLAGS, defined in         |
2489	   |                   |                   | Table 13.  A TLV of type  |
2490	   |                   |                   | FLAGS MUST always be      |
2491	   |                   |                   | included in an RREP       |
2492	   |                   |                   | message.                  |
2493	   |   RREP.hop-limit  |  <msg-hop-limit>  | 8 bits.  MUST be included |
2494	   |                   |                   | in an RREQ message        |
2495	   |   RREP.hop-count  |  <msg-hop-count>  | 8 bits, hence             |
2496	   |                   |                   | MAX_HOP_COUNT is 255.     |
2497	   |                   |                   | MUST be included in an    |
2498	   |                   |                   | RREP message.             |
2499	   |  RREP.originator  |  <msg-orig-addr>  | MUST be included in an    |
2500	   |                   |                   | RREP message.             |
2501	   |  RREP.destination |     Address in    | Encoded by way of an      |
2502	   |                   |   Address-Block   | address in an address     |
2503	   |                   |       w/TLV       | block, with which a       |
2504	   |                   |                   | Message-Type-specific     |
2505	   |                   |                   | Address Block TLV of type |
2506	   |                   |                   | ADDR-TYPE and with        |
2507	   |                   |                   | Type-Extension            |
2508	   |                   |                   | DESTINATION is            |
2509	   |                   |                   | associated, defined in    |
2510	   |                   |                   | Table 14.  An RREP MUST   |
2511	   |                   |                   | contain exactly one       |
2512	   |                   |                   | address with a TLV of     |
2513	   |                   |                   | type ADDR-TYPE and with   |
2514	   |                   |                   | Type-Extension            |
2515	   |                   |                   | DESTINATION associated.   |
2516	   +-------------------+-------------------+---------------------------+

2518	                      Table 3: RREP Message Elements

2520	A.3.  RREP_ACK Message Encoding

2522	   This protocol defines, and hence owns, the RREP_ACK Message Type.
2523	   Thus, as specified in [RFC5444], this protocol generates and
2524	   transmits all RREP_ACK messages, receives all RREP_ACK messages and
2525	   is responsible for determining whether and how each RREP_ACK message
2526	   is to be processed (updating the Information Base), according to this
2527	   specification.  Table 4 describes how RREP_ACK Messages are mapped
2528	   into [RFC5444]-elements.

2530	   +----------------------+-------------------+------------------------+
2531	   |   RREP_ACK Element   |  RFC5444-Element  | Considerations         |
2532	   +----------------------+-------------------+------------------------+
2533	   | RREP_ACK.addr-length | <msg-addr-length> | Supports addresses     |
2534	   |                      |                   | from 1-16 octets       |
2535	   |   RREP_ACK.seq-num   |   <msg-seq-num>   | 16 bits, hence         |
2536	   |                      |                   | MAXVALUE (Section 8)   |
2537	   |                      |                   | is 65535.  MUST be     |
2538	   |                      |                   | included               |
2539	   | RREP_ACK.destination |     Address in    | Encoded by way of an   |
2540	   |                      |   Address-Block   | address in an address  |
2541	   |                      |       w/TLV       | block, with which a    |
2542	   |                      |                   | Message-Type-specific  |
2543	   |                      |                   | Address Block TLV of   |
2544	   |                      |                   | type ADDR-TYPE and     |
2545	   |                      |                   | with Type-Extension    |
2546	   |                      |                   | DESTINATION is         |
2547	   |                      |                   | associated, defined in |
2548	   |                      |                   | Table 17.  An RREP_ACK |
2549	   |                      |                   | MUST contain exactly   |
2550	   |                      |                   | one address with a TLV |
2551	   |                      |                   | of type ADDR-TYPE and  |
2552	   |                      |                   | with Type-Extension    |
2553	   |                      |                   | DESTINATION            |
2554	   |                      |                   | associated.            |
2555	   +----------------------+-------------------+------------------------+

2557	                    Table 4: RREP_ACK Message Elements

2559	A.4.  RERR Message Encoding

2561	   This protocol defines, and hence owns, the RERR Message Type.  Thus,
2562	   as specified in [RFC5444], this protocol generates and transmits all
2563	   RERR messages, receives all RERR messages and is responsible for
2564	   determining whether and how each RERR message is to be processed
2565	   (updating the Information Base) and/or forwarded, according to this
2566	   specification.  Table 5 describes how RERR Messages are mapped into
2567	   [RFC5444]-elements.

2569	   +------------------------+------------------+-----------------------+
2570	   |      RERR Element      |  RFC5444-Element | Considerations        |
2571	   +------------------------+------------------+-----------------------+
2572	   |    RERR.addr-length    | <msg-addr-length | Supports addresses    |
2573	   |                        | >                | from 1-16 octets      |
2574	   |     RERR.hop-limit     |  <msg-hop-limit> | 8 bits.  MUST be      |
2575	   |                        |                  | included in an RREQ   |
2576	   |                        |                  | message               |
2577	   |     RERR.errorcode     |   Address Block  | According to          |
2578	   |                        |     TLV Value    | Section 19.1.         |
2579	   | RERR.unreachableAddres |    Address in    | Encoded by way of an  |
2580	   | s                      |   Address-Block  | address in an address |
2581	   |                        |       w/TLV      | block, with which a   |
2582	   |                        |                  | Message-Type-specific |
2583	   |                        |                  | Address Block TLV of  |
2584	   |                        |                  | type ADDR-TYPE and    |
2585	   |                        |                  | with Type-Extension   |
2586	   |                        |                  | ERRORCODE is          |
2587	   |                        |                  | associated, defined   |
2588	   |                        |                  | in Table 20.          |
2589	   |     RERR.originator    |  <msg-orig-addr> | MUST be included in   |
2590	   |                        |                  | an RERR message.      |
2591	   |    RERR.destination    |    Address in    | Encoded by way of an  |
2592	   |                        |   Address-Block  | address in an address |
2593	   |                        |       w/TLV      | block, with which a   |
2594	   |                        |                  | Message-Type-specific |
2595	   |                        |                  | Address Block TLV of  |
2596	   |                        |                  | type ADDR-TYPE and    |
2597	   |                        |                  | with Type-Extension   |
2598	   |                        |                  | DESTINATION is        |
2599	   |                        |                  | associated, defined   |
2600	   |                        |                  | in Table 20.  An RERR |
2601	   |                        |                  | MUST contain exactly  |
2602	   |                        |                  | one address with a    |
2603	   |                        |                  | TLV of type ADDR-TYPE |
2604	   |                        |                  | and with              |
2605	   |                        |                  | Type-Extension        |
2606	   |                        |                  | DESTINATION           |
2607	   |                        |                  | associated.           |
2608	   +------------------------+------------------+-----------------------+

2610	                      Table 5: RERR Message Elements

2612	A.5.  RFC5444-Specific IANA Considerations

2614	   This specification defines four Message Types, which must be
2615	   allocated from the "Message Types" repository of [RFC5444], two
2616	   Message TLV Types, which must be allocated from the "Message TLV
2617	   Types" repository of [RFC5444], and four Address Block TLV Types,
2618	   which must be allocated from the "Address Block TLV Types" repository
2619	   of [RFC5444].

2621	A.5.1.  Expert Review: Evaluation Guidelines

2623	   For the registries where an Expert Review is required, the designated
2624	   expert should take the same general recommendations into
2625	   consideration as are specified by [RFC5444].

2627	A.5.2.  Message Types

2629	   This specification defines four Message Type, to be allocated from
2630	   the 0-223 range of the "Message Types" namespace defined in
2631	   [RFC5444], as specified in Table 6.

2633	         +------+-----------------------------------------------+
2634	         | Type | Description                                   |
2635	         +------+-----------------------------------------------+
2636	         | TBD1 | RREQ: Route Request Message                   |
2637	         | TBD1 | RREP: Route Reply Message                     |
2638	         | TBD1 | RREP_ACK: Route Reply Acknowledgement Message |
2639	         | TBD1 | RERR: Route Error Message                     |
2640	         +------+-----------------------------------------------+

2642	                     Table 6: Message Type assignment

2644	A.6.  RREQ Message-Type-Specific TLV Type Registries

2646	   IANA is requested to create a registry for Message-Type-specific
2647	   Message TLVs for RREQ messages, in accordance with Section 6.2.1 of
2648	   [RFC5444], and with initial assignments and allocation policies as
2649	   specified in Table 7.

2651	               +---------+-------------+-------------------+
2652	               |   Type  | Description | Allocation Policy |
2653	               +---------+-------------+-------------------+
2654	               |   128   | METRIC      |                   |
2655	               | 129-223 | Unassigned  | Expert Review     |
2656	               +---------+-------------+-------------------+

2658	           Table 7: RREQ Message-Type-specific Message TLV Types

2660	   Allocation of the METRIC TLV from the RREQ Message-Type-specific
2661	   Message TLV Types in Table 7 will create a new Type Extension
2662	   registry, with assignments as specified in Table 8.

2664	   +--------+------+-----------+------------------------+--------------+
2665	   |  Name  | Type |    Type   | Description            | Allocation   |
2666	   |        |      | Extension |                        | Policy       |
2667	   +--------+------+-----------+------------------------+--------------+
2668	   | METRIC |  128 |     0     | HOP_COUNT:             |              |
2669	   |        |      |           | MSG.hop-count is used  |              |
2670	   |        |      |           | instead of the METRIC  |              |
2671	   |        |      |           | TLV Value.  MAX_DIST   |              |
2672	   |        |      |           | is 255.                |              |
2673	   | METRIC |  128 |     1     | DIMENSIONLESS: A       |              |
2674	   |        |      |           | 32-bit, dimensionless, |              |
2675	   |        |      |           | additive metric,       |              |
2676	   |        |      |           | single precision       |              |
2677	   |        |      |           | float, formatted       |              |
2678	   |        |      |           | according to           |              |
2679	   |        |      |           | [IEEE754-2008].        |              |
2680	   | METRIC |  128 |   2-251   | Unassigned             | Expert       |
2681	   |        |      |           |                        | Review       |
2682	   | METRIC |  128 |  252-255  | Unassigned             | Experimental |
2683	   +--------+------+-----------+------------------------+--------------+

2685	               Table 8: Message TLV Type assignment: METRIC

2687	   IANA is requested to create a registry for Message-Type-specific
2688	   Address Block TLVs for RREQ messages, in accordance with Section
2689	   6.2.1 of [RFC5444], and with initial assignments and allocation
2690	   policies as specified in Table 9.

2692	               +---------+-------------+-------------------+
2693	               |   Type  | Description | Allocation Policy |
2694	               +---------+-------------+-------------------+
2695	               |   128   | ADDR-TYPE   | Expert Review     |
2696	               | 129-223 | Unassigned  | Expert Review     |
2697	               +---------+-------------+-------------------+

2699	        Table 9: RREQ Message-Type-specific Address Block TLV Types

2701	   Allocation of the ADDR-TYPE TLV from the RREQ Message-Type-specific
2702	   Address Block TLV Types in Table 9 will create a new Type Extension
2703	   registry, with assignments as specified in Table 10.

2705	   +-----------+------+----------------+-------------+-----------------+
2706	   |    Name   | Type | Type Extension | Description | Allocation      |
2707	   |           |      |                |             | Policy          |
2708	   +-----------+------+----------------+-------------+-----------------+
2709	   | ADDR-TYPE |  128 |        0       | DESTINATION |                 |
2710	   | ADDR-TYPE |  128 |      2-255     | Unassigned  | Expert Review   |
2711	   +-----------+------+----------------+-------------+-----------------+
2712	          Table 10: Address Block TLV Type assignment: ADDR-TYPE

2714	A.7.  RREP Message-Type-Specific TLV Type Registries

2716	   IANA is requested to create a registry for Message-Type-specific
2717	   Message TLVs for RREP messages, in accordance with Section 6.2.1 of
2718	   [RFC5444], and with initial assignments and allocation policies as
2719	   specified in Table 11.

2721	               +---------+-------------+-------------------+
2722	               |   Type  | Description | Allocation Policy |
2723	               +---------+-------------+-------------------+
2724	               |   128   | METRIC      |                   |
2725	               |   129   | FLAGS       |                   |
2726	               | 130-223 | Unassigned  | Expert Review     |
2727	               +---------+-------------+-------------------+

2729	          Table 11: RREP Message-Type-specific Message TLV Types

2731	   Allocation of the METRIC TLV from the RREP Message-Type-specific
2732	   Message TLV Types in Table 11 will create a new Type Extension
2733	   registry, with assignments as specified in Table 12.

2735	   +--------+------+-----------+------------------------+--------------+
2736	   |  Name  | Type |    Type   | Description            | Allocation   |
2737	   |        |      | Extension |                        | Policy       |
2738	   +--------+------+-----------+------------------------+--------------+
2739	   | METRIC |  128 |     0     | HOP_COUNT:             |              |
2740	   |        |      |           | MSG.hop-count is used  |              |
2741	   |        |      |           | instead of the METRIC  |              |
2742	   |        |      |           | TLV Value.  MAX_DIST   |              |
2743	   |        |      |           | is 255.                |              |
2744	   | METRIC |  128 |     1     | DIMENSIONLESS: A       |              |
2745	   |        |      |           | 32-bit, dimensionless, |              |
2746	   |        |      |           | additive metric,       |              |
2747	   |        |      |           | single precision       |              |
2748	   |        |      |           | float, formatted       |              |
2749	   |        |      |           | according to           |              |
2750	   |        |      |           | [IEEE754-2008].        |              |
2751	   | METRIC |  128 |   2-251   | Unassigned             | Expert       |
2752	   |        |      |           |                        | Review       |
2753	   | METRIC |  128 |  252-255  | Unassigned             | Experimental |
2754	   +--------+------+-----------+------------------------+--------------+

2756	               Table 12: Message TLV Type assignment: METRIC

2758	   Allocation of the FLAGS TLV from the RREP Message-Type-specific
2759	   Message TLV Types in Table 11 will create a new Type Extension
2760	   registry, with assignments as specified in Table 13.

2762	   +-------+------+-----------+---------------------------+------------+
2763	   |  Name | Type |    Type   | Description               | Allocation |
2764	   |       |      | Extension |                           | Policy     |
2765	   +-------+------+-----------+---------------------------+------------+
2766	   | FLAGS |  129 |     0     | Bit 0 represents the      |            |
2767	   |       |      |           | ackrequired flag (i.e.,   |            |
2768	   |       |      |           | ackrequired is TRUE when  |            |
2769	   |       |      |           | bit 0 is set to 1 and     |            |
2770	   |       |      |           | FALSE when bit 0 is 0.).  |            |
2771	   |       |      |           | All other bits are        |            |
2772	   |       |      |           | reserved for future use.  |            |
2773	   | FLAGS |  129 |   1-255   | Unassigned                | Expert     |
2774	   |       |      |           |                           | Review     |
2775	   +-------+------+-----------+---------------------------+------------+

2777	               Table 13: Message TLV Type assignment: FLAGS

2779	   IANA is requested to create a registry for Message-Type-specific
2780	   Address Block TLVs for RREP messages, in accordance with Section
2781	   6.2.1 of [RFC5444], and with initial assignments and allocation
2782	   policies as specified in Table 14.

2784	               +---------+-------------+-------------------+
2785	               |   Type  | Description | Allocation Policy |
2786	               +---------+-------------+-------------------+
2787	               |   128   | ADDR-TYPE   | Expert Review     |
2788	               | 129-223 | Unassigned  | Expert Review     |
2789	               +---------+-------------+-------------------+

2791	       Table 14: RREP Message-Type-specific Address Block TLV Types

2793	   Allocation of the ADDR-TYPE TLV from the RREP Message-Type-specific
2794	   Address Block TLV Types in Table 14 will create a new Type Extension
2795	   registry, with assignments as specified in Table 15.

2797	   +-----------+------+----------------+-------------+-----------------+
2798	   |    Name   | Type | Type Extension | Description | Allocation      |
2799	   |           |      |                |             | Policy          |
2800	   +-----------+------+----------------+-------------+-----------------+
2801	   | ADDR-TYPE |  128 |        0       | DESTINATION |                 |
2802	   | ADDR-TYPE |  128 |      1-255     | Unassigned  | Expert Review   |
2803	   +-----------+------+----------------+-------------+-----------------+

2805	          Table 15: Address Block TLV Type assignment: ADDR-TYPE

2807	A.8.  RREP_ACK Message-Type-Specific TLV Type Registries

2809	   IANA is requested to create a registry for Message-Type-specific
2810	   Message TLVs for RREP_ACK messages, in accordance with Section 6.2.1
2811	   of [RFC5444], and with initial assignments and allocation policies as
2812	   specified in Table 16.

2814	               +---------+-------------+-------------------+
2815	               |   Type  | Description | Allocation Policy |
2816	               +---------+-------------+-------------------+
2817	               | 128-223 | Unassigned  | Expert Review     |
2818	               +---------+-------------+-------------------+

2820	        Table 16: RREP_ACK Message-Type-specific Message TLV Types

2822	   IANA is requested to create a registry for Message-Type-specific
2823	   Address Block TLVs for RREP_ACK messages, in accordance with Section
2824	   6.2.1 of [RFC5444], and with initial assignments and allocation
2825	   policies as specified in Table 17.

2827	               +---------+-------------+-------------------+
2828	               |   Type  | Description | Allocation Policy |
2829	               +---------+-------------+-------------------+
2830	               |   128   | ADDR-TYPE   | Expert Review     |
2831	               | 129-223 | Unassigned  | Expert Review     |
2832	               +---------+-------------+-------------------+

2834	     Table 17: RREP_ACK Message-Type-specific Address Block TLV Types

2836	   Allocation of the ADDR-TYPE TLV from the RREP_ACK Message-Type-
2837	   specific Address Block TLV Types in Table 17 will create a new Type
2838	   Extension registry, with assignments as specified in Table 18.

2840	   +-----------+------+----------------+-------------+-----------------+
2841	   |    Name   | Type | Type Extension | Description | Allocation      |
2842	   |           |      |                |             | Policy          |
2843	   +-----------+------+----------------+-------------+-----------------+
2844	   | ADDR-TYPE |  128 |        0       | DESTINATION |                 |
2845	   | ADDR-TYPE |  128 |      2-255     | Unassigned  | Expert Review   |
2846	   +-----------+------+----------------+-------------+-----------------+

2848	          Table 18: Address Block TLV Type assignment: ADDR-TYPE

2850	A.9.  RERR Message-Type-Specific TLV Type Registries

2852	   IANA is requested to create a registry for Message-Type-specific
2853	   Message TLVs for RERR messages, in accordance with Section 6.2.1 of
2854	   [RFC5444], and with initial assignments and allocation policies as
2855	   specified in Table 19.

2857	               +---------+-------------+-------------------+
2858	               |   Type  | Description | Allocation Policy |
2859	               +---------+-------------+-------------------+
2860	               | 128-223 | Unassigned  | Expert Review     |
2861	               +---------+-------------+-------------------+

2863	          Table 19: RERR Message-Type-specific Message TLV Types

2865	   IANA is requested to create a registry for Message-Type-specific
2866	   Address Block TLVs for RERR messages, in accordance with Section
2867	   6.2.1 of [RFC5444], and with initial assignments and allocation
2868	   policies as specified in Table 20.

2870	               +---------+-------------+-------------------+
2871	               |   Type  | Description | Allocation Policy |
2872	               +---------+-------------+-------------------+
2873	               |   128   | ADDR-TYPE   | Expert Review     |
2874	               | 129-223 | Unassigned  | Expert Review     |
2875	               +---------+-------------+-------------------+

2877	     Table 20: RREP_ACK Message-Type-specific Address Block TLV Types

2879	   Allocation of the ADDR-TYPE TLV from the RERR Message-Type-specific
2880	   Address Block TLV Types in Table 20 will create a new Type Extension
2881	   registry, with assignments as specified in Table 21.

2883	   +-----------+------+----------------+-------------+-----------------+
2884	   |    Name   | Type | Type Extension | Description | Allocation      |
2885	   |           |      |                |             | Policy          |
2886	   +-----------+------+----------------+-------------+-----------------+
2887	   | ADDR-TYPE |  128 |        0       | DESTINATION |                 |
2888	   | ADDR-TYPE |  128 |        1       | ERRORCODE   |                 |
2889	   | ADDR-TYPE |  128 |      2-255     | Unassigned  | Expert Review   |
2890	   +-----------+------+----------------+-------------+-----------------+

2892	          Table 21: Address Block TLV Type assignment: ADDR-TYPE

2894	Appendix B.  LOADng Control Packet Illustrations

2896	   This section presents example packets following this specification.

2898	B.1.  RREQ

2900	   RREQ messages are instances of [RFC5444] messages.  This
2901	   specification requires that RREQ messages contain RREQ.msg-seq-num,
2902	   RREQ.msg-hop-limit, RREQ.msg-hop-count and RREQ.msg-orig-addr fields.

2904	   It supports RREQ messages with any combination of remaining message
2905	   header options and address encodings, enabled by [RFC5444] that
2906	   convey the required information.  As a consequence, there is no
2907	   single way to represent how all RREQ messages look.  This section
2908	   illustrates an RREQ message, the exact values and content included
2909	   are explained in the following text.

2911	   The RREQ message's four bit Message Flags (MF) field has value 15
2912	   indicating that the message header contains originator address, hop
2913	   limit, hop count, and message sequence number fields.  Its four bit
2914	   Message Address Length (MAL) field has value 3, indicating addresses
2915	   in the message have a length of four octets, here being IPv4
2916	   addresses.  The overall message length is 30 octets.

2918	   The message has a Message TLV Block with content length 6 octets
2919	   containing one TLV.  The TLVs is of type METRIC and has a Flags octet
2920	   (MTLVF) value 144, indicating that it has a Value, a type extension,
2921	   but no start and stop indexes.  The Value Length of the METRIC TLV is
2922	   2 octets.

2924	   The message has one Address Block.  The Address Block contains 1
2925	   address, with Flags octet (ATLVF) value 0, hence with no Head or Tail
2926	   sections, and hence with a Mid section with length four octets.  The
2927	   following TLV Block (content length 2 octets) contains one TLV.  The
2928	   TLV is an ADDR_TYPE TLV with Flags octet (ATLVF) value 0, indicating
2929	   no Value and no indexes.  Thus, the address is associated with the
2930	   Type ADDR_TYPE, i.e., it is the destination address of the RREQ.

2932	      0                   1                   2                   3
2933	      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2934	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2935	     |     RREQ      | MF=15 | MAL=3 |      Message Length = 30      |
2936	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2937	     |                      Originator Address                       |
2938	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2939	     |   Hop Limit   |   Hop Count   |    Message Sequence Number    |
2940	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2941	     | Message TLV Block Length = 6  |    METRIC     |  MTLVF = 144  |
2942	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2943	     |  Type Ext.    | Value Len = 2 |       Value (metric)          |
2944	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2945	     | Num Addrs = 1 |    ABF = 0    |             Mid               |
2946	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2947	     |            Mid                | Address TLV Block Length = 2  |
2948	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2949	     |   ADDR-TYPE   |   ATLVF = 0   |
2950	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2952	B.2.  RREP

2954	   RREP messages are instances of [RFC5444] messages.  This
2955	   specification requires that RREP messages contain RREP.msg-seq-num,
2956	   RREP.msg-hop-limit, RREP.msg-hop-count and RREP.msg-orig-addr fields.
2957	   It supports RREP messages with any combination of remaining message
2958	   header options and address encodings, enabled by [RFC5444] that
2959	   convey the required information.  As a consequence, there is no
2960	   single way to represent how all RREP messages look.  This section
2961	   illustrates an RREP message, the exact values and content included
2962	   are explained in the following text.

2964	   The RREP message's four bit Message Flags (MF) field has value 15
2965	   indicating that the message header contains originator address, hop
2966	   limit, hop count, and message sequence number fields.  Its four bit
2967	   Message Address Length (MAL) field has value 3, indicating addresses
2968	   in the message have a length of four octets, here being IPv4
2969	   addresses.  The overall message length is 34 octets.

2971	   The message has a Message TLV Block with content length 10 octets
2972	   containing two TLVs.  The first TLV is of type METRIC and has a Flags
2973	   octet (MTLVF) value 144, indicating that it has a Value, a type
2974	   extension, but no start and stop indexes.  The Value Length of the
2975	   METRIC TLV is 2 octets.  The second TLV is of type FLAGS and has a
2976	   Flags octet (MTLVF) value of 16, indicating that it has a Value, but
2977	   no type extension or start and stop indexes.  The Value Length of the
2978	   FLAGS TLV is 1 octet.  The TLV value is 0x80 indicating that the
2979	   ackrequired flag is set.

2981	   The message has one Address Block.  The Address Block contains 1
2982	   address, with Flags octet (ATLVF) value 0, hence with no Head or Tail
2983	   sections, and hence with a Mid section with length four octets.  The
2984	   following TLV Block (content length 2 octets) contains one TLV.  The
2985	   TLV is an ADDR_TYPE TLV with Flags octet (ATLVF) value 0, indicating
2986	   no Value and no indexes.  Thus, the address is associated with the
2987	   Type ADDR_TYPE, i.e., it is the destination address of the RREP.

2989	      0                   1                   2                   3
2990	      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2991	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2992	     |     RREP      | MF=15 | MAL=3 |      Message Length = 34      |
2993	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2994	     |                      Originator Address                       |
2995	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2996	     |   Hop Limit   |   Hop Count   |    Message Sequence Number    |
2997	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2998	     | Message TLV Block Length = 10 |    METRIC     |  MTLVF = 144  |
2999	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3000	     |  Type Ext.    | Value Len = 2 |        Value (metric)         |
3001	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3002	     |     FLAGS     |   MTLVF = 16  | Value Len = 1 | Value (0x80)  |
3003	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3004	     | Num Addrs = 1 |    ABF = 0    |             Mid               |
3005	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3006	     |              Mid              |  Address TLV Block Length = 2 |
3007	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3008	     |   ADDR-TYPE   |   ATLVF = 0   |
3009	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3011	B.3.  RREP_ACK

3013	   RREP_ACK messages are instances of [RFC5444] messages.  This
3014	   specification requires that RREP_ACK messages contains RREP_ACK.msg-
3015	   seq-num.  It supports RREP_ACK messages with any combination of
3016	   remaining message header options and address encodings, enabled by
3017	   [RFC5444] that convey the required information.  As a consequence,
3018	   there is no single way to represent how all RREP_ACK messages look.
3019	   This section illustrates an RREP_ACK message, the exact values and
3020	   content included are explained in the following text.

3022	   The RREP_ACK message's four bit Message Flags (MF) field has value 1
3023	   indicating that the message header contains the message sequence
3024	   number field.  Its four bit Message Address Length (MAL) field has
3025	   value 3, indicating addresses in the message have a length of four
3026	   octets, here being IPv4 addresses.  The overall message length is 18
3027	   octets.

3029	   The message has a Message TLV Block with content length 0 octets
3030	   containing zero TLVs.

3032	   The message has one Address Block.  The Address Block contains 1
3033	   address, with Flags octet (ATLVF) value 0, hence with no Head or Tail
3034	   sections, and hence with a Mid section with length four octets.  The
3035	   following TLV Block (content length 2 octets) contains one TLV.  The
3036	   TLV is an ADDR_TYPE TLV with Flags octet (ATLVF) value 0, indicating
3037	   no Value and no indexes.  Thus, the address is associated with the
3038	   Type ADDR_TYPE, i.e., it is the destination address of the RREP_ACK.

3040	      0                   1                   2                   3
3041	      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
3042	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3043	     |   RREP_ACK    | MF=1  | MAL=3 |      Message Length = 18      |
3044	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3045	     |    Message Sequence Number    | Message TLV Block Length = 0  |
3046	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3047	     | Num Addrs = 1 |    ABF = 0    |               Mid             |
3048	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3049	     |               Mid             | Address TLV Block Length = 2  |
3050	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3051	     |   ADDR-TYPE   |   ATLVF = 0   |
3052	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3054	B.4.  RERR

3056	   RERR messages are instances of [RFC5444] messages.  This
3057	   specification supports RERR messages with any combination of message
3058	   header options and address encodings, enabled by [RFC5444] that
3059	   convey the required information.  As a consequence, there is no
3060	   single way to represent how all RERR messages look.  This section
3061	   illustrates an RERR message, the exact values and content included
3062	   are explained in the following text.

3064	   The RERR message's four bit Message Flags (MF) field has value 12
3065	   indicating that the message header contains RERR.msg-orig-addr field
3066	   and RERR.msg-hop-limit field.  Its four bit Message Address Length
3067	   (MAL) field has value 3, indicating addresses in the message have a
3068	   length of four octets, here being IPv4 addresses.  The overall
3069	   message length is 30 octets.

3071	   The message has a Message TLV Block with content length 0 octets
3072	   containing zero TLVs.

3074	   The message has one Address Block.  The Address Block contains 2
3075	   addresses, with Flags octet (ATLVF) value 128, hence with a Head
3076	   section (with length 3 octets), but no Tail section, and hence with
3077	   Mid sections with length one octet.  The following TLV Block (content
3078	   length 9 octets) contains two TLVs.  The first TLV is an ADDR_TYPE
3079	   TLV with Flags octet (ATLVF) value 64, indicating a single index of
3080	   0, but no Value.  Thus, the first address is associated with the Type
3081	   ADDR_TYPE and Type Extension DESTINATION, i.e., it is the destination
3082	   address of the RERR.  The second TLV is an ADDR_TYPE TLV with Flags
3083	   octet (ATLVF) value 208, indicating Type Extension, Value, and single
3084	   index.  Thus, the second address is associated with the Type
3085	   ADDR_TYPE, Type Extension ERRORCODE, and Value 0, i.e., it is
3086	   associated with error code 0.

3088	      0                   1                   2                   3
3089	      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
3090	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3091	     |     RERR      | MF=12 | MAL=3 |      Message Length = 30      |
3092	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3093	     |                      Originator Address                       |
3094	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3095	     |   Hop Limit   | Message TLV Block Length = 0  | Num Addrs = 2 |
3096	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3097	     |  ABF = 128    | Head Len = 3  |       Head                    |
3098	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3099	     |    Head       |             Mid               | Address TLV   |
3100	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3101	     |Block Length= 9|   ADDR-TYPE   |   ATLVF = 64  |  Index = 0    |
3102	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3103	     |   ADDR-TYPE   |  ATLVF = 208  |TypEx=ERRORCODE|  Index = 1    |
3104	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3105	     | Value Len = 1 |  Value = 0    |
3106	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3108	Authors' Addresses

3110	   Thomas Heide Clausen
3111	   LIX, Ecole Polytechnique

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

3117	   Axel Colin de Verdiere
3118	   LIX, Ecole Polytechnique

3120	   Phone: +33 6 1264 7119
3121	   EMail: axel@axelcdv.com
3122	   URI:   http://www.axelcdv.com/
3123	   Jiazi Yi
3124	   LIX, Ecole Polytechnique

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

3130	   Afshin Niktash
3131	   Maxim Integrated Products

3133	   Phone: +1 94 9450 1692
3134	   EMail: afshin.niktash@maxim-ic.com
3135	   URI:   http://www.Maxim-ic.com/

3137	   Yuichi Igarashi
3138	   Hitachi, Ltd., Yokohama Research Laboratory

3140	   Phone: +81 45 860 3083
3141	   EMail: yuichi.igarashi.hb@hitachi.com
3142	   URI:   http://www.hitachi.com/

3144	   Hiroki Satoh
3145	   Hitachi, Ltd., Yokohama Research Laboratory

3147	   Phone: +81 44 959 0205
3148	   EMail: hiroki.satoh.yj@hitachi.com
3149	   URI:   http://www.hitachi.com/

3151	   Ulrich Herberg
3152	   Fujitsu Laboratories of America

3154	   Phone: +1 408 530 4528
3155	   EMail: ulrich@herberg.name
3156	   URI:   http://www.herberg.name/

3158	   Cedric Lavenu
3159	   EDF R&D

3161	   Phone: +33 1 4765 2729
3162	   EMail: cedric-2.lavenu@edf.fr
3163	   URI:   http://www.edf.fr/
3164	   Thierry Lys
3165	   ERDF

3167	   Phone: +33 1 8197 6777
3168	   EMail: thierry.lys@erdfdistribution.fr
3169	   URI:   http://www.erdfdistribution.fr/

3171	   Charles E. Perkins
3172	   Futurewei Inc.

3174	   Phone: +1-408-421-1172
3175	   EMail: charliep@computer.org
3176	   URI:   http://www.huawei.com/na/en/

3178	   Justin Dean
3179	   Naval Research Laboratory

3181	   EMail: jdean@itd.nrl.navy.mil
3182	   URI:   http://cs.itd.nrl.navy.mil/