Re: [manet-dlep-rg] Multicast destination

Maybe I'm being dense here, but….. 

Multicast addresses "come with" Layer 2 MAC addresses. Yes, they are derived. Yes, they might collide. But DLEP already supports (at least spec-wise) the notion of one MAC address having multiple Layer 3 addresses associated with it. So, in my little (maybe weird??) world, either

1. The radio is "PIM snooping", sees Multicast traffic, and peels the MAC/Layer 3 address off. The "DLEP smarts" in the modem generates a "Destination Up" message, with the MAC and Layer 3 address. Oh, and it puts metrics on that, too. If the characteristics of the multicast transmission change (bandwidth, etc), a "Destination Update" is used, just like for any other destination in the network. 

*OR* 

2. The "Destination Up" is supplied by the router, when the appropriate PIM information is received. Again, the "Destination Up" (this time, from router to modem), will have the MAC and Layer 3 information. The modem takes note of the new Destination MAC (I assume that's the only thing the modem is interested in), and can then respond with a "Destination Update" that gives the router metrics.

After the initial exchange, there's really no difference between the modem-initiated and the router-initiated case. 

What am I missing? 

Regards,
Stan

On Nov 8, 2013, at 10:23 AM, Teco Boot <teco@inf-net.nl> wrote:

> Yes, this leaves the two zero-tailed multicast addresses free for corresponding IPv4 and IPv6 multicast addresses.
> 
> Layer-2 devices with some multicast features may use MAC and IP addresses. For DLEP, we can use IP addresses in signaling. The IP multicast address to IEEE MAC address is a hack anyway.
> 
> Teco
> 
> Op 8 nov. 2013, om 01:24 heeft Henning Rogge <hrogge@googlemail.com> het volgende geschreven:
> 
>> Could we maybe state in DLEP that FF:FF:FF:FF:FF:FF contains the
>> default for all multicast MACs that are not otherwise signaled by the
>> radio? It would be a special rule, but it makes sense because it
>> describes what most IP capable radios without explicit multicast rates
>> are doing.
>> 
>> A radio that wants to deliver more information would just add more
>> multicast destinations.
>> 
>> On Fri, Nov 8, 2013 at 5:07 AM, Teco Boot <teco@inf-net.nl> wrote:
>>> We have an open issue on Multicast destination.
>>> Rick suggested the 01:00:5E:00:00:00 & 33:33:00:00:00:00 for all possible IPv4 and IPv6 Multicast destinations.
>>> Stan noticed the limitation that this prevents signaling for more specific groups.
>>> 
>>> Maybe solve this in the dlep extension with reporting per traffic class. Here the 3GPP TS 27.007 Traffic flow template configuration.
>>> +CGTFT=[<cid>,
>>> [<packet filter identifier>,<evaluation precedence index>
>>> [,<remote address and subnet mask>
>>> [,<protocol number (ipv4) / next header (ipv6)>
>>> [,<local port range>
>>> [,<remote port range>
>>> [,<ipsec security parameter index (spi)>
>>> [,<type of service (tos) (ipv4) and mask / traffic class (ipv6) and mask>
>>> [,<flow label (ipv6)>
>>> [,<direction>
>>> ]]]]]]]]]]
>>> 
>>> Discuss in our next teleconf session?
>> 
>> Yes, that sounds like a good topic for the monthly/next teleconf.
>> 
>> Henning Rogge
>> 
>> 
>> -- 
>> We began as wanderers, and we are wanderers still. We have lingered
>> long enough on the shores of the cosmic ocean. We are ready at last to
>> set sail for the stars - Carl Sagan
> 
> _______________________________________________
> manet-dlep-rg mailing list
> manet-dlep-rg@ietf.org
> https://www.ietf.org/mailman/listinfo/manet-dlep-rg