MyeongGi Jeong, I have read the wiki article on routing, and I think I understand what you are trying to do. I agree that this capability will be a valuable addition to OIC in general and IoTivity in particular. I have several comments. Rather than mark up your well written Wiki page, I will provide them here.
1. This capability would be better handled by a stand-alone router. Routing is a complicated process, and adding that process to the IoTivity stack would compromise both. An optimized ?IoTivity router? would likely be about the same size as the extra code needed to make the IoTivity stack act as a router. 2. The IoTivity stack must function in a variety of environments, including client, server, normal gateway, etc., and it is already a compromise among those capabilities. I believe our goal should be to make the IoTivity stack as small and efficient as possible, and I believe adding routing to it will make our job harder. 3. A stand-alone router could be made very capable without burdening the IoTivity stack. It would need parts of the CA layer in order to do its job. Specifically, it would need access to the network adapters and the code that multiplexes them. (I don?t think it needs RI layer or the upper layers of CA, as we shall see.) 4. Going forward, I believe all uses of IoTivity will need to be secure. I didn?t see any mention of security in the routing proposal, but I did see weaknesses with respect to security which will require some rethinking. More on that below. 5. I believe the attempt to handle routing within the CoAP framework will create problems. Among the problems is that doing so requires that the routed CoAP messages will need to be decrypted and encrypted at each gateway. This requires establishing separate trusted relations with every intermediate node, which adds considerable overhead, and results in lower overall security, as each intermediate node becomes an attack surface. 6. Network routing is almost always best handled out-of-band. I don?t think this needs to be a CoAP issue. While we have agreed that resource messaging will be handled with CoAP protocol, there is no requirement that all messaging done by IoTivity use CoAP. (For example, video streaming over CoAP would be problematical.) 7. I believe a better security solution would be to have out of band messages that carry, when appropriate, encrypted CoAP resource messages. The encrypted CoAP resource messages would be between the original client and the ultimate server, requiring only one encryption session to communicate between them. 8. Of course, this might leave the routing itself vulnerable to exploit, so a separate decision can be made to encrypt the out-of-band messages, and that would involve only one shared encryption session between each pair of nodes that could be used by any number of resource routes and not compromise them. I?m not convinced that we need to secure the routings as long as the endpoints are secured end-to-end. I will defer that issue to better security minds. 9. I am responding to this proposal because of an apparent need for network addressing in the CAGetNetworkInformation calls for each network adapter, specifically the IP Adapter. In writing the new IP Adapter, I eliminated address information from the CAGetNetworkInformation, and you feel that the address information is needed to make the router work. I want to assure you that the necessary information is available, but we need to think about it differently. 10. With the addition of IPv6, the nature and usage of IP addresses changes considerably. This is important because long term usage of IoTivity will depend on IPv6, to the extent that some capabilities may not even remain available on IPv4. A big issue is that while an interface typically has one IPv4 address (thought it can have more), it can have any number of IPv6 addresses. In industrial networks a network interface may have a dozen or more IPv6 addresses. Thus, IP addresses lose their usefulness in identifying and selecting interfaces. The use of IPv4 addresses to identify an interface is an artifact of IPv4 addressing that we need to let go of. 11. The current CAGetNetworkInformation call returns the name of the interface, which is really all you need to route a message. However, the IP Adapter currently provides no capability for using the interface name to help route a message. Thiago and I have discussed that capability, and agree that it is needed, for reasons other than the Routing Manager. Since that capability has not been implemented, it can be chosen to best support routing. 12. I will point out here that network interface selection referred to in the previous item is only needed for discovery. Once a route has been established, the routing information consists of IP addresses, which implicitly contain interface information and can be used by the current IP Adapter to do the required routing by letting the powerful IP network stack do the hard work of routing. In summary, here is what I hope you take away from my comments: ? You need to rework the routing proposal to make it work with IoTivity security requirements. ? I hope the reworked proposal will work as an optimized stand-alone router, without burdening the IoTivity stack. ? I need to add the planned capability to direct discovery to specific network interfaces using the interface name. (It?s not much work.) ? The IP Adapter will be able to support the Routing Manager, with only the addition of interface selection. John Light Intel OTC OIC Development From: ??? [mailto:[email protected]] Sent: Thursday, July 23, 2015 12:35 AM To: Light, John J; iotivity-dev at lists.iotivity.org Subject: Re: RE: Re: [dev] CAGetNetworkInformation() function does not work John Light. If you would have attended dc_tg cc or checked wiki pages, it would have not a news for you. We described in several cc's about this new feature. Please check routing manager feature via https://wiki.iotivity.org/routing_through_heterogeneous_transports and raise your comments in @ JIRA https://jira.iotivity.org/browse/IOT-565. Also source code available in routing_manager branch in IoTivity. We expected previous source to work as it is when new feature is added but it?s not with IPV6. Different strategies are followed when source code is pushed based on individual preferences. If it is not possible to get any required information from IPV6, we will keep routing manger limited among IPv4, BT and BLE. Regards, Best Regards, --- MyeongGi Jeong Senior Engineer, Software Architect Software R&D Center, Samsung Electronics Co., Ltd. +82-10-3328-1130 ------- Original Message ------- Sender : Light, John J<john.j.light at intel.com<mailto:john.j.light at intel.com>> Date : 2015-07-23 00:17 (GMT+09:00) Title : RE: Re: [dev] CAGetNetworkInformation() function does not work MyeongGi Jeong, I believe I hear you saying that other parts of IoTivity than the RI layer use the CA layer. This is news to me, and I suspect it is news to others. I believe I have heard others say that the IoTivity stack should only be used through the official C and C++ APIs. I am not familiar with the Routing Manager, and its requirements were never on the table for the development of the new IP Adapter. Furthermore, I don?t understand how getting local addresses allows or enables any sort of routing. Please direct me to documentation of what the Routing Manager does. Also please direct me to where the Routing Manager resides. I can?t find the word Routing in the source tree. If it is a planned feature, please point me at Wiki or JIRA postings describing it. I suspect that if the Routing Manager expects to benefit from the address information provided previously, its design needs reconsideration. Since addressing for IPv6 is substantially different than that for IPv4, I suspect the Routing Manager will require much more/different information than was provided previously in order to support IPv6. Once I find out what a Routing Manager does, I will be glad to work with you on a solution that meets IoTivity?s need to support both IPv4 and IPv6. John Light Intel OTC OIC Development From: ??? [mailto:[email protected]] Sent: Tuesday, July 21, 2015 10:05 PM To: Light, John J; ???; iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> Subject: Re: Re: [dev] CAGetNetworkInformation() function does not work Hi, John. We are not sure why you are saying unwise and unnecessary. It?s up to the API user to use any internal APIs. Currently Routing manager requires the GertNetworkInformation to know the available networks and route the packet. The main subject of the mail is because of your changes, this API is not working. Instead of resolving, questioning the API usability is unreasonable. As its been reproduced because of your changes, we are trying get clarification. If you cannot modify, please let us know. Only Application devlopers required to use C or C++ APIs. Any feature contributors can use internal APIs and any feature can have unit test cases and samples to make sure all units are functional. If you feel an internal API is unnecessary, please raise the issue during the biweekly CC or through the dev-mailing list before you changes. Thanks. Best Regards, --- MyeongGi Jeong Senior Engineer, Software Architect Software R&D Center, Samsung Electronics Co., Ltd. +82-10-3328-1130 ------- Original Message ------- Sender : Light, John J<john.j.light at intel.com<mailto:john.j.light at intel.com>> Date : 2015-07-22 00:09 (GMT+09:00) Title : Re: [dev] CAGetNetworkInformation() function does not work Hyuna Jo, Please orient the tests to the two IoTivity APIs: C and C++. The stack should not add code just for obsolete unit tests. We must drive the stack to smaller and smaller form factors, eliminating unnecessary code. The request you make does not generalize, as the IP Adapter network interface code uses mechanisms such as SIOCGIFCONF which do not supply equivalent IPv6 addresses. Thus we need to generalize the testing to support this. As you suggest, the tests can be done using discovery, which allows testing of the discovery mechanism as well. I believe it is unnecessary and unwise to continue thinking of the CA as a separate API. Our path to simplification will necessarily involve higher integration between the CA and RI layers, and I expect the CA ?API? to disappear shortly. So I don?t think adding code whose only purpose is to enable testing is appropriate. John Light Intel OTC OIC Development From: ??? [mailto:[email protected]] Sent: Tuesday, July 21, 2015 1:53 AM To: Light, John J; iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> Subject: RE: [dev] CAGetNetworkInformation() function does not work Hi, John CA Sample was implemented to test CA API directly. we have to know the ip address and port number of the remote device to create CAEndpoint_t object. and we used CAGetNetworkInformation() function to get local network information. of course we can get network information of remote device through multicast message. But that process is unnecessary in CA sample. We should test all CA API directly. In addition, multicast is not supported on arduino platform. because arduino wifi shield can have one connection. so we cannot test all CA API including CASendRequest, CASendResponse, CASendNotification, if there is no network information. Therefore, more network information should be provided by using CAGetNetworkInformation() function. Regards, Hyuna Jo ------- Original Message ------- Sender : Light, John J<john.j.light at intel.com<mailto:john.j.light at intel.com>> Date : 2015-07-21 00:51 (GMT+09:00) Title : RE: [dev] CAGetNetworkInformation() function does not work Hyuna Jo, The only API?s I?m familiar with are the IoTivity C API and the IoTivity C++ API. The Connectivity Abstraction is an implementation detail of the C stack. Since CAGetNetworkInformation doesn?t currently support any features at the C or C++ API level, it is low priority. I intended for it to continue working, as it may be useful in the future, but it is possible that it may not work as it did before. Currently, the only anticipated use for CAGetNetworkInformation is to allow application selection of interfaces for multicasting. For that use, only the information provided is necessary. If you feel more information is needed for some other purpose, please describe the intended use case. I know the original CAGetNetworkInformation provided more information, but that information wasn?t used anywhere except in unit tests of the function. The simplified IP adapter doesn?t need the extra information, so it is not currently provided. When you justify the additional information with a valid use case, additional information can be provided. In the meantime, let?s work at making IoTivity smaller and easier to maintain. John Light Intel OTC OIC Development From: ??? [mailto:[email protected]] Sent: Monday, July 20, 2015 3:52 AM To: iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org>; Light, John J Subject: [dev] CAGetNetworkInformation() function does not work Hi, John Light I have taken the latest master code but I have some problems runnings the CA sample. I'm trying to use CAGetNetworkInformation() function to get local network information. but it looks like that it does not work well. I cannot get the ip address and port information from CAGetNetworkInformation function. currently, CAGetNetworkInformation function returns network interface name only. why did you change the code to return interface name instead of address and fixed the port number with 0? Without the ip address and port number information, ca sample can not be executed well on Linux/Tizen/Android/Arduino platform. Please help me to resolve this issues. Regards, Hyuna Jo [http://mail.naver.com/readReceipt/notify/?img=Lr%2B%2FBX0mWrKXMrtXMomsKApoFAUqpzpvpAi4K6tdK6UZKApvpoJgMX%2B0Mog%2F74lR74lcWNFlbX30WLloWrdQar0T%2Bz0r1B3l7630%2BvIn1BFdbZlGWX3G%2B40dDLlTb4b%3D.gif] [cid:image001.gif at 01D0C5EE.BD421FA0] [http://ext.samsung.net/mailcheck/SeenTimeChecker?do=0fa18573320d6211ae84b436bb78d64e8342742767503050032aa89e99be1a3e738ed17e7639ce1f641b1a8c451b073656239170f5eb4b5c326bbdfb2ea96a2fcf878f9a26ce15a0] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150724/4885ddab/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 13168 bytes Desc: image001.gif URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150724/4885ddab/attachment.gif>
