Re: = [manet] DLEP and broadcast/multicast

Joe = Macker <joseph.macker = at nrl.navy.mil> · Wed, 14 = Sep 2011 14:58:36 -0400

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

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.

 <=
/pre>> 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 <reller =
at cococorp.com>
>>> To: Vikram KAUL =
<vkaul at =
research.telcordia.com>,
>>>  =
 "manet at ietf.org" <manet at =
ietf.org>
>>> 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: =
manet-bounces at ietf.org [mailto:manet-bounces at ietf.org] On =
Behalf Of Vikram KAUL
>>> Sent: Monday, =
August 15, 2011 8:15 AM
>>> To: manet at =
ietf.org
>>> 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
>>> manet at =
ietf.org
>>> https://www.ietf.org=
/mailman/listinfo/manet
>>> =
>> =
_______________________________________________
>=
> manet mailing list
>> manet at =
ietf.org
>> https://www.ietf.org=
/mailman/listinfo/manet
> =
> =
_______________________________________________
>=
 manet mailing list
> manet at =
ietf.org
> https://www.ietf.org=
/mailman/listinfo/manet
> =

Follow-Ups: =
Re: [manet] DLEP and broadcast/multicast 
From: A. Riley =
Eller
References: =
[manet] DLEP and broadcast/multicast 
From: Vikram =
KAUL
Re: [manet] DLEP and broadcast/multicast 
From: A. Riley =
Eller
Re: [manet] DLEP and broadcast/multicast 
From: Vikram =
KAUL
Re: [manet] DLEP and broadcast/multicast 
From: Stan =
Ratliff
Prev by Date: Re: [manet] DLEP and broadcast/multicast =
Next by Date: Re: [manet] [Int-area] SMF and =
intarea-ipv4-id-update 
Previous by thread: Re: [manet] DLEP and broadcast/multicast =
Next by thread: Re: [manet] DLEP and broadcast/multicast =
Index(es): 
Date
Thread 

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.

> 
> 
> Regards,
> 
> 
>> 
>> 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.
>> 
>> 
>> 
>> 
>>> Date: Mon, =
15 Aug 2011 10:01:47 -0700
>>> From: A. =
Riley Eller <reller at cococorp.com>
>>>   =
"manet at ietf.org" <manet at ietf.org>
>>> Perhaps the DLEP =
specification would benefit from accepting a pseudo-link identifier for =
multicast messages?
>>> 
>>> 
>>> -----Original =
Message-----
>>> From: manet-bounces at =
ietf.org [mailto:manet-bounces at ietf.org] On =
Behalf Of Vikram KAUL
>>> Sent: Monday, August =
15, 2011 8:15 AM
>>> To: manet at =
ietf.org
>>> 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.
>>> =
archives
>>> 
>>> link characteristics =
(MDR, CDR, Latency, etc) are focused on individual
>>> most of the =
messages
>>> 
>>> emanate from a router. =
Let us presume that the underlying multicast
>>> 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
>>> it for individual links =
to neighbors. But if I presume that multicast and
>>> am wrong about that), =
how can one use DLEP   "Link Characteristics =
Request
>>> Message" to specify that =
traffic to a particular MAC address should be
>>> 
>>> 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
>>> 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
>>> 
>>> =
regards..
>>> Vikram
>>> >> =
_______________________________________________
>> manet at =
ietf.org
>> > =
_______________________________________________
> manet at =
ietf.org
>  
�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.�  
 � 
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 <reller at cococorp.com>  
>>> To: Vikram KAUL <vkaul at research.telcordia.com>,  
>>>�� "manet at ietf.org" <manet at ietf.org>  
>>> 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: manet-bounces at ietf.org [mailto:manet-bounces at ietf.org] On Behalf Of Vikram KAUL  
>>> Sent: Monday, August 15, 2011 8:15 AM  
>>> To: manet at ietf.org  
>>> 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  
>>> manet at ietf.org  
>>> https://www.ietf.org/mailman/listinfo/manet  
>>>   
>> _______________________________________________  
>> manet mailing list  
>> manet at ietf.org  
>> https://www.ietf.org/mailman/listinfo/manet  
>   
> _______________________________________________  
> manet mailing list  
> manet at ietf.org  
> https://www.ietf.org/mailman/listinfo/manet  
>   
 � 

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

Re: = [manet] DLEP and broadcast/multicast

Re: [manet] DLEP and = broadcast/multicast

Re: [manet] DLEP and broadcast/multicast