Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local

[Ralph Droms <[e-mail]>]

On Oct 15, 2013, at 9:08 AM 10/15/13, Michael Richardson <[e-mail]> wrote:

> 
> Ralph Droms (rdroms) <[e-mail]> wrote:
>> What is your definition for "subnet" that is compatible with the
>> definition from draft-ietf-6man-multicast-scopes:
> 
>>  automatically configured, i.e., automatically derived from physical
>> connectivity or other, non-multicast-related configuration.
> 
>> I chose PAN ID as a way of identifying a "subnet" within a distribution
>> of MPL forwarders that might be within radio range of each other but
>> should be in separate MPL domains.  For example, suppose I have MPL
>> forwarders in my flat and you have MPL forwarders in your flat.  How do
>> my forwarders know they belong to the MPL domain in my flat while your
>> forwarders know they belong to the MPL domain in your flat.  PAN ID
>> would be one way to make that differentation.
> 
> PANID is too restrictive in my opinion.
> 
> I may well have a radio networks on the first floor of my (penthouse) flat,
> and another radio network on the second floor of my flat, connected by any
> number of wired (ethernet) or higher-powered wireless (wifi) layer-2
> technologies.  There are good radio reasons to use different PANIDs,
> because the isolation might be inconsistent.  The devices which connect my
> two floors know they are supposed to do that at the RPL level, and so
> subnet is the right thing.
> 
> This is where we need to be prescriptive.

If I'm understanding your example correctly, I would say that the MPL domain you describe would use scop 4, administratively defined to cover the various radio domains.

I might also consider using scop 3 to simply forward across the mesh networks, with a broader scope and traditional multicast protocols to tie together the MPL domains with other links in the home network.

Suppose an application uses multicast address FF08::DB8:0:1234 in a network with RTR1 connected to MESH1 and some other links, and RTR2 connected to MESH2 and some other links.  RTR1 and RTR2 share at least on link.

One architecture would be to use traditional multicast protocols to connect the various links to which RTR1 and RTR2 are connected.  RTR1 and RTR2 then act as MPL encapsulators for MESH1 and MESH2.  Traffic on MESH1 looks like (hope the summarization is understandable)

   FF03:0:0:0:0:0:0:FC | MPL header | FF08::DB8:0:1234 | application payload

- Ralph

> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
> 
> 
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll