idnits 2.17.1 

draft-clausen-lln-loadng-15.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 668 has weird spacing: '...-length  is an...'

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

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

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

  == Line 685 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 (July 4, 2016) is 2847 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)

  -- Obsolete informational reference (is this intentional?): RFC 6982
     (Obsoleted by RFC 7942)


     Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 3 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: January 5, 2017                             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

14	                                                               C. Lavenu
15	                                                                 EDF R&D
16	                                                                  T. Lys
17	                                                                    ERDF
18	                                                                 J. Dean
19	                                               Naval Research Laboratory
20	                                                            July 4, 2016

22	The Lightweight On-demand Ad hoc Distance-vector Routing Protocol - Next
23	                          Generation (LOADng)
24	                      draft-clausen-lln-loadng-15

26	Abstract

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

32	Status of This Memo

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

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

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

51	Copyright Notice

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

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

66	Table of Contents

68	   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
69	   2.  Terminology and Notation . . . . . . . . . . . . . . . . . . .  6
70	     2.1.  Message and Message Field Notation . . . . . . . . . . . .  6
71	     2.2.  Variable Notation  . . . . . . . . . . . . . . . . . . . .  7
72	     2.3.  Other Notation . . . . . . . . . . . . . . . . . . . . . .  7
73	     2.4.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  7
74	   3.  Applicability Statement  . . . . . . . . . . . . . . . . . . .  8
75	   4.  Protocol Overview and Functioning  . . . . . . . . . . . . . .  9
76	     4.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .  9
77	     4.2.  LOADng Routers and LOADng Interfaces . . . . . . . . . . . 11
78	     4.3.  Information Base Overview  . . . . . . . . . . . . . . . . 11
79	     4.4.  Signaling Overview . . . . . . . . . . . . . . . . . . . . 12
80	   5.  Protocol Parameters  . . . . . . . . . . . . . . . . . . . . . 13
81	     5.1.  Protocol and Port Numbers  . . . . . . . . . . . . . . . . 13
82	     5.2.  Router Parameters  . . . . . . . . . . . . . . . . . . . . 13
83	     5.3.  Interface Parameters . . . . . . . . . . . . . . . . . . . 14
84	     5.4.  Constants  . . . . . . . . . . . . . . . . . . . . . . . . 15
85	   6.  Protocol Message Content . . . . . . . . . . . . . . . . . . . 15
86	     6.1.  Route Request (RREQ) Messages  . . . . . . . . . . . . . . 15
87	     6.2.  Route Reply (RREP) Messages  . . . . . . . . . . . . . . . 16
88	     6.3.  Route Reply Acknowledgement (RREP_ACK) Messages  . . . . . 17
89	     6.4.  Route Error (RERR) Messages  . . . . . . . . . . . . . . . 18
90	   7.  Information Base . . . . . . . . . . . . . . . . . . . . . . . 19
91	     7.1.  Routing Set  . . . . . . . . . . . . . . . . . . . . . . . 19
92	     7.2.  Local Interface Set  . . . . . . . . . . . . . . . . . . . 20
93	     7.3.  Blacklisted Neighbor Set . . . . . . . . . . . . . . . . . 20
94	     7.4.  Destination Address Set  . . . . . . . . . . . . . . . . . 21
95	     7.5.  Pending Acknowledgment Set . . . . . . . . . . . . . . . . 21
96	   8.  LOADng Router Sequence Numbers . . . . . . . . . . . . . . . . 22
97	   9.  Route Maintenance  . . . . . . . . . . . . . . . . . . . . . . 22
98	   10. Unidirectional Link Handling . . . . . . . . . . . . . . . . . 24
99	     10.1. Blacklist Usage  . . . . . . . . . . . . . . . . . . . . . 24
100	   11. Common Rules for RREQ and RREP Messages  . . . . . . . . . . . 25
101	     11.1. Identifying Invalid RREQ or RREP Messages  . . . . . . . . 26
102	     11.2. RREQ and RREP Message Processing . . . . . . . . . . . . . 27
103	   12. Route Requests (RREQs) . . . . . . . . . . . . . . . . . . . . 30
104	     12.1. RREQ Generation  . . . . . . . . . . . . . . . . . . . . . 30
105	     12.2. RREQ Processing  . . . . . . . . . . . . . . . . . . . . . 31
106	     12.3. RREQ Forwarding  . . . . . . . . . . . . . . . . . . . . . 31
107	     12.4. RREQ Transmission  . . . . . . . . . . . . . . . . . . . . 32
108	   13. Route Replies (RREPs)  . . . . . . . . . . . . . . . . . . . . 32
109	     13.1. RREP Generation  . . . . . . . . . . . . . . . . . . . . . 32
110	     13.2. RREP Processing  . . . . . . . . . . . . . . . . . . . . . 33
111	     13.3. RREP Forwarding  . . . . . . . . . . . . . . . . . . . . . 34
112	     13.4. RREP Transmission  . . . . . . . . . . . . . . . . . . . . 34
113	   14. Route Errors (RERRs) . . . . . . . . . . . . . . . . . . . . . 35
114	     14.1. Identifying Invalid RERR Messages  . . . . . . . . . . . . 36
115	     14.2. RERR Generation  . . . . . . . . . . . . . . . . . . . . . 36
116	     14.3. RERR Processing  . . . . . . . . . . . . . . . . . . . . . 37
117	     14.4. RERR Forwarding  . . . . . . . . . . . . . . . . . . . . . 38
118	     14.5. RERR Transmission  . . . . . . . . . . . . . . . . . . . . 38
119	   15. Route Reply Acknowledgments (RREP_ACKs)  . . . . . . . . . . . 39
120	     15.1. Identifying Invalid RREP_ACK Messages  . . . . . . . . . . 39
121	     15.2. RREP_ACK Generation  . . . . . . . . . . . . . . . . . . . 39
122	     15.3. RREP_ACK Processing  . . . . . . . . . . . . . . . . . . . 40
123	     15.4. RREP_ACK Forwarding  . . . . . . . . . . . . . . . . . . . 41
124	     15.5. RREP_ACK Transmission  . . . . . . . . . . . . . . . . . . 41
125	   16. Metrics  . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
126	     16.1. Specifying New Metrics . . . . . . . . . . . . . . . . . . 41
127	   17. Implementation Status  . . . . . . . . . . . . . . . . . . . . 41
128	     17.1. Implementation of Ecole Polytechnique  . . . . . . . . . . 42
129	     17.2. Implementation of Fujitsu Laboratories of America  . . . . 42
130	     17.3. Implementation of Hitachi Yokohama Research Laboratory
131	           - 1  . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
132	     17.4. Implementation of Hitachi Yokohama Research Laboratory
133	           -2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
134	   18. Security Considerations  . . . . . . . . . . . . . . . . . . . 43
135	     18.1. Security Threats . . . . . . . . . . . . . . . . . . . . . 44
136	       18.1.1.  Confidentiality . . . . . . . . . . . . . . . . . . . 44
137	       18.1.2.  Integrity . . . . . . . . . . . . . . . . . . . . . . 45
138	       18.1.3.  Channel Jamming and State Explosion . . . . . . . . . 46
139	       18.1.4.  Interaction with External Routing Domains . . . . . . 47
140	     18.2. Integrity Protection . . . . . . . . . . . . . . . . . . . 47
141	       18.2.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . 48
142	       18.2.2.  Message Generation and Processing . . . . . . . . . . 50
143	   19. LOADng Specific IANA Considerations  . . . . . . . . . . . . . 52
144	     19.1. Error Codes  . . . . . . . . . . . . . . . . . . . . . . . 52

146	   20. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 53
147	   21. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 53
148	   22. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54
149	     22.1. Normative References . . . . . . . . . . . . . . . . . . . 54
150	     22.2. Informative References . . . . . . . . . . . . . . . . . . 54
151	   Appendix A.  Gateway Considerations  . . . . . . . . . . . . . . . 56
152	   Appendix B.  LOADng Control Messages using RFC5444 . . . . . . . . 56
153	     B.1.  RREQ-Specific Message Encoding Considerations  . . . . . . 56
154	     B.2.  RREP-Specific Message Encoding Considerations  . . . . . . 58
155	     B.3.  RREP_ACK Message Encoding  . . . . . . . . . . . . . . . . 60
156	     B.4.  RERR Message Encoding  . . . . . . . . . . . . . . . . . . 61
157	     B.5.  RFC5444-Specific IANA Considerations . . . . . . . . . . . 62
158	       B.5.1.   Expert Review: Evaluation Guidelines  . . . . . . . . 62
159	       B.5.2.   Message Types . . . . . . . . . . . . . . . . . . . . 63
160	     B.6.  RREQ Message-Type-Specific TLV Type Registries . . . . . . 63
161	     B.7.  RREP Message-Type-Specific TLV Type Registries . . . . . . 64
162	     B.8.  RREP_ACK Message-Type-Specific TLV Type Registries . . . . 67
163	     B.9.  RERR Message-Type-Specific TLV Type Registries . . . . . . 67
164	   Appendix C.  LOADng Control Packet Illustrations . . . . . . . . . 68
165	     C.1.  RREQ . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
166	     C.2.  RREP . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
167	     C.3.  RREP_ACK . . . . . . . . . . . . . . . . . . . . . . . . . 71
168	     C.4.  RERR . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

170	1.  Introduction

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

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

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

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

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

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

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

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

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

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

229	2.  Terminology and Notation

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

236	   Additionally, this document uses the notations in Section 2.1,
237	   Section 2.2, and Section 2.3 and the terminology defined in
238	   Section 2.4.

240	2.1.  Message and Message Field Notation

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

247	                   MsgType.field

249	   where:

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

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

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

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

266	2.2.  Variable Notation

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

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

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

277	2.3.  Other Notation

279	   This document uses the following additional notational conventions:

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

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

287	2.4.  Terminology

289	   This document uses the following terminology:

291	   LOADng Router -  A router that implements this routing protocol.  A
292	      LOADng Router is equipped with at least one, and possibly more,
293	      LOADng Interfaces.

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

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

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

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

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

313	   Network Address -  A layer 3 IP address plus an associated prefix
314	      length.  This may be an address with an associated maximum prefix
315	      length or an address prefix including a prefix length.  A network
316	      address thus represents a range of IP addresses.

318	3.  Applicability Statement

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

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

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

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

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

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

352	   o  Is a reactive routing protocol for Mobile Ad hoc NETworks
353	      (MANETs).

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

359	   o  Supports the use of optimized flooding for RREQs.

361	   o  Enables any LOADng Router to discover bi-directional routes to
362	      destinations in the routing domain, i.e., to any other LOADng
363	      Router, as well as hosts or networks attached to that LOADng
364	      Router, in the same routing domain.

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

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

373	   o  Supports per-destination route maintenance; if a destination
374	      becomes unreachable, rediscovery of that single (bi-directional)
375	      route is performed, without need for global topology
376	      recalculation.

378	4.  Protocol Overview and Functioning

380	   The objective of this protocol is for each LOADng Router to,
381	   independently:

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

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

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

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

395	4.1.  Overview

397	   These objectives are achieved, for each LOADng Router, by performing
398	   the following tasks:

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

407	   o  Upon receiving an RREQ, insert or refresh a tuple in the Routing
408	      Set, recording a route towards the originator address from the
409	      RREQ, as well as to the neighbor LOADng Router from which the RREQ
410	      was received.  This will install the Reverse Route (towards the
411	      originator address from the RREQ).

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

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

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

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

427	   o  Upon receiving an RREP, insert or refresh a tuple in the Routing
428	      Set, recording a route towards the originator address from the
429	      RREP, as well as to the neighbor LOADng Router, from which that
430	      RREP was received.  This will install the Forward Route (towards
431	      the originator address from the RREP).  The originator address is
432	      either an address from the Local Interface Set of the LOADng
433	      Router, or an address from its Destination Address Set (i.e., an
434	      address of a host attached to that LOADng Router).

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

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

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

456	4.2.  LOADng Routers and LOADng Interfaces

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

461	   o  Is configured with one or more addresses.

463	   o  Has a number of interface parameters.

465	   In addition to a set of LOADng Interfaces as described above, each
466	   LOADng Router:

468	   o  Has a number of router parameters.

470	   o  Has an Information Base.

472	   o  Generates and processes RREQ, RREP, RREP_ACK and RERR messages,
473	      according to this specification.

475	4.3.  Information Base Overview

477	   Necessary protocol state is recorded by way of five information sets:
478	   the "Routing Set", the "Local Interface Set", the "Blacklisted
479	   Neighbor Set", the "Destination Address Set", and the "Pending
480	   Acknowledgment Set".

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

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

496	   The Blacklisted Neighbor Set contains tuples representing neighbor
497	   LOADng Interface addresses of a LOADng Router with which
498	   unidirectional connectivity has been recently detected.

500	   The Destination Address Set contains tuples representing addresses,
501	   for which the LOADng Router is responsible, i.e., addresses of this
502	   LOADng Router, or of hosts and networks directly attached to this
503	   LOADng Router and which use it to connect to the routing domain.

505	   These addresses may in particular belong to devices which do not
506	   implement LOADng, and thus cannot process LOADng messages.  A LOADng
507	   Router provides connectivity to these addresses by generating RREPs
508	   in response to RREQs directed towards them.

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

514	   The Routing Set, the Blacklisted Neighbor Set and the Pending
515	   Acknowledgment Set are updated by this protocol.  The Local Interface
516	   Set and the Destination Address Set are used, but not updated by this
517	   protocol.

519	4.4.  Signaling Overview

521	   This protocol generates and processes the following routing messages:

523	   Route Request (RREQ) -  Generated by a LOADng Router when it has a
524	      data packet to deliver to a given destination, where the data
525	      packet source is local to that LOADng Router (i.e., is an address
526	      in the Local Interface Set or Destination Address Set of that
527	      LOADng Router), but where it does not have an available tuple in
528	      its Routing Set indicating a route to that destination.  An RREQ
529	      contains:

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

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

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

542	      An RREQ is flooded through the network, according to the flooding
543	      operation specified for the network.

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

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

554	      *  The (destination) address towards which the RREP is to be sent.
555	         More precisely, the destination address determines the unicast
556	         route which the RREP follows.

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

560	   Route Reply Acknowledgment (RREP_ACK) -  Generated by a LOADng Router
561	      as a response to an RREP, in order to signal to the neighbor that
562	      transmitted the RREP that the RREP was successfully received.
563	      Receipt of an RREP_ACK indicates that the link between these two
564	      neighboring LOADng Routers is bidirectional.  An RREP_ACK is
565	      unicast to the neighbor from which the RREP has arrived, and is
566	      not forwarded.  RREP_ACKs are generated only in response to an
567	      RREP which, by way of a flag, has explicitly indicated that an
568	      RREP_ACK is desired.

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

575	5.  Protocol Parameters

577	   The following parameters and constants are used in this
578	   specification.

580	5.1.  Protocol and Port Numbers

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

585	5.2.  Router Parameters

587	   NET_TRAVERSAL_TIME -  is the maximum time that a RREQ message is
588	      expected to take when traversing from one end of the network to
589	      the other, with the consideration of RREQ_MAX_JITTER.

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

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

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

601	   MAX_DIST -  is the value representing the maximum possible metric
602	      (R_metric field).

604	   B_HOLD_TIME -  is the time during which the link between the neighbor
605	      LOADng Router and this LOADng Router MUST be considered as non-
606	      bidirectional, and that therefore RREQs received from that
607	      neighbor LOADng Router MUST be ignored during that time
608	      (B_HOLD_TIME).  B_HOLD_TIME should be greater than 2 x
609	      NET_TRAVERSAL_TIME x RREQ_RETRIES, to ensure that subsequent RREQs
610	      will reach the destination via a route, excluding the link to the
611	      blacklisted neighbor.

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

616	5.3.  Interface Parameters

618	   Different LOADng Interfaces (on the same or on different LOADng
619	   Routers) MAY employ different interface parameter values and MAY
620	   change their interface parameter values dynamically.  A particular
621	   case is where all LOADng Interfaces on all LOADng Routers within a
622	   given LOADng routing domain employ the same set of interface
623	   parameter values.

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

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

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

640	   RREP_ACK_TIMEOUT -  is the minimum amount of time after transmission
641	      of an RREP, that a LOADng Router SHOULD wait for an RREP_ACK from
642	      a neighbor LOADng Router, before considering the link to this
643	      neighbor to be unidirectional.

645	5.4.  Constants

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

653	6.  Protocol Message Content

655	   The protocol messages, generated and processed by LOADng, are
656	   described in this section using the notational conventions described
657	   in Section 2.  The encoding of messages for transmission by way of
658	   [RFC5444] packets/messages is described in Appendix B, and Appendix C
659	   illustrates the bit layout of a selection of LOADng control messages.
660	   Unless stated otherwise, the message fields described below are set
661	   by the LOADng Router that generates the message, and MUST NOT be
662	   changed by intermediate LOADng Routers.

664	6.1.  Route Request (RREQ) Messages

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

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

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

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

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

680	   RREQ.route-metric  is a unsigned integer field, of length defined by
681	      RREQ.metric-type, which specifies the route metric of the route
682	      (the sum of the link metrics of the links), through which this
683	      RREQ has traveled.

685	   RREQ.hop-count  is an unsigned integer field and specifies the total
686	      number of hops which the message has traversed from the
687	      RREQ.originator.

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

692	   RREQ.originator  is an identifier of RREQ.addr-length + 1 octets,
693	      specifying the address of the LOADng Interface over which this
694	      RREQ was generated, and to which a route (the "reverse route") is
695	      supplied by this RREQ.  In case the message is generated by a
696	      LOADng Router on behalf of an attached host, RREQ.originator
697	      corresponds to an address of that host, otherwise it corresponds
698	      to an address of the sending LOADng Interface of the LOADng
699	      Router.

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

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

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

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

719	6.2.  Route Reply (RREP) Messages

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

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

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

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

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

735	   RREP.route-metric  is a unsigned integer field, of length defined by
736	      RREP.metric-type, which specifies the route metric of the route
737	      (the sum of the link metrics of the links) through which this RREP
738	      has traveled.

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

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

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

752	   RREP.originator  is an identifier of RREP.addr-length + 1 octets,
753	      specifying the address for which this RREP was generated, and to
754	      which a route (the "forward route") is supplied by this RREP.  In
755	      case the message is generated on a LOADng Router on behalf of an
756	      attached host, RREP.originator corresponds to an address of that
757	      host, otherwise it corresponds to an address of the LOADng
758	      Interface of the LOADng Router, over which the RREP was generated.

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

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

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

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

780	6.3.  Route Reply Acknowledgement (RREP_ACK) Messages

782	   A Route Reply Acknowledgement (RREP_ACK) message has the following
783	   fields:

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

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

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

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

797	   RREP_ACK messages are sent only across a single link and are never
798	   forwarded.

800	6.4.  Route Error (RERR) Messages

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

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

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

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

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

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

820	   RERR.destination  is an identifier of RERR.address-length + 1 octets,
821	      specifying the destination address of this RERR message.
822	      RERR.destination is, in general, the source address of a data
823	      packet, for which delivery to RERR.unreachableAddress failed, and
824	      the unicast destination of the RERR message is the LOADng Router
825	      which has RERR.destination listed in a Local Interface Tuple or in
826	      a Destination Address Tuple.

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

831	   The following fields of an RERR message are immutable, i.e., they
832	   MUST NOT be changed during processing or forwarding of the message:

834	   RERR.addr-length, RERR.errorcode, RERR.unreachableAddress,
835	   RERR.originator and RERR.destination.

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

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

845	7.  Information Base

847	   Each LOADng Router maintains an Information Base, containing the
848	   information sets necessary for protocol operation, as described in
849	   the following sections.  The organization of information into these
850	   information sets is non-normative, given so as to facilitate
851	   description of message generation, forwarding and processing rules in
852	   this specification.  An implementation may choose any representation
853	   or structure for when maintaining this information.

855	7.1.  Routing Set

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

861	   (R_dest_addr, R_next_addr, R_metric, R_metric_type, R_hop_count,
862	      R_seq_num, R_bidirectional, R_local_iface_addr, R_valid_time)

864	   where:

866	   R_dest_addr -  is the address of the destination, either an address
867	      of a LOADng Interface of a destination LOADng Router, or an
868	      address of an interface reachable via the destination LOADng
869	      Router, but which is outside the routing domain.

871	   R_next_addr -  is the address of the "next hop" on the selected route
872	      to the destination.

874	   R_metric -  is the metric associated with the selected route to the
875	      destination with address R_dest_addr.

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

880	   R_hop_count -  is the hop count of the selected route to the
881	      destination with address R_dest_addr.

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

888	   R_bidirectional -  is a boolean flag, which specifies if the Routing
889	      Tuple is verified as representing a bi-directional route.  Data
890	      traffic SHOULD only be routed through a routing tuple with
891	      R_bidirectional flag equals TRUE, unless the LOADng Router is
892	      configured as accepting routes without bi-directionality
893	      verification explicitly by setting USE_BIDIRECTIONAL_LINK_ONLY to
894	      FALSE of the interface with R_local_iface_address.

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

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

902	7.2.  Local Interface Set

904	   A LOADng Router's Local Interface Set records its local LOADng
905	   Interfaces.  It consists of Local Interface Tuples, one per LOADng
906	   Interface:

908	               (I_local_iface_addr_list)

910	   where:

912	   I_local_iface_addr_list -  is an unordered list of the network
913	      addresses of this LOADng Interface.

915	   The implementation MUST initialize the Local Interface Set with at
916	   least one tuple containing at least one address of an LOADng
917	   Interface.  The Local Interface Set MUST be updated if there is a
918	   change of the LOADng Interfaces of a LOADng Router (i.e., a LOADng
919	   Interface is added, removed or changes addresses).

921	7.3.  Blacklisted Neighbor Set

923	   The Blacklisted Neighbor Set records the neighbor LOADng Interface
924	   addresses of a LOADng Router, with which connectivity has been
925	   detected to be unidirectional.  Specifically, the Blacklisted
926	   Neighbor Set records neighbors from which an RREQ has been received
927	   (i.e., through which a Forward Route would possible) but to which it
928	   has been determined that it is not possible to communicate (i.e.,
929	   forwarding Route Replies via this neighbor fails, rendering
930	   installing the Forward Route impossible).  It consists of Blacklisted
931	   Neighbor Tuples:

933	               (B_neighbor_address, B_valid_time)

935	   where:

937	   B_neighbor_address -  is the address of the blacklisted neighbor
938	      LOADng Interface.

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

943	7.4.  Destination Address Set

945	   The Destination Address Set records addresses, for which a LOADng
946	   Router will generate RREPs in response to received RREQs, in addition
947	   to its own LOADng Interface addresses (as listed in the Local
948	   Interface Set).  The Destination Address Set thus represents those
949	   destinations (i.e., hosts), for which this LOADng Router is providing
950	   connectivity.  It consists of Destination Address Tuples:

952	               (D_address)

954	   where:

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

960	   The Destination Address Set is used for generating signaling, but is
961	   not itself updated by signaling specified in this document.  Updates
962	   to the Destination Address Set are due to changes of the environment
963	   of a LOADng Router - hosts or external networks being connected to or
964	   disconnected from a LOADng Router.  The Destination Address Set may
965	   be administrationally provisioned, or provisioned by external
966	   protocols.

968	7.5.  Pending Acknowledgment Set

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

975	               (P_next_hop, P_originator, P_seq_num,
976	                P_ack_received, P_ack_timeout)

978	   where:

980	   P_next_hop -  is the address of the neighbor LOADng Interface to
981	      which the RREP was sent.

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

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

987	   P_ack_received -  is a boolean flag, which specifies the tuple has
988	      been acknowledged by a corresponding RREP_ACK message.  The
989	      default value is FALSE.

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

993	8.  LOADng Router Sequence Numbers

995	   Each LOADng Router maintains a single sequence number, which must be
996	   included in each RREQ or RREP message it generates.  Each LOADng
997	   Router MUST make sure that no two messages (both RREQ and RREP) are
998	   generated with the same sequence number, and MUST generate sequence
999	   numbers such that these are monotonically increasing.  This sequence
1000	   number is used as information for when comparing routes to the LOADng
1001	   Router having generated the message.

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

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

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

1015	9.  Route Maintenance

1017	   Tuples in the Routing Set are maintained by way of five different
1018	   mechanisms:

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

1022	   o  Data traffic delivery success.

1024	   o  Data traffic delivery failure.

1026	   o  External signals indicating that a tuple in the Routing Set needs
1027	      updating.

1029	   o  Information expiration.

1031	   Routing Tuples in the Routing Set contain a validity time, which
1032	   specifies the time until which the information recorded in this tuple
1033	   is considered valid.  After this time, the information in such tuples
1034	   is to be considered as invalid, for the processing specified in this
1035	   document.

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

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

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

1059	   o  Conversely, for each successful delivery of a packet to a neighbor
1060	      or a destination, if signaled by a lower layer or a transport
1061	      mechanism, or each positive confirmation of the presence of a
1062	      neighbor by way of an external neighbor discovery protocol, MAY be
1063	      interpreted as validation that the corresponding Routing Tuple(s)
1064	      are valid, and their R_valid_time refreshed correspondingly.  Note
1065	      that when refreshing a Routing Tuple corresponding to a
1066	      destination of a data packet, the Routing Tuple corresponding to
1067	      the next hop toward that destination SHOULD also be refreshed.

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

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

1078	10.  Unidirectional Link Handling

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

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

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

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

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

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

1102	   When a LOADng Router detects, via one of these mechanisms, that a
1103	   link to a neighbor LOADng Router is unidirectional or broken, the
1104	   LOADng Router MUST blacklist this neighbor (see Section 10.1).
1105	   Conversely, if a LOADng Router detects via one of these mechanisms
1106	   that a previously blacklisted LOADng Router has a bidirectional link
1107	   to this LOADng Router, it MAY remove it from the blacklist before the
1108	   B_valid_time of the corresponding tuple.

1110	10.1.  Blacklist Usage

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

1117	   o  B_neighbor_address := the address of the blacklisted neighbor
1118	      LOADng Router interface

1120	   o  B_valid_time := current_time + B_HOLD_TIME

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

1127	   o  Every RREQ received from this neighbor LOADng Router interface
1128	      MUST be discarded;

1130	11.  Common Rules for RREQ and RREP Messages

1132	   RREQ and RREP messages, both, supply routes between their recipients
1133	   and the originator of the RREQ or RREP message.  The two message
1134	   types therefore share common processing rules, and differ only in the
1135	   following:

1137	   o  RREQ messages are multicast or broadcast, intended to be received
1138	      by all LOADng Routers in the network, whereas RREP messages are
1139	      all unicast, intended to be received only by LOADng Routers on a
1140	      specific route towards a specific destination.

1142	   o  Receipt of an RREQ message by a LOADng router, which has the
1143	      RREQ.destination address in its Local Interface Set or Destination
1144	      Address Set MUST trigger the procedures for generation of an RREP
1145	      message.

1147	   o  Receipt of an RREP message with RREP.ackrequired set MUST trigger
1148	      generation of an RREP_ACK message.

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

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

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

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

1162	   >  is the comparison operator for sequence numbers, as specified in
1163	      Section 8.

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

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

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

1175	   link-metric  is a variable, representing the link metric between this
1176	      LOADng Router and the LOADng Router from which the RREQ or RREP
1177	      message was received, as calculated by the receiving LOADng
1178	      Router, see Section 16.

1180	   route-metric  is a variable, representing the route metric, as
1181	      included in the received RREQ or RREP message, plus the link-
1182	      metric for the link, over which the RREQ or RREP was received,
1183	      i.e., the total route cost from the originator to this LOADng
1184	      Router.

1186	11.1.  Identifying Invalid RREQ or RREP Messages

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

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

1196	   o  The address contained in MSG.originator is an address of this
1197	      LOADng Router.

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

1201	      *  R_dest_addr = MSG.originator

1203	      *  R_seq_num > MSG.seq-num

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

1209	   A LOADng Router MAY recognize additional reasons for identifying that
1210	   an RREQ or RREP message is invalid for processing, e.g., to allow a
1211	   security mechanism as specified in Section 18.2 to perform
1212	   verification of integrity check values and prevent processing of
1213	   unverifiable RREQ or RREP message by this protocol.

1215	11.2.  RREQ and RREP Message Processing

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

1219	   1.  Included TLVs are processed/updated according to their
1220	       specification.

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

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

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

1229	       *  Set the variable used-metric-type to the value of MSG.metric-
1230	          type.

1232	       *  Determine the link metric over the link over which the message
1233	          was received, according to used-metric-type, and set the
1234	          variable link-metric to the calculated value.

1236	       *  Compute the route metric to MSG.originator according to used-
1237	          metric-type by adding link-metric to the received-route-metric
1238	          advertised by the received message, and set the variable
1239	          route-metric to the calculated value.

1241	   5.  Otherwise:

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

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

1247	       *  Set the variable link-metric to MAX_DIST.

1249	   6.  Find the Routing Tuple (henceforth, Matching Routing Tuple)
1250	       where:

1252	       *  R_dest_addr = MSG.originator

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

1258	       *  R_dest_addr := MSG.originator
1259	       *  R_next_addr := previous-hop

1261	       *  R_metric_type := used-metric-type

1263	       *  R_metric := MAX_DIST

1265	       *  R_hop_count := hop-count

1267	       *  R_seq_num := -1

1269	       *  R_valid_time := current time + R_HOLD_TIME

1271	       *  R_bidirectional := FALSE

1273	       *  R_local_iface_addr := the address of the LOADng Interface
1274	          through which the message was received.

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

1279	       1.  If

1281	           +  R_seq_num = MSG.seq-num; AND

1283	           +  R_metric_type = used-metric-type; AND

1285	           +  R_metric > route-metric

1287	           OR

1289	           +  R_seq_num = MSG.seq-num; AND

1291	           +  R_metric_type = used-metric-type; AND

1293	           +  R_metric = route-metric; AND

1295	           +  R_hop_count > hop-count

1297	           OR

1299	           +  R_seq_num = MSG.seq-num; AND

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

1303	           +  R_metric_type = HOP_COUNT

1305	           OR
1306	           +  R_seq_num < MSG.seq-num

1308	           Then:

1310	           1.  The message is used for updating the Routing Set. The
1311	                Routing Tuple, where:

1313	                -  R_dest_addr = MSG.originator;

1315	                is updated thus:

1317	                -  R_next_addr := previous-hop

1319	                -  R_metric_type = used-metric-type

1321	                -  R_metric := route-metric

1323	                -  R_hop_count := hop-count

1325	                -  R_seq_num := MSG.seq-num

1327	                -  R_valid_time := current time + R_HOLD_TIME

1329	                -  R_bidirectional := TRUE, if the message being
1330	                   processed is an RREP.

1332	           2.  If previous-hop is not equal to MSG.originator, and if
1333	                there is no Matching Routing Tuple in the Routing Set
1334	                with R_dest_addr = previous-hop, create a new Matching
1335	                Routing Tuple with:

1337	                -  R_dest_addr := previous-hop

1339	                -  R_next_addr := previous-hop

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

1344	                -  R_metric_type := used-metric-type

1346	                -  R_metric := link-metric

1348	                -  R_hop_count := 1

1350	                -  R_seq_num := -1

1352	                -  R_valid_time := current time + R_HOLD_TIME
1353	                -  R_bidirectional := TRUE, if the processed message is
1354	                   an RREP, otherwise FALSE.

1356	                -  R_local_iface_addr := the address of the LOADng
1357	                   Interface through which the message was received.

1359	       2.  Otherwise, if the message is an RREQ, it is not processed
1360	           further and is not considered for forwarding.  If it is an
1361	           RREP and if RREP.ackrequired is set, an RREP_ACK message MUST
1362	           be sent to the previous-hop, according to Section 15.2.  The
1363	           RREP is not considered for forwarding.

1365	12.  Route Requests (RREQs)

1367	   Route Requests (RREQs) are generated by a LOADng Router when it has
1368	   data packets to deliver to a destination, where the data packet
1369	   source is local to that LOADng Router (i.e., is an address in the
1370	   Local Interface Set or Destination Address Set of that LOADng
1371	   Router), but for which the LOADng router has no matching tuple in the
1372	   Routing Set. Furthermore, if there is a matching tuple in the Routing
1373	   Set with the R_bidirectional set to FALSE, and the parameter
1374	   USE_BIDIRECTIONAL_LINK_ONLY of the interface with
1375	   R_local_iface_address equals TRUE, an RREQ MUST be generated.

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

1384	12.1.  RREQ Generation

1386	   An RREQ message is generated according to Section 6 with the
1387	   following content:

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

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

1394	   o  RREQ.route-metric := 0.

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

1399	   o  RREQ.hop-count := 0;
1400	   o  RREQ.hop-limit := MAX_HOP_LIMIT;

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

1404	   o  RREQ.originator := one address of the LOADng Interface of the
1405	      LOADng Router that generates the RREQ.  If the LOADng Router is
1406	      generating RREQ on behalf of a host connected to this LOADng
1407	      Router, the source address of the data packet, generated by that
1408	      host, is used;

1410	12.2.  RREQ Processing

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

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

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

1423	   3.  If RREQ.destination is listed in I_local_iface_addr_list of any
1424	       Local Interface Tuple, or corresponds to D_address of any
1425	       Destination Address Tuple of this LOADng Router, the RREP
1426	       generation process in Section 13.1 MUST be applied.  The RREQ is
1427	       not considered for forwarding.

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

1433	12.3.  RREQ Forwarding

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

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

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

1445	   3.  RREQ.hop-count := hop-count (as set in Section 11.2)
1446	   4.  RREQ.hop-limit := hop-limit (as set in Section 11.2)

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

1457	12.4.  RREQ Transmission

1459	   RREQs, whether initially generated or forwarded, are sent to all
1460	   neighbor LOADng Routers through all interfaces in the Local Interface
1461	   Set.

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

1470	13.  Route Replies (RREPs)

1472	   Route Replies (RREPs) are generated by a LOADng Router in response to
1473	   an RREQ (henceforth denoted "corresponding RREQ"), and are sent by
1474	   the LOADng Router which has, in either its Destination Address Set or
1475	   in its Local Interface Set, the address from RREQ.destination.  RREPs
1476	   are sent, hop by hop, in unicast towards the originator of the RREQ,
1477	   in response to which the RREP was generated, along the Reverse Route
1478	   installed by that RREQ.  A LOADng Router, upon forwarding an RREP,
1479	   installs the Forward Route towards the RREP.destination.

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

1485	13.1.  RREP Generation

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

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

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

1506	   o  RREP.metric-type set to the same value as the RREQ.metric-type in
1507	      the corresponding RREQ if the metric type is known to the router.
1508	      Otherwise, RREP.metric-type is set to HOP_COUNT;

1510	   o  RREP.route-metric := 0

1512	   o  RREP.hop-count := 0;

1514	   o  RREP.hop-limit := MAX_HOP_LIMIT;

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

1520	   o  RREP.originator := the address of the LOADng Router, generating
1521	      the RREP.  If the LOADng Router is generating an RREP on behalf of
1522	      the hosts connected to it, or on behalf of one of the addresses
1523	      contained in the LOADng Routers Destination Address Set, the host
1524	      address is used.

1526	   The RREP that is generated is transmitted according to Section 13.4.

1528	13.2.  RREP Processing

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

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

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

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

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

1547	   5.  Otherwise, if RREP.destination is not listed in
1548	       I_local_iface_addr_list of any Local Interface Tuple and does not
1549	       correspond to D_address of any Destination Address Tuple of this
1550	       LOADng Router, the RREP message is considered for forwarding
1551	       according to Section 13.3.

1553	13.3.  RREP Forwarding

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

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

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

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

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

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

1571	   The RREP message is then unicast to the next hop towards
1572	   RREP.destination.

1574	13.4.  RREP Transmission

1576	   An RREP is, ultimately, destined for the LOADng Router which has the
1577	   address listed in the RREP.destination field in either of its Local
1578	   Interface Set, or in its Destination Address Set. The RREP is
1579	   forwarded in unicast towards that LOADng Router.  The RREP MUST,
1580	   however, be transmitted so as to allow it to be processed in each
1581	   intermediate LOADng Router to:

1583	   o  Install proper forward routes; AND

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

1587	   RREP Transmission is accomplished by the following procedure:

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

1592	       *  R_dest_addr = RREP.destination

1594	   2.  Find the Local Interface Tuple (henceforth, "Matching Interface
1595	       Tuple), where:

1597	       *  I_local_iface_addr_list contains R_local_iface_addr from the
1598	          Matching Routing Tuple

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

1603	       *  Create a new Pending Acknowledgment Tuple with:

1605	          +  P_next_hop := R_next_addr from the Matching Routing Tuple

1607	          +  P_originator := RREP.originator

1609	          +  P_seq_num := RREP.seq-num

1611	          +  P_ack_received := FALSE

1613	          +  P_ack_timeout := current_time + RREP_ACK_TIMEOUT

1615	       *  RREP.ackrequired := TRUE

1617	   4.  Otherwise:

1619	       *  RREP.ackrequired := FALSE

1621	   5.  The RREP is transmitted over the LOADng Interface, identified by
1622	       the Matching Interface Tuple to the neighbor LOADng Router,
1623	       identified by R_next_addr from the Matching Routing Tuple.

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

1629	14.  Route Errors (RERRs)

1631	   If a LOADng Router fails to deliver a data packet to a next hop or a
1632	   destination, and if neither the source nor destination address of
1633	   that data packet belongs to the Destination Address Set of that
1634	   LOADng Router, it MUST generate a Route Error (RERR).  This RERR MUST
1635	   be sent along the Reverse Route towards the source of the data packet
1636	   for which delivery was unsuccessful (to the last LOADng Router along
1637	   the Reverse Route, if the data packet was originated by a host behind
1638	   that LOADng Router).

1640	   The following definition is used in this section:

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

1645	14.1.  Identifying Invalid RERR Messages

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

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

1654	   o  The address contained in RERR.originator is an address of this
1655	      LOADng Router.

