idnits 2.17.1 draft-yi-loadngct-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 355 has weird spacing: '...trigger is th...' == Line 360 has weird spacing: '...Q.build is th...' == Line 364 has weird spacing: '...ct-rrep is th...' == Line 373 has weird spacing: '...-length is an...' == Line 378 has weird spacing: '...ginator is an...' == (2 more instances...) -- The document date (July 4, 2014) is 3583 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-clausen-lln-loadng-10 -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Yi 3 Internet-Draft T. Clausen 4 Intended status: Experimental LIX, Ecole Polytechnique 5 Expires: January 5, 2015 July 4, 2014 7 Collection Tree Protocol for Lightweight On-demand Ad hoc Distance- 8 vector Routing - Next Generation (LOADng-CT) 9 draft-yi-loadngct-02 11 Abstract 13 This document describes the Collection Tree Protocol for Lightweight 14 Ad hoc On-Demand - Next Generation (LOADng-CT) to build routes 15 between a designated root and all the other routers in Mobile Ad Hoc 16 NETworks (MANETs). The protocol is an extension of LOADng. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 5, 2015. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 4 55 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 5 56 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 4.2. Information Base Overview . . . . . . . . . . . . . . . . 6 58 4.3. Signaling Overview . . . . . . . . . . . . . . . . . . . . 6 59 5. Parameters and Constants . . . . . . . . . . . . . . . . . . . 6 60 6. Information Bases . . . . . . . . . . . . . . . . . . . . . . 7 61 6.1. Link Set . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 7. Protocol Message Content . . . . . . . . . . . . . . . . . . . 8 63 7.1. Route Request (RREQ) Message . . . . . . . . . . . . . . . 8 64 7.2. HELLO Message . . . . . . . . . . . . . . . . . . . . . . 8 65 8. Route Request for Collection Tree Triggering (RREQ_TRIGGER) . 9 66 8.1. RREQ_TRIGGER Generation . . . . . . . . . . . . . . . . . 9 67 8.2. RREQ_TRIGGER Processing . . . . . . . . . . . . . . . . . 10 68 8.3. RREQ_TRIGGER Forwarding . . . . . . . . . . . . . . . . . 11 69 8.4. RREQ_TRIGGER Transmission . . . . . . . . . . . . . . . . 11 70 9. HELLO message . . . . . . . . . . . . . . . . . . . . . . . . 11 71 9.1. HELLO Generation . . . . . . . . . . . . . . . . . . . . . 11 72 9.2. HELLO Processing . . . . . . . . . . . . . . . . . . . . . 12 73 9.3. HELLO Forwarding . . . . . . . . . . . . . . . . . . . . . 12 74 9.4. HELLO Transmission . . . . . . . . . . . . . . . . . . . . 13 75 10. Route Request for Collection Tree Building (RREQ_BUILD) . . . 13 76 10.1. RREQ_BUILD Generation . . . . . . . . . . . . . . . . . . 13 77 10.2. RREQ_BUILD Processing . . . . . . . . . . . . . . . . . . 13 78 10.3. RREQ_BUILD Forwarding . . . . . . . . . . . . . . . . . . 14 79 10.4. RREQ_BUILD Transmission . . . . . . . . . . . . . . . . . 14 80 11. Collection Tree Maintenance and Local Repair . . . . . . . . . 14 81 12. Implementation Status . . . . . . . . . . . . . . . . . . . . 15 82 12.1. Implementation of Ecole Polytechnique . . . . . . . . . . 16 83 13. Security Considerations . . . . . . . . . . . . . . . . . . . 16 84 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 85 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 86 15.1. Normative References . . . . . . . . . . . . . . . . . . . 17 87 15.2. Informative References . . . . . . . . . . . . . . . . . . 17 88 Appendix A. LOADng-CT Control Messages using RFC5444 . . . . . . 18 89 A.1. RREQ_TRIGGER and RREQ_BUILD Messages Encoding 90 Considerations . . . . . . . . . . . . . . . . . . . . . . 18 91 A.2. HELLO Message Encoding Considerations . . . . . . . . . . 18 92 Appendix B. RFC5444-Specific IANA Considerations . . . . . . . . 19 93 Appendix C. LOADng-CT Control Packet Illustrations . . . . . . . 20 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 96 1. Introduction 98 Collection Tree Protocol for Ligthweight Ad hoc On-Demand - Next 99 Generation (LOADng-CT) is an extension of LOADng protocol 100 [I-D.clausen-lln-loadng] for use in discovering routes from between a 101 designated root and all the other routers in Mobile Ad hoc NETworks 102 (MANETs) by building a Collection Tree. 104 Compared to LOADng, which builds mainly point-to-point routes, 105 LOADng-CT inherits the information base, message format, basic 106 functions and main characteristics of LOADng, and is extended as 107 follows: 109 o The root of the expected collection tree can initiate the 110 collection tree building process, so that every LOADng-CT router 111 in the MANETs can discover a route to the root. 113 o HELLO message and Link Set are introduced to discover the bi- 114 directional neighbors, which guarantees the routes built are bi- 115 directional. 117 o If required, LOADng-CT can also build the routes from the root to 118 all the other routers in the network. 120 LOADng-CT is compatible with LOADng [I-D.clausen-lln-loadng], which 121 means: 123 o LOADng-CT shares the same message format with LOADng. 125 o A router with LOADng implementation can join the collection tree 126 initiated by a router with LOADng-CT implementation. 128 o As an extension of LOADng, a router with LOADng-CT implementation 129 has all the functions of LOADng implicitly. 131 2. Terminology 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 135 "OPTIONAL" in this document are to be interpreted as described in 136 [RFC2119]. 138 This document uses the terminology and notation defined in 139 [I-D.clausen-lln-loadng]. Additionally, it defines the following 140 terminology: 142 Collection Tree - A directed graph that all edges are oriented 143 toward and terminate at one root node. 145 LOADng-CT Router - A router that implements this LOADng-CT protocol. 146 A LOADng-CT router can be equipped with one or multiple distinct 147 interfaces. 149 LOADng Router - A router that implements LOADng protocol 150 [I-D.clausen-lln-loadng] without collection tree extension. A 151 LOADng router can be equipped with one or multiple distinct 152 interfaces. 154 Root - A LOADng-CT Router, which is the root node in the collection 155 tree. 157 Sensor - A LOADng-CT Router, which is not root node in the 158 collection tree. 160 Root-to-sensor route - A route from the Root to a sensor. In some 161 documents, it is also called "downward route", or "point-to- 162 multipoint route". 164 Sensor-to-root route - A route from a sensor to the Root. In some 165 documents, it is also called "upward route", or "multipoint-to- 166 point route". 168 Sensor-to-sensor route - A route from a sensor to another sensor. 169 In some documents, it is also called "point-to-point route". 171 3. Applicability Statement 173 This protocol: 175 o Is a collection tree protocol for building sensor-to-root routes 176 in MANETs. 178 o Enables LOADng-CT Routers in the MANETs to discover bi-directional 179 route to the root. 181 o Can discover the routes on-demand, in case of route failure or 182 participation of new routers, without rebuilding the collection 183 tree. 185 o Inherits the main characteristics of LOADng, which includes: 186 optimal flooding support, different address lenght support, layer- 187 agnostic, etc. 189 o Is compatible with LOADng specification. A LOADng Router without 190 this collection tree extension can also join the collection tree. 192 4. Protocol Overview and Functioning 194 A LOADng-CT router is able to: 196 o Initiate a collection tree building process by the Root. 198 o Identify the bi-directional links between its neighbors by HELLO 199 message exchange. 201 o Discover routes using only bi-directional links to the root by 202 joining the collection tree. 204 o Maintain the collection tree on-demand without rebuilding the 205 tree. 207 o Build routes using only bi-directional links from the root to 208 other routers, if required. 210 4.1. Overview 212 To participate in a MANET, a LOADng-CT Router MUST have at least one 213 or more LOADng-CT interfaces. Each LOADng-CT Router MUST be 214 configured with one or more interface addresses. 216 Each LOADng-CT router performs the following tasks: 218 o A LOADng-CT router that is expected to be the root of the 219 collection tree initiates the collection tree building by 220 transmitting a Route Request message with COLLECTION_TREE_TRIGGER 221 flag (denoted RREQ_TRIGGER message). 223 o Upon receiving an RREQ_TRIGGER, the LOADng-CT Router records the 224 address of the sending router interface (i.e., the neighbor, from 225 which it received the RREQ_TRIGGER) in its Link Set, with the 226 status HEARD. If this RREQ_TRIGGER has not been received before, 227 it is retransmitted to its neighbors according to the flooding 228 operation, specified for the network. A HELLO message is also 229 transmitted carrying all the neighbors so that each router can be 230 aware of its bi-directional neighbors. By such RREQ_TRIGGER and 231 HELLO message exchange, every LOADng-CT Router can identify its 232 bi-directional neighbors, marked as SYM. 234 o After initiating the RREQ_TRIGGER for 2 x NET_TRAVERSAL_TIME, the 235 root generates an RREQ with COLLECTION_TREE_BUILD flag (denoted 236 RREQ_BUILD message). The RREQ_BUILD is flooded in the network 237 according to the flooding operation. The routers only process and 238 retransmit the RREQ_BUILD from it bi-directional neighbors. On 239 receiving a valid RREQ_BUILD, a new routing tuple to the root is 240 inserted into the Routing Set. 242 o If the route from the root to the non-root LOADng-CT Router is 243 desired, the router receiving the RREQ_BUILD MUST unicast an RREP 244 to the root. 246 4.2. Information Base Overview 248 In addition to the Routing Set, Local Interface Set, Blacklisted 249 Neighbor Set, Destination Address Set, Pending Acknowledgment Set 250 described in [I-D.clausen-lln-loadng], a Link Set is introduced for 251 LOADng-CT. 253 Link Set contains tuples, each representing a single link to a 254 router's 1-hop neighbor. 256 4.3. Signaling Overview 258 In addition to the Route Request (RREQ), Route Reply (RREP), Route 259 Reply Acknowledgment (RREP_ACK), Route Error (RERR) messages 260 described in [I-D.clausen-lln-loadng], a LOADng-CT router generates 261 and processes following messages: 263 Route Request with COLLECTION_TREE_TRIGGER flag (RREQ_TRIGGER) - 264 Generated by the root of the collection tree to begin the 265 collection tree building process. An RREQ_TRIGGER is flooded 266 through the network, according to the flooding operation specified 267 for the network. 269 Route Request with COLLECTION_TREE_BUILD flag (RREQ_BUILD) - 270 Generated by the root of the collection tree and flooded through 271 the network. The LOADng-CT routers receiving RREQ_BUILD can build 272 the routes to the Root. 274 HELLO - Generated by each LOADng-CT router carrying its 1-hop 275 neighbor information. 277 5. Parameters and Constants 279 In addition to the parameters and constants defined in 280 [I-D.clausen-lln-loadng], a LOADng-CT Router uses the parameters and 281 constants described in this section. 283 RREQ_MAX_JITTER - is the maximum jitter for RREQ message 284 transmission. 286 HELLO_MIN_JITTER - is the minimum jitter for HELLO message 287 transmission. HELLO_MIN_JITTER MUST be greater than 2 x 288 RREQ_MAX_JITTER. 290 HELLO_MAX_JITTER - is the maximum jitter for HELLO message 291 transmission. 293 L_HOLD_TIME - is the minimum time a Link Tuple SHOULD be kept in the 294 Link Set after it was last refreshed. 296 RREP_REQUIRED - is the flag to define if an RREP message is required 297 on receiving RREQ_BUILD message, to build route from sensor to 298 root. 300 6. Information Bases 302 Each LOADng-CT Router maintains an Information Base, containing 303 several information sets. These information sets are given so as to 304 facilitate description of message generation, forwarding and 305 processing rules. In particular, an implementation may chose any 306 representation or structure for when maintaining this information. 307 In addition to the information sets described in 308 [I-D.clausen-lln-loadng], the Link Set is introduced for LOADng-CT 309 extension. 311 6.1. Link Set 313 The Link Set records the link status to 1-hop neighbors. It consists 314 of Link Tuples, each of which representing a single link: 316 (L_neighbor_iface_addr, L_HEARD_time, L_SYM_time, L_time) 318 NOTE: compared to NHDP link set, I eliminated L_quality, 319 L_pending, L_lost fields. 320 Do we need them? 322 where: 324 L_neighbor_iface_addr - is a network addresses of the MANET 325 interface of the 1-hop neighbor; 327 L_HEARD_time - is the time up to which the MANET interface of the 328 1-hop neighbor would be considered heard; 330 L_SYM_time - is the time up to which the link to the 1-hop neighbor 331 would be considered symmetric; 333 L_time - specifies when this Tuple expires and MUST be removed. 335 The link can be in following status: 337 LOST - If L_HEARD_time and L_SYM_time is expired; 339 SYM - If L_SYM_time is not expired; 341 HEARD - If L_HEARD_time is not expired, and L_SYM_time is expired. 343 7. Protocol Message Content 345 The packet and message format used by this protocol follows the 346 specification of [I-D.clausen-lln-loadng]. Three additional flags 347 for RREQ and a new HELLO message are introduced for collection tree 348 extension. 350 7.1. Route Request (RREQ) Message 352 The fields of RREQ message is defined in [I-D.clausen-lln-loadng]. 353 In addition, LOADng-CT has has three flags: 355 RREQ.trigger is the COLLECTION_TREE_TRIGGER flag. It is a boolean 356 flag. When set ('1'), it identifies the message is generated by 357 the root of the collection tree to trigger the collection tree 358 building process. 360 RREQ.build is the COLLECTION_TREE_BUILD flag. It is a boolean flag. 361 When set ('1'), it identifies the message is generated by the root 362 of the collection tree to build routes to the root. 364 RREQ.ct-rrep is the COLLECTION_TREE_RREP flag. It is a boolean 365 flag. When set ('1'), it identifies the RREQ_BUILD message 366 requires the receiving sensors send an RREP message to the root, 367 to build root-to-sensor routes. 369 7.2. HELLO Message 371 A HELLO message has the following fields: 373 HELLO.addr-length is an unsigned integer field, encoding the length 374 of the originator and destination addresses as follows: 376 HELLO.addr-length := the length of an address in octets - 1 378 HELLO.originator is an identifier of HELLO.addr-length + 1 octets, 379 specifying the address for which this RREP was generated 381 HELLO.validity-time represents L_HOLD_TIME for the transmitting 382 MANET interface. 384 HELLO.1hop-list represents a list of 1-hop neighbor. It consists of 385 1-hop tuples: 387 (H_1hop_address, H_1hop_status) 389 where: 391 H_1hop_address - is a network address of 1-hop neighbors from the 392 Link Set of this MANET interface (i.e., L_neighbor_iface_addr). 394 H_1hop_status - is the associated 1-hop status (L_status) of 395 H_1hop_address. 397 8. Route Request for Collection Tree Triggering (RREQ_TRIGGER) 399 The RREQ_TRIGGER is an RREQ message with COLLECTION_TREE_TRIGGER flag 400 set ('1'). It is generated by a LOADng-CT root when a collection 401 tree is desired or needs to be rebuilt. It will trigger the 402 collection tree building process. 404 8.1. RREQ_TRIGGER Generation 406 A packet with RREQ_TRIGGER message is generated by a LOADng-CT router 407 that wants to be a root of a collection tree, according to 408 Section 7.1 with the following content: 410 o RREQ.addr-length set to the length of the address in octets -1; 412 o RREQ.metric-type set to the desired metric type; 414 o RREQ.route-metric := 0; 416 o RREQ.seq-num set to the next unused sequence number, maintained by 417 this LOADng-CT Router; 419 o RREQ.hop-count := 0; 421 o RREQ.hop-limit := MAX_HOP_LIMIT; 423 o RREQ.originator := one address of the LOADng-CT Interface of the 424 LOADng Router that generates the RREQ. If the LOADng-CT Router is 425 generating RREQ on behalf of a host connected to this LOADng-CT 426 Router, the source address of the data packet, generated by that 427 host, is used; 429 o RREQ.destination := RREQ.originator; 431 o RREQ.trigger := true. 433 8.2. RREQ_TRIGGER Processing 435 On receiving an RREQ_TRIGGER message, a LOADng-CT Router MUST process 436 the message according to this section: 438 1. A received RREQ_TRIGGER is invalid, and MUST be discarded without 439 further processing, if any of the following conditions are true: 441 * The address length specified by this message (i.e., MSG.addr- 442 length + 1) differs from the length of the address(es) of this 443 LOADng Router. 445 * There is a tuple in the Routing Set where: 447 + R_dest_addr = MSG.originator 449 + R_seq_num >= MSG.seq-num 451 2. Add the heard neighbor to the Link Set: 453 * Find the the Link Tuple (henceforth, matching Link Tuple) 454 where: 456 + L_neighbor_iface_addr = previous-hop 458 * The matching Neighbor Tuple is updated with the following 459 information. If there is no matching Neighbor Tuple found, a 460 new Neighbor Tuple is created with: 462 + L_neighbor_iface_addr := previous-hop; 464 + L_HEARD_time := current_time + L_HOLD_TIME; 465 + L_local_iface_addr := the interface address through which 466 the RREQ_TRIGGER was received; 468 + L_time := current_time + L_HOLD_TIME; 470 3. If the address contained in MSG.originator is an address of this 471 LOADng Router, the message is processed according to Section 11.2 472 of [I-D.clausen-lln-loadng]. All the Routing Tuples created or 473 updated MUST set the R_bidirectional to FALSE. Otherwise, the 474 message is discarded without further processing. 476 4. 478 5. If hop-count is less than MAX_HOP_COUNT and hop-limit is greater 479 than 0, the message is considered for forwarding according to 480 Section 8.3 482 6. A HELLO message is scheduled according to Section 9. 484 8.3. RREQ_TRIGGER Forwarding 486 An RREQ_TRIGGER message considered for forwarding follows Section 487 12.3: RREQ Forwarding of [I-D.clausen-lln-loadng]. 489 8.4. RREQ_TRIGGER Transmission 491 An RREQ_TRIGGER message is transmitted according to Section 12.4: 492 RREQ Transmission of [I-D.clausen-lln-loadng]. 494 9. HELLO message 496 HELLO messages are generated by a LOADng-CT Router after receiving 497 RREQ_TRIGGER for a certain periode of time. (TODO: define the time 498 here) HELLO message carries the router's 1-hop neighbor information. 499 Each LOADng-CT Router that receives the HELLO messages are thus able 500 to determine its bi-directional 1-hop neighbors. 502 9.1. HELLO Generation 504 A packet with HELLO message is generated after receiving a fresh 505 RREQ_TRIGGER message, and MUST be jittered according to 506 MIN_HELLO_JITTER and MAX_HELLO_JITTER, in which MIN_HELLO_JITTER MUST 507 be greater than 2 x MAX_RREQ_JITTER. A new HELLO message is created 508 with following content: 510 o HELLO.addr-length set to the length of the address in octets -1; 511 o HELLO.originator := the address of the LOADng-CT interface that 512 generates the HELLO message; 514 o HELLO.validity-time := L_HOLD_TIME; 516 o HELLO.1hop-list includes all the 1-hop neighbors in Link Set, 517 other than those from Link Tuples with L_status = LOST. Each 1hop 518 tuple is set with following content: 520 * H_1hop_address := L_neigbhor_iface_addr; 522 * H_1hop_status := L_status. 524 9.2. HELLO Processing 526 On receiving a HELLO message, a LOADng-CT Router MUST process the 527 message according to this section: 529 1. Find the 1-hop neighbor address in the HELLO message's 1-hop 530 neighbor List (henceforth, matching Neighbor Address) where: 532 * H_1hop_address = any address in Local Interface Set 534 2. If no matching Neighbor Address is found, the originator of the 535 HELLO message MUST be blacklisted by creating a Blacklist tuple: 537 * B_neighbor_address := HELLO.originator; 539 * B_valid_time := current_time + B_HOLD_TIME. 541 3. For the matching Neighbor Address, find the Link Tuple in the 542 LOADng-CT Router's Link Set (henceforth, matching Link Tuple) 543 where: 545 * L_neighbor_iface_addr = matching Neighbor Address 547 If the matching Link Tuple exists, update the matching Link Tuple 548 as: 550 * L_SYS_time := current_time + L_HOLD_TIME; 552 * L_time := current_time + L_HOLD_TIME 554 9.3. HELLO Forwarding 556 The HELLO message is not considered for forwarding. 558 9.4. HELLO Transmission 560 The initially generated HELLO messages are sent to all neighbor 561 LOADng-CT Routers. 563 10. Route Request for Collection Tree Building (RREQ_BUILD) 565 The RREQ_BUILD is an RREQ message with COLLECTION_TREE_BUILD flag set 566 ('1'). It is generated by a LOADng-CT root after 2 x 567 NETWORK_TRAVERSAL_TIME of the RREQ_TRIGGER message. The sensors 568 receiving the RREQ_BUILD messages will build the route to the root. 570 10.1. RREQ_BUILD Generation 572 A packet with RREQ_TRIGGER message is generated by the root, 573 following the generation of RREQ_TRIGGER, according to Section 7.1 574 with the following content: 576 o RREQ.addr-length set to the length of the address in octets -1; 578 o RREQ.metric-type set to the desired metric type; 580 o RREQ.route-metric := 0; 582 o RREQ.seq-num set to the next unused sequence number, maintained by 583 this LOADng-CT Router; 585 o RREQ.hop-count := 0; 587 o RREQ.originator := one address of the LOADng-CT Interface of the 588 LOADng Router that generates the RREQ. If the LOADng-CT Router is 589 generating RREQ on behalf of a host connected to this LOADng-CT 590 Router, the source address of the data packet, generated by that 591 host, is used; 593 o RREQ.destination := RREQ.originator; 595 o RREQ.build := true; 597 o If the root requires root-to-sensor routes, RREQ.ct-rrep := true. 599 10.2. RREQ_BUILD Processing 601 On receiving an RREQ_BUILD message, the root MUST discard it silently 602 without further processing. A sensor MUST process the message 603 according to this section: 605 1. If the message is invalid for processing, as defined in Section 606 11.1: Identifying Invalid RREQ or RREP Messages of 607 [I-D.clausen-lln-loadng], the message MUST be discarded without 608 further processing. The message is not considered for 609 forwarding. 611 2. Find the Link Tuple in the Link Set where: 613 * L_neighbor_iface_address = previous-hop; AND 615 * L_status = SYM 617 If no tuple is found, the message MUST be discarded without 618 further processing. The message is not considered for 619 forwarding. 621 3. The message is processed according to Section 11.2: RREQ and RREP 622 Message Processing of [I-D.clausen-lln-loadng]. All the Route 623 Tuples created or updated during processing MUST set 624 R_bidirectional to TRUE. 626 4. If hop-count is less than MAX_HOP_COUNT and hop-limit is greater 627 than 0, the message is considered for forwarding according to 628 Section 8.3 630 5. If the downward route from the root to the sensor is required 631 (i.e., RREQ.ct-rrep is set, or REPLY_REQUIRED is true), an RREP 632 is generated and unicast to the root. 634 10.3. RREQ_BUILD Forwarding 636 An RREQ_BUILD message considered for forwarding follows Section 12.3 637 RREQ Forwarding of [I-D.clausen-lln-loadng]. 639 10.4. RREQ_BUILD Transmission 641 An RREQ_BUILD message is transmitted according to Section 12.4 RREQ 642 Transmission of [I-D.clausen-lln-loadng]. 644 11. Collection Tree Maintenance and Local Repair 646 The tuples in the Routing Set are maintained by mechanisms specified 647 in Section 9: Route Maintenance in [I-D.clausen-lln-loadng]. For the 648 collection tree, LOADng-CT Routers are able to: 650 o Repair a broken route to the root. 652 o Participate in an existed collection tree, as a newly joined 653 LOADng-CT Router, or a LOADng router that does not support 654 collection tree extension. 656 If a link break occurs during data packet transmission, or a new 657 LOADng-CT Router wishes to participate in the collection tree, the 658 sensor initiate a new RREQ message without COLLECTION_TREE_TRIGGER 659 and COLLECTION_TREE_BUILD flag set (denoted RREQ_NORMAL message) and 660 field set to one of the interface addresses of the 661 root. The RREQ_NORMAL MUST be processed and forwarded according to 662 Section 12: Route Requests (RREQs) in [I-D.clausen-lln-loadng]. 664 The collection tree can also be re-built by triggering a new 665 RREQ_TRIGGER message by the root. How and when this RREQ_TRIGGER 666 message should initiated would depend on network implementations. 667 Some of the possible solutions can be: 669 o The root initiates an RREQ_TRIGGER message periodically. The 670 interval SHOULD be depend on the frequency of topology changes. 672 o The root initiates an RREQ_TRIGGER message when it receives large 673 amount of RREQ message destined to itself. 675 To avoid normal RREQ messages (without TRIGGER or BUILD flag) being 676 broadcast through the whole network, and take benefits from the fact 677 that "most of other neighbor routers might have an available route 678 the to root", a Smart Route Request scheme MAY be employed: 680 o On receiving an RREQ_NORMAL message, the intermediate LOADng-CT 681 Router checks if it has an available Route Tuple to the 682 destination. If no Route Tuple is found, the message is forwarded 683 according to the RREQ forward procedure. 685 o If an available Route Tuple to the destination is found, the 686 intermediate router jut unicasts the RREQ_NORMAL to the 687 destination according to the Route Tuple. 689 The LOADng Routers cannot join the collection tree in the collection 690 tree building phase, because they cannot generate HELLO message and 691 thus cannot be verified as bi-directional neighbor. For those 692 routers, they can join the collection tree by initiating a new normal 693 RREQ message. 695 12. Implementation Status 697 This section records the status of known implementations of the 698 protocol defined by this specification at the time of posting of this 699 Internet-Draft, and based on a proposal described in [RFC6982]. The 700 description of implementations in this section is intended to assist 701 the IETF in its decision processes in progressing drafts to RFCs. 702 Please note that the listing of any individual implementation here 703 does not imply endorsement by the IETF. Furthermore, no effort has 704 been spent to verify the information presented here that was supplied 705 by IETF contributors. This is not intended as, and must not be 706 construed to be, a catalog of available implementations or their 707 features. Readers are advised to note that other implementations may 708 exist. 710 According to [RFC6982], "this will allow reviewers and working groups 711 to assign due consideration to documents that have the benefit of 712 running code, which may serve as evidence of valuable experimentation 713 and feedback that have made the implemented protocols more mature. 714 It is up to the individual working groups to use this information as 715 they see fit". 717 There is currently one publicly-known implementation of LOADng-CT 718 specified in this document. 720 12.1. Implementation of Ecole Polytechnique 722 This implementation is developed by the Networking Group at Ecole 723 Polytechnique and applied to LOADng [I-D.clausen-lln-loadng]. It can 724 run over real network interfaces, and can also be integrated with the 725 network simulator NS2. It is a Java implementation, and can be used 726 on any platform that includes a Java virtual machine. 728 The implementation is based on -00 revision of this document, and 729 includes only about 100 lines of additional code to the LOADng 730 implementation. Primary simulation results have been published in 731 [IEEE_WiCOM2012]. Results show that LOADng-CT extension can greatly 732 reduce the overhead for collection tree building, compared to LOADng 733 core specification. 735 13. Security Considerations 737 As an extension of LOADng protocol, LOADng-CT inherits the 738 vulnerabilities of LOADng discussed in section 18 of 739 [I-D.clausen-lln-loadng]. 741 In addition, the collection tree building process relies on strictly 742 ordered message sequences: RREQ_TRIGGER message for triggering the 743 building process, then HELLO message for bi-direction neighbor check, 744 and RREQ_BUILD message for collection tree build in the end. The 745 message emission is controlled by router parameters like 746 NET_TRAVERSAL_TIME, RREQ_JITTER, and HELLO_JITTER. 748 The receiving order can be expected if those parameters are set 749 correctly -- however, in real implementations, there might exist mis- 750 configured routers, or even compromised routers that emit messages 751 out of order. For example, if a router sends a HELLO message before 752 it receives all the RREQ_TRIGGER messages from its neighbours, or an 753 RREQ_BUILD message is received before the HELLO message exchange 754 finished, the router cannot identify its bi-directional neighbours 755 correctly -- thus is not able to join the collection tree as 756 expected. 758 14. IANA Considerations 760 IANA is requested to .... 762 15. References 764 15.1. Normative References 766 [I-D.clausen-lln-loadng] 767 Clausen, T., Verdiere, A., Yi, J., Niktash, A., Igarashi, 768 Y., Satoh, H., Herberg, U., Lavenu, C., Lys, T., and J. 769 Dean, "The Lightweight On-demand Ad hoc Distance-vector 770 Routing Protocol - Next Generation (LOADng)", 771 draft-clausen-lln-loadng-10 (work in progress), 772 October 2013. 774 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 775 Requirement Levels", BCP 14, RFC 2119, March 1997. 777 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 778 "Generalized Mobile Ad Hoc Network (MANET) Packet/Message 779 Format", RFC 5444, February 2009. 781 [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value 782 Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, 783 March 2009. 785 15.2. Informative References 787 [IEEE_WiCOM2012] 788 Yi, J., Clausen, T., and A. Colin de Verdiere, "Efficient 789 Data Acquisition in Sensor Networks: Introducing (the) 790 LOADng Collection Tree Protocol", Proceedings of IEEE 791 WiCOM2012, IEEE International Conference on Wireless 792 Communications, Networking and Mobile Computing, 2012. 794 [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc 795 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 796 RFC 6130, April 2011. 798 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 799 Code: The Implementation Status Section", RFC 6982, 800 July 2013. 802 Appendix A. LOADng-CT Control Messages using RFC5444 804 This section presents how the abstract LOADng-CT messages, used 805 throughout this specification, are mapped into [RFC5444] messages. 807 A.1. RREQ_TRIGGER and RREQ_BUILD Messages Encoding Considerations 809 This protocol makes use of RREQ message defined in 810 [I-D.clausen-lln-loadng]. Therefore, it reuses the RREQ Message Type 811 defined in [I-D.clausen-lln-loadng], and defines three additional 812 flags: RREQ.trigger, RREQ.build and RREQ.ct-rrep. Table 1 describes 813 how those flags are mapped into [RFC5444]. 815 +--------------+-----------------+----------------------------------+ 816 | RREQ Element | RFC5444-Element | Considerations | 817 +--------------+-----------------+----------------------------------+ 818 | RREQ.trigger | FLAGS Message | Encoded by way of a | 819 | | TLV | Message-Type-specific Message | 820 | | | TLV of type FLAGS, defined in | 821 | | | Table 4 | 822 | RREQ.build | FLAGS Message | Encoded by way of a | 823 | | TLV | Message-Type-specific Message | 824 | | | TLV of type FLAGS, defined in | 825 | | | Table 4 | 826 | RREQ.ct-rrep | FLAGS Message | Encoded by way of a | 827 | | TLV | Message-Type-specific Message | 828 | | | TLV of type FLAGS, defined in | 829 | | | Table 4 | 830 +--------------+-----------------+----------------------------------+ 832 Table 1: RREQ Message Elements for LOADng-CT 834 A.2. HELLO Message Encoding Considerations 836 This protocol makes use of HELLO Message Type. It is compatible with 837 HELLO Message defined in [RFC6130], i.e., the HELLO message generated 838 by this protocol is also valid for [RFC6130]. Table 2 describes how 839 HELLO messages are mapped in to [RFC5444] elements. 841 +---------------------+-------------------+-------------------------+ 842 | HELLO Element | RFC5444-Element | Considerations | 843 +---------------------+-------------------+-------------------------+ 844 | HELLO.addr-length | | Supports addresses from | 845 | | | 1-16 octets | 846 | HELLO.originator | | MUST be included in a | 847 | | | HELLO message | 848 | HELLO.validity-time | VALIDITY_TIME | Exactly one | 849 | | Message TLV (Type | VALIDITY_TIME TLV MUST | 850 | | 1) | be included in a HELLO | 851 | | | message. The value is | 852 | | | calculated by [RFC5497] | 853 | HELLO.1hop-list | LINK_STATUS | With type extension 0. | 854 | | Address Block TLV | Specifies the status of | 855 | | (Type 3) | the link from the | 856 | | | indicated network | 857 | | | address (LOST = 0, | 858 | | | SYMMETRIC = 1, or HEARD | 859 | | | = 2) | 860 +---------------------+-------------------+-------------------------+ 862 Table 2: HELLO Message Elements for LOADng-CT 864 Appendix B. RFC5444-Specific IANA Considerations 866 This specification uses two message types: RREQ and HELLO, which has 867 been allocated in "Message Types" namespace of [RFC5444], in 868 [I-D.clausen-lln-loadng] and [RFC6130] respectively. 870 IANA is requested to add a RREQ Message-Type-specific Message TLV 871 Type, in accordance with Section 6.2.1 of [RFC5444], with allocation 872 policies as specified in Table 3. 874 +---------+-------------+-------------------+ 875 | Type | Description | Allocation Policy | 876 +---------+-------------+-------------------+ 877 | 129 | FLAGS | | 878 | 130-223 | Unassigned | Expert Review | 879 +---------+-------------+-------------------+ 881 Table 3: RREQ Message-Type-specific TLV Type for LOADng-CT 883 Allocation of the FLAGS TLV from the RREQ Message-Type-specific 884 Message TLV Types in Table 3 will create a new Type Extension 885 registry, with type extension 0, as illustrated in Table 4. 887 +-------+------+-----------+-----+----------------------------------+ 888 | Name | Type | Type | Bit | Description | 889 | | | Extension | | | 890 +-------+------+-----------+-----+----------------------------------+ 891 | FLAGS | 129 | 0 | 0 | NOTE: 0 is recommended for | 892 | | | | | smart-rreq flag. To be defined | 893 | | | | | in another document | 894 | FLAGS | 129 | 0 | 1 | RREQ.trigger flag (i.e. the RREQ | 895 | | | | | message is RREQ_TRIGGER when it | 896 | | | | | is set to 1) | 897 | FLAGS | 129 | 0 | 2 | RREQ.build flag (i.e. the RREQ | 898 | | | | | message is RREQ_BUILD when it is | 899 | | | | | set to 1) | 900 | FLAGS | 129 | 0 | 3 | RREQ.ct-rrep flag (i.e. the | 901 | | | | | receiving sensors are required | 902 | | | | | to send RREP when it is set to | 903 | | | | | 1) | 904 | FLAGS | 129 | 0 | 4-7 | reserved for future use | 905 | FLAGS | 129 | 1-255 | | Unassigned | 906 +-------+------+-----------+-----+----------------------------------+ 908 Table 4: Message TLV Type assignment: FLAGs 910 Appendix C. LOADng-CT Control Packet Illustrations 912 TODO 914 Authors' Addresses 916 Jiazi Yi 917 LIX, Ecole Polytechnique 919 Phone: +33 1 6933 4031 920 Email: jiazi@jiaziyi.com 921 URI: http://www.jiaziyi.com/ 923 Thomas Clausen 924 LIX, Ecole Polytechnique 925 91128 Palaiseau Cedex, 926 France 928 Phone: +33-6-6058-9349 929 Email: T.Clausen@computer.org 930 URI: http://www.thomasclausen.org