Subject: [manet-dlep-rg] Multicast destination

From: Teco Boot <[email-masked]>
Date: Thu, 7 Nov 2013 20:07:28 -0800

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?

Teco

Op 27 aug. 2013, om 13:06 heeft Stan Ratliff (sratliff) <[email-masked]> het volgende geschreven:

> My initial thoughts on MCAST is that the router (or the radio, but probably the router) would announce availability/capability. It would use the created MAC address, *and* (most likely) the MCAST address as well (at least the router should). That way, a radio implementation at least has the chance of declaring bandwidth for a specific MCAST group (address)… I could see the scheme below, but there's no granularity over and above "I can do MCAST".
> 
> Regards,
> Stan
> 
> On Aug 27, 2013, at 8:56 AM, Henning Rogge <[email-masked]>
> wrote:
> 
>> On 08/27/2013 02:50 PM, Taylor, Rick wrote:
>>> I agree Henning, a Neighbour_Up message with a multicast/broadcast MAC address is a good way of indicating multicast/broadcast capability.
>>> 
>>> But, multicast MAC addresses encode the multicast IPv4/6 group address, and I'm not sure having a neighbour up for 33:33:00:01:00:03 and 33:33:00:01:00:04 and 33:33:00:01:00:05 etc... is a good way for advertise IPv6 multicast.
>>> 
>>> Could we just state:
>>> 
>>> Neighbour MAC = FF:FF:FF:FF:FF:FF - Broadcast/Link-local multicast supported
>>> Neighbour MAC = 01:00:5E:00:00:00 - IPv4 multicast supported
>>> Neighbour MAC = 33:33:00:00:00:00 - IPv6 multicast supported
>> 
>> This looks like a nice way to do it.
>> 
>> Henning Rogge
>> 
>> 
>> -- 
>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE
>> Kommunikationssysteme (KOM)
>> Fraunhofer Straße 20, 53343 Wachtberg, Germany
>> Telefon +49 228 9435-961,   Fax +49 228 9435 685
>> mailto:[email-masked] http://www.fkie.fraunhofer.de
>> 
>> _______________________________________________
>> manet-dlep-rg mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/manet-dlep-rg
> 
> _______________________________________________
> manet-dlep-rg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet-dlep-rg

---

From: Henning Rogge <[email-masked]>
Date: Fri, 8 Nov 2013 10:24:51 +0100

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.

