Subject: Re: [manet] DLEP and broadcast/multicast

From: Vikram KAUL <[email-masked]>
Date: Wed, 5 Oct 2011 20:54:25 -0400 (Eastern Daylight Time)

Stan, others

  Here are my thoughts on the DLEP broadcast/multicast matter.

  I will first discuss the addressing/identification and then the potential
usages of 'existing' DLEP Protocol messages for multicast/broadcast

MAC Address Sub-TLV
-------------------

  The MAC Address Sub-TLV could be used as the identifier for 
multicast/broadcast sessions that traverse the modems. So the language in 
the draft could be modified to expand the references from the MAC Address 
sub-TLV to be one of the following
  1) The MAC address of the far-end (neighbor) router
  2) An all-broadcast address 0xffffffffffff (6 bytes all 0xFF)
  3) An IPv4 multicast address, the most significant two bytes being 0x0100
     and the next 4 octets being the IPv4 multicast address octets

example, 01:00:5E:00:00:01  for 224.0.0.1

A point to be noted here is that some implementations of host/router 
stacks don't use the MAC address (3) above to designate multicast packets. I 
don't know if the DLEP standard can mandate it or not. Another thing is 
that I don't know what happens for IPv6 in so far as how that translation 
from IPv6 to the MAC address would occur

Once the MAC Address Sub-TLV is available to handle such (non peer MAC 
address values), it is then necessary to identify the DLEP messages that 
would be exercised using the newer values and the appropriate use cases 
for them

Neighbor Up/Down
-----------------
As Stan pointed out, the Neighbor Up and Neighbor Down Messages could be 
initiated by either the router or the modem. The traditional flow for 
Neighbor Up is that the modem sends it to the router to declare the 
presence of a peer.

For multicast, the router could send the Neighbor Up message to the modem 
to indicate the initiation (Tx or Rx) for a multicast group. Again, the 
Neighbor Down message would be sent by the router to the modem to indicate 
the termination of the group.

The IPv4 (or IPv6) Sub-TLV would be populated, even though they are 
OPTIONAL, with the IPv4 or IPv6 multicast address. The router could 
specify the MDR, CDR, Latency requirements for the session it desires from 
the modem

Link Characteristics Request (and ACK)
---------------------------------------
If the router desires different set of characteristics for a multicast 
group, it would use the Link Characteristics request. The MAC Address 
sub-TLV would carry the multicast version of the sub-TLV

As the draft points out, the router could "query" the modem to tell it the 
existing session characteristics (MDR, CDR, latency, etc)

Next steps
==========
If the above discussion makes sense, then the following things can be done 
to update the draft:

  - Expand the description of the MAC Address sub-TLV
  - Where required, caveat all occurances of MAC Address sub-TLV to specify
    what type of MAC-Address sub-TLV would be used. For example, a Neighbor
    Address Update message would only use the 'traditional' MAC Address
    sub-TLV
  - In the initial sections, have use-cases that illustrate the use of
    DLEP for multicast/broadcast sessions

regards..
Vikram

On Mon, 19 Sep 2011, Stan Ratliff wrote:

> Date: Mon, 19 Sep 2011 11:19:32 -0400
> From: Stan Ratliff <[email-masked]>
> To: A. Riley Eller <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Subject: Re: [manet] DLEP and broadcast/multicast
> 
> My apologies for the quick comments on this to date.
>
> In response to Vikram's initial email, I look at a multicast MAC as another 
> "destination" in the network. A destination that needs to be characterized 
> from a metrics standpoint, so MCAST destinations are essentially a DLEP 
> "neighbor". Cognizance of the neighbor can come from the radio, provided the 
> radio is doing something like PIM "snooping", or it can come from the router. 
> Because of that, we were going to insert language into the DLEP spec that 
> Neighbor Up/Neighbor Down orders can actually come from either of the session 
> peers (either the router or the modem device). If/when the modem receives a 
> Neighbor Up from the router, it would be incumbent on the modem to provide 
> metrics for that "destination".
>
> Regards,
> Stan
>
>
> On Sep 15, 2011, at 5:08 PM, A. Riley Eller wrote:
>
>> Just to be clear, the request I filed below is only to measure the latency 
>> for these packets. The goal is to provide an approximation for some EFT 
>> variables. The value returned does not even need to come from multicast 
>> packets. For instance, in Wi-Fi, measuring the 
>> receipt-through-first-transmission duration of unicast packets would be an 
>> equivalent indicator.
>> 
>> The idea here is to offer the router distinct latency views of access to 
>> the medium and each peer. For each peer, the total link latency will be 
>> (latency of access to the medium scaled by expected latency of 
>> retransmission to that peer). The first term of that clause was my intended 
>> goal, and might be well approximated by an exponential moving weighted 
>> average of forwarding time of multicast/broadcast packets.
>> 
>> Hopefully some of those concepts will help to shape the motivation 
>> discussion.
>> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of 
>> Joe Macker
>> Sent: Wednesday, September 14, 2011 11:59 AM
>> To: Stan Ratliff
>> Cc: [email-masked]
>> Subject: Re: [manet] DLEP and broadcast/multicast
>> 
>> I realize there are some specific sub areas being discussed here but I also 
>> feel lower layer wireless designs will have more general performance and 
>> flow control issues related to multicast/broadcast interaction.
>> 
>> I think we could author some core framework in this area that could be 
>> useful.  A requirements/motivation discussion might be a good first step.
>> 
>> 
>>> Vikram,
>>> 
>>> Yes, there is interest amongst the DLEP co-authors to include 
>>> broadcast/multicast. Do you have any specific ideas?
>>> 
>>> Regards,
>>> Stan
>>> 
>>> On Sep 14, 2011, at 12:45 PM, Vikram KAUL wrote:
>>> 
>>>> 
>>>> Reviving this old thread....
>>>> 
>>>> Is there any interest in the details of the messages below. I believe 
>>>> that the specifications would be more complete if we include some version 
>>>> of broadcast/multicast.
>>>> 
>>>> Perhaps the dlep_tools software could also be modified to handle the 
>>>> upgraded specifications as a proof of concept
>>>> 
>>>> Vikram
>>>> 
>>>> On Mon, 15 Aug 2011, A. Riley Eller wrote:
>>>> 
>>>>> Date: Mon, 15 Aug 2011 10:01:47 -0700
>>>>> From: A. Riley Eller <[email-masked]>
>>>>> To: Vikram KAUL <[email-masked]>,
>>>>> "[email-masked]" <[email-masked]>
>>>>> Subject: RE: [manet] DLEP and broadcast/multicast
>>>>> Perhaps the DLEP specification would benefit from accepting a 
>>>>> pseudo-link identifier for multicast messages?
>>>>> 
>>>>> My team's research shows that EFT implementations achieve higher overall 
>>>>> accuracy by measuring multicast messages as a universal estimator for 
>>>>> queuing-plus-congestion. Giving DLEP the ability to describe that value, 
>>>>> and also gaining the ability to control the radio's performance for 
>>>>> multicast traffic, would be a valuable addition.
>>>>> 
>>>>> 
>>>>> -----Original Message-----
>>>>> From: [email-masked] [mailto:[email-masked]] On Behalf 
>>>>> Of Vikram KAUL
>>>>> Sent: Monday, August 15, 2011 8:15 AM
>>>>> To: [email-masked]
>>>>> Subject: [manet] DLEP and broadcast/multicast
>>>>> 
>>>>> 
>>>>> Folks
>>>>> 
>>>>> I have some questions about how DLEP handles multicast/broadcast traffic
>>>>> and the intents that the router might have to send to the modem device.
>>>>> Some of this might have been answered; but I couldn't find it in the
>>>>> archives
>>>>> 
>>>>> The inherent nature of DLEP seems focused on neighbor relationships and
>>>>> link characteristics (MDR, CDR, Latency, etc) are focused on individual
>>>>> neighbors as identifed by the 'MAC Address Sub-TLV' which is mandatory 
>>>>> in
>>>>> most of the messages
>>>>> 
>>>>> My question is related to broadcast and/or multicast traffic that would
>>>>> emanate from a router. Let us presume that the underlying multicast
>>>>> protocol is SMF for ease of discussion... but it could be anything that
>>>>> forwards native multicast packets, either via flooding or after creating
>>>>> trees.
>>>>> 
>>>>> How can one use DLEP to specify the MDR/CDR or latency requirements for
>>>>> those flows ? Is it even possible to do so ? I understand how one could 
>>>>> do
>>>>> it for individual links to neighbors. But if I presume that multicast 
>>>>> and
>>>>> broadcast is the predominant traffic (say 70%-80%, and I don't believe I
>>>>> am wrong about that), how can one use DLEP   "Link Characteristics 
>>>>> Request
>>>>> Message" to specify that traffic to a particular MAC address should be
>>>>> able to get at least what is specified by the CDR Sub-TLV
>>>>> 
>>>>> Typically (but not always) MAC addresses for multicast IP packets are 
>>>>> set
>>>>> to  01:00:xx:yy:zz:aa for a destination multicast address of 
>>>>> xx.yy.zz.aa.
>>>>> Could one not have that 01:00:xx:yy:zz:aa MAC Address Sub-TLV so that 
>>>>> the
>>>>> modem could identify that traffic to that MAC Address (and hence traffic
>>>>> to that destination multicast IP address) needs to get at least that 
>>>>> data
>>>>> rate. How the modems would achieve that is a separate question, but DLEP
>>>>> does not delve into those answers anyway
>>>>> 
>>>>> Again, it might be that the charter for DLEP is to focus specifically on
>>>>> one-to-one relationships (and hence one-to-one specifications and
>>>>> conditions). Could the specs not be augmented to support something on
>>>>> one-to-many specifications ? Just thinking aloud.
>>>>> 
>>>>> regards..
>>>>> Vikram
>>>>> _______________________________________________
>>>>> manet mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/manet
>>>>> 
>>>> _______________________________________________
>>>> manet mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/manet
>>> 
>>> _______________________________________________
>>> manet mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/manet
>>> 
>> 
>> _______________________________________________
>> manet mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/manet
>> _______________________________________________
>> manet mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/manet
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet