Subject: [manet] DLEP framework and requirements (UNCLASSIFIED)

From: "Cole, Robert G USA CIV (US)" <[email-masked]>
Date: Wed, 2 Nov 2011 18:07:56 +0000

Classification: UNCLASSIFIED
Caveats: NONE

On Sept 14th, Joe Macker stated:

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

Has anyone followed up on this?  There has been a lot of discussion and
valuable comments on DLEP by a number of folks since the last meeting.  But
I do not see the WG coming to consensus on the issues and alternatives.  Can
we have a discussion at the meeting in Taipei?

Thanks,

Bob Cole

Re: [manet] DLEP and broadcast/multicast

  _____  

*	To: Stan Ratliff <sratliff at cisco.com
<mailto:[email-masked]> >
*	Subject: Re: [manet] DLEP and broadcast/multicast
*	From: Joe Macker <joseph.macker at nrl.navy.mil
<mailto:[email-masked]> >
*	Date: Wed, 14 Sep 2011 14:58:36 -0400
*	Cc: manet at ietf.org <mailto:[email-masked]> 
*	Delivered-to: manet at ietfa.amsl.com <mailto:[email-masked]> 
*	In-reply-to: <A9C264D6-45DD-4ADA-B911-4EB4E963FE61 at cisco.com
<mailto:[email-masked]> >
*	List-archive: <http://www.ietf.org/mail-archive/web/manet>
*	List-help: <mailto:[email-masked]?subject=help>
*	List-id: Mobile Ad-hoc Networks <manet.ietf.org>
*	List-post: <mailto:[email-masked]>
*	List-subscribe: <https://www.ietf.org/mailman/listinfo/manet>,
<mailto:[email-masked]?subject=subscribe>
*	List-unsubscribe: <https://www.ietf.org/mailman/options/manet>,
<mailto:[email-masked]?subject=unsubscribe>
*	References: <alpine.WNT.2.01.1108151053430.5496 at vkaul7-t61
<mailto:[email-masked]> >
<3D05610F3AC2E047AACAA68F63DF908D345B1AA01A at EXMBX13.exchhosting.com
<mailto:[email-masked]> >
<alpine.WNT.2.01.1109141241400.3140 at vkaul7-t61
<mailto:[email-masked]> >
<A9C264D6-45DD-4ADA-B911-4EB4E963FE61 at cisco.com
<mailto:[email-masked]> >

  _____  

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

*	Follow-Ups: 

*	 <http://www.ietf.org/mail-archive/web/manet/current/msg12180.html>
Re: [manet] DLEP and broadcast/multicast 

*	From: A. Riley Eller

*	References: 

*	 <http://www.ietf.org/mail-archive/web/manet/current/msg12161.html>
[manet] DLEP and broadcast/multicast 

*	From: Vikram KAUL

*	 <http://www.ietf.org/mail-archive/web/manet/current/msg12162.html>
Re: [manet] DLEP and broadcast/multicast 

*	From: A. Riley Eller

*	 <http://www.ietf.org/mail-archive/web/manet/current/msg12176.html>
Re: [manet] DLEP and broadcast/multicast 

*	From: Vikram KAUL

*	 <http://www.ietf.org/mail-archive/web/manet/current/msg12177.html>
Re: [manet] DLEP and broadcast/multicast 

*	From: Stan Ratliff

*	Prev by Date: Re: [manet] DLEP and broadcast/multicast
<http://www.ietf.org/mail-archive/web/manet/current/msg12177.html>  
*	Next by Date: Re: [manet] [Int-area] SMF and intarea-ipv4-id-update
<http://www.ietf.org/mail-archive/web/manet/current/msg12179.html>  
*	Previous by thread: Re: [manet] DLEP and broadcast/multicast
<http://www.ietf.org/mail-archive/web/manet/current/msg12177.html>  
*	Next by thread: Re: [manet] DLEP and broadcast/multicast
<http://www.ietf.org/mail-archive/web/manet/current/msg12180.html>  
*	Index(es): 

*
<http://www.ietf.org/mail-archive/web/manet/current/maillist.html#12178>
Date
*
<http://www.ietf.org/mail-archive/web/manet/current/threads.html#12178>
Thread

Classification: UNCLASSIFIED
Caveats: NONE

