Re: [Tsvwg] EndPoint and Association Address conflict

[Jon Grimm <[e-mail]>]

Ivan/All
	
	I think something that needs to come out of this discussion are
scenarios and mandatory behavior in those scenarios (or why flexibility
is allowed if not mandatory behavior).  Its a little disturbing that a
similar 'what is an endpoint?' discussion seems to pop up again every so
often.  (e.g.bindx discussion last Sept in
ftp://ftp.ietf.org/ietf-mail-archive/tsvwg/2001-09.mail ) and still does
not seem to be completely clear even to those following SCTP closely
over the last year.  


For each of the following scenarios,

1) A new address is to be added an endpoint. (manual) 
2) An address is to be deleted from an endpoint.  (manual)
3) A new NIC/address is configured and an endpoint is bound to all
(auto)
4) An address bound is brought down (no longer available) (auto).   
5) An address bound is brought down for maintenance and then brought
on-line again. (auto)

consider each of the following subcases (assuming multiple associations
under an ep).  

a) All Peers have ADD-IP.  
b) No Peers have ADD-IP.
c) A subset of Peers support ADD-IP.


What happens?  


Another comment:
Dropping down a little bit into the Sockets API for illustration:

Depending on one's interpretation of endpoint, what is the endpoint for
the association of a peeled-off UDP style socket or for that matter an
'accepted' TCP-style socket.  If the strict interpretation of the
endpoint is kept.. wouldn't an ADD-IP on the child sockets (peeled off
or accept TCP) affect the local endpoint of the parent socket?  Or vise
versa, should an ADD-IP on a TCP-style listening socket, affect the
accepted sockets?  If yes, was this expected?  If no, does the original
definition of endpoint still hold?  

Even if each expected behavior does not get spelled it, it would be nice
for the SCTP Sockets API I-D to clarify the relationship between a
socket and an endpoint, so implementors can at least infer what the
intended behavior should be.   


Best Regards,
Jon Grimm

[e-mail] wrote:

>         I don't think it is absurd at all. You need to have a group of IP addresses that "go together". Otherwise, how could you know which addresses you should include in the INIT ACK when an INIT chunk hits one of those addresses/port? Or when the user tells you to establish a new association from endpoint X...
> 
>         And the restriction is completely logical... Otherwise, if you receive an INIT going to IPA/PortZ, and that address/port pair is part of two different endpoints, how can you know to which one it goes?
> 
>         As far as I understood from this long thread, Brian, you are saying that it is legal to have endpoint E1: [(IPA, IPB); Port 1024], and endpoint E2: [(IPA, IPC); Port 1024] (please, correct me if I'm wrong). Then, you receive an INIT (or any other chunk, but let's say it is an INIT to make things clearer), from endpoint EZ, going to IPA/Port 1024... Should you include IPA, IPB, or IPA, IPC?... That's why you cannot include the same address/port pair in two different endpoints...
> 
>         In my understanding, an endpoint is basically a port plus some of the host's addresses, and it is mainly used when responding to datagrams that don't go to any established association. It is kind of listener socket... When you receive something whose source/destination address/port is not part of any existing association, then you try to see if that datagram goes or not to any of the endpoint that might be "listening" to the destination address/port of the datagram (our source address/port). If there is any endpoint listening at the port to which the datagram was sent, then you process the datagram (as stated in section 8.4 of RFC 2960).
> 
>         And now, regarding the AddIP issues... Let me show you the way I see all this...
> 
>         In my understanding, when you establish a new association, you start with the "default" set of addresses, i.e., all of the addresses of the endpoint. Later on, you can delete some of those addresses in *some* associations, stopping using them as your source addresses. Also, if the endpoint adds new addresses, then, you can add those addresses to the associations that were created inside that endpoint...
> 
>         Basically, an association created from your endpoint E1, CAN NOT have more addresses than the ones that currently E1 has, but it CAN have less.
> 
>         In the examples given by Randall when you add a new card, I think that you have a problem if you bind to INADDR_ANY... That's because you don't know if the peer supports or not AddIP... If it doesn't, and you are not able to add the new addresses, you might end up receiving an ABORT from you peer if you use the newly added address.
> 
>         So I think that the associations should have knowledge about which addresses they can use as source address, because they might not always be all the addresses of the endpoint to which they belong... :-/
> 
>         And the point is not only that I might not be able to add the address, I might simply not want to do it. If it cost more money to send packets through the new address, then I might not want to use it at all, even though I could...
> 
>         So, associations can (independently) use AddIP extension to delete a source address in any case (except if it is the last one, of course). BUT, associations might only be able to add a new source address if the endpoint is using it. So, in my mind, I make a distinction between adding/deleting an address to/from an endpoint, and adding/deleting an address to/from a particular association... If you add an address to an association using ASCONFs, you MUST previously add it to the endpoint. If you delete an address from an endpoint, you SHOULD try to delete it previously using ASCONFs for all the associations using that source address and belonging to the endpoint to which the address is about to be added (i.e., also using the source address and the source port of the endpoint). I'm not sure if it should be a MUST or a SHOULD. If you are really unplugging the network card, then it doesn't matter since you are not really going to use that address any more either for sen!
 di!
!
ng or receiving. If you are simply doing it because you want to modify the endpoint (but the address is still physically working), then you should take care of what you are doing... :-/
> 
>         Summarizing:
> 
>         - An endpoint can use a subset of the source addresses of the host.
>         - An association, can use a subset of the source addresses of the endpoint to which it belongs.
> 
>         I would very much appreciate comments about this mail...
> 
>         Thanks a lot!
> 
>         BR Iván Arias Rodríguez
>


_______________________________________________
tsvwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tsvwg