1657	   A LOADng Router MAY recognize additional reasons, external to this
1658	   specification, for identifying that an RERR message is invalid for
1659	   processing, e.g., to allow a security mechanism as specified in
1660	   Section 18.2 to perform verification of integrity check values and
1661	   prevent processing of unverifiable RERR message by this protocol.

1663	14.2.  RERR Generation

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

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

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

1675	   o  RERR.unreachableAddress := the destination address from the
1676	      unsuccessfully delivered data packet.

1678	   o  RERR.originator := one address of the LOADng Interface of the
1679	      LOADng Router that generates the RERR.

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

1684	   o  RERR.hop-limit := MAX_HOP_LIMIT;

1686	14.3.  RERR Processing

1688	   For the purpose of the processing description below, the following
1689	   additional notation is used:

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

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

1697	   Upon receiving an RERR, a LOADng Router MUST perform the following
1698	   steps:

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

1704	   2.  Included TLVs are processed/updated according to their
1705	       specification.

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

1709	   4.  Find the Routing Tuple (henceforth "matching Routing Tuple") in
1710	       the Routing Set where:

1712	       *  R_dest_addr = RERR.unreachableAddress

1714	       *  R_next_addr = previous-hop

1716	   5.  If no matching Routing Tuple is found, the RERR is not processed
1717	       further, but is considered for forwarding, as specified in
1718	       Section 14.4.

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

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

1726	           +  R_valid_time := EXPIRED

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

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

1735	14.4.  RERR Forwarding

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

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

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

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

1748	       *  D_address = RERR.destination

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

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

1757	       *  I_local_iface_addr_list contains RERR.destination.

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

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

1767	14.5.  RERR Transmission

1769	   An RERR is, ultimately, destined for the LOADng Router which has the
1770	   address listed in the RERR.destination field in either of its Local
1771	   Interface Set, or in its Destination Address Set. The RERR is
1772	   forwarded in unicast towards that LOADng Router.  The RERR MUST,
1773	   however, be transmitted so as to allow it to be processed in each
1774	   intermediate LOADng Router to:

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

1779	   RERR Transmission is accomplished by the following procedure:

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

1784	       *  R_dest_addr = RERR.destination

1786	   2.  Find the Local Interface Tuple (henceforth, "Matching Interface
1787	       Tuple), where:

1789	       *  I_local_iface_addr_list contains R_local_iface_addr from the
1790	          Matching Routing Tuple

1792	   3.  The RERR is transmitted over the LOADng Interface, identified by
1793	       the Matching Interface Tuple to the neighbor LOADng Router,
1794	       identified by R_next_addr from the Matching Routing Tuple.

1796	15.  Route Reply Acknowledgments (RREP_ACKs)

1798	   A LOADng Router MUST signal in a transmitted RREP that it is
1799	   expecting an RREP_ACK, by setting RREP.ackrequired flag in the RREP.
1800	   When doing so, the LOADng Router MUST also add a tuple (P_next_hop,
1801	   P_originator, P_seq_num, P_ack_timeout) to the Pending Acknowledgment
1802	   Set, and set P_ack_timeout to current_time + RREP_ACK_TIMEOUT, as
1803	   described in Section 13.4.

1805	   The following definition is used in this section:

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

1810	15.1.  Identifying Invalid RREP_ACK Messages

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

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

1819	   A LOADng Router MAY recognize additional reasons, external to this
1820	   specification, for identifying that an RREP_ACK message is invalid
1821	   for processing, e.g., to allow a security protocol to perform
1822	   verification of signatures and prevent processing of unverifiable
1823	   RREP_ACK message by this protocol.

1825	15.2.  RREP_ACK Generation

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

1831	   An RREP_ACK message is generated by a LOADng Router with the
1832	   following content:

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

1837	   o  RREP_ACK.seq-num := the value of the RREP.seq-num field of the
1838	      received RREP;

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

1842	15.3.  RREP_ACK Processing

1844	   On receiving an RREP_ACK from a LOADng neighbor LOADng Router, a
1845	   LOADng Router MUST do the following:

1847	   1.  If the RREP_ACK is invalid for processing, as defined in
1848	       Section 15.1, the RREP_ACK MUST be discarded without further
1849	       processing.

1851	   2.  Find the Routing Tuple (henceforth, Matching Routing Tuple)
1852	       where:

1854	       *  R_dest_addr = previous-hop;

1856	       The Matching Routing Tuple is updated as follows:

1858	       *  R_bidirectional := TRUE

1860	   3.  If a Pending Acknowledgement Tuple (henceforth, Matching Pending
1861	       Acknowledgement Tuple) exists, where:

1863	       *  P_next_hop is the address of the LOADng Router from which the
1864	          RREP_ACK was received.

1866	       *  P_originator = RREP_ACK.destination

1868	       *  P_seq_num = RREP_ACK.seq-num

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

1873	       *  P_ack_received := TRUE

1875	       *  P_ack_timeout := EXPIRED

1877	15.4.  RREP_ACK Forwarding

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

1882	15.5.  RREP_ACK Transmission

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

1887	16.  Metrics

1889	   This specification enables the use of different metrics for when
1890	   calculating route metrics.

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

1896	16.1.  Specifying New Metrics

1898	   When defining a metric, the following considerations SHOULD be taken
1899	   into consideration:

1901	   o  The definition of the R_metric field, as well as the value of
1902	      MAX_DIST.

1904	17.  Implementation Status

1906	   This section records the status of known implementations of the
1907	   protocol defined by this specification at the time of posting of this
1908	   Internet-Draft, and based on a proposal described in [RFC6982].  The
1909	   description of implementations in this section is intended to assist
1910	   the IETF in its decision processes in progressing drafts to RFCs.
1911	   Please note that the listing of any individual implementation here
1912	   does not imply endorsement by the IETF.  Furthermore, no effort has
1913	   been spent to verify the information presented here that was supplied
1914	   by IETF contributors.  This is not intended as, and must not be
1915	   construed to be, a catalog of available implementations or their
1916	   features.  Readers are advised to note that other implementations may
1917	   exist.

1919	   According to [RFC6982], "this will allow reviewers and working groups
1920	   to assign due consideration to documents that have the benefit of
1921	   running code, which may serve as evidence of valuable experimentation
1922	   and feedback that have made the implemented protocols more mature.
1923	   It is up to the individual working groups to use this information as
1924	   they see fit".

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

1932	17.1.  Implementation of Ecole Polytechnique

1934	   This implementation is developed by the Networking Group at Ecole
1935	   Polytechnique.  It can run over real network interfaces, and can also
1936	   be integrated with the network simulator NS2.  It is a Java
1937	   implementation, and can be used on any platform that includes a Java
1938	   virtual machine.

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

1948	   All the protocol functions of this revision (-08) of the
1949	   specification, including RREQ/RREP/RREP-ACK/RERR generation,
1950	   processing, forwarding and transmission, as well as blacklisting, are
1951	   implemented.

1953	   The latest implementation conforms to the LOADng-07 revision as
1954	   documented in this specification.  This software is currently closed
1955	   source.

1957	17.2.  Implementation of Fujitsu Laboratories of America

1959	   This implementation is developed by Fujitsu Laboratories of America.
1960	   It is a Java implementation, structured in multiple separate modules,
1961	   notably a [RFC5444] generator and parser, and integration module in
1962	   the network simulator Ns-2, a kernel module for integrating the
1963	   implementation in a Linux kernel (not yet completed), and the
1964	   protocol core.

1966	   The implementation is mature and has been tested both in
1967	   interoperability tests with other implementations
1968	   [I-D.loadng-interop-report], as well as large-scale simulations with
1969	   hundreds of routers.  The implementation is not currently used in
1970	   deployments.  The implementation supports all LOADng functions (RREQ,
1971	   RREP, RREP-ACK generation, processing, forwarding and transmission),
1972	   and conforms to the LOADng-06 specification.  The software is
1973	   currently closed source.

1975	17.3.  Implementation of Hitachi Yokohama Research Laboratory - 1

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

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

1991	17.4.  Implementation of Hitachi Yokohama Research Laboratory -2

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

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

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

2006	18.  Security Considerations

2008	   This section analyzes security threats of LOADng, and specifies
2009	   mandatory-to-implement security mechanisms of LOADng for integrity
2010	   and replay projection.  A deployment of LOADng protocol may choose to
2011	   employ an alternative(s) to these mechanisms.  For example, it may
2012	   choose to use an alternative Integrity Check Value (ICV) with
2013	   preferred properties, and/or it may use an alternative timestamp.  A
2014	   deployment may choose to use no such security mechanisms, but this is
2015	   not recommended.

2017	   Section 18.1 illustrates the security threats of the protocol
2018	   assuming if no security measure is applied.  Section 18.2 specifies
2019	   how to use Integrity Check Value (ICV) and timestamps to project the
2020	   protocol messages, and how the security mechanisms can alleviate the
2021	   threats.

2023	18.1.  Security Threats

2025	   As a reactive routing protocol, this protocol is a potential target
2026	   for various attacks.  Various possible vulnerabilities are discussed
2027	   in this section.  For each kind of threats, the vulnerabilities of
2028	   the protocol is firstly analyzed, with the assumption that no
2029	   security measure is applied.  Then how the integrity protection
2030	   specified in Section 18.2 can alleviate the threats are discussed,
2031	   with the analyses of limitations.

2033	18.1.1.  Confidentiality

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

2040	   o  Part of the network topology is revealed to anyone who listens,
2041	      specifically (i) the identity (and existence) of the source LOADng
2042	      Router; (ii) the identity of the destination; and (iii) the fact
2043	      that a path exists between the source LOADng Router and the LOADng
2044	      Router from which the RREQ was received.

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

2052	   This protocol also unicasts Route Replies (RREPs) from the
2053	   destination of an RREQ to the originator of that same RREQ.  Hence,
2054	   if used in an unprotected network (such as an unprotected wireless
2055	   network):

2057	   o  Part of the network topology is revealed to anyone who is near or
2058	      on the unicast path of the RREP (such as within radio range of
2059	      LOADng Routers on the unicast path in an unprotected wireless
2060	      network), specifically that a path from the originator (of the
2061	      RREP) to the destination (of the RREP) exists.

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

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

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

2079	   This protocol does not specify mechanism to protect the
2080	   confidentiality of network topology.  Unless the information about
2081	   the network topology itself is confidential, integrity of control
2082	   messages is sufficient to admit only trusted routers (i.e., routers
2083	   with valid credentials) to the network.

2085	   In situations where the confidentiality of the network topology is of
2086	   importance, regular cryptographic techniques, can be applied to
2087	   ensure that control traffic can be read and interpreted by only those
2088	   authorized to do so.

2090	18.1.2.  Integrity

2092	   A LOADng Router injects topological information into the network by
2093	   way of transmitting RREQ and RREP messages, and removes installed
2094	   topological information by way of transmitting RERR messages.  If
2095	   some LOADng Routers for some reason, malice or malfunction, are able
2096	   to inject invalid control traffic, network integrity may be
2097	   compromised.  Therefore, message authentication is recommended.

2099	   Different such situations may occur if not integrity protection
2100	   mechanism is applied, for instance:

2102	   1.  A LOADng Router generates RREQ messages, pretending to be another
2103	       LOADng Router;

2105	   2.  A LOADng Router generates RREP messages, pretending to be another
2106	       LOADng Router;

2108	   3.  A LOADng Router generates RERR messages, pretending to be another
2109	       LOADng Router;

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

2114	   5.  A LOADng Router forwards altered control messages;

2116	   6.  A LOADng Router does not forward control messages;
2117	   7.  A LOADng Router forwards RREPs and RREQs, but does not forward
2118	       unicast data traffic;

2120	   8.  A LOADng Router "replays" previously recorded control messages
2121	       from another LOADng Router.

2123	18.1.3.  Channel Jamming and State Explosion

2125	   A reactive protocol, LOADng control messages are generated in
2126	   response to network events.  For RREQs, such an event is that a data
2127	   packet is present in a router which does not have a route to the
2128	   destination of the data packet, or that the router receives an RERR
2129	   message, invalidating a route.  For RREPs, such an event is the
2130	   receipt of an RREQ corresponding to a destination owned by the LOADng
2131	   Router.  A router that forwards an RREQ records the reverse route
2132	   state.  A router that forwards an RREP records the forward route
2133	   state.  If some routers for some reason, malice or malfunction,
2134	   generates excessive RREQ, RREP or RERRs, otherwise correctly
2135	   functioning LOADng Routers may fall victim to either "indirect
2136	   jamming" (being "tricked" into generating excessive control traffic)
2137	   or an explosion in the state necessary for maintaining protocol state
2138	   (potentially, exhausting the available memory resources).

2140	   Different such situations may occur, for instance:

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

2147	   2.  A router generates excessively frequent RREQs to the same
2148	       (existing) destination, causing the corresponding LOADng Router
2149	       to generate excessive RREPs.

