[Ndn-interest] Broadcast message

[Lixia Zhang]

> On Apr 8, 2017, at 4:20 AM, Aboodi Ahed Hussein Ali <aboodi at student.usm.my> wrote:
> 
> Hi,
> 
> Thank you Lixia for you addition statements, I wrote some notes and a question in your replay based on your statements, kindly, correct me if i wrongly understand the statements.

My comments were not exactly clear to start with.
I just had a quick chat with Alex, he'll get back to you with more specifics.


> 
> From: Lixia Zhang <lixia at cs.ucla.edu>
> Sent: Saturday, April 8, 2017 11:28 AM
> To: Junxiao Shi
> Cc: Aboodi Ahed Hussein Ali; ndn-interest at lists.cs.ucla.edu
> Subject: Re: [Ndn-interest] Broadcast message
>  
> 
>> On Apr 7, 2017, at 3:33 PM, Junxiao Shi <shijunxiao at email.arizona.edu <mailto:shijunxiao at email.arizona.edu>> wrote:
> 
>> 
> 
>> Hi Ahed
> 
>> 
> 
>>> In a network scenario where every node is equipped with IEEE 802.15.4-based NDN:
> 
>>> 1 - Is it possible to send a broadcast message (to send command or to advertise a service) to all the neighbor nodes.
> 
>> Yes, 802.15.4 MAC supports broadcast addressing. NDN packets can be transmitted over broadcast channel.
> 
>> 
> 
>>> 2-  How can I get information on how to structure a broadcast message.
> 
>> The main concern is that 802.15.4’s MTU is 127 octets. You may send regular Interests with NDNLPv2 fragmentation and reassembly, but each Interest would use many lower layer frames.
> 
> 
> Not necessarily, right?  It depends on the size of Interest packets. 
> An Interest packet does not have to be more than 100 bytes, especially if one does not use ascii-encoded names.
> 
>>> 3- I have also read about "extensible command markers" of CCNx which might use "%C1.M.S.neighborhood" to broadcast a message/invoke services (correct me if I am wrong), does NDN has similar extension, and how to do it (a reference or example should help).
> 
>> The NDN equivalent of “extensible command markers” is MarkedComponent <https://redmine.named-data.net/issues/2012>. It’s not yet approved and not implemented.
> 
> 
> Please let me make a modification to the above statement. 
> 
> 1/ marked components are used all the time.  the real questions are how to identify the right types of name components, how many types would be needed
> 
> So that means based on my app I need to identify the right types of name components needed by my app. By types you refer to the service, right?
> 
> 2/ at the moment, all the NDN apps at this time use a name component as a type marker, this offers apps flexibility to define their own marked types, though a less efficient encoding than marked component.
> 
> What are those marked component that have efficient encoding in NDN?
> 
> 3/ my understanding of our current thinking is that we do plan to define marked name component once recurring marked components are identified.
> 
> For example "serv/service-name", the node that broadcast the service needs to know how to construct the "serv/service-name" component and the receiving node needs to know how to parse it. more like defining the app's  marked name component for its service ("serv/service-name").
> 
> Lixia

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20170409/ad4bc342/attachment.html>