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