2151	   3.  A router generates RERRs for a destination to the source LOADng
2152	       Router for traffic to that destination, causing that LOADng
2153	       Router to flood renewed RREQs.

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

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

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

2177	18.1.4.  Interaction with External Routing Domains

2179	   This protocol does provide a basic mechanism for a LOADng Router to
2180	   be able to discover routes to external routing domains: a LOADng
2181	   Router configured to "own" a given set of addresses will respond to
2182	   RREQs for destinations with these addresses, and can - by whatever
2183	   protocols governing the routing domain wherein these addresses exist
2184	   - provide paths to these addresses.

2186	   When operating routers connecting a LOADng domain to an external
2187	   routing domain, destinations inside the LOADng domain can be injected
2188	   into the external domain, if the routing protocol governing that
2189	   domain so permits.  Care MUST be taken to not allow potentially
2190	   insecure and untrustworthy information to be injected into the
2191	   external domain.

2193	   In case LOADng is used on the IP layer, a RECOMMENDED way of
2194	   extending connectivity from an external routing domain to a LOADng
2195	   routed domain is to assign an IP prefix (under the authority of the
2196	   routers/gateways connecting the LOADng routing domain with the
2197	   external routing domain) exclusively to that LOADng routing domain,
2198	   and to statically configure gateways to advertise routes for that
2199	   prefix into the external domain.  Within the LOADng domain, gateways
2200	   SHOULD only generate RREPs for destinations which are not part of
2201	   that prefix; this is in particularly important if a gateway otherwise
2202	   provides connectivity to "a default route".

2204	18.2.  Integrity Protection

2206	   The mechanisms specified are the use of an ICV for protection of the
2207	   protocols' control messages and the use of timestamps in those
2208	   messages to prevent replay attacks.  Both use the TLV mechanism
2209	   specified in [RFC5444] to add this information to the messages.
2210	   These ICV and TIMESTAMP TLVs are defined in [RFC7182].

2212	18.2.1.  Overview

2214	   When an RREQ/RREP/RREP_ACK/RERR message is being processed, LOADng
2215	   specifies that it MAY recognize additional reasons for identifying
2216	   invalid messages (Section 11.1 and Section 14.1 ).  This section
2217	   specifies a mechanism that provides this functionality.
2218	   Implementations of this protocol MUST include this mechanism, and
2219	   deployments of LOADng SHOULD use this mechanism, except when a
2220	   different security mechanism is more appropriate.

2222	   The integrity protection mechanism specified in this section is
2223	   placed in the control packet/message processing flow as indicated in
2224	   Figure 1.  It exists between the control packet parsing/generation
2225	   function of [RFC5444] and the message processing/generation function
2226	   of LOADng.

2228	                               |                        |
2229	                    Incoming   |                       /|\ Outgoing
2230	                     packet   \|/                       |   packet
2231	                               |                        |
2232	                           +--------------------------------+
2233	                           |                                |
2234	                           |        RFC 5444 packet         |
2235	                           |       parsing/generation       |
2236	                           |                                |
2237	                           +--------------------------------+
2238	                               |                        |
2239	                    Messages   |                       /|\ Messages with
2240	                              \|/                       |  added TLVs
2241	                               |                        |
2242	    D                      +--------------------------------+
2243	    R  /__________________ |                                |
2244	    O  \      Messages     | Integrity protection specified |
2245	    P      (failed check)  |       in this section          |
2246	                           |                                |
2247	                           +--------------------------------+
2248	                               |                        |
2249	                  Messages     |                       /|\ Messages
2250	               (passed check) \|/                       |
2251	                               |                        |
2252	                           +--------------------------------+
2253	                           |                                |
2254	                           |        LOADng message          |
2255	                           |     processing/generation      |
2256	                           |                                |
2257	                           +--------------------------------+

2259	              Figure 1: Relationship with RFC5444 and LOADng

2261	   The integrity projection mechanism:

2263	   o  Specifies an association of ICVs with protocol messages, and
2264	      specifies how to use a missing or invalid ICV as a reason to
2265	      reject a message as invalid for processing.

2267	   o  Specifies the implementation of an ICV Message TLV, defined in
2268	      [RFC7182], using a SHA-256-based Hashed Message Authentication
2269	      Code (HMAC) applied to the appropriate message contents.
2270	      Implementations of this protocol MUST support an HMAC-SHA-256 ICV
2271	      TLV, and deployments SHOULD use it except when use of a different
2272	      algorithm is more appropriate.  An implementation MAY use more
2273	      than one ICV TLV in a message, as long as they each use a
2274	      different algorithm or key to calculate the ICV.

2276	   o  Specifies the implementation of a TIMESTAMP Message TLV, defined
2277	      in [RFC7182], to provide message replay protection.
2278	      Implementations of LOADng using this mechanism MUST support a
2279	      timestamp based on POSIX time, and deployments SHOULD use it if
2280	      the clocks in all routers in the network can be synchronized with
2281	      sufficient precision.

2283	   o  Assumes that a router that is able to generate correct integrity
2284	      check values is considered trusted.

2286	   This mechanism does not:

2288	   o  Specify which key identifiers are to be used in a MANET in which
2289	      the routers share more than one secret key.  (Such keys will be
2290	      differentiated using the &ltkey-id&gt field defined in an ICV TLV
2291	      in [RFC7182].)

2293	   o  Specify how to distribute cryptographic material (shared secret
2294	      key(s)).

2296	   o  Specify how to detect compromised routers with valid keys.

2298	   o  Specify how to handle (revoke) compromised routers with valid
2299	      keys.

2301	   No key management mechanism is specified in this scenario because
2302	   given the various application scenarios of LOADng, it is hard to
2303	   identify a basic mechanism that fits for all.  Depending on the
2304	   applications, either automated key management or manual key
2305	   management [RFC4107] can be used.  For example, in a controlled
2306	   industrial environments but with very limited data rate and high
2307	   delay, a manual key management is probably preferred.  In a home
2308	   applications, simple pairing mechanisms for key exchange can be
2309	   applied.  However, in a malicious environments, such as battlefield,
2310	   a much more sophisticated key management is desired, by taking
2311	   consideration of compromised routers, etc.

2313	18.2.2.  Message Generation and Processing

2315	18.2.2.1.  Message Content

2317	   Messages MUST have the content specified in Section 6.  In addition,
2318	   messages that conform to the integration protection mechanism MUST
2319	   contain:

2321	   o  At least one ICV Message TLV (as specified in [RFC7182]),
2322	      generated according to Section 18.2.2.2.  Implementations of
2323	      LOADng MUST support the following version of the ICV TLV, but
2324	      other versions MAY be used instead, or in addition, in a
2325	      deployment, if more appropriate:

2327	      *  For RREQ/RREP/RREP_ACK/RERR messages, type-extension := 1

2329	      *  hash-function := 3 (SHA-256)

2331	      *  cryptographic-function := 3 (HMAC)

2333	   o  At least one TIMESTAMP Message TLV (as specified in [RFC7182]),
2334	      generated according to Section 18.2.2.2.  Implementations of
2335	      LOADng using this mechanism MUST support the following version of
2336	      the TIMESTAMP TLV, but other versions MAY be used instead, or in
2337	      addition, in a deployment, if more appropriate:

2339	      *  type-extension := 1

2341	18.2.2.2.  Message Generation

2343	   For each RREQ/RREP/RREP_ACK/RERR message, after message generation
2344	   and before message transmission, the additional TLVs specified in
2345	   Section 18.2.2.1 MUST (unless already present) be added to the
2346	   outgoing message when using this mechanism.

2348	   The following processing steps (when using a single timestamp version
2349	   and a single ICV algorithm) MUST be performed for a cryptographic
2350	   algorithm that is used for generating an ICV for a message:

2352	   1.  All ICV TLVs (if any) are temporarily removed from the message.
2353	       Any temporarily removed ICV TLVs MUST be stored, in order to be
2354	       reinserted into the message in step 5.  The message size and
2355	       Message TLV Block size are updated accordingly.

2357	   2.  All the mutable fields of the message (specified in Section 6)
2358	       are temporarily set to 0.

2360	   3.  A TLV of type TIMESTAMP, as specified in Section 18.2.2.1, is
2361	       added to the Message TLV Block.  The message size and Message TLV
2362	       Block size are updated accordingly.

2364	   4.  A TLV of type ICV, as specified in Section 18.2.2.1, is added to
2365	       the Message TLV Block.  The message size and Message TLV Block
2366	       size are updated accordingly.

2368	   5.  All ICV TLVs that were temporary removed in step 1, are restored.
2369	       The message size and Message TLV Block size are updated
2370	       accordingly.

2372	   6.  All mutable fields that are temporarily set to 0 are restored to
2373	       their previous values.

2375	   An implementation MAY add either alternative TIMESTAMP and/or ICV
2376	   TLVs or more than one TIMESTAMP and/or ICV TLVs.  All TIMESTAMP TLVs
2377	   MUST be inserted before adding ICV TLVs.

2379	18.2.2.3.  Message Processing

2381	   LOADng gives a number of conditions that will lead to a rejection of
2382	   the message as "invalid".  When using a single timestamp version, and
2383	   a single ICV algorithm, add the following conditions to that list,
2384	   each of which, if true, MUST cause LOADng to consider the message as
2385	   invalid for processing when using this integrity protection
2386	   mechanism:

2388	   1.  The Message TLV Block of the message does not contain exactly one
2389	       TIMESTAMP TLV of the selected version.  This version
2390	       specification includes the type extension.  (The Message TLV
2391	       Block may also contain TIMESTAMP TLVs of other versions.)

2393	   2.  The Message TLV Block does not contain exactly one ICV TLV using
2394	       the selected algorithm and key identifier.  This algorithm
2395	       specification includes the type extension, and for type
2396	       extensions 1, the hash function and cryptographic function.  (The
2397	       Message TLV Block may also contain ICV TLVs using other
2398	       algorithms and key identifiers.)

2400	   3.  Validation of the identified (in step 1) TIMESTAMP TLV in the
2401	       Message TLV Block of the message fails, as according to the
2402	       timestamp validation:

2404	       1.  If the current POSIX time minus the value of that TIMESTAMP
2405	           TLV is greater than NET_TRAVERSAL_TIME, then the message
2406	           validation fails.

2408	       2.  Otherwise, the message validation succeeds.

2410	   4.  Validation of the identified (in step 2) ICV TLV in the Message
2411	       TLV Block of the message fails, as according to the ICV
2412	       validation:

2414	       1.  All ICV Message TLVs (including the identified ICV Message
2415	           TLV) are temporarily removed from the message, and the
2416	           message size and Message TLV Block size are updated
2417	           accordingly.

2419	       2.  All the mutable fields of the message (specified in
2420	           Section 6) are temporarily set to 0.

2422	       3.  Calculate the ICV for the parameters specified in the
2423	           identified ICV Message TLV, as specified in [RFC7182].