---

From: Stan Ratliff <[email-masked]>
Date: Wed, 2 Nov 2011 14:44:17 -0400

Bob,

 From a draft perspective, we are following up with the notion that  
Neighbor Up orders can flow in both directions, with the intent being  
that Multicast groups would be identified by the router, and  
communicated to the radio via this Neighbor Up. The Neighbor Up would  
contain the MCAST MAC and IP address, and would essentially notify the  
radio that it needs to provide some sort of metrics (for rate-shaping,  
if nothing else) for the MCAST group.  That being said, as Joe  
mentioned, I'm open to any and all discussion - here on the list, as  
well as at the next IETF, if you're going to be there.

Also, there was a draft submitted in another group that is essentially  
a "DLEP light" - the draft is at http://tools.ietf.org/html/draft-ivancic-mobopts-modemlpa-00
I've contacted some of the co-authors of that draft, as we've now got  
two protocols working that essentially do the same thing. We'll need  
to resolve that.

One other item - the current DLEP draft is set to expire today (Nov  
2). Unfortunately, I won't be able to get another draft posted before  
this one expires (work pressures), but I promise - an updated draft is  
forthcoming. I just need to get sufficient time to get it all put  
together.

Regards,
Stan

On Nov 2, 2011, at 2:07 PM, Cole, Robert G USA CIV (US) wrote:

> “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.”
>
>
> Has anyone followed up on this?  There has been a lot of discussion  
> and valuable comments on DLEP by a number of folks since the last  
> meeting.  But I do not see the WG coming to consensus on the issues  
> and alternatives.  Can we have a discussion at the meeting in Taipei?
>
> Thanks,
> Bob Cole
>
> To: Stan Ratliff <sratliff at cisco.com>
> Subject: Re: [manet] DLEP and broadcast/multicast
> From: Joe Macker <joseph.macker at nrl.navy.mil>
> Date: Wed, 14 Sep 2011 14:58:36 -0400
> Cc: manet at ietf.org
> Delivered-to: manet at ietfa.amsl.com
> In-reply-to: <A9C264D6-45DD-4ADA-B911-4EB4E963FE61 at cisco.com>
> List-archive: <http://www.ietf.org/mail-archive/web/manet>
> List-help: <mailto:[email-masked]?subject=help>
> List-id: Mobile Ad-hoc Networks <manet.ietf.org>
> List-post: <mailto:[email-masked]>
> List-subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:[email-masked]?subject=subscribe 
> >
> List-unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:[email-masked]?subject=unsubscribe 
> >
> References: <alpine.WNT.2.01.1108151053430.5496 at vkaul7-t61>  
> <3D05610F3AC2E047AACAA68F63DF908D345B1AA01A at  
> EXMBX13.exchhosting.com> <alpine.WNT.2.01.1109141241400.3140 at  
> vkaul7-t61> <A9C264D6-45DD-4ADA-B911-4EB4E963FE61 at cisco.com>
> 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,
> >
> >> 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
> >>
> >>> 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.
> >>>
> >>>
> >>> From: manet-bounces at ietf.org [mailto:manet-bounces at  
> ietf.org] On Behalf Of Vikram KAUL
> >>> neighbors as identifed by the 'MAC Address Sub-TLV' which is  
> mandatory in
> >>> most of the messages
> >>>
> >>> 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
> >>> am wrong about that), how can one use DLEP   "Link  
> Characteristics Request
> >>> Typically (but not always) MAC addresses for multicast IP  
> packets are set
> >>> 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
> Follow-Ups:
> From: A. Riley Eller
> References:
> From: Vikram KAUL
> From: A. Riley Eller
> From: Vikram KAUL
> 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
>
>
> [email-masked]

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Wed, 2 Nov 2011 14:17:01 -0500

modemlpa is "DLEP light"  and provides an ability to notify devices that are multiple hops away from the modem the downlink status.  DLEP is really for directly connected devices and just didn't seem to be able to handle the multi-hop problem well.   Also note, the same techniques could be used for security devices and application layer networking such as Delay/Disruption Tolerant Networking.

We sent this draft to mobopts as this draft addresses "examination of the feasibility of generic mechanisms that allow tighter integration of the link layer with the IP layer for improving handover performance" as well as allowing applications and routing protocols and even new concepts such as disruption/delay tolerant networking (DTN) to have some clue of network connectivity and link layer characteristics even if the host / router / forwarding agent is multiple hops away from the modem.

- Will

On Nov 2, 2011, at 2:44 PM, Stan Ratliff wrote:

> Bob, 
> 
> From a draft perspective, we are following up with the notion that Neighbor Up orders can flow in both directions, with the intent being that Multicast groups would be identified by the router, and communicated to the radio via this Neighbor Up. The Neighbor Up would contain the MCAST MAC and IP address, and would essentially notify the radio that it needs to provide some sort of metrics (for rate-shaping, if nothing else) for the MCAST group.  That being said, as Joe mentioned, I'm open to any and all discussion - here on the list, as well as at the next IETF, if you're going to be there. 
> 
> Also, there was a draft submitted in another group that is essentially a "DLEP light" - the draft is at http://tools.ietf.org/html/draft-ivancic-mobopts-modemlpa-00
> I've contacted some of the co-authors of that draft, as we've now got two protocols working that essentially do the same thing. We'll need to resolve that. 
> 
> One other item - the current DLEP draft is set to expire today (Nov 2). Unfortunately, I won't be able to get another draft posted before this one expires (work pressures), but I promise - an updated draft is forthcoming. I just need to get sufficient time to get it all put together. 
> 
> Regards,
> Stan
>

---

From: "Cole, Robert G USA CIV (US)" <[email-masked]>
Date: Wed, 2 Nov 2011 19:38:36 +0000

Will,
Stan,

Thanks for the heads up on DLEP light. How do these relate to our NHDP for
one and two hop discovery?

Bob

-----Original Message-----
From: Ivancic, William D. (GRC-RHN0) [mailto:[email-masked]] 
Sent: Wednesday, November 02, 2011 3:17 PM
To: Stan Ratliff
Cc: Cole, Robert G USA CIV (US); [email-masked]
Subject: Re: [manet] DLEP framework and requirements (UNCLASSIFIED)

modemlpa is "DLEP light"  and provides an ability to notify devices that are
multiple hops away from the modem the downlink status.  DLEP is really for
directly connected devices and just didn't seem to be able to handle the
multi-hop problem well.   Also note, the same techniques could be used for
security devices and application layer networking such as Delay/Disruption
Tolerant Networking.

We sent this draft to mobopts as this draft addresses "examination of the
feasibility of generic mechanisms that allow tighter integration of the link
layer with the IP layer for improving handover performance" as well as
allowing applications and routing protocols and even new concepts such as
disruption/delay tolerant networking (DTN) to have some clue of network
connectivity and link layer characteristics even if the host / router /
forwarding agent is multiple hops away from the modem.

- Will

> From a draft perspective, we are following up with the notion that
Neighbor Up orders can flow in both directions, with the intent being that
Multicast groups would be identified by the router, and communicated to the
radio via this Neighbor Up. The Neighbor Up would contain the MCAST MAC and
IP address, and would essentially notify the radio that it needs to provide
some sort of metrics (for rate-shaping, if nothing else) for the MCAST
group.  That being said, as Joe mentioned, I'm open to any and all
discussion - here on the list, as well as at the next IETF, if you're going
to be there. 
> 
> Also, there was a draft submitted in another group that is essentially a
"DLEP light" - the draft is at
http://tools.ietf.org/html/draft-ivancic-mobopts-modemlpa-00
> I've contacted some of the co-authors of that draft, as we've now got two
protocols working that essentially do the same thing. We'll need to resolve
that. 
> 
> One other item - the current DLEP draft is set to expire today (Nov 2).
Unfortunately, I won't be able to get another draft posted before this one
expires (work pressures), but I promise - an updated draft is forthcoming. I
just need to get sufficient time to get it all put together.

---

From: Stan Ratliff <[email-masked]>
Date: Wed, 2 Nov 2011 16:12:03 -0400

Will,

Since DLEP is running over UDP in the first incarnation (RFC 5444  
itself is operating over UDP), it would seem to me that DLEP could  
indeed handle the multi-hop case. I understand there are also some  
issues with regard to the transparent bridge mode of operation, but I  
would think we should at least explore to see if we can get these to  
merge.

