Subject: [core] #355: Clarify assumptions on reliable/unreliable multicast

From: "core issue tracker" <[email-masked]>
Date: Wed, 13 Nov 2013 08:05:13 -0000

#355: Clarify assumptions on reliable/unreliable multicast

 Based on IETF88 discussion, we propose to add some text to describe that
 we assume an unreliable IP multicast mechanism. Also mention that ROLL MPL
 (Trickle) is a way to achieve higher reliability without requiring new
 mechanisms on the CoAP level.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-core-
  [email-masked]  |  [email-masked]
     Type:  editorial    |     Status:  new
 Priority:  minor        |  Milestone:
Component:  groupcomm    |    Version:
 Severity:  -            |   Keywords:
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/355>
core <http://tools.ietf.org/core/>

---

From: "weigengyu" <[email-masked]>
Date: Thu, 14 Nov 2013 12:46:30 +0800

Hi, all,

I would like to remind all that there is no words "reliability" mentioned in
" Multicast Protocol for Low power and Lossy Networks (MPL) 
draft-ietf-roll-trickle-mcast-05. "

While in another draft,  Applicability Statement: The use of the RPL 
protocol set in Home Automation and Building Control
draft-ietf-roll-applicability-home-building-01, give some descriptions as 
following:
{/begin
2.2. Traffic Characteristics
    For reliability purposes, it is therefore essential that alternative 
n-hop communication routes exist for quick error recovery.
2.2.7. RPL applicability per communication paradigm
    N-cast over the wireless network will be done using multicast with MPL 
[I-D.ietf-roll-trickle-mcast]. Configuration constraints that
are necessary to meet reliability and timeliness with MPL are discussed in 
Section 4.1.7.
3. Using RPL to meet Functional Requirements
    When reliability is required, multiple independent paths are used with 
RPL-P2P. For 1-hop destinations this means that one 1-hop
communication and a second 2-hop communication take place via a neigboring 
node. The same reliability can be achieved by using MPL
where the seed is a repeater and a second repeater is 1 hop removed from the 
seed and the destination node.
4. RPL Profile
    RPL-P2P MUST be used in home and building networks. Non-storing mode 
allows for constrained memory in repeaters when source routing is used.
4.1.7. Multicast
    Commercial light deployments may have a need for multicast. Several 
mechanisms exist for achieving such functionality;
[I-D.ietf-roll-trickle-mcast] is RECOMMENDED for home and building 
deployments.
    Guaranteeing timeliness is intimately related to the density of the MPL 
routers. ......
    There are no rules about selecting repeaters for MPL. In buildings with 
central managment tools, the repeaters can be selected, but in
the home is not possible to automatically configure the repeater topology at 
this moment.
/end}
NOTE: no reliability mentioned in 4.1.7.

At least until now, " ROLL MPL (Trickle) " of " Multicast Protocol for Low 
power and Lossy Networks (MPL) draft-ietf-roll-trickle-mcast-05. "
does not guarante reliability.

Regards,

Gengyu

Network Technology Center
School of Computer
Beijing University of Posts & Telecommunications

-----原始邮件----- 
From: core issue tracker
Sent: Wednesday, November 13, 2013 4:05 PM
To: [email-masked] ; [email-masked]
Cc: [email-masked]
Subject: [core] #355: Clarify assumptions on reliable/unreliable multicast

_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

---

From: "Dijk, Esko" <[email-masked]>
Date: Thu, 14 Nov 2013 07:44:17 +0000

Hi Gengyu,

indeed the guaranteed-reliability aspect is not considered in MPL nor RPL. However MPL has the inherent property of multiple (possibly many, depending on parameter settings) transmission 'retries' at each hop (i.e. MPL Forwarder). Also the flooding nature of MPL means that many/all routing paths through a network are simultaneously attempted to reach a destination or group of destinations. Also this approach is highly robust against changes in network topology and network density. So MPL (provided parameters are set to enable this) does provide the highest level of reliability one can get without going to the guaranteed-reliable multicast techniques that Carsten already listed in an earlier email on the reliability topic.

If the MPL spec and applicability statement fail to mention this aspect, it's a good reason perhaps to say this in core-groupcomm.

Esko

-----Original Message-----
From: weigengyu [mailto:[email-masked]]
Sent: Thursday, November 14, 2013 05:47
To: [email-masked]; [email-masked]; Dijk, Esko
Cc: [email-masked]
Subject: Re: [core] #355: Clarify assumptions on reliable/unreliable multicast

Hi, all,

I would like to remind all that there is no words "reliability" mentioned in " Multicast Protocol for Low power and Lossy Networks (MPL) draft-ietf-roll-trickle-mcast-05. "

While in another draft,  Applicability Statement: The use of the RPL protocol set in Home Automation and Building Control draft-ietf-roll-applicability-home-building-01, give some descriptions as
following:
{/begin
2.2. Traffic Characteristics
    For reliability purposes, it is therefore essential that alternative n-hop communication routes exist for quick error recovery.
2.2.7. RPL applicability per communication paradigm
    N-cast over the wireless network will be done using multicast with MPL [I-D.ietf-roll-trickle-mcast]. Configuration constraints that are necessary to meet reliability and timeliness with MPL are discussed in Section 4.1.7.
3. Using RPL to meet Functional Requirements
    When reliability is required, multiple independent paths are used with RPL-P2P. For 1-hop destinations this means that one 1-hop communication and a second 2-hop communication take place via a neigboring node. The same reliability can be achieved by using MPL where the seed is a repeater and a second repeater is 1 hop removed from the seed and the destination node.
4. RPL Profile
    RPL-P2P MUST be used in home and building networks. Non-storing mode allows for constrained memory in repeaters when source routing is used.
4.1.7. Multicast
    Commercial light deployments may have a need for multicast. Several mechanisms exist for achieving such functionality; [I-D.ietf-roll-trickle-mcast] is RECOMMENDED for home and building deployments.
    Guaranteeing timeliness is intimately related to the density of the MPL routers. ......
    There are no rules about selecting repeaters for MPL. In buildings with central managment tools, the repeaters can be selected, but in the home is not possible to automatically configure the repeater topology at this moment.
/end}
NOTE: no reliability mentioned in 4.1.7.

At least until now, " ROLL MPL (Trickle) " of " Multicast Protocol for Low power and Lossy Networks (MPL) draft-ietf-roll-trickle-mcast-05. "
does not guarante reliability.

Regards,

Gengyu

-----原始邮件-----
From: core issue tracker
Sent: Wednesday, November 13, 2013 4:05 PM
To: [email-masked] ; [email-masked]
Cc: [email-masked]
Subject: [core] #355: Clarify assumptions on reliable/unreliable multicast

Based on IETF88 discussion, we propose to add some text to describe that we assume an unreliable IP multicast mechanism. Also mention that ROLL MPL
(Trickle) is a way to achieve higher reliability without requiring new mechanisms on the CoAP level.

--
-------------------------+----------------------------------------------
-------------------------+---
Reporter:               |      Owner:  draft-ietf-core-
  [email-masked]  |  [email-masked]
     Type:  editorial    |     Status:  new
Priority:  minor        |  Milestone:
Component:  groupcomm    |    Version:
Severity:  -            |   Keywords:
-------------------------+----------------------------------------------
-------------------------+---

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: "core issue tracker" <[email-masked]>
Date: Thu, 28 Nov 2013 11:00:32 -0000

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => fixed

Comment:

 Text added in [1560]

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-core-
  [email-masked]  |  [email-masked]
     Type:  editorial    |      Status:  closed
 Priority:  minor        |   Milestone:
Component:  groupcomm    |     Version:
 Severity:  -            |  Resolution:  fixed
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/355#comment:1>
core <http://tools.ietf.org/core/>