2425	       4.  If this ICV differs from the value of &ltICV-data&gt in the
2426	           ICV Message TLV, then the message validation fails.  If the
2427	           &ltICV-data&gt has been truncated (as specified in [RFC7182],
2428	           the ICV calculated in the previous step MUST be truncated to
2429	           the TLV length of the ICV Message TLV before comparing it
2430	           with the &ltICV-data&gt.

2432	       5.  Otherwise, the message validation succeeds.  The message's
2433	           mutable fields are restored to their previous value, and the
2434	           ICV Message TLVs are returned to the message, whose size is
2435	           updated accordingly.

2437	19.  LOADng Specific IANA Considerations

2439	19.1.  Error Codes

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

2444	           +---------+--------------------+-------------------+
2445	           |   Code  | Description        | Allocation Policy |
2446	           +---------+--------------------+-------------------+
2447	           |    0    | No available route |                   |
2448	           |  1-251  | Unassigned         | Expert Review     |
2449	           | 252-255 | Unassigned         | Experimental Use  |
2450	           +---------+--------------------+-------------------+
2451	                           Table 1: Error Codes

2453	20.  Contributors

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

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

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

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

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

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

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

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

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

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

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

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

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

2487	21.  Acknowledgments

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

2497	22.  References
2498	22.1.  Normative References

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

2504	   [RFC5444]                    Clausen, T., Dean, J., Dearlove, C., and
2505	                                C. Adjih, "Generalized Mobile Ad Hoc
2506	                                Network (MANET) Packet/Message Format",
2507	                                RFC 5444, February 2009.

2509	   [RFC7182]                    Herberg, U., Clausen, T., and C.
2510	                                Dearlove, "Integrity Check Value and
2511	                                Timestamp TLV Definitions for Mobile Ad
2512	                                Hoc Networks (MANETs)", RFC 7182,
2513	                                April 2014.

2515	   [RFC5498]                    Chakeres, I., "IANA Allocations for
2516	                                Mobile Ad Hoc Network (MANET)
2517	                                Protocols", RFC 5498, March 2009.

2519	22.2.  Informative References

2521	   [RFC6982]                    Sheffer, Y. and A. Farrel, "Improving
2522	                                Awareness of Running Code: The
2523	                                Implementation Status Section",
2524	                                RFC 6982, July 2013.

2526	   [I-D.loadng-interop-report]  Clausen, T., Camacho, A., Yi, J., Colin
2527	                                de Verdiere, A., Igarashi, Y., Satoh,
2528	                                H., Morii, Y., Heropberg, U., and C.
2529	                                Lavenu, "Interoperability Report for the
2530	                                Lightweight On-demand Ad hoc Distance-
2531	                                vector Routing Protocol - Next
2532	                                Generation (LOADng)", draft-lavenu-lln-
2533	                                loadng-interoperability-report-04 (work
2534	                                in progress), December 2012.

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

2540	   [RFC4861]                    Narten, T., Nordmark, E., Simpson, W.,
2541	                                and H. Soliman, "Neighbor Discovery for
2542	                                IP version 6 (IPv6)", RFC 4861,
2543	                                September 2007.

2545	   [RFC4944]                    Montenegro, G., Kushalnagar, N., Hui,
2546	                                J., and D. Culler, "Transmission of IPv6
2547	                                Packets over IEEE 802.15.4 Networks",
2548	                                RFC 4944, September 2007.

2550	   [RFC5148]                    Clausen, T., Dearlove, C., and B.
2551	                                Adamson, "Jitter Considerations in
2552	                                Mobile Ad Hoc Networks (MANETs)",
2553	                                RFC 5148, February 2008.

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

2559	   [RFC6206]                    Levis, P., Clausen, T., Gnawali, O., and
2560	                                J. Ko, "The Trickle Algorithm",
2561	                                RFC 6206, March 2011.

2563	   [RFC6621]                    Macker, J., "Simplified Multicast
2564	                                Forwarding", RFC 6621, May 2012.

2566	   [RFC4107]                    Bellovin, S. and R. Housley, "Guidelines
2567	                                for Cryptographic Key Management",
2568	                                BCP 107, RFC 4107, June 2005.

2570	   [EUI64]                      IEEE, "Guidelines for 64-bit Global
2571	                                Identifier (EUI-64) Registration
2572	                                Authority".

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

2577	   [IEEE_VTC2012]               Clausen, T., Yi, J., and A. Coline de
2578	                                Verdiere, "Towards AODV Version 2",
2579	                                Proceedings of IEEE VTC 2012 Fall, IEEE
2580	                                76th Vehicular Technology Conference,
2581	                                2012.

2583	   [IEEE_WiCom2012]             Yi, J., Clausen, T., and A. Coline de
2584	                                Verdiere, "Efficient Data Acquisition in
2585	                                Sensor Networks:Introducing (the) LOADng
2586	                                Collection Tree Protocol",
2587	                                Proceedings of IEEE WiCom 2012, The 8th
2588	                                IEEE International Conference on
2589	                                Wireless Communications, Networking and
2590	                                Mobile Computing., 2012.

2592	   [IEEE_ICWITS2012]            Yi, J., Clausen, T., and A. Bas, "Smart
2593	                                Route Request for On-demand Route
2594	                                Discovery in Constrained Environments",
2595	                                Proceedings of IEEE ICWITS 2012, IEEE
2596	                                International Conference on Wireless
2597	                                Information Technology and Systems.,
2598	                                2012.

2600	Appendix A.  Gateway Considerations

2602	   For the LOADng implementations running in network layer, sometimes
2603	   gateways are desired to connect to other networks.  This section
2604	   specifies how to enable gateways for LOADng routing domains.

2606	   A LOADng router in a network, which is a gateway to 'the larger
2607	   Internet' MAY answer to RREQs for any destination except for
2608	   destinations within the network itself for which it MUST NOT answer
2609	   to RREQs.  Consequently, a LOADng router, intended to act as a
2610	   gateway, MUST be configured with the addresses which can occur within
2611	   the network (ideally, the network is configured such that all devices
2612	   share a common prefix).

2614	Appendix B.  LOADng Control Messages using RFC5444

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

2619	B.1.  RREQ-Specific Message Encoding Considerations

2621	   This protocol defines, and hence owns, the RREQ Message Type.  Thus,
2622	   as specified in [RFC5444], this protocol generates and transmits all
2623	   RREQ messages, receives all RREQ messages and is responsible for
2624	   determining whether and how each RREQ message is to be processed
2625	   (updating the Information Base) and/or forwarded, according to this
2626	   specification.  Table 2 specifies how RREQ messages are mapped into
2627	   [RFC5444]-elements.

2629	   +-------------------+-------------------+---------------------------+
2630	   |    RREQ Element   |  RFC5444-Element  | Considerations            |
2631	   +-------------------+-------------------+---------------------------+
2632	   |  RREQ.addr-length | <msg-addr-length> | Supports addresses from   |
2633	   |                   |                   | 1-16 octets               |
2634	   |    RREQ.seq-num   |   <msg-seq-num>   | 16 bits, hence MAXVALUE   |
2635	   |                   |                   | (Section 8) is 65535.     |
2636	   |                   |                   | MUST be included          |
2637	   |  RREQ.metric-type |   METRIC Message  | Encoded by way of the     |
2638	   |                   |        TLV        | Type-Extension of a       |
2639	   |                   |                   | Message-Type-specific     |
2640	   |                   |                   | Message TLV of type       |
2641	   |                   |                   | METRIC, defined in        |
2642	   |                   |                   | Table 8.  A LOADng Router |
2643	   |                   |                   | generating an RREQ (as    |
2644	   |                   |                   | specified in              |
2645	   |                   |                   | Section 12.1) when using  |
2646	   |                   |                   | the HOP_COUNT metric,     |
2647	   |                   |                   | MUST NOT add the METRIC   |
2648	   |                   |                   | Message TLV to the RREQ   |
2649	   |                   |                   | (in order to reduce       |
2650	   |                   |                   | overhead, as the hop      |
2651	   |                   |                   | count value is already    |
2652	   |                   |                   | encoded in                |
2653	   |                   |                   | RREQ.hop-count).  LOADng  |
2654	   |                   |                   | Routers receiving an RREQ |
2655	   |                   |                   | without METRIC Message    |
2656	   |                   |                   | TLV assume that           |
2657	   |                   |                   | RREQ.metric-type is       |
2658	   |                   |                   | HOP_COUNT, and MUST not   |
2659	   |                   |                   | add the METRIC Message    |
2660	   |                   |                   | TLV when forwarding the   |
2661	   |                   |                   | message.  Otherwise,      |
2662	   |                   |                   | exactly one METRIC TLV    |
2663	   |                   |                   | MUST be included in each  |
2664	   |                   |                   | RREQ message.             |
2665	   | RREQ.route-metric |   METRIC Message  | Encoded as the value      |
2666	   |                   |     TLV value     | field of the METRIC TLV.  |
2667	   |                   |                   | (LOADng Routers           |
2668	   |                   |                   | generating RREQs when     |
2669	   |                   |                   | using the HOP_COUNT       |
2670	   |                   |                   | metric do not need need   |
2671	   |                   |                   | to add the METRIC Message |
2672	   |                   |                   | TLV, as specified above   |
2673	   |                   |                   | for the RREQ.metric-type  |
2674	   |                   |                   | field.)                   |
2675	   |   RREQ.hop-limit  |  <msg-hop-limit>  | 8 bits.  MUST be included |
2676	   |                   |                   | in an RREQ message        |
2677	   |   RREQ.hop-count  |  <msg-hop-count>  | 8 bits, hence             |
2678	   |                   |                   | MAX_HOP_COUNT is 255.     |
2679	   |                   |                   | MUST be included in an    |
2680	   |                   |                   | RREQ message.             |
2681	   |  RREQ.originator  |  <msg-orig-addr>  | MUST be included in an    |
2682	   |                   |                   | RREQ message.             |
2683	   |  RREQ.destination |     Address in    | Encoded by way of an      |
2684	   |                   |   Address-Block   | address in an address     |
2685	   |                   |       w/TLV       | block, with which a       |
2686	   |                   |                   | Message-Type-specific     |
2687	   |                   |                   | Address Block TLV of type |
2688	   |                   |                   | ADDR-TYPE and with        |
2689	   |                   |                   | Type-Extension            |
2690	   |                   |                   | DESTINATION is            |
2691	   |                   |                   | associated, defined in    |
2692	   |                   |                   | Table 9.  An RREQ MUST    |
2693	   |                   |                   | contain exactly one       |
2694	   |                   |                   | address with a TLV of     |
2695	   |                   |                   | type ADDR-TYPE and with   |
2696	   |                   |                   | Type-Extension            |
2697	   |                   |                   | DESTINATION associated.   |
2698	   +-------------------+-------------------+---------------------------+

2700	                      Table 2: RREQ Message Elements

2702	B.2.  RREP-Specific Message Encoding Considerations

2704	   This protocol defines, and hence owns, the RREP Message Type.  Thus,
2705	   as specified in [RFC5444], this protocol generates and transmits all
2706	   RREP messages, receives all RREP messages and is responsible for
2707	   determining whether and how each RREP message is to be processed
2708	   (updating the Information Base) and/or forwarded, according to this
2709	   specification.  Table 3 describes how RREP messages are mapped into
2710	   [RFC5444]-elements.

2712	   +-------------------+-------------------+---------------------------+
2713	   |    RREP Element   |  RFC5444-Element  | Considerations            |
2714	   +-------------------+-------------------+---------------------------+
2715	   |  RREP.addr-length | <msg-addr-length> | Supports addresses from   |
2716	   |                   |                   | 1-16 octets               |
2717	   |    RREP.seq-num   |   <msg-seq-num>   | 16 bits, hence MAXVALUE   |
2718	   |                   |                   | (Section 8) is 65535.     |
2719	   |                   |                   | MUST be included          |
2720	   |  RREP.metric-type |   METRIC Message  | Encoded by way of the     |
2721	   |                   |        TLV        | Type-Extension of a       |
2722	   |                   |                   | Message-Type-specific     |
2723	   |                   |                   | Message TLV of type       |
2724	   |                   |                   | METRIC, defined in        |
2725	   |                   |                   | Table 12.  A LOADng       |
2726	   |                   |                   | Router generating an RREP |
2727	   |                   |                   | (as specified in          |
2728	   |                   |                   | Section 13.1) when using  |
2729	   |                   |                   | the HOP_COUNT metric,     |
2730	   |                   |                   | MUST NOT add the METRIC   |
2731	   |                   |                   | Message TLV to the RREP   |
2732	   |                   |                   | (in order to reduce       |
2733	   |                   |                   | overhead, as the hop      |
2734	   |                   |                   | count value is already    |
2735	   |                   |                   | encoded in                |
2736	   |                   |                   | RREP.hop-count).  LOADng  |
2737	   |                   |                   | Routers receiving an RREP |
2738	   |                   |                   | without METRIC Message    |
2739	   |                   |                   | TLV assume that           |
2740	   |                   |                   | RREP.metric-type is       |
2741	   |                   |                   | HOP_COUNT, and MUST not   |
2742	   |                   |                   | add the METRIC Message    |
2743	   |                   |                   | TLV when forwarding the   |
2744	   |                   |                   | message.  Otherwise,      |
2745	   |                   |                   | exactly one METRIC TLV    |
2746	   |                   |                   | MUST be included in each  |
2747	   |                   |                   | RREP message.             |
2748	   | RREP.route-metric |   METRIC Message  | Encoded as the value      |
2749	   |                   |     TLV value     | field of the METRIC TLV.  |
2750	   |                   |                   | (LOADng Routers           |
2751	   |                   |                   | generating RREPs when     |
2752	   |                   |                   | using the HOP_COUNT       |
2753	   |                   |                   | metric do not need need   |
2754	   |                   |                   | to add the METRIC Message |
2755	   |                   |                   | TLV, as specified above   |
2756	   |                   |                   | for the RREP.metric-type  |
2757	   |                   |                   | field.)                   |
2758	   |  RREP.ackrequired | FLAGS Message TLV | Encoded by way of a       |
2759	   |                   |                   | Message-Type-specific     |
2760	   |                   |                   | Message TLV of type       |
2761	   |                   |                   | FLAGS, defined in         |
2762	   |                   |                   | Table 13.  A TLV of type  |
2763	   |                   |                   | FLAGS MUST always be      |
2764	   |                   |                   | included in an RREP       |
2765	   |                   |                   | message.                  |
2766	   |   RREP.hop-limit  |  <msg-hop-limit>  | 8 bits.  MUST be included |
2767	   |                   |                   | in an RREQ message        |
2768	   |   RREP.hop-count  |  <msg-hop-count>  | 8 bits, hence             |
2769	   |                   |                   | MAX_HOP_COUNT is 255.     |
2770	   |                   |                   | MUST be included in an    |
2771	   |                   |                   | RREP message.             |
2772	   |  RREP.originator  |  <msg-orig-addr>  | MUST be included in an    |
2773	   |                   |                   | RREP message.             |
2774	   |  RREP.destination |     Address in    | Encoded by way of an      |
2775	   |                   |   Address-Block   | address in an address     |
2776	   |                   |       w/TLV       | block, with which a       |
2777	   |                   |                   | Message-Type-specific     |
2778	   |                   |                   | Address Block TLV of type |
2779	   |                   |                   | ADDR-TYPE and with        |
2780	   |                   |                   | Type-Extension            |
2781	   |                   |                   | DESTINATION is            |
2782	   |                   |                   | associated, defined in    |
2783	   |                   |                   | Table 14.  An RREP MUST   |
2784	   |                   |                   | contain exactly one       |
2785	   |                   |                   | address with a TLV of     |
2786	   |                   |                   | type ADDR-TYPE and with   |
2787	   |                   |                   | Type-Extension            |
2788	   |                   |                   | DESTINATION associated.   |
2789	   +-------------------+-------------------+---------------------------+

2791	                      Table 3: RREP Message Elements

2793	B.3.  RREP_ACK Message Encoding

2795	   This protocol defines, and hence owns, the RREP_ACK Message Type.
2796	   Thus, as specified in [RFC5444], this protocol generates and
2797	   transmits all RREP_ACK messages, receives all RREP_ACK messages and
2798	   is responsible for determining whether and how each RREP_ACK message
2799	   is to be processed (updating the Information Base), according to this
2800	   specification.  Table 4 describes how RREP_ACK Messages are mapped
2801	   into [RFC5444]-elements.

2803	   +----------------------+-------------------+------------------------+
2804	   |   RREP_ACK Element   |  RFC5444-Element  | Considerations         |
2805	   +----------------------+-------------------+------------------------+
2806	   | RREP_ACK.addr-length | <msg-addr-length> | Supports addresses     |
2807	   |                      |                   | from 1-16 octets       |
2808	   |   RREP_ACK.seq-num   |   <msg-seq-num>   | 16 bits, hence         |
2809	   |                      |                   | MAXVALUE (Section 8)   |
2810	   |                      |                   | is 65535.  MUST be     |
2811	   |                      |                   | included               |
2812	   | RREP_ACK.destination |     Address in    | Encoded by way of an   |
2813	   |                      |   Address-Block   | address in an address  |
2814	   |                      |       w/TLV       | block, with which a    |
2815	   |                      |                   | Message-Type-specific  |
2816	   |                      |                   | Address Block TLV of   |
2817	   |                      |                   | type ADDR-TYPE and     |
2818	   |                      |                   | with Type-Extension    |
2819	   |                      |                   | DESTINATION is         |
2820	   |                      |                   | associated, defined in |
2821	   |                      |                   | Table 17.  An RREP_ACK |
2822	   |                      |                   | MUST contain exactly   |
2823	   |                      |                   | one address with a TLV |
2824	   |                      |                   | of type ADDR-TYPE and  |
2825	   |                      |                   | with Type-Extension    |
2826	   |                      |                   | DESTINATION            |
2827	   |                      |                   | associated.            |
2828	   +----------------------+-------------------+------------------------+

2830	                    Table 4: RREP_ACK Message Elements

2832	B.4.  RERR Message Encoding

2834	   This protocol defines, and hence owns, the RERR Message Type.  Thus,
2835	   as specified in [RFC5444], this protocol generates and transmits all
2836	   RERR messages, receives all RERR messages and is responsible for
2837	   determining whether and how each RERR message is to be processed
2838	   (updating the Information Base) and/or forwarded, according to this
2839	   specification.  Table 5 describes how RERR Messages are mapped into
2840	   [RFC5444]-elements.

2842	   +------------------------+------------------+-----------------------+
2843	   |      RERR Element      |  RFC5444-Element | Considerations        |
2844	   +------------------------+------------------+-----------------------+
2845	   |    RERR.addr-length    | <msg-addr-length | Supports addresses    |
2846	   |                        | >                | from 1-16 octets      |
2847	   |     RERR.hop-limit     |  <msg-hop-limit> | 8 bits.  MUST be      |
2848	   |                        |                  | included in an RREQ   |
2849	   |                        |                  | message               |
2850	   |     RERR.errorcode     |   Address Block  | According to          |
2851	   |                        |     TLV Value    | Section 19.1.         |
2852	   | RERR.unreachableAddres |    Address in    | Encoded by way of an  |
2853	   | s                      |   Address-Block  | address in an address |
2854	   |                        |       w/TLV      | block, with which a   |
2855	   |                        |                  | Message-Type-specific |
2856	   |                        |                  | Address Block TLV of  |
2857	   |                        |                  | type ADDR-TYPE and    |
2858	   |                        |                  | with Type-Extension   |
2859	   |                        |                  | ERRORCODE is          |
2860	   |                        |                  | associated, defined   |
2861	   |                        |                  | in Table 20.          |
2862	   |     RERR.originator    |  <msg-orig-addr> | MUST be included in   |
2863	   |                        |                  | an RERR message.      |
2864	   |    RERR.destination    |    Address in    | Encoded by way of an  |
2865	   |                        |   Address-Block  | address in an address |
2866	   |                        |       w/TLV      | block, with which a   |
2867	   |                        |                  | Message-Type-specific |
2868	   |                        |                  | Address Block TLV of  |
2869	   |                        |                  | type ADDR-TYPE and    |
2870	   |                        |                  | with Type-Extension   |
2871	   |                        |                  | DESTINATION is        |
2872	   |                        |                  | associated, defined   |
2873	   |                        |                  | in Table 20.  An RERR |
2874	   |                        |                  | MUST contain exactly  |
2875	   |                        |                  | one address with a    |
2876	   |                        |                  | TLV of type ADDR-TYPE |
2877	   |                        |                  | and with              |
2878	   |                        |                  | Type-Extension        |
2879	   |                        |                  | DESTINATION           |
2880	   |                        |                  | associated.           |
2881	   +------------------------+------------------+-----------------------+

2883	                      Table 5: RERR Message Elements

2885	B.5.  RFC5444-Specific IANA Considerations

2887	   This specification defines four Message Types, which must be
2888	   allocated from the "Message Types" repository of [RFC5444], two
2889	   Message TLV Types, which must be allocated from the "Message TLV
2890	   Types" repository of [RFC5444], and four Address Block TLV Types,
2891	   which must be allocated from the "Address Block TLV Types" repository
2892	   of [RFC5444].

2894	B.5.1.  Expert Review: Evaluation Guidelines

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

2900	B.5.2.  Message Types

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

2906	         +------+-----------------------------------------------+
2907	         | Type | Description                                   |
2908	         +------+-----------------------------------------------+
2909	         | TBD1 | RREQ: Route Request Message                   |
2910	         | TBD1 | RREP: Route Reply Message                     |
2911	         | TBD1 | RREP_ACK: Route Reply Acknowledgement Message |
2912	         | TBD1 | RERR: Route Error Message                     |
2913	         +------+-----------------------------------------------+

2915	                     Table 6: Message Type assignment

2917	B.6.  RREQ Message-Type-Specific TLV Type Registries

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

2924	               +---------+-------------+-------------------+
2925	               |   Type  | Description | Allocation Policy |
2926	               +---------+-------------+-------------------+
2927	               |   128   | METRIC      |                   |
2928	               | 129-223 | Unassigned  | Expert Review     |
2929	               +---------+-------------+-------------------+

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

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

2937	   +--------+------+-----------+------------------------+--------------+
2938	   |  Name  | Type |    Type   | Description            | Allocation   |
2939	   |        |      | Extension |                        | Policy       |
2940	   +--------+------+-----------+------------------------+--------------+
2941	   | METRIC |  128 |     0     | HOP_COUNT:             |              |
2942	   |        |      |           | MSG.hop-count is used  |              |
2943	   |        |      |           | instead of the METRIC  |              |
2944	   |        |      |           | TLV Value.  MAX_DIST   |              |
2945	   |        |      |           | is 255.                |              |
2946	   | METRIC |  128 |     1     | DIMENSIONLESS: A       |              |
2947	   |        |      |           | 32-bit, dimensionless, |              |
2948	   |        |      |           | additive metric,       |              |
2949	   |        |      |           | single precision       |              |
2950	   |        |      |           | float, formatted       |              |
2951	   |        |      |           | according to           |              |
2952	   |        |      |           | [IEEE754-2008].        |              |
2953	   | METRIC |  128 |   2-251   | Unassigned             | Expert       |
2954	   |        |      |           |                        | Review       |
2955	   | METRIC |  128 |  252-255  | Unassigned             | Experimental |
2956	   +--------+------+-----------+------------------------+--------------+

2958	               Table 8: Message TLV Type assignment: METRIC

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

2965	               +---------+-------------+-------------------+
2966	               |   Type  | Description | Allocation Policy |
2967	               +---------+-------------+-------------------+
2968	               |   128   | ADDR-TYPE   | Expert Review     |
2969	               | 129-223 | Unassigned  | Expert Review     |
2970	               +---------+-------------+-------------------+

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

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

2978	   +-----------+------+----------------+-------------+-----------------+
2979	   |    Name   | Type | Type Extension | Description | Allocation      |
2980	   |           |      |                |             | Policy          |
2981	   +-----------+------+----------------+-------------+-----------------+
2982	   | ADDR-TYPE |  128 |        0       | DESTINATION |                 |
2983	   | ADDR-TYPE |  128 |      2-255     | Unassigned  | Expert Review   |
2984	   +-----------+------+----------------+-------------+-----------------+

2986	          Table 10: Address Block TLV Type assignment: ADDR-TYPE

2988	B.7.  RREP Message-Type-Specific TLV Type Registries

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

2995	               +---------+-------------+-------------------+
2996	               |   Type  | Description | Allocation Policy |
2997	               +---------+-------------+-------------------+
2998	               |   128   | METRIC      |                   |
2999	               |   129   | FLAGS       |                   |
3000	               | 130-223 | Unassigned  | Expert Review     |
3001	               +---------+-------------+-------------------+

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

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

3009	   +--------+------+-----------+------------------------+--------------+
3010	   |  Name  | Type |    Type   | Description            | Allocation   |
3011	   |        |      | Extension |                        | Policy       |
3012	   +--------+------+-----------+------------------------+--------------+
3013	   | METRIC |  128 |     0     | HOP_COUNT:             |              |
3014	   |        |      |           | MSG.hop-count is used  |              |
3015	   |        |      |           | instead of the METRIC  |              |
3016	   |        |      |           | TLV Value.  MAX_DIST   |              |
3017	   |        |      |           | is 255.                |              |
3018	   | METRIC |  128 |     1     | DIMENSIONLESS: A       |              |
3019	   |        |      |           | 32-bit, dimensionless, |              |
3020	   |        |      |           | additive metric,       |              |
3021	   |        |      |           | single precision       |              |
3022	   |        |      |           | float, formatted       |              |
3023	   |        |      |           | according to           |              |
3024	   |        |      |           | [IEEE754-2008].        |              |
3025	   | METRIC |  128 |   2-251   | Unassigned             | Expert       |
3026	   |        |      |           |                        | Review       |
3027	   | METRIC |  128 |  252-255  | Unassigned             | Experimental |
3028	   +--------+------+-----------+------------------------+--------------+

3030	               Table 12: Message TLV Type assignment: METRIC

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

3036	   +-------+------+-----------+---------------------------+------------+
3037	   |  Name | Type |    Type   | Description               | Allocation |
3038	   |       |      | Extension |                           | Policy     |
3039	   +-------+------+-----------+---------------------------+------------+
3040	   | FLAGS |  129 |     0     | Bit 0 represents the      |            |
3041	   |       |      |           | ackrequired flag (i.e.,   |            |
3042	   |       |      |           | ackrequired is TRUE when  |            |
3043	   |       |      |           | bit 0 is set to 1 and     |            |
3044	   |       |      |           | FALSE when bit 0 is 0.).  |            |
3045	   |       |      |           | All other bits are        |            |
3046	   |       |      |           | reserved for future use.  |            |
3047	   | FLAGS |  129 |   1-255   | Unassigned                | Expert     |
3048	   |       |      |           |                           | Review     |
3049	   +-------+------+-----------+---------------------------+------------+

3051	               Table 13: Message TLV Type assignment: FLAGS

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

3058	               +---------+-------------+-------------------+
3059	               |   Type  | Description | Allocation Policy |
3060	               +---------+-------------+-------------------+
3061	               |   128   | ADDR-TYPE   | Expert Review     |
3062	               | 129-223 | Unassigned  | Expert Review     |
3063	               +---------+-------------+-------------------+

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

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

3071	   +-----------+------+----------------+-------------+-----------------+
3072	   |    Name   | Type | Type Extension | Description | Allocation      |
3073	   |           |      |                |             | Policy          |
3074	   +-----------+------+----------------+-------------+-----------------+
3075	   | ADDR-TYPE |  128 |        0       | DESTINATION |                 |
3076	   | ADDR-TYPE |  128 |      1-255     | Unassigned  | Expert Review   |
3077	   +-----------+------+----------------+-------------+-----------------+

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

3081	B.8.  RREP_ACK Message-Type-Specific TLV Type Registries

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

3088	               +---------+-------------+-------------------+
3089	               |   Type  | Description | Allocation Policy |
3090	               +---------+-------------+-------------------+
3091	               | 128-223 | Unassigned  | Expert Review     |
3092	               +---------+-------------+-------------------+

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

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

3101	               +---------+-------------+-------------------+
3102	               |   Type  | Description | Allocation Policy |
3103	               +---------+-------------+-------------------+
3104	               |   128   | ADDR-TYPE   | Expert Review     |
3105	               | 129-223 | Unassigned  | Expert Review     |
3106	               +---------+-------------+-------------------+

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

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

3114	   +-----------+------+----------------+-------------+-----------------+
3115	   |    Name   | Type | Type Extension | Description | Allocation      |
3116	   |           |      |                |             | Policy          |
3117	   +-----------+------+----------------+-------------+-----------------+
3118	   | ADDR-TYPE |  128 |        0       | DESTINATION |                 |
3119	   | ADDR-TYPE |  128 |      2-255     | Unassigned  | Expert Review   |
3120	   +-----------+------+----------------+-------------+-----------------+

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

3124	B.9.  RERR Message-Type-Specific TLV Type Registries

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

3131	               +---------+-------------+-------------------+
3132	               |   Type  | Description | Allocation Policy |
3133	               +---------+-------------+-------------------+
3134	               | 128-223 | Unassigned  | Expert Review     |
3135	               +---------+-------------+-------------------+

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

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

3144	               +---------+-------------+-------------------+
3145	               |   Type  | Description | Allocation Policy |
3146	               +---------+-------------+-------------------+
3147	               |   128   | ADDR-TYPE   | Expert Review     |
3148	               | 129-223 | Unassigned  | Expert Review     |
3149	               +---------+-------------+-------------------+

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

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

3157	   +-----------+------+----------------+-------------+-----------------+
3158	   |    Name   | Type | Type Extension | Description | Allocation      |
3159	   |           |      |                |             | Policy          |
3160	   +-----------+------+----------------+-------------+-----------------+
3161	   | ADDR-TYPE |  128 |        0       | DESTINATION |                 |
3162	   | ADDR-TYPE |  128 |        1       | ERRORCODE   |                 |
3163	   | ADDR-TYPE |  128 |      2-255     | Unassigned  | Expert Review   |
3164	   +-----------+------+----------------+-------------+-----------------+

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

3168	Appendix C.  LOADng Control Packet Illustrations

3170	   This section presents example packets following this specification.

3172	C.1.  RREQ

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

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

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

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

3198	   The message has one Address Block.  The Address Block contains 1
3199	   address, with Flags octet (ATLVF) value 0, hence with no Head or Tail
3200	   sections, and hence with a Mid section with length four octets.  The
3201	   following TLV Block (content length 2 octets) contains one TLV.  The
3202	   TLV is an ADDR_TYPE TLV with Flags octet (ATLVF) value 0, indicating
3203	   no Value and no indexes.  Thus, the address is associated with the
3204	   Type ADDR_TYPE, i.e., it is the destination address of the RREQ.

3206	      0                   1                   2                   3
3207	      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
3208	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3209	     |     RREQ      | MF=15 | MAL=3 |      Message Length = 30      |
3210	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3211	     |                      Originator Address                       |
3212	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3213	     |   Hop Limit   |   Hop Count   |    Message Sequence Number    |
3214	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3215	     | Message TLV Block Length = 6  |    METRIC     |  MTLVF = 144  |
3216	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3217	     |  Type Ext.    | Value Len = 2 |       Value (metric)          |
3218	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3219	     | Num Addrs = 1 |    ABF = 0    |             Mid               |
3220	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3221	     |            Mid                | Address TLV Block Length = 2  |
3222	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3223	     |   ADDR-TYPE   |   ATLVF = 0   |
3224	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3226	C.2.  RREP

3228	   RREP messages are instances of [RFC5444] messages.  This
3229	   specification requires that RREP messages contain RREP.msg-seq-num,
3230	   RREP.msg-hop-limit, RREP.msg-hop-count and RREP.msg-orig-addr fields.
3231	   It supports RREP messages with any combination of remaining message
3232	   header options and address encodings, enabled by [RFC5444] that
3233	   convey the required information.  As a consequence, there is no
3234	   single way to represent how all RREP messages look.  This section
3235	   illustrates an RREP message, the exact values and content included
3236	   are explained in the following text.

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

3245	   The message has a Message TLV Block with content length 10 octets
3246	   containing two TLVs.  The first TLV is of type METRIC and has a Flags
3247	   octet (MTLVF) value 144, indicating that it has a Value, a type
3248	   extension, but no start and stop indexes.  The Value Length of the
3249	   METRIC TLV is 2 octets.  The second TLV is of type FLAGS and has a
3250	   Flags octet (MTLVF) value of 16, indicating that it has a Value, but
3251	   no type extension or start and stop indexes.  The Value Length of the
3252	   FLAGS TLV is 1 octet.  The TLV value is 0x80 indicating that the
3253	   ackrequired flag is set.

3255	   The message has one Address Block.  The Address Block contains 1
3256	   address, with Flags octet (ATLVF) value 0, hence with no Head or Tail
3257	   sections, and hence with a Mid section with length four octets.  The
3258	   following TLV Block (content length 2 octets) contains one TLV.  The
3259	   TLV is an ADDR_TYPE TLV with Flags octet (ATLVF) value 0, indicating
3260	   no Value and no indexes.  Thus, the address is associated with the
3261	   Type ADDR_TYPE, i.e., it is the destination address of the RREP.

3263	      0                   1                   2                   3
3264	      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
3265	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3266	     |     RREP      | MF=15 | MAL=3 |      Message Length = 34      |
3267	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3268	     |                      Originator Address                       |
3269	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3270	     |   Hop Limit   |   Hop Count   |    Message Sequence Number    |
3271	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3272	     | Message TLV Block Length = 10 |    METRIC     |  MTLVF = 144  |
3273	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3274	     |  Type Ext.    | Value Len = 2 |        Value (metric)         |
3275	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3276	     |     FLAGS     |   MTLVF = 16  | Value Len = 1 | Value (0x80)  |
3277	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3278	     | Num Addrs = 1 |    ABF = 0    |             Mid               |
3279	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3280	     |              Mid              |  Address TLV Block Length = 2 |
3281	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3282	     |   ADDR-TYPE   |   ATLVF = 0   |
3283	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3285	C.3.  RREP_ACK

3287	   RREP_ACK messages are instances of [RFC5444] messages.  This
3288	   specification requires that RREP_ACK messages contains RREP_ACK.msg-
3289	   seq-num.  It supports RREP_ACK messages with any combination of
3290	   remaining message header options and address encodings, enabled by
3291	   [RFC5444] that convey the required information.  As a consequence,
3292	   there is no single way to represent how all RREP_ACK messages look.
3293	   This section illustrates an RREP_ACK message, the exact values and
3294	   content included are explained in the following text.

3296	   The RREP_ACK message's four bit Message Flags (MF) field has value 1
3297	   indicating that the message header contains the message sequence
3298	   number field.  Its four bit Message Address Length (MAL) field has
3299	   value 3, indicating addresses in the message have a length of four
3300	   octets, here being IPv4 addresses.  The overall message length is 18
3301	   octets.

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

3306	   The message has one Address Block.  The Address Block contains 1
3307	   address, with Flags octet (ATLVF) value 0, hence with no Head or Tail
3308	   sections, and hence with a Mid section with length four octets.  The
3309	   following TLV Block (content length 2 octets) contains one TLV.  The
3310	   TLV is an ADDR_TYPE TLV with Flags octet (ATLVF) value 0, indicating
3311	   no Value and no indexes.  Thus, the address is associated with the
3312	   Type ADDR_TYPE, i.e., it is the destination address of the RREP_ACK.

3314	      0                   1                   2                   3
3315	      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
3316	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3317	     |   RREP_ACK    | MF=1  | MAL=3 |      Message Length = 18      |
3318	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3319	     |    Message Sequence Number    | Message TLV Block Length = 0  |
3320	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3321	     | Num Addrs = 1 |    ABF = 0    |               Mid             |
3322	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3323	     |               Mid             | Address TLV Block Length = 2  |
3324	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3325	     |   ADDR-TYPE   |   ATLVF = 0   |
3326	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3328	C.4.  RERR

3330	   RERR messages are instances of [RFC5444] messages.  This
3331	   specification supports RERR messages with any combination of message
3332	   header options and address encodings, enabled by [RFC5444] that
3333	   convey the required information.  As a consequence, there is no
3334	   single way to represent how all RERR messages look.  This section
3335	   illustrates an RERR message, the exact values and content included
3336	   are explained in the following text.

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

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

3348	   The message has one Address Block.  The Address Block contains 2
3349	   addresses, with Flags octet (ATLVF) value 128, hence with a Head
3350	   section (with length 3 octets), but no Tail section, and hence with
3351	   Mid sections with length one octet.  The following TLV Block (content
3352	   length 9 octets) contains two TLVs.  The first TLV is an ADDR_TYPE
3353	   TLV with Flags octet (ATLVF) value 64, indicating a single index of
3354	   0, but no Value.  Thus, the first address is associated with the Type
3355	   ADDR_TYPE and Type Extension DESTINATION, i.e., it is the destination
3356	   address of the RERR.  The second TLV is an ADDR_TYPE TLV with Flags
3357	   octet (ATLVF) value 208, indicating Type Extension, Value, and single
3358	   index.  Thus, the second address is associated with the Type
3359	   ADDR_TYPE, Type Extension ERRORCODE, and Value 0, i.e., it is
3360	   associated with error code 0.

3362	      0                   1                   2                   3
3363	      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
3364	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3365	     |     RERR      | MF=12 | MAL=3 |      Message Length = 30      |
3366	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3367	     |                      Originator Address                       |
3368	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3369	     |   Hop Limit   | Message TLV Block Length = 0  | Num Addrs = 2 |
3370	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3371	     |  ABF = 128    | Head Len = 3  |       Head                    |
3372	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3373	     |    Head       |             Mid               | Address TLV   |
3374	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3375	     |Block Length= 9|   ADDR-TYPE   |   ATLVF = 64  |  Index = 0    |
3376	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3377	     |   ADDR-TYPE   |  ATLVF = 208  |TypEx=ERRORCODE|  Index = 1    |
3378	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3379	     | Value Len = 1 |  Value = 0    |
3380	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3382	Authors' Addresses

3384	   Thomas Heide Clausen
3385	   Ecole Polytechnique

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

3391	   Axel Colin de Verdiere
3392	   Ecole Polytechnique

3394	   Phone: +33 6 1264 7119
3395	   EMail: axel@axelcdv.com
3396	   URI:   http://www.axelcdv.com/
3397	   Jiazi Yi
3398	   Ecole Polytechnique

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

3404	   Afshin Niktash
3405	   Maxim Integrated Products

3407	   Phone: +1 94 9450 1692
3408	   EMail: afshin.niktash@maxim-ic.com
3409	   URI:   http://www.Maxim-ic.com/

3411	   Yuichi Igarashi
3412	   Hitachi, Ltd., Yokohama Research Laboratory

3414	   Phone: +81 45 860 3083
3415	   EMail: yuichi.igarashi.hb@hitachi.com
3416	   URI:   http://www.hitachi.com/

3418	   Hiroki Satoh
3419	   Hitachi, Ltd., Yokohama Research Laboratory

3421	   Phone: +81 44 959 0205
3422	   EMail: hiroki.satoh.yj@hitachi.com
3423	   URI:   http://www.hitachi.com/

3425	   Ulrich Herberg

3427	   EMail: ulrich@herberg.name
3428	   URI:   http://www.herberg.name/

3430	   Cedric Lavenu
3431	   EDF R&D

3433	   Phone: +33 1 4765 2729
3434	   EMail: cedric-2.lavenu@edf.fr
3435	   URI:   http://www.edf.fr/
3436	   Thierry Lys
3437	   ERDF

3439	   Phone: +33 1 8197 6777
3440	   EMail: thierry.lys@erdfdistribution.fr
3441	   URI:   http://www.erdfdistribution.fr/

3443	   Justin Dean
3444	   Naval Research Laboratory

3446	   EMail: jdean@itd.nrl.navy.mil
3447	   URI:   http://cs.itd.nrl.navy.mil/