idnits 2.17.1 draft-vanderstok-roll-mcreq-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 339 has weird spacing: '... Imax k Par...' == Line 531 has weird spacing: '...end out the m...' -- The document date (July 11, 2012) is 4306 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-17) exists of draft-ietf-roll-p2p-rpl-13 == Outdated reference: A later version (-12) exists of draft-ietf-roll-trickle-mcast-00 == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-10 == Outdated reference: A later version (-25) exists of draft-ietf-core-groupcomm-02 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROLL P. van der Stok, Ed. 3 Internet-Draft vanderstok consultancy 4 Intended status: Informational E. Dijk 5 Expires: January 12, 2013 A. Lelkens 6 Philips Research 7 July 11, 2012 9 Multicast requirements for control over LLN 10 draft-vanderstok-roll-mcreq-02 12 Abstract 14 This is a working document intended to focus discussion on 15 requirements for multicast in Low-power and Lossy Networks in the 16 area of M2M communication for control applications. The Trickle 17 algorithm, which uses random re-broadcasting to assure that messages 18 arrive at all destinations, has been proposed in the Trickle 19 Multicast Forwarding ROLL WG draft as the basis for a multicast 20 routing protocol. In this draft additional requirements on multicast 21 routing are presented, such as timeliness, motivated by building 22 control. Random re-broadcasting and timeliness can be difficult to 23 reconcile. This draft presents some simulation results in typical 24 control settings which show that achieving latencies below 400 ms is 25 feasible with Trickle. Recommendations are proposed for the current 26 Trickle Multicast Forwarding draft to achieve optimal performance and 27 meet the stated requirements. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 12, 2013. 46 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Application characteristics . . . . . . . . . . . . . . . . . 4 67 3. Multicast requirements . . . . . . . . . . . . . . . . . . . . 6 68 4. Performance of Trickle-based multicast . . . . . . . . . . . . 7 69 4.1. Reasons for using Trickle . . . . . . . . . . . . . . . . 7 70 4.2. Simulation setup . . . . . . . . . . . . . . . . . . . . . 7 71 4.3. Simulation results . . . . . . . . . . . . . . . . . . . . 8 72 4.4. Simulation conclusions . . . . . . . . . . . . . . . . . . 9 73 5. Performance issues of Trickle Multicast Forwarding . . . . . . 9 74 5.1. Redundancy of Trickle ICMP message . . . . . . . . . . . . 10 75 5.2. Ability to configure forwarders as data sinks . . . . . . 11 76 5.3. Issues in the 'consistency' definition . . . . . . . . . . 11 77 5.4. Window handling without ICMP . . . . . . . . . . . . . . . 12 78 6. Summary of Recommendations for Trickle Multicast Forwarding . 12 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 81 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 84 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 87 1. Introduction 89 The ROLL working group is chartered to design and standardize a 90 routing protocol for resource constrained devices in Low-power and 91 Lossy Networks (LLN) [RFC6550]. The requirements for ROLL are 92 documented in [RFC5548] [RFC5673] [RFC5826] [RFC5867]. For building 93 control it is recognized that most communication is local to the 94 wireless mesh network, and does not necessarily pass through the edge 95 router. The point-to-point RPL routing algorithm is developed to 96 efficiently support unicast routing in such applications 97 [I-D.ietf-roll-p2p-rpl]. The Trickle algorithm was initially 98 developed to support the RPL routing algorithm [RFC6206], and later 99 proposed to support general multicast delivery in LLNs in Trickle 100 Multicast Forwarding (TMF) [I-D.ietf-roll-trickle-mcast]. 102 This draft discusses the multicast requirements for constrained 103 devices participating in M2M building control networks. An important 104 requirement is the delivery of control commands to a subset (group) 105 of neighbouring devices in the LLN within some latency bound. Also, 106 analyses are provided of how well Trickle algorithm and TMF can meet 107 these requirements and suggestions for improvement are made. 109 1.1. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC 2119 [RFC2119]. 114 Addtional privileged words are described below. 116 "TMF" is used as an abbreviation for Trickle Multicast Forwarding as 117 described in [I-D.ietf-roll-trickle-mcast]. 119 A "device" is a physical processor connected to at least one link 120 through a network interface. Each interface has at least one IP 121 unicast address. The IP address is optionally bound to a host name, 122 which may be a Fully Qualified Domain Name (FQDN). 124 One device communicates directly with another device by wirelessly 125 transmitting packets to it over a link. The link quality is divided 126 in three regions [Zhao]: 128 1. good: where a transmitted packet will be correctly received by a 129 destination with a probability of say 95% or more. 130 2. transitional: where the probability of correct reception 131 fluctuates. 132 3. bad: where almost no transmission is successfully received. 134 It is empirically known that good links can become bad occasionally 135 (e.g. once a week for a few minutes)due to dynamic effects such as 136 multipath interference. 138 A distinction is made between reception and delivery of a message. A 139 message is received when it is stored in the reception buffer of the 140 receiver after transmission and all error checks have been 141 succesfully passed. The message is delivered when the message is 142 passed from the reception buffer to the destination application. We 143 also say the application accepts the message. 145 Broadcasting is used for the link-local sending of one packet to all 146 reachable 1-hop neigbours. This is equivalent to the term link-local 147 multicast. 149 1.2. Motivation 151 In this draft, we focus and develop discussions on requirements 152 pertaining to IP multicasting requirements and IP multicast routing, 153 in the context of building control applications on LLNs. This draft 154 aims to show potential (latency) improvements for current proposed 155 multicast routing approaches, that can be easily attained. 157 2. Application characteristics 159 Multicast is important for building control applications. Two types 160 of applications are considered: 162 1. Discovery messages to (a subset of) the members of the mesh 163 (multicast GET) 164 2. Control messages to a subset of the mesh (multicast PUT) 166 The first type requires the message to be sent to a (sub)set which 167 may be randomly distributed over the building area. Some of the 168 destinations return unicast response messages to the source. 170 The second type requires a Non-Confirmable message mostly to be sent 171 to a closely spaced subset. No return messages are generated. This 172 second type is the subject of this draft, although most of the 173 requirements equally apply to case 1. 175 GET and PUT and Confirmable/Non-Confirmable are message types defined 176 for CoAP [I-D.ietf-core-coap]. They are thought representative for 177 the two applications types, as the multicast GET SHOULD return a 178 unicast response and the multicast PUT typically does not return a 179 response in control applications. 181 An office building typically consist of multiple floors, divided in 182 working areas. The working areas can be open or enclosed by walls. 183 Within a working area sensors measure temperature, presence, humidity 184 and other parameters. On the basis of these measurements, equipment 185 within the working area can receive commands to change settings. A 186 well-known example is presence detection to switch on or dim lights. 187 The equipment configuration is quite stable, because devices are 188 installed in the ceiling, and modifying (or servicing) the 189 installation can be costly. 191 The equipment is interconnected in a wireless network. The RF 192 transmissions pass through the walls and generate interference to the 193 wireless equipment in other working areas. 195 The lay-out of a network may be different from installation to 196 installation. However, it is expected that many wireless networks 197 extend over one floor and include several working areas. Another 198 working hypothesis is that most of the time sensors will multicast 199 their values to a group of devices within the working area. 200 Consequently, multicast messages are often meant for a subset of 201 neigbouring (not necessarily 1-hop) devices. 203 A LoWPAN is a mesh of wireless devices that share the same IPv6 204 address prefix. A typical LowPAN in a building may cover the area of 205 an entire floor. A commercial installation may cover 1000 m2 per 206 floor. A length of 50 m can easily mean a hop count >5 for a message 207 to pass from end to end. For example, devices may be installed in 208 the ceiling in a grid with a grid pattern distance of 2 m between 209 devices. 211 Messages may consist of sensor measurements performed or commands 212 issued in a given working area, which then must be acted upon by 213 neigbouring devices in the same working area. Under this control 214 pattern, source and sink are located in one working area, and 215 accordingly sink and source of a multicast message are often between 216 3 - 6 m from each other. Consequently, it is required to send a 217 multicast to a subset of the devices in the LoWPAN. 219 In case of commands to luminaries, a command message must be 220 delivered to all LoWPAN-local multicast group members within a clear 221 deadline of about 200ms. In [RFC5867] a deadline of 120 ms is 222 suggested for other building applications. 224 Although control messages are frequently exchanged between closely 225 spaced (less than 6 m) devices, it is sometimes necessary to send a 226 message to a subset of devices covering the whole building. In that 227 case the multicast message will need to pass the edge router of the 228 LoWPAN and to propagate to other subnets. This case is discussed in 229 more detail in [I-D.ietf-core-groupcomm]. 231 3. Multicast requirements 233 The multicast requirements are derived from the characteristics of 234 the aforementioned applications. A device is said to be correct it 235 it follows the selected multicast routing algorithm. The application 236 characteristics and the network installation make it possible to add 237 an additional set of network properties to make the multicast 238 algorithm more efficient. 240 The basic traditional multicast requirements (applicable to both PUT 241 and GET) are [Mullender]: 243 o Validity: If sender S sends message, m, to a group, g, of 244 destinations, a path exists between S and any destination D, and 245 if S and D are correct, D eventually accepts m. 246 o Integrity: A destination D accepts m at most once from sender S 247 and only if S sent m to a group including D. 248 o Agreement: If a correct destination of g accepts m, then all 249 correct destinations of g accept m. 251 The set of intended destination devices is identified by the 252 multicast (group) IP address. Every device in the associated 253 multicast group is a destination of the multicast. Each destination 254 accepts messages with as destination the specified IP multicast 255 address. Additional multicast requirements are: 257 o Timeliness: There is a known constant C such that if m is sent at 258 time t, no correct destination accepts m after t+C. 260 For lighting control applications the value of C is taken as 200 ms. 261 This requirement only holds for the PUT case without response from a 262 destination, but not for the GET case where a response is returned. 264 o Ordering: When m1 and m2 sent to the same group g, and a receiver 265 in g accepts message m1 before m2, every receiver in g accepts m1 266 before accepting m2 268 Ordering applies to both the PUT and GET cases. Ordering can be 269 partial or total. Partial ordering means that for specified message 270 pairs, one message of the pair precedes the other. In case of total 271 ordering, every message pair is ordered. Partial ordering is 272 obtained by adding message counters in the message such that 273 destinations can order the messages of a given sender. Messages from 274 different sources are not ordered. Total ordering can be obtained 275 with vector clocks or using synchronized clocks. Vector clocks 276 require a large overhead that increases linearly with the number of 277 devices in the network. As long as no synchronized clocks are 278 available, partial ordering seems the most realistic. Total Ordering 279 is interesting for the discovery application. When two devices 280 announce themselves simultaneously with conflicting properties, all 281 participants can come to the same decision by favoring the first 282 arrival. Partial ordering is necessary when a multicast message 283 needs multiple packets (for example discovery messages) or when 284 multicast messages are sent with intervals shorter than the maximum 285 throughput delay. 287 4. Performance of Trickle-based multicast 289 In this section we investigate the behavior of the Trickle algorithm 290 [RFC6206] when used for multicast routing. Rebroadcasting as defined 291 in Trickle makes meeting tight deadlines a challenge. Simulation 292 results in this section show for particlar configurations and 293 parameter settings which end-to-end communication delays can be 294 expected. 296 4.1. Reasons for using Trickle 298 The simplest approach to IP multicast is to broadcast from a source 299 to a set of devices reachable over good links in one hop. This is 300 not sufficient however, because the set of reachable devices is often 301 a subset of the set of destination devices. Consequently, additional 302 measures are needed to make sure that the Agreement requirement is 303 met. A standard technique, to reach all devices instead of a subset, 304 stipulates that every receiver of a broadcast message rebroadcasts 305 this message (flooding). When the multicast destination address of 306 the message corresponds with a specified multicast address in the 307 receiver device, the message is delivered. Thanks to this technique 308 it is assured that when a path exists between the source and the 309 destination device, the destination device will eventually receive 310 the message from the sender. 312 Given the network density described in section 2, the multicast can 313 generate a broadcast storm with lots of interfering senders. The 314 technique to prevent the storm, also used in Trickle, is to randomly 315 delay a message rebroadcast. However, long delays can seriously 316 jeopardize the Timeliness requirement. The following sections give 317 insight under which conditions the Timeliness requirement can be met. 319 4.2. Simulation setup 321 The simulations were done on a general rectangular network topology 322 and on an approximation of known building installations. The IEEE 323 802.15.4 protocol is simulated with CSMA and the standard back-off 324 intervals specified by IEEE 802.15.4. Packets between A and B arrive 325 with a probability dependent on the distance but independent of the 326 direction. A distance of 70m is at the limit of the transmission 327 range. Two rectangular meshes were tried: (1) 5 x 5 nodes and (2) 10 328 x 10 nodes. The distance between two adjoining neigbors was varied 329 between 5 and 70 m. The total surface for the 10 x 10 mesh varied 330 accordingly between 45 x 45 m^2 and 630 x 630 m^2. The building 331 installation approximation consist of a rectangular grid of 14 x 7 332 nodes over a surface of 35 x 15 m^2. Parameters Imin, Imax and k and 333 variables I, t and c are defined as in [RFC6206]. 335 4.3. Simulation results 337 The table below presents some of the results on the 5 x 5 mesh. 339 Imax k Parameter Distance 340 10m 40m 70m 341 250ms 1 hopcount 1 2-4 5-9 342 250ms 1 avg delay 5 ms 40 ms 110 ms 343 250ms 1 max delay 18 ms 90 ms 1050 ms 344 250ms 1 msgs sent 0-5 0-11 1-12 345 250ms 1 msgs received 18-36 3-20 0-20 346 250ms 3 hopcount 1 2-4 5-9 347 250ms 3 avg delay 5 ms 40 ms 130 ms 348 250ms 3 max delay 25 90 ms 260 ms 349 250ms 3 msgs sent 1-7 3-12 7-13 350 250ms 3 msgs received 40-60 14-32 9-23 351 500ms 1 hopcount 1 3-5 5-10 352 500ms 1 avg delay 5 ms 40 ms 110 ms 353 500ms 1 max delay 19 ms 100 ms 1500 ms 354 500ms 1 msgs sent 0-4 0-8 0-10 355 500ms 1 msgs received 12-26 0-16 0-16 356 500ms 3 hopcount 1 3-5 5-10 357 500ms 3 avg delay 5 ms 40 ms 120 ms 358 500ms 3 max delay 22 80 ms 240 ms 359 500ms 3 msgs sent 1-8 2-9 5-10 360 500ms 3 msgs received 28-44 8-27 5-18 362 The observed behavior is close to what is observed on the 10 x 10 363 mesh and on the installation configuration. Behavior on, for 364 example, a single row of nodes tends to be quite different and 365 requires quite different parameter settings. The results in the 366 table concern node (4,4) which had the longest end-to-end delays of 367 all nodes. Node (0,0) sent a message every 2 seconds. Individual 368 packets were lost but all messages arrived at all nodes eventually. 369 The Imin was taken to 10 ms and Imax was taken to 250 ms and 500 ms 370 with quite similar results. Changing the Imax has measurable 371 influence on the maximum end-to-end delay. The table shows how many 372 copies of a given message were received by node (4,4) and how many 373 times a given message was rebroadcast. For k=3 more messages were 374 received and sent. Receiving more messages leads to lower maximum 375 delays because the probability of receiving the message early 376 increases with increasing rebroadcast frequency. 378 The causes for the large maximum delays (>400ms), occurring at d=70m, 379 have been investigated in more detail. It is shown that a new packet 380 does not always arrive after the first transmission. This is 381 probably due to the synchronization of nodes when a new message 382 arrives, resulting in hidden terminal effects at the destination node 383 by overlapping sending intervals of its neighbors. For d=70 m, 384 packets are only received by the direct neighbor along the x-axis or 385 the y-axis. Consequently, when node (x, y) receives a new message, 386 it originates probably from (x-1, y) or (x, y-1). When node (x, y) 387 sends, packets are received in nodes (x+1, y) and (x,y+1). Given a 388 Imin value of 10ms there is a large probability that the sending by 389 nodes (x+1, y) and (x, y+1) overlap, leading to collision of the 390 messages at node (x+1, y+1). In the following intervals, nodes (x+1, 391 y) and nodes (x, y+1) receive the last message from their neighbors 392 and do not repeat the message because c is larger than k, thus 393 leading to long delays. The receiving node (x+1, y+1) sends at 394 regular intervals, determined by the Imax value, its last received 395 'old' message. Often the reception of the old message by a neighbor 396 leads to resending the new message. For that reason the maximum 397 delay is linked to the maximum interval Imax. Increasing the value 398 of k increases the probability of reciveing rebroadcast messages. 400 4.4. Simulation conclusions 402 The results indicate that for the network configurations we foresee, 403 with Trickle it is quite possible to reach average message delivery 404 latency within the 200 ms range, meeting the Timeliness requirement 405 for most nodes, and to limit the maximum latency by tuning parameter 406 k. 408 5. Performance issues of Trickle Multicast Forwarding 410 The Trickle Multicast Forwarding (TMF) draft 411 [I-D.ietf-roll-trickle-mcast] differs from direct application of 412 [RFC6206] in the introduction of multi-source, sliding windows, and 413 use of ICMP messages. For Trickle parameter k finite, a transmission 414 event consists of sending a Trickle ICMP advertizement (that 415 summarizes a forwarder's state i.e. buffered IP multicast packets) 416 and in addition any multicast messages that need rebroadcasting. 417 This section analyzes some issues of TMF, in particular its ability 418 to meet the Timeliness requirement for building control scenarios, 419 and proposes improvements to address the issues. 421 5.1. Redundancy of Trickle ICMP message 423 Summarizing state in an ICMP message is clearly useful to reduce 424 network traffic, if many IP multicast packets are being buffered in 425 Trickle multicast forwarders. However, if only one or a few 426 multicast packets are active in the network at a time, a forwarder 427 sending ICMP messages generates unnecessary overhead. As an example, 428 consider a forwarder that stores and needs to rebroadcast a single 429 multicast message m1. According to TMF, it would need to send an 430 ICMP message containing information about m1 (SeedID, sequence 431 number, M bit) and additionally send a Trickle Multicast message with 432 a Trickle Multicast header option which contains exactly the same 433 information (SeedID, sequence number, M bit) plus the useful 434 application data. 436 In such cases were low latency is required, the extra overhead of 437 sending the ICMP message leads to additional delays, for example in 438 dense network topologies due to increased congestion. In a 439 simulation of a building control installation the operation with and 440 without extra ICMP message was compared for the case that a single 441 multicast message was active. Without ICMP messages an average 442 latency of message delivery to the entire group of 131 ms was 443 observed. The extra overhead generated by ICMP messages led to an 444 average delay of 197 ms, quite close to the Timeliness bound of 200 445 ms. 447 The simulation modeled a single IP multicast message active in a 448 6LoWPAN network, delivery targeted to a group which is a subset of 13 449 nodes out of 95 nodes total, with a 40-byte data payload, each node 450 acting as a forwarder, with Trickle parameters k=1, Imin=32 ms, 451 Imax=128 ms. 453 To addresss the latency issue without increasing k (which would lead 454 to increased traffic), we propose that: 455 o sending the Trickle ICMP message is made OPTIONAL as part of a 456 transmission event, if a Trickle forwarder has any Trickle 457 Multicast Messages to send in that transmission event. A Trickle 458 Multicast forwarder may decide per transmission event (depending 459 on internal state e.g. number of buffered messages) whether the 460 ICMP message is sent or not. 461 o as part of a transmission event, sending the Trickle ICMP message 462 MAY be done after retransmitting Trickle Multicast Messages. Note 463 that the TMF draft does not clearly express a preferred order for 464 Trickle ICMP messages. 465 These proposed changes are still fully compatible with existing 466 implementations of TMF. 468 5.2. Ability to configure forwarders as data sinks 470 The current TMF makes a separation between (IP) hosts and Trickle 471 Multicast forwarders. Nodes that only need to receive IP multicast 472 packets (not wanting to participate in rebroadcasting) therefore can 473 be configured as hosts unaware of the multicast routing protocol. 474 However, this bears the risk that such hosts receive a specific 475 multicast packet very late or never, because they don't have a way to 476 signal missing packets to Trickle forwarders. Implementing a node as 477 a host has the clear advantages that the node does not need to buffer 478 any Trickle Multicast Messages which can considerably reduce memory 479 usage. 481 A solution that enables the best of both worlds is to allow Trickle 482 Multicast forwarders to act as 'data sinks' only i.e. not acting as a 483 repeater. We propose that: 484 o a Trickle Multicast forwarder MAY act as a data sink, which means 485 that it does keep sliding window state for messages it accepts, 486 and sends Trickle ICMP messages, but does not buffer any Trickle 487 Multicast Messages for retransmission. 489 5.3. Issues in the 'consistency' definition 491 In the TMF draft the notion of 'consistency' (as we read it) is based 492 on information received in Trickle ICMP messages only, not on 493 information received from incoming Trickle Multicast Messages. This 494 operation can lead to unnecessary delays in certain use cases. 495 Consider the following scenario: 497 o Nodes A, B, C are Trickle Multicast forwarders; where A cannot 498 hear C and C cannot hear A 499 o A stores messages m1,m2,m3, B stores m1,m2,m3, C stores m2,m3 500 o C sends ICMP(m2,m3) 501 o B sees an inconsistency based on this and schedules the missing m1 502 for transmission 503 o A sends ICMP (m1,m2,m3) but not any multicast message m_i 504 o B sees a consistency and increments c 505 o When the Trickle timer at B expires assuming k=1, the scheduled 506 transmission of m1 is cancelled 507 o C does not get m1 from B, at least not during this round. 509 Eventually C will get m2, after more rounds (when B transmits before 510 A does), but later than necessary. 512 A first approach to improve latency in this scenario is to apply the 513 suppression only to ICMP messages, not to scheduled multicast 514 messages (such as m1 by B in the example above). A refinement of 515 this approach is to maintain a counter c for each SeedID/ 516 Sequence-number combination, in addition to a global Trickle counter 517 c. Then, retransmission of Trickle Multicast Messages is only 518 suppressed for those messages that have been received at least k 519 times. ICMP suppression is still based on the global Trickle counter 520 c as in the current TMF draft. 522 5.4. Window handling without ICMP 524 A forwarder that does not support sending ICMP advertizements could 525 advertize its state by retransmitting the multicasat message with the 526 largest number in its window that has no missing messages relative to 527 the lower bound of the window. So if a forwarder has a window 528 containing m1,m2,m4,m5 it retransmits m2, triggering others to send 529 m3 (and maybe higher numbers). If it encounters an inconsistency, 530 i.e. seeing a multicast with a number lower than its own upperbound, 531 it itself would send out the messages that have a higher number than 532 the received multicast message (excluding the ones that it has 533 received at least k tines during the current Trickle interval). 535 6. Summary of Recommendations for Trickle Multicast Forwarding 537 From the analyses above emerge a number of recommendations that aim 538 to reduce transmission latency of multicast messages and to reduce 539 the probability of missing a multicast message. In summary, the 540 following adaptations to TMF [I-D.ietf-roll-trickle-mcast] are 541 proposed which can be applied independently of each other: 542 1. Efficient retransmission: sending the Trickle ICMP message is 543 made OPTIONAL as part of a transmission event if a Trickle 544 forwarder already has any Trickle Multicast Messages to send. 545 2. Allow data sinks: a Trickle Multicast forwarder MAY refrain from 546 buffering any Trickle Multicast Messages for retransmission. 547 3. Consistency improvement: When a transmission is suppressed, a 548 forwarder MAY only suppress ICMP but not suppress transmission of 549 a multicast message that was scheduled due to a detected 550 inconsistency. This approach could be refined by keeping in 551 addition to a global Trickle consistency counter c, separate 552 counters c per SeedID/sequence-number combination suppressing 553 only messages seen at least k times. 554 4. Window handling without ICMP: forwarders without ICMP sending 555 capability can ask for retransmissions by rebroadcasting 556 multicast messages 558 7. IANA Considerations 560 This document makes no request of IANA. 562 Note to RFC Editor: this section may be removed on publication as an 563 RFC. 565 8. Security Considerations 567 TBD 569 9. Acknowledgments 571 This I-D has benefited from conversations with and comments from 572 Anders Brandt, Kerry Lynn, Zach Shelby, Emmanuel Frimout, Michael 573 Verschoor, Jamie Mc Cormack, Dee Denteneer, Jerald Martocci, Matthieu 574 Vial, and Nicolas Riou. 576 10. References 578 10.1. Normative References 580 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 581 Requirement Levels", BCP 14, RFC 2119, March 1997. 583 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 584 "Routing Requirements for Urban Low-Power and Lossy 585 Networks", RFC 5548, May 2009. 587 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 588 "Industrial Routing Requirements in Low-Power and Lossy 589 Networks", RFC 5673, October 2009. 591 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 592 Routing Requirements in Low-Power and Lossy Networks", 593 RFC 5826, April 2010. 595 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 596 "Building Automation Routing Requirements in Low-Power and 597 Lossy Networks", RFC 5867, June 2010. 599 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 600 "The Trickle Algorithm", RFC 6206, March 2011. 602 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 603 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 604 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 605 Lossy Networks", RFC 6550, March 2012. 607 10.2. Informative References 609 [I-D.ietf-roll-p2p-rpl] 610 Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J. 611 Martocci, "Reactive Discovery of Point-to-Point Routes in 612 Low Power and Lossy Networks", draft-ietf-roll-p2p-rpl-13 613 (work in progress), June 2012. 615 [I-D.ietf-roll-trickle-mcast] 616 Hui, J. and R. Kelsey, "Multicast Forwarding Using 617 Trickle", draft-ietf-roll-trickle-mcast-00 (work in 618 progress), April 2011. 620 [I-D.ietf-core-coap] 621 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 622 "Constrained Application Protocol (CoAP)", 623 draft-ietf-core-coap-10 (work in progress), June 2012. 625 [I-D.ietf-core-groupcomm] 626 Rahman, A. and E. Dijk, "Group Communication for CoAP", 627 draft-ietf-core-groupcomm-02 (work in progress), 628 July 2012. 630 [Zhao] Zhao, J. and R. Govindan, "Understanding Packet Delivery 631 Performance in Dense Wireless Sensor Networks", senSys , 632 2003. 634 [Mullender] 635 Mullender, S., "Distributed Systems, Second Edition", 636 Section 5 , Addison-Wesley Publishing Company, Inc. , 637 ISBN 0-201-62427-3, 1995. 639 Authors' Addresses 641 Peter van der Stok (editor) 642 vanderstok consultancy 643 Kamperfoelie 8 644 Helmond, 5708 DM 645 The Netherlands 647 Email: consultancy@vanderstok.org 648 Esko Dijk 649 Philips Research 650 High Tech Campus 34-1 651 Eindhoven, 5656 AA 652 The Netherlands 654 Email: esko.dijk@philips.com 656 Armand Lelkens 657 Philips Research 658 High Tech Campus 34-1 659 Eindhoven, 5656 AA 660 The Netherlands 662 Email: armand.lelkens@philips.com