Re: Comments on draft-ietf-rserpool-asap-04.txt
Qiaobing Xie <Qiaobing.Xie <at> Motorola.com>
2002-09-27 21:39:12 GMT
> Hmmmm, OK, it seems that we agree that an ENRP server SHOULD always
> listen on a TCP and SCTP socket, MAY listen on a UDP multicast socket and always
> uses the same port number. What is new (for me) that the response of the
> SERVER_HUNT is sent by TCP or SCTP. This would mean that the NS is a client. Hmm.
> In my understanding the SERVER_HUNT was sent as UDP unicast. Thats all. The PU
> has to set up an SCTP assoc or TCP connection for doing name resolution requests.
> If mutlicast is not available, the first step (send UDP multicast, receive UDP
> unicasr) is omitted. For security this would be simpler, because in both case
> would the PU start the communication.
I sense that more clarifications are needed for server hunt in both enrp
and asap. Let's lay it out with more details here (assuming the
to-be-defined well known asap port is 5151 for both TCP and SCTP, and
the well-known IP m-cast channel for asap is 244.1.2.3):
After an ENRP server (aka NS) finishes its initialization and
enters the service, it:
1) MUST listen for incoming asap messages on SCTP/port=5151;
2) optionally also listens for incoming asap messages on TCP/port=5151;
3) optionally join m-cast group 244.1.2.3 (via a UDP or TCP socket, but
this shouldn't matter) for incoming m-cast asap messages.
If the NS choice not to support TCP-based PUs, it won't do 2).
Similarly, if m-cast is not available at the NS site, it won't do 3).
Now let's move on to the PE/PU side.