Hi Joonghong, Between across network discovery, IoTivity routing component will work. IoTivity already have the routing logic internally. If you build IoTivity with EP=GW then, routing logic will be enabled. Routing will do the discovery forwarding also.
Resource Directory is DNS like solution. OCF Server device can register its address on the RD and client can look up it thru RD for addressing target device. When device register its address on the RD server, it will push address from its network perspective, not considering for other network. Resource Directory is implemented on service/resource-directory, but this looks covering far more than you are seeking. BR, Uze Choi From: [email protected] [mailto:iotivity-dev- bounces at lists.iotivity.org] On Behalf Of ??? Sent: Thursday, June 23, 2016 9:38 AM To: Thiago Macieira; iotivity-dev at lists.iotivity.org Subject: Re: [dev] Testing gateway on IPv6 environment Dear Thiago Macieira and developers, Thank you for being interested in my questions. First of all regarding my network connection, currently layer 3 connections is established with different IPv6 prefixes. So multicast packets from Device 1 can not reach Device 3. Could you let me know more details? (1) Regarding Resource Directory or Bridging, you mean that the role of implementing them is not in IoTivity side. Or let me ask differently, is there no solution currently in IoTivity side to discover among different subnet(prefix) networks? (2) Regarding Routing, I understand your meaning. So it was my confusion because routing(gateway) functions are included in IoTivity 1.1.0. It means that there will be no further support for routing(gateway) functions, right? If you have any good example of Resource Directory or Bridging, could you let me know? If my understandings are wrong, please let me know also. Best regards, Joonghong Park. --------- Original Message --------- Sender : Thiago Macieira <thiago.macieira at intel.com> Date : 2016-06-23 07:06 (GMT+9) Title : Re: [dev] Testing gateway on IPv6 environment On quarta-feira, 22 de junho de 2016 10:33:18 PDT ??? wrote: > Dear developers, > > I'm trying to run IoTivity on three IP devices. > - Device 1 : WiFi > - Device 2 : Both WiFi and Thread > - Device 3 : Thread > > Each device has IPv6 address and IP connections are established each other. > I confirmed using ping6 between Device 1 and Device 3 through Device 2. Hello Joonghong If you can ping6 from one device to another, that means you've got Layer 3 (IP) connectivity between those two devices. That leads me to the conclusion that Device 2 must be working as a Layer 1, Layer 2 or Layer 3 connection (respectively, hub, switch or router). Layer 1 is extremely unlikely. So which one is it: Layer 2 or Layer 3? Or asked differently: are Device 1 and Device 3 in the same network segment? Do they have the same IPv6 prefix? > I would like to route IoTivity packets from Device 1(client) to Device > 3(server) through Device 2(gateway). > Let me give you more information. I need more information on your network to be able to give a better reply. See above. If it's a Layer 2 connection, then all three devices are in the same network segment and they all have the same IPv6 prefix. Same network segment implies "same multicast domain", so anything that Device 2 needs to do falls outside of IoTivity's responsibility. We couldn't help you. Doing it as a Layer 2 is also a violation of Thread recommendations on how to set up your network. If it is a Layer 3 connection, then we have separate network segments, separate multicast domains and different IPv6 prefixes. That means a discovery from either Device 1 or 3 the way we're doing will never reach the other device. But both devices should reach[1] Device 2. To support a network of this manner, you need to make Device 2 behave as a Resource Directory. That is, it needs to act as an intermediary and answer any queries received in one network segment with the information received in the other. It should NOT simply relay queries, as that would be a violation of the Thread recommendations on forwarding of packets, but should instead cache discoveries from the Thread side, at least. Implementing a Resource Directory is not IoTivity's job (not yet, anyway). Your application is the RD, which means you need to write the code for that. [1] modulo bugs. The Thread side requires a realm-local multicast discovery but I don't think we're doing realm-local. > Devices are ARM-based devices, and I'm using SimpleClientServer > applications. (/resources/csdk/stack/samples/linux/) Between two devices, I > tested ocserverbasicops and occlientbasicops then succeeded. For testing > three devices, I used ocrouting between ocserverbasicops and > occlientbasicops. I saw some packets are transferred between ocrouting and > ocserverbasicops through tcpdump, but I'm not sure the packet types or > process. As you can imagine, once occlientbasicops runs I could not get any > discovery result from ocserverbasicops. I'm not sure but I can see some > discovery messages in occlientbasicops device, and these seem to be from > ocrouting device. Routing as currently implemented in IoTivity is a misfeature and will not be standardised. Resource Directory and Bridging are the correct, long-term solutions. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center <http://v70ext.samsung.net/mail/ext/v1/external/status/update?userid=joongho ng.park&do=bWFpbElEPTIwMTYwNjIzMDAzODA2ZXBjbXMycDc1MjZjYTE2YjY5MWY1MDk2ZWQ5M mY0OWFiY2E4ZTg4MiZyZWNpcGllbnRBZGRyZXNzPWlvdGl2aXR5LWRldkBsaXN0cy5pb3Rpdml0e S5vcmc_> -------------- next part -------------- HTML ?????? ??????????????... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160623/0cc5b802/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 33527 bytes Desc: ?????? ?? ????????. URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160623/0cc5b802/attachment.png>