>   [,<type of service (tos) (ipv4) and mask / traffic class (ipv6) and mask>

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

---

From: Teco Boot <[email-masked]>
Date: Fri, 8 Nov 2013 07:23:03 -0800

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

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Mon, 11 Nov 2013 01:08:53 +0000

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

---

From: Teco Boot <[email-masked]>
Date: Mon, 11 Nov 2013 17:48:27 +0100

Op 11 nov. 2013, om 02:08 heeft Stan Ratliff (sratliff) <[email-masked]> het volgende geschreven:

> 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.

We have to discuss the address TLVs at a next teleconf. Personally, I think the address TLVs deserve a separate RFC. Let's do it right. I'm willing to put energy in it. 

> So, in my little (maybe weird??) world, either
> 
> 1. The radio is "PIM snooping"

Could be. There is more than PIM.

> , 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.

Why would it do so? If it is a bridge, it floods multicast (unless IGMP/PIM snooping of RGMP). And multicast has same metrics as broadcast.

If it supports some kind of smart multicast forwarding, shouldn't we first describe what it is? And as a next step define signaling between router and modem, if we need such?

If it is for traffic management, why not use the Traffic Flow Template? Much more powerful and implemented in millions of devices already.

> 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* 
> 

This is RGMP, I believe (rfc3488).

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

If two mechanisms result in same outcome, let's skip one.

But maybe they are different, I don't know. An "Order" message from router to modem looks different to me than a "Report" message from modem to router.

Teco

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Mon, 11 Nov 2013 18:17:29 +0000

On Nov 11, 2013, at 11:48 AM, Teco Boot <[email-masked]> wrote:

> We have to discuss the address TLVs at a next teleconf.

OK.

> Personally, I think the address TLVs deserve a separate RFC.

No. Just. No. The address TLVs haven't been discussed in almost a year. The design team is NOT a "raison d'être" for re-litigating EACH and EVERY detail about DLEP that you disagree with. In this mode of operation, I GUARANTEE that the DT will stall out (due to lack of consensus on the part of the co-authors) and will fail. Pushing things that haven't been looked at yet (e.g. metrics within the context of traffic classification) off into supplemental drafts makes sense; this does not. 

> Let's do it right. I'm willing to put energy in it. 
> 
> 

I can count at least a couple of reasons: 
1. Really? Multicast metrics = Broadcast metrics? For *ALL* radios? In *EVERY* circumstance? You can GUARANTEE that? And it will *NEVER* change? 
2. Creating a separate "Destination" (Neighbor) for each Multicast allows for the manipulation of the credit windows (yet another part of DLEP that will NOT be pushed into a separate draft) for each MCAST group. The short answer is "more granular flow control".

> If two mechanisms result in same outcome, let's skip one.

I don't think you can do that. And I really don't understand this line of thought from someone who, in another thread, is arguing "let's not preclude options"…. logically inconsistent at best. 

Stan

---

From: Henning Rogge <[email-masked]>
Date: Mon, 11 Nov 2013 19:23:02 +0100

> No. Just. No. The address TLVs haven't been discussed in almost a year. The design team is NOT a "raison d'être" for re-litigating EACH and EVERY detail about DLEP that you disagree with. In this m…

We need to think about Multicast anyways, otherwise IPv6 will not work
over DLEP radios.

It would be nice to have an option that says "I don't support
different metrics for multicast/broadcast, just look at the broadcast
data" but we WILL have to mention what to do with multicast MACs.

So I agree, completely moving the multicast handling to a different
draft looks like the wrong thing.

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Mon, 11 Nov 2013 19:38:17 +0100

> draft looks like the wrong thing.

That was the outcome of earlier discussions. Now we do the basic stuff, enhancements come later. For now we can declare multicast is handled as broadcast (with ff:ff:ff:ff:ff:ff Destination), unless signaled otherwise.

Setting up multicast forwarding rules, from router to radio, is not something I expect from CORE DLEP spec.

Teco

---

From: Teco Boot <[email-masked]>
Date: Mon, 11 Nov 2013 19:44:02 +0100

Op 11 nov. 2013, om 19:17 heeft Stan Ratliff (sratliff) <[email-masked]> het volgende geschreven:

> (due to lack of consensus on the part of the co-authors)

This is not how WG draft editor should respond. It is the MANET WG that decides what is in the draft. DT prepares something.

Because the importance of this, I'll postpone processing your mails until this is resolved.

Teco

---

From: "Taylor, Rick" <[email-masked]>
Date: Tue, 12 Nov 2013 13:10:05 +0000

I'm sort of in the middle with this one.

I like support for FF:FF:FF:FF:FF:FF.  If the modem sends a Destination_Up with this address then it is advertising support for basic broadcast/multicast.

If the modem wishes to do PIM snooping (and friends) then it MAY send Destination_Up for the relevant mapped layer-2 address.  By doing this the modem is explicitly stating that it will send *different* metrics for that group than the broadcast group.

This has the advantages of:
1) The modem can advertise its support for broadcast.
2) The modem can advertise its support for more complex multicast stuff if it wants.

Rick Taylor

> -----Original Message-----
> From: [email-masked] [mailto:manet-dlep-rg-
> [email-masked]] On Behalf Of Teco Boot
> Sent: 11 November 2013 18:44
> To: Stan Ratliff
> Cc: Henning Rogge; [email-masked]
> Subject: Re: [manet-dlep-rg] Multicast destination
>
>
> Op 11 nov. 2013, om 19:17 heeft Stan Ratliff (sratliff)
> <[email-masked]> het volgende geschreven:
>
> This is not how WG draft editor should respond. It is the MANET WG that
> decides what is in the draft. DT prepares something.
>
The information contained within this e-mail and any files attached to this e-mail is private and in addition may include commercially sensitive information. The contents of this e-mail are for the intended recipient only and therefore if you wish to disclose the information contained within this e-mail or attached files, please contact the sender prior to any such disclosure. If you are not the intended recipient, any disclosure, copying or distribution is prohibited. Please also contact the sender and inform them of the error and delete the e-mail, including any attached files from your system. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com