Subject: [6lo] FW: dinner consensus on trickle-mcast and multicast-scoopes

From: Samita Chakrabarti <[email-masked]>
Date: Sun, 10 Nov 2013 23:43:39 +0000

Fyi...

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: Friday, November 08, 2013 12:45 PM
To: [email-masked]; [email-masked]
Subject: dinner consensus on trickle-mcast and multicast-scoopes

(I didn't have time to write a shorter note) (Resending because I got the 6man list address wrong. Wish there was an alias)

glossary for 6man readers:
      RPL = ROLL RFC6550 mesh-over routing protocol.
      MPL = ROLL draft-ietf-trickle-mcast multicast distribution
            protocol.

This email is a bit long, but represents what I believe was the consensus that was arrived at by a number of ROLL WG ID authors, some Zigbee IP experts, and Ralph.  This consensus was arrived at slowly over Tuesday night and Wednesday, and was brought to you by the letters B and I.  

I will start with the executive summary:

1) there are some minor tweaks necessary to trickle-mcast to make
   it consistent with multicast-scopes, and to indicate that 
   encapsulation in scopes 4 and 5 are appropriate for some use cases

2) that the text in multicast-scopes that speaks of "administratively
   defined" is confusing to many, and a suggestion on different text
   will be posted in a reply to this email.

=== background and discussion

Trickle-mcast must use/define scope 3 in order to get traffic to flow
across the entire RPL LLN (mesh-over).   The current multicast-scopes
document makes scope 3 span all the interfaces of the nodes of a single instance of a technology.  The intention was that IP-over-FOO documents would explain how this is defined, with the understanding that for
802.15.4 it would span all interfaces which are in a single PAN-ID.

RPL, however, can and does run over many different link types, and there are existing deployed systems that have mixes of 802.15.4/802.15.4G/802.11*/802.3(wired), in some cases, with the
technologies even alternating on a hop by hop basis.   Both Zigbee IP,
metering and home systems need to span multiple technologies for multicast, and Zigbee IP SEP 2 specifies using multicast to do service discovering using mDNS.  

Many want to automatically configure a multicast scope to cover all of the interfaces which are part of an RPL DODAG and/or that an address in
the same (multi-link subnet) prefix.   There was many months of
confusing discussion about having this be the definition of scope 3, but the alternate view was that MPL was not tied to RPL, and that neither the DODAG nor the prefix were inherent physical properties of the network in the way that a set of cables and a switch or a radio with a specific PANID.

The origin of the second mis-understanding was that the text in multicast-scopes (and rfc 4291) says:

         Admin-Local scope is the smallest scope that must be
         administratively configured, i.e., not automatically derived

The understanding of "administratively configured" for many people implies truck rolls, or ssh logins or router CLI commands.  It was only when this assumption was clearly articulated that the origin of the conflict became clear to all parties.

The new understanding is that "administratively configured" is not limited to the things that a human did it, but rather includes any processes or operations that a human (including an IETF document) might
cause.   The intent of multicast-scopes is not to limit ways that 
scopes 4+ can be determined, but to clarify that scopes <=3 are *not* intended to be defined by a physical (or physical-like) topologies.

To put it another way, a human, looking at some non-virtualized equipement likely can determine the extent of scope 1,2,3 even if there is no power connected.

The conclusion was that the group reached was that scope 3 can be defined on a per-technology basis, and in wireless links such as
the 802.15.4 PANID.   Where exactly to define this is still an open
question, but we did conclude that the place is *not* in trickle-mcast.
We are undecided if we need another worlds-shortest-RFC on 805.15.4 (effectively a 6lowpan/6lo/6man document) vs in multicast-scopes, but another RFC is preferred by most. (Perhaps; all) 

In another place, to be determined, possibly in applicability statements, or possibly in an application specific document (e.g. something like "mdns-over-lln"), a process by which a scope 4 multicast boundary could be defined to be something like the set of all interfaces which are in at least one DODAG.

It should fall to homenet to define scope 5 for use in the home to cover the set of interfaces which are in the inside of the homenet.  This should be easy for homenet to articulate discover of the homenet
boundary is already a work item.    The LLN border router would be
speaking homenet routing protocol on the interface that connects it to the homenet, and would include the LLN scope 4 zone as part of the scope
5 homenet.

This implies that LLNs will be using scope 5 to do mDNS resolution, and that this packet will be carried through the LLNs various links
encapsulated into a scope 3 packet.   While it is likely that dnssd will
not solve the multi-subnet problem using straight multicast, but rather using a proxy mechanism, use of scope 5 is agnostic to exactly how this would be done.
A mote that wishes to resolve only within the LLN may use scope 3 or 4, while one that wants to possibly find things in any place of the home will use scope 5.  

--
Michael Richardson
-on the road-