1. Peter van der Stok August 3,2012 ROLL working group 1 draft-vanderstok-roll-mcreq-02 Multicast Requirements for LLN in Buildings

2. August 3,2012, IETF, RoLL 2 Multicast in Building Control Multicast purposes : 1.Sending messages with bounded delay to set of (nearby) receivers No response required (this presentation) 2.Service discovery (mDNS) for stand-alone network Response required

3. August 3,2012, IETF, RoLL 3 2 1 ER 1 2 2 2 3 3 3 4 4 4 2 1 1 2 2 2 3 3 3 4 4 4 2 1 1 1 1 2 2 2 3 3 3 4 4 4 2 2 2 2 2 2 2 2 3 3 3 4 4 4 2 2 2 2 2 2 2 2 3 3 3 4 4 4 2 2 2 2 2 2 2 3 3 3 3 4 4 4 2 2 2 2 2 2 2 3 3 3 3 4 4 4 Typical network configuration x Node; X indicates the number of hops a node is away from the ER (i.e. the rank of the node in the ER-rooted DAG)

4. August 3,2012, IETF, RoLL 4 Operational characteristics Central requirements: Agreement Timeliness (200 ms); occasionally a message takes 1-2 seconds Variable network density: node every 30 - 100 cm In general multicast ranges over one office (6*6 m) or one floor

5. August 3,2012, IETF, RoLL 5 Simulation configuration 10x10 mesh IEEE 802.15.4 (0,0) (9,9) Sender (0,0) sends message every 2 seconds Observe e2e delay at (9,9)

6. August 3,2012, IETF, RoLL 6 K=1K=5 sec 50-100 neighbors2-4 neighbors 50-100 neighbors Inter-node distance 10ms < I min < 30ms 100ms < I max < 500ms E2E Delay as function of distance max avg min

7. August 3,2012, IETF, RoLL 7 Suggestions to trickle multicast forwarding draft Window per sender necessary solution. Sending ICMP messages reduces overhead with multiple sources BUT, relation between forwarding and ICMP message not clear With one sender, ICMP message creates unnecessary overhead Suggestion: ICMP optional per node Consider receivers which do not forward but send their status Suggestion: Forwarding optional Reduce delay of missing messages Suggestion: c-counter per message and source