We don't need reserved port numbers with IANA for that.

As I said before, any number is fine if the implementation can remember which 
one it had last.

We can add the API to IoTivity for the implementation to provide a hint on 
which port number to use. This assumes that the API can store the port number 
it last had. As a hint, if the port number isn't available, the implementation 
will just choose another.

Em ter?a-feira, 19 de abril de 2016, ?s 02:54:42 PDT, ??? escreveu:
> Hi Thiago,
> I assume DHCP will work most of cases currently.
> This proposal does not intend to cover every case but just maximize the hit
> ratio. BR Uze Choi
> 
> 
> ---?? ???---
> ??? : Thiago Macieira/thiago.macieira at intel.com
> ???? : 2016/04/19 11:44 (GMT+09:00)
> ?? : Re: [cftg] RE: OCF IANA Port Number Assignment
> 
> 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


-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

Reply via email to