Regards,
Stan

On Nov 2, 2011, at 3:17 PM, Ivancic, William D. (GRC-RHN0) wrote:

> modemlpa is "DLEP light"  and provides an ability to notify devices  
> that are multiple hops away from the modem the downlink status.   
> DLEP is really for directly connected devices and just didn't seem  
> to be able to handle the multi-hop problem well.   Also note, the  
> same techniques could be used for security devices and application  
> layer networking such as Delay/Disruption Tolerant Networking.
>
> We sent this draft to mobopts as this draft addresses "examination  
> of the feasibility of generic mechanisms that allow tighter  
> integration of the link layer with the IP layer for improving  
> handover performance" as well as allowing applications and routing  
> protocols and even new concepts such as disruption/delay tolerant  
> networking (DTN) to have some clue of network connectivity and link  
> layer characteristics even if the host / router / forwarding agent  
> is multiple hops away from the modem.
>
> - Will
>
>
>> Neighbor Up orders can flow in both directions, with the intent  
>> being that Multicast groups would be identified by the router, and  
>> communicated to the radio via this Neighbor Up. The Neighbor Up  
>> would contain the MCAST MAC and IP address, and would essentially  
>> notify the radio that it needs to provide some sort of metrics (for  
>> rate-shaping, if nothing else) for the MCAST group.  That being  
>> said, as Joe mentioned, I'm open to any and all discussion - here  
>> on the list, as well as at the next IETF, if you're going to be  
>> there.
>>
>> Also, there was a draft submitted in another group that is  
>> essentially a "DLEP light" - the draft is at http://tools.ietf.org/html/draft-ivancic-mobopts-modemlpa-00
>> I've contacted some of the co-authors of that draft, as we've now  
>> got two protocols working that essentially do the same thing. We'll  
>> need to resolve that.
>>
>> 2). Unfortunately, I won't be able to get another draft posted  
>> before this one expires (work pressures), but I promise - an  
>> updated draft is forthcoming. I just need to get sufficient time to  
>> get it all put together.
>>
>> Regards,
>> Stan
>>
>

---

From: Subir Das <[email-masked]>
Date: Wed, 02 Nov 2011 16:12:30 -0400

Stan, Bob,
Having a discussion in Taipei session is a good idea.

regards,
-Subir

On 11/2/2011 2:44 PM, Stan Ratliff wrote:
> a "DLEP light" - the draft is at 
>> On Sept 14^th , Joe Macker stated:
>> “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.”
>>      
>>     * /To/: Stan Ratliff <sratliff at cisco.com
>>       <mailto:[email-masked]>>
>>     * /Subject/: Re: [manet] DLEP and broadcast/multicast
>>     * /From/: Joe Macker <joseph.macker at nrl.navy.mil
>>       <mailto:[email-masked]>>
>>     * /Date/: Wed, 14 Sep 2011 14:58:36 -0400
>>     * /Cc/:manet at ietf.org <mailto:[email-masked]>
>>     * /Delivered-to/:manet at ietfa.amsl.com
>>       <mailto:[email-masked]>
>>     * /In-reply-to/: <A9C264D6-45DD-4ADA-B911-4EB4E963FE61 at
>>       cisco.com
>>       <mailto:[email-masked]>>
>>     * /List-archive/: <http://www.ietf.org/mail-archive/web/manet>
>>     * /List-help/: <mailto:[email-masked]?subject=help>
>>     * /List-id/: Mobile Ad-hoc Networks <manet.ietf.org>
>>     * /List-post/: <mailto:[email-masked]>
>>     * /List-subscribe/:
>>       <https://www.ietf.org/mailman/listinfo/manet>,
>>     * /List-unsubscribe/:
>>       <https://www.ietf.org/mailman/options/manet>,
>>     * /References/: <alpine.WNT.2.01.1108151053430.5496 at vkaul7-t61
>>       <mailto:[email-masked]>>
>>       EXMBX13.exchhosting.com
>>       <mailto:[email-masked]>>
>>       <mailto:[email-masked]>>
>>       <mailto:[email-masked]>>
>>
>> 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
>> >    
>> >>  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
>> >>    
>> >>>  From: A. Riley Eller<reller at cococorp.com>   
>> >>>  To: Vikram KAUL<vkaul at research.telcordia.com>,
>> >>>    "manet at ietf.org"<manet at ietf.org>   
>> >>>  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.
>> >>>    
>> >>>    
>> >>>  From: manet-bounces at ietf.org [mailto:manet-bounces  at ietf.org] On Behalf Of Vikram KAUL
>> >>>  neighbors as identifed by the 'MAC Address Sub-TLV' which is mandatory in
>> >>>  most of the messages
>> >>>    
>> >>>  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
>> >>>  am wrong about that), how can one use DLEP   "Link Characteristics Request
>> >>>  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
>> >>>  to that destination multicast IP address) needs to get at least that data
>>     * *Follow-Ups*:
>>           o *Re: [manet] DLEP and broadcast/multicast*
>>                 + /From:/A. Riley Eller
>>     * *References*:
>>           o *[manet] DLEP and broadcast/multicast*
>>             <http://www.ietf.org/mail-archive/web/manet/current/msg12161.html>
>>
>>                 + /From:/Vikram KAUL
>>           o *Re: [manet] DLEP and broadcast/multicast*
>>             <http://www.ietf.org/mail-archive/web/manet/current/msg12162.html>
>>
>>                 + /From:/A. Riley Eller
>>           o *Re: [manet] DLEP and broadcast/multicast*
>>             <http://www.ietf.org/mail-archive/web/manet/current/msg12176.html>
>>
>>                 + /From:/Vikram KAUL
>>           o *Re: [manet] DLEP and broadcast/multicast*
>>                 + /From:/Stan Ratliff
>>     * Prev by Date:*Re: [manet] DLEP and broadcast/multicast
>>       <http://www.ietf.org/mail-archive/web/manet/current/msg12177.html>*
>>
>>     * Next by Date:*Re: [manet] [Int-area] SMF and
>>       intarea-ipv4-id-update
>>       <http://www.ietf.org/mail-archive/web/manet/current/msg12179.html>*
>>
>>     * Previous by thread:*Re: [manet] DLEP and broadcast/multicast
>>       <http://www.ietf.org/mail-archive/web/manet/current/msg12177.html>*
>>
>>     * Next by thread:*Re: [manet] DLEP and broadcast/multicast
>>       <http://www.ietf.org/mail-archive/web/manet/current/msg12180.html>*
>>
>>     * Index(es):
>>           o *Date*
>>           o *Thread*
>> [email-masked] <mailto:[email-masked]>

---

From: "Cole, Robert G USA CIV (US)" <[email-masked]>
Date: Thu, 3 Nov 2011 13:04:07 +0000

Stan,

I guess my questions and concerns are the following (and they are not aimed
at DLEP per se).  It seems that through various drafts and RFCs we are
defining the radio subnet and how the network layer sits on top of it,
without defining (in one place) a radio subnet and then addressing how IP
over Radio works.

So we have NHDP that assumes link information typically is not available
from the radio subnet and hence it provides this capability plus additional
two hop neighbor information for higher layer routing and multicasting.
Then DLEP comes along and says a) we need a control protocol to communicate
pt-to-pt and perhaps pt-to-multipoint QOS information between the IP layer
and the radio subnet, and b) radio subnet should provide neighbor discovery
and link up/down information to improve performance.  Further we also
include SatCom subnets into the radio subnet discussions almost as if they
are the same.

When DLEP becomes approved, we will still need NHDP for two-hop neighbor
information (when running OLSR and SMF).  So should we focus DLEP on QOS
control and de-emphasize one-hop neighbor discovery within the radio subnet,
or should we mandate one-hop neighbor discovery within the radio subnet as
well.

Should we document our common understanding of a) radio subnet, b) satcom
subnet and then c) IP over radio and IP over satcom?

Bob

-----Original Message-----
From: Stan Ratliff [mailto:[email-masked]] 
Sent: Wednesday, November 02, 2011 2:44 PM
To: Cole, Robert G USA CIV (US)
Cc: [email-masked]
Subject: Re: [manet] DLEP framework and requirements (UNCLASSIFIED)

Bob, 

>From a draft perspective, we are following up with the notion that Neighbor
Up orders can flow in both directions, with the intent being that Multicast
groups would be identified by the router, and communicated to the radio via
this Neighbor Up. The Neighbor Up would contain the MCAST MAC and IP
address, and would essentially notify the radio that it needs to provide
some sort of metrics (for rate-shaping, if nothing else) for the MCAST
group.  That being said, as Joe mentioned, I'm open to any and all
discussion - here on the list, as well as at the next IETF, if you're going
to be there. 

Regards,
Stan

	

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

	Has anyone followed up on this?  There has been a lot of discussion
and valuable comments on DLEP by a number of folks since the last meeting.
But I do not see the WG coming to consensus on the issues and alternatives.
Can we have a discussion at the meeting in Taipei?
	 
	Thanks,
	Bob Cole

________________________________

	*	Delivered-to: manet at ietfa.amsl.com
	*	In-reply-to: <A9C264D6-45DD-4ADA-B911-4EB4E963FE61 at
cisco.com <mailto:[email-masked]> >
	*	List-subscribe:
	*	List-unsubscribe:
	*	References: <alpine.WNT.2.01.1108151053430.5496 at
vkaul7-t61 <mailto:[email-masked]> >

________________________________

	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.

	>> 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.
	>>> 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.
mandatory in
one could do
multicast and
Characteristics Request
packets are set
xx.yy.zz.aa.
that the
that data
	>>> one-to-many specifications ? Just thinking aloud.
	 
________________________________

	*	Follow-Ups:

		*	Re: [manet] DLEP and broadcast/multicast
<http://www.ietf.org/mail-archive/web/manet/current/msg12180.html> 

			*	From: A. Riley Eller

	*	References:

		*	[manet] DLEP and broadcast/multicast
<http://www.ietf.org/mail-archive/web/manet/current/msg12161.html> 

			*	From: Vikram KAUL

		*	Re: [manet] DLEP and broadcast/multicast
<http://www.ietf.org/mail-archive/web/manet/current/msg12162.html> 

			*	From: A. Riley Eller

		*	Re: [manet] DLEP and broadcast/multicast
<http://www.ietf.org/mail-archive/web/manet/current/msg12176.html> 

			*	From: Vikram KAUL

		*	Re: [manet] DLEP and broadcast/multicast
<http://www.ietf.org/mail-archive/web/manet/current/msg12177.html> 

			*	From: Stan Ratliff

	*	Next by Date: Re: [manet] [Int-area] SMF and

		*	Date
		*	Thread

---

From: "Justin Dean" <[email-masked]>
Date: Wed, 2 Nov 2011 15:37:32 -0400

I will also be in Taipei and am very much looking forward to going over
DLEP.  And to echo Bob, thanks for the heads up on modemlpa gives me time to
read and absorb it before the meeting.

Justin

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Cole, Robert G USA CIV (US)
> Sent: Wednesday, November 02, 2011 3:39 PM
> To: Ivancic, William D. (GRC-RHN0); Stan Ratliff
> Cc: [email-masked]
> Thanks for the heads up on DLEP light. How do these relate to our NHDP
> for one and two hop discovery?
> 
> Bob
> 
> that are multiple hops away from the modem the downlink status.  DLEP
> is really for directly connected devices and just didn't seem to be
> able to handle the
> security devices and application layer networking such as
> Delay/Disruption Tolerant Networking.
> 
> We sent this draft to mobopts as this draft addresses "examination of
> the feasibility of generic mechanisms that allow tighter integration of
> the link layer with the IP layer for improving handover performance" as
> well as allowing applications and routing protocols and even new
> concepts such as disruption/delay tolerant networking (DTN) to have
> some clue of network connectivity and link layer characteristics even
> if the host / router / forwarding agent is multiple hops away from the
> modem.
> 
> - Will
> 
> 
> essentially
> > two
> protocols working that essentially do the same thing. We'll need to
> resolve that.
> >
> 2).
> Unfortunately, I won't be able to get another draft posted before this
> one expires (work pressures), but I promise - an updated draft is

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Thu, 3 Nov 2011 10:51:54 -0500

Justin,

I will NOT be in Taipei.   If you have some type of informal meeting and I can be available (at some awful hour being 12 hours difference or so) I would try and participate.

I might make Paris.

Regardless, one thing that modemlpa does is simply multicast (or unicast) information out to listeners.  There is no client/server relationship.  

- Will