[Ndn-interest] Broadcast message
aa at cs.ucla.edu
Sun Apr 9 11:22:41 PDT 2017
> On Apr 7, 2017, at 8:31 PM, Lixia Zhang <lixia at cs.ucla.edu> wrote:
>> On Apr 7, 2017, at 5:26 PM, Aboodi Ahed Hussein Ali <aboodi at student.usm.my> wrote:
>> Hi Junxiao,
>> Thanks for clarifying that I should use the broadcast-channel for the MAC layer to broadcast a message and for informing me to consider the frame size when I send the interest. Yet, I still need to know how to advertise a service or send a command to all neighbor nodes. An example of CCNx's Service Naming Conventions is "%C1.serv/", which should be received by all neighbor nodes, where "C1" is the special name component and "serv" is the advertised service.
>> From your answer, I understand that NDN has no service naming conventions" yet like CCNx, any advice, guide or suggestion that might help me do something similar to service naming convention of CCNx or do advertise a service?
> as I mentioned in the prev msg: you could just code a service name like
> given you are playing with it, your code at both ends know how to construct the name and parse it
I think you're misunderstanding the role of the naming conventions. The naming conventions are required when you have multiple applications that wants to inter-operate with a similar goal in mind. Given that you're designing a way you can advertise your service, you just need to define a naming structure for your application (in the future, this can become a convention).
A few things that you want to consider:
- If you want to advertise within a single hop domain, your naming structure should start with "/localhop", ensuring that such interests will not cross 1-hop boundary (see https://redmine.named-data.net/projects/nfd/wiki/ScopeControl <https://redmine.named-data.net/projects/nfd/wiki/ScopeControl> for more information)
- You should include some form of identification of your application in the name, e.g., "/localhop/APP"
- Anything else after that, would be up to you to define. You can put any data as part of the name components, including any binary data (or compressed data) that your application understand how to interpret.
Ideally, you want to design your name so that packets are not fragmented within 802.15.4's MTU. If not possible, you can rely on some form of fragmentation. One option is to implement (use) NDNLPv2 (https://redmine.named-data.net/projects/nfd/wiki/NDNLPv2 <https://redmine.named-data.net/projects/nfd/wiki/NDNLPv2>) or, if NDNLPv2 overhead is not acceptable, you can define an alternative way to do fragmentation. Our NDN-RIOT implementation (https://github.com/named-data-iot/ndn-riot <https://github.com/named-data-iot/ndn-riot>) defines and realizes a more space-efficient way to fragment packets.
>> From: Junxiao Shi <shijunxiao at email.arizona.edu>
>> Sent: Saturday, April 8, 2017 6:33:01 AM
>> To: Aboodi Ahed Hussein Ali
>> Cc: ndn-interest at lists.cs.ucla.edu
>> Subject: Re: [Ndn-interest] Broadcast message
>> 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.
>>> 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. It’s not yet approved and not implemented.
>> Yours, Junxiao
>> Ndn-interest mailing list
>> Ndn-interest at lists.cs.ucla.edu
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 841 bytes
Desc: Message signed with OpenPGP
More information about the Ndn-interest