Subject: RE: [Rserpool] Data transmission

From: "Gopal Ram (NRC/Boston)" <[email-masked]>
Date: Wed, 25 Jul 2001 07:07:53 -0500

Hello Stewart,
Please see my embedded comments!

>-----Original Message-----
>From: ext Randall Stewart at work 
>[mailto:[email-masked]]
>Sent: Wednesday, July 25, 2001 7:55 AM
>To: Miguel Angel Nieto Jimenez ECE/TL/NA TU-146 Tlf.91.339.4670
>Cc: [email-masked]
>Subject: Re: [Rserpool] Data transmission
>
>
>"Miguel Angel Nieto Jimenez ECE/TL/NA TU-146 Tlf.91.339.4670" wrote:
>> 
>> Hi,
>>    I have some doubts about how data transmission is performed.
>> Are the associations for data transmission between ASAP endpoints
>> or between the ASAP under the PU and the PE? Reading the draft I
>> suppose that is the second one because there is not any ASAP
>> message defined for data transmission. If this is OK, what would
>> happen in the following scenario. Suppose we have two nodes, one
>> has two PU and the other one PE. If both PU want to communicate
>> with the PE there would be only one association. Then, how would
>> be the PUs multiplexed? Should be used different streams? Should
>> be used the SCTP field payloadProtocolId?
>>    When should the association been closed? Can be supposed that
>> is going to be only an answer from the PE?
>> 
>> Miguel
>
>Hi Miguel:
>
>An answer.. or at least I will attempt an answer since I
>am not to sure about your questions :-)
>
>When a PU wants to talk to a PE.. it
>
>1) Asks ENRP where it is.
>2) Gets a list back of PE's that are registered under the
>   name... the list has the IP address/ports. 
>
>3) The PU sets up an association with the PE and sends data
>   directly to the PE with NO ASAP formatting or any intervention.
>
>
>The idea is that ASAP is a SESSION layer and only handles getting
>two endpoints in contact with each other... It does not as such
>get involved in the transport of data... for example it does NOT
>wrap application data messages with some ASAP wrapper.. but instead
>just sends through the data send primitives to the SCTP stack.

I agree that ASAP should not do any thing with the Data which is
application 
specific. But it defeats  a purpose say -  From the above statement,  
any one (not a PU) who knows the transport address 
of PE can directly communicate with  PE there is no need for ENRP.  

>
>Now your question on two PU's and one PE on boxes is quite simple
>
>one PU (PU1) would say have a port 5555 the other PU2
>would have a port say 6666 and our friend the PE that both
>wants to talk to would have a port 8888
>
>So you would end up with an association between
>
>PU1:5555 <----->PE:8888
>and
>PU2:6666 <----->PE:8888
>
>It takes two sets of transport addresses each with a port on
>the respective peer to create an association.. so even
>if PU1 and PU2 are on the same machine the SCTP layer will
>know that it has two assocaiations on both sides based
>on the differences in port numbers.
>
>In a non-multi-homed machine you have the same situation
>as in TCP aka a assocaition is comprised of:
>
>Source Port+Source Address+Destination Port+Destination Address
>
>In a multi homed case it is a bit more complicated and you end up with:
>
>Source Port+[Set of source addresses]+Destination Port+[Set of
>destination addresses]
>
>All comprising one associaition..
>
>
>Hope that helps..
>
>R
>
>
>
>
>
>-- 
>Randall R. Stewart
>[email-masked] 815-342-5222 (cell phone)
>
>_______________________________________________
>rserpool mailing list
>[email-masked]
>http://www.ietf.org/mailman/listinfo/rserpool
>

_______________________________________________
rserpool mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/rserpool

---

From: Randall Stewart at work <[email-masked]>
Date: Wed, 25 Jul 2001 08:54:38 -0500

Comments below :)

> of PE can directly communicate with  PE there is no need for ENRP.

Of course if you know the address you SHOULD be able to NOT use
ENRP and talk to a applicaiton. ENRP provides you

1) The location/port number 
2) Alternate PE's that can be used for redundancy.
3) Dynamic addition and deletion of PE's

If you do decide to bypass the session layer then you loose
the advantages of it... i.e. the fault tolerance/fail-over and
load balancing characteristics of it.. This is ok.. it is
the applications choice.  

The point is to allow maximum flexibility for the application and
yet be able to provide a fault tolerant/session layer service.

R