Hi Uze, I don't think reserving port numbers for the server instance is the right approach to mitigate the issue raised here.
A platform can have several IoTivity instances running independently (one cannot assume SO_REUSEADDR) is applied to socket options, not assume that it is permitted/supported on the platform. That means that a sufficient range would have to be allotted. Also, device presence should allow for a client to detect and perform a rediscovery of a server under these circumstances. It seems to be that locally assigned port by the OS is the best choice. Thanks, Mats > On Apr 18, 2016, at 19:44, Thiago Macieira <thiago.macieira at intel.com> > wrote: > > Hi Uze > > I don't see how reserving port numbers will help us in that scenario. > > If a device is able to keep its IP address and port number, then we don't > need > reserved port numbers: any number is fine. If a device isn't able to keep the > address or the port number, then rediscovery is necessary and any port number > is also fine. > > I'll also claim that having a finite range is harmful because it limits us to > a > certain number of instances running on a given IP address. > > Moreover, please note that IPv6 with privacy extensions enabled, it's very > likely that the device's IP address will change after a reboot (it's possible > to retain the information and resume using a random IP if it's still valid > after a reboot, but it's not required. Linux doesn't implement that, for > example). With IPv4, it's even worse since the decision is taken out of the > device's hands completely and relies on the DHCP server provisioning with the > same address. > >> Em ter?a-feira, 19 de abril de 2016, ?s 02:06:40 PDT, ??? escreveu: >> Currently IoTivity use random number, but this logic causes issue from >> client application , which eventually requires finding the server device >> again when target reboot. As far as I remember Thiago also understood this >> requirement before. Discussion was not for undiscoverable service. >> >> >> ---?? ???--- >> ??? : Thiago Macieira/thiago.macieira at intel.com >> ???? : 2016/04/19 00:38 (GMT+09:00) >> ?? : Re: [cftg] RE: OCF IANA Port Number Assignment >> >> IoTivity decided to use random port numbers and there has been no discussion >> to change that. The port number is assigned by the OS from any of the non- >> privileged unused port numbers at the time the application starts. >> >> We had an inconclusive discussion about port number for services that aren't >> discoverable, but instead are well-known, like cloud services. That >> discussion didn't finish, so there are no conclusions yet. >> >> But for now, we don't need assigned port numbers. >> >> Em segunda-feira, 18 de abril de 2016, ?s 16:12:27 PDT, ???(Uze Choi) >> >> escreveu: >>> Hi Ravi, >>> >>> >>> >>> Ok, I got it, this could be IoTivity specific issue. >>> >>> >>> >>> During reboot the device. most of case, IP will be same in the local >>> network. >>> >>> For the same port, there are two approaches. >>> >>> >>> >>> One, is to store the previously assigned port. >>> >>> The other is to use registered port. >>> >>> >>> >>> IoTivity have decided to use the registered port for several reasons. >>> (second option) >>> >>> In this case I?m not sure to define the port name with ocf naming. >>> >>> >>> >>> BR, Uze Choi >>> >>> From: cftg at openconnectivity.org [mailto:cftg at openconnectivity.org] On >>> Behalf Of Subramaniam, Ravi Sent: Monday, April 18, 2016 3:38 PM >>> To: uzchoi at samsung.com; 'Michael Koster'; 'Aja Murray'; >>> iotivity-dev at lists.iotivity.org; cftg at openconnectivity.org Subject: >>> RE: >>> [cftg] RE: OCF IANA Port Number Assignment >>> >>> >>> >>> Hi Uze, >>> >>> >>> >>> I recognize that each stack for multiple instances may require an >>> individual port (each instance does not always need to have individual >>> port but let?s assume they do). I don?t understand why these need to be >>> registered ports. Also what happens in a situation where there are more >>> than the 5 instances (wouldn?t we have issues because we would have run >>> out of reserved ports?) >>> >>> >>> >>> From what I can understand from reading the thread is that >>> >>> >>> >>> a) There are multiple stacks on a device ? each stack has its own IP >>> address and port. >>> >>> b) The URIs are tied to the IP address/port. >>> >>> c) So when the stack reboots and gets a new IP address, the URI that the >>> Client has does not work because the client has the URI associated with >>> the >>> older IP address. >>> >>> d) So the Client has to do resource discovery again and this causes all >>> the OIC Devices to respond and Client has to process all the responses to >>> get the new URIs for this Client. >>> >>> >>> >>> Did I understand the issue correctly? If this is the objective then there >>> may be other ways to solve this ?same objective?. If I have misunderstood, >>> could you try explaining again? >>> >>> >>> >>> Ravi >>> >>> >>> >>> From: cftg at openconnectivity.org [mailto:cftg at openconnectivity.org] On >>> Behalf Of ???(Uze Choi) Sent: Sunday, April 17, 2016 11:17 PM >>> To: Subramaniam, Ravi <ravi.subramaniam at intel.com>; 'Michael Koster' >>> <michael.koster at smartthings.com>; 'Aja Murray' <amurray at vtmgroup.com>; >>> iotivity-dev at lists.iotivity.org; cftg at openconnectivity.org Subject: >>> RE: >>> [cftg] RE: OCF IANA Port Number Assignment >>> >>> >>> >>> Hi Ravi >>> >>> Could you clarify your declaration of ?same objective?? >>> >>> This is proposed for multiple IoTivity instance(stack)s in a single >>> device. >>> Each stack needs to assign individual port. >>> >>> BR, Uze Choi >>> >>> From: cftg at openconnectivity.org [mailto:cftg at openconnectivity.org] On >>> Behalf Of Subramaniam, Ravi Sent: Monday, April 18, 2016 3:08 PM >>> To: uzchoi at samsung.com; 'Michael Koster'; 'Aja Murray'; >>> iotivity-dev at lists.iotivity.org; cftg at openconnectivity.org Cc: '???'; >>> '??'; >>> '????'; '???'; '???'; '???'; '???'; rami.jung at samsung.com Subject: RE: >>> [cftg] RE: OCF IANA Port Number Assignment >>> >>> >>> >>> Hi Uze, >>> >>> >>> >>> Shouldn?t we explore other ways of achieving the same objective? I may >>> need >>> to understand the details better .. but this multiple reserved ports use >>> seems rather heavy. >>> >>> >>> >>> The idea of using only fixed Device ID in the URI as in the OIC URI and >>> resolving to endpoints in the transport layer was meant to solve this very >>> problem (multiple OIC Devices or stack instances on a single platform). In >>> addition, for the case where there are multiple OIC Device from a single >>> IP/port, the device ID in the URI is used to select the right OIC Device. >>> >>> >>> >>> Ravi >>> >>> >>> >>> From: cftg at openconnectivity.org [mailto:cftg at openconnectivity.org] On >>> Behalf Of ???(Uze Choi) Sent: Sunday, April 17, 2016 10:46 PM >>> To: 'Michael Koster' <michael.koster at smartthings.com>; 'Aja Murray' >>> <amurray at vtmgroup.com>; iotivity-dev at lists.iotivity.org; >>> cftg at openconnectivity.org Cc: '???' <jinchoe at samsung.com>; '??' >>> <ashok.channa at samsung.com>; '????' <markus.jung at samsung.com>; '???' >>> <junghyun.oh at samsung.com>; '???' <jjack.lee at samsung.com>; '???' >>> <soohong.park at samsung.com>; '???' <jinguk.jeong at samsung.com>; >>> rami.jung at samsung.com Subject: [cftg] RE: OCF IANA Port Number Assignment >>> >>> >>> >>> Hi Michael, >>> >>> >>> >>> Let me extend the discussion channel into Core TG and IoTivity. This >>> sounds >>> related with specification also. >>> >>> >>> >>> Michael, >>> >>> I understand why we separate the port for secure and non-secure channel. >>> >>> However, we need to avoid the consecutive port number from non-secure port >>> to secure port as follows. >>> >>> From IoTivity start, stack will internally assign the port number by +1 >>> increasing if port is already occupied. >>> >>> So that port 4380 is already occupied in the non-secure mode, then stack >>> will assign the port 4381 which will cause conflict with port ?4381 UDP - >>> ocf-coaps-1? >>> >>> Please update the final port proposal. >>> >>> >>> >>> Proposal >>> >>> port 4380 UDP - ocf-coap-1 >>> >>> port 4380 TCP - ocf-coap-1 >>> >>> port 4381 UDP - ocf-coap-2 >>> >>> port 4381 TCP - ocf-coap-2 >>> >>> >>> >>> port 7380 UDP - ocf-coaps-1 (7380 is arbitrary number, please assign >>> appropriate one.) >>> >>> port 7380 TCP - ocf-coaps-1 >>> >>> port 7381 UDP - ocf-coaps-2 >>> >>> port 7381 TCP - ocf-coaps-2 >>> >>> (more..port). >>> >>> >>> >>> ?We may need to justify why we need so many ports.? >>> >>> ? Should we describe why this is required? >>> >>> >>> >>> Ashok, >>> >>> I?ll create on the issue on Jira once port proposal is updated from >>> Michael. >>> >>> Please handle it. >>> >>> From the CA stack please check whether it is possible to assign the port >>> incrementally with separation between secure port and non-secure port. >>> >>> >>> >>> BR, Uze Choi >>> >>> From: Michael Koster [mailto:michael.koster at smartthings.com] >>> Sent: Tuesday, March 01, 2016 7:50 AM >>> To: Aja Murray >>> Cc: ???; ??; ????; ???; ???; ???; ???; uzchoi at samsung.com >>> Subject: Re: Introducing Uze Choi - IANA Port Number Assignment >>> >>> >>> >>> Thanks! >>> >>> >>> >>> There are no legal obligations and there is no cost. We should get >>> consensus on what we want to do, so it would be great if OSWG and SWG >>> agree on the registration. >>> >>> >>> >>> I guess my question is if we really need 5 ports for the same service. >>> IESG >>> makes it clear that IP endpoints are expected to multiplex users of a >>> service on a port. I understand we want multiple service *instances* and >>> each to have it's own port. >>> >>> >>> >>> I would think we would allocate one non-secure port for testing but mostly >>> would need secure ports. I would propose to reserve one port each TCP and >>> UDP for non-secure coap, and the other ports for secure coaps on both UDP >>> and TCP. By doing this we are actually requesting up to 10 ports and >>> submitting 10 forms. We may need to justify why we need so many ports. >>> >>> >>> >>> So specifically: >>> >>> >>> >>> port 4380 UDP - ocf-coap >>> >>> port 4380 TCP - ocf-coap >>> >>> port 4381 UDP - ocf-coaps-1 >>> >>> port 4381 TCP - ocf-coaps-1 >>> >>> port 4382 UDP - ocf-coaps-2 >>> >>> port 4382 TCP - ocf-coaps-2 >>> >>> (and of we need more) >>> >>> port 4383 UDP - ocf-coaps-3 >>> >>> port 4383 TCP - ocf-coaps-3 >>> >>> port 4384 UDP - ocf-coaps-4 >>> >>> port 4384 TCP - ocf-coaps-4 >>> >>> >>> >>> Is this what is intended? Do we need to make a request to review this? >>> >>> >>> >>> Michael >>> >>> >>> >>> >>> >>> On Feb 29, 2016, at 2:15 PM, Aja Murray <amurray at vtmgroup.com> wrote: >>> >>> >>> >>> Hi Michael, >>> >>> >>> >>> I would still like to know if there is any cost or legal implications for >>> reserving these port numbers, and if we need OSWG and/or SWG approval >>> before deciding on them. >>> >>> >>> >>> When the time comes, here is the address information you requested for >>> OCF: >>> >>> Mailing Address: 3855 SW 153rd Drive, Beaverton, OR 97003, USA >>> >>> Email: <mailto:admin at openinterconnect.org> admin at openinterconnect.org >>> >>> >>> >>> Regards, >>> >>> Aja >>> >>> >>> >>> From: Michael Koster [ <mailto:michael.koster at smartthings.com> >>> mailto:michael.koster at smartthings.com] Sent: Saturday, February 27, 2016 >>> 5:25 PM >>> To: <mailto:uzchoi at samsung.com> uzchoi at samsung.com >>> Cc: ??? < <mailto:jinchoe at samsung.com> jinchoe at samsung.com>; ?? < >>> <mailto:ashok.channa at samsung.com> ashok.channa at samsung.com>; ???? < >>> <mailto:markus.jung at samsung.com> markus.jung at samsung.com>; ??? < >>> <mailto:junghyun.oh at samsung.com> junghyun.oh at samsung.com>; ??? < >>> <mailto:jjack.lee at samsung.com> jjack.lee at samsung.com>; Aja Murray < >>> <mailto:amurray at vtmgroup.com> amurray at vtmgroup.com>; ??? < >>> <mailto:soohong.park at samsung.com> soohong.park at samsung.com>; ??? < >>> <mailto:jinguk.jeong at samsung.com> jinguk.jeong at samsung.com> Subject: >>> Re: >>> Introducing Uze Choi - IANA Port Number Assignment >>> >>> >>> >>> OK, I have a couple of questions before I fill out the requests. >>> >>> >>> >>> I can make the OCF organization the assignee, and I can be the contact. I >>> just need an address and email for OCF. >>> >>> >>> >>> There are no contiguous blocks of unassigned port numbers below 4380-4388. >>> Does it matter what the port numbers are? >>> >>> >>> >>> Also, IANA won't assign a block of ports, each port needs to have a >>> service >>> name. >>> >>> >>> >>> Why 5 ports? How should we construct the service names? I assume they are >>> instances of the same OCF CoAP service, so is it simply >>> ocf-coap-instance-1, ocf-coap-instance-2, etc? >>> >>> >>> >>> Are multiple devices distinguished by the device ID? If the URIs are >>> discinct between devices, do we need more than one port? >>> >>> >>> >>> Ports are now assigned for use by one or more transport protocols. Will we >>> need to assign TCP use of these ports as well? >>> >>> >>> >>> Do we need non-secure ports in this new range? >>> >>> >>> >>> Michael >>> >>> >>> >>> On Feb 24, 2016, at 5:26 PM, ??? < <mailto:uzchoi at samsung.com> >>> uzchoi at samsung.com> wrote: >>> >>> >>> >>> Is it standard stuff or open source stuff otherwise common stuff? >>> >>> Daniel and Jin any opinion? >>> >>> BR Uze Choi >>> >>> >>> >>> ---?? ???--- >>> ??? : Michael <mailto:Koster/michael.koster at smartthings.com> >>> Koster/michael.koster at smartthings.com ???? : 2016/02/24 22:57 (GMT+09:00) >>> ?? : Re: Introducing Uze Choi >>> >>> We will require an assignee and a contact for these. I can be the contact, >>> to answer questions from IANA and track the process. >>> >>> >>> >>> However, the assignee should probably be a persistent administrative role >>> at OCF. >>> >>> >>> >>> Aja, who should be the OCF assignee when we register identifiers like port >>> numbers and content formats with bodies like IANA and IETF? >>> >>> >>> >>> Thanks, >>> >>> >>> >>> Michael >>> >>> >>> >>> >>> >>> On Feb 24, 2016, at 5:39 AM, Michael Koster < >>> <mailto:michael.koster at smartthings.com> michael.koster at >>> smartthings.com> >>> wrote: >>> >>> >>> >>> Hi Uze, >>> >>> >>> >>> Sorry, I was checking into some procedural questions. It will require a >>> separate application for each port and there is a review process. I will >>> start the process today. >>> >>> >>> >>> Best regards, >>> >>> >>> >>> Michael >>> >>> >>> >>> >>> >>> On Feb 24, 2016, at 2:07 AM, ??????(Uze Choi) < >>> <mailto:uzchoi at samsung.com> >>> uzchoi at samsung.com> wrote: >>> >>> >>> >>> Michael, >>> >>> We should finalize the code by this week for this upcoming IoTivity >>> release. Could you check it ASAP if possible? >>> >>> BR, Uze Choi >>> >>> From: ???(Uze Choi) [ <mailto:uzchoi at samsung.com> >>> mailto:uzchoi at samsung.com] Sent: Tuesday, February 23, 2016 8:50 PM >>> To: ' <mailto:jinchoe at samsung.com> jinchoe at samsung.com'; ' >>> <mailto:michael.koster at smartthings.com> michael.koster at >>> smartthings.com' >>> Cc: >>> ASHOKBABU CHANNA ( <mailto:ashok.channa at samsung.com> >>> ashok.channa at samsung.com); <mailto:markus.jung at samsung.com> >>> markus.jung at samsung.com; ??? ( <mailto:junghyun.oh at samsung.com> >>> junghyun.oh at samsung.com); ???( <mailto:jjack.lee at samsung.com> >>> jjack.lee at samsung.com) Subject: RE: Introducing Uze Choi >>> >>> >>> >>> Hi Michael, >>> >>> As Jin explained, I need to register the port region for UDP unicast port >>> for OIC(IoTivity) Server as follows. >>> >>> There are some requirement for port assignment for OIC communication to >>> IANA. >>> >>> As a UDP multicast socket, IoTivity uses Port 5683 which is CoAP default >>> port registered in IANA, >>> >>> and for unicast socket, OIC stack(IoTivity) randomly assign the port from >>> the system currently. >>> >>> Sometime, single device can launch multiple OIC instances which requires >>> multiple unicast sockets assignment. (multicast socket is shared commonly) >>> >>> However, this random port assignment policy makes the OIC client >>> re-discover whenever OIC server restart, which is very cumbersome task. >>> >>> >>> >>> I propose the default UDP unicast port for OIC for example 3333~3337, OIC >>> server assign the port from 3333 always. >>> >>> I heard that you are the person to know how to register the port into IANA >>> and understand the related context. >>> >>> Could you help me for this task? >>> >>> BR, Uze Choi >>> >>> From: ??? [ <mailto:jinchoe at samsung.com> mailto:jinchoe at samsung.com] >>> Sent: Tuesday, February 23, 2016 7:45 PM >>> To: ???; <mailto:michael.koster at smartthings.com> >>> michael.koster at smartthings.com Subject: Introducing Uze Choi >>> >>> >>> >>> Michael >>> >>> >>> >>> Let me introduce my colleague Uze Choi >>> >>> >>> >>> Uze Choi >>> >>> <mailto:uzchoi at samsung.com> uzchoi at samsung.com >>> >>> >>> >>> who belongs to SWG (Software Center) & >>> >>> is a (?THE) core member of Samsung IoTivity activity. >>> >>> >>> >>> He contacted me with an issue >>> >>> & I recommended to contact you in turn. >>> >>> >>> >>> In short he has in mind >>> >>> allocating certain UDP port numbers (maybe 5) >>> >>> for exclusive CoAP or OIC usage >>> >>> because of the following. >>> >>> >>> >>> One physical platform may have multiple (logical) OIC devices >>> >>> (i.e. IoTivity instance), then for unicast CoAP message, >>> >>> a way for URI to differentiate each instance is required. >>> >>> >>> >>> Right now IoTivity uses different port number for different instance >>> >>> but due to dynamic nature of port number assignment, >>> >>> upon rebooting, sender may forget the receiver's port number >>> >>> & have to find it again. >>> >>> >>> >>> It would help to assign a certain block of UPD port number for such usage. >>> >>> We may ask IANA to allocate 5 UPD port numbers exclusively for CoAP or OIC >>> usage. >>> >>> >>> >>> I recommended Uze Choi to ask you, Samsung IETF expert, >>> >>> whether the approach is feasible & >>> >>> if so, how to proceed in IETF & IANA. >>> >>> >>> >>> He will send you a mail with more detail. >>> >>> >>> >>> Thanks in advance for your kind consideration. >>> >>> >>> >>> best regards >>> >>> >>> >>> JinHyeock >>> >>> >>> >>> >>> >>> >>> <image001.jpg> >>> >>> >>> >>> >>> >>> <~WRD174.jpg> >> >> -- >> Thiago Macieira - thiago.macieira (AT) intel.com >> Software Architect - Intel Open Source Technology Center > > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center >
