Subject: RE: [Tsvwg] End point and association Address conflict

From: Tuexen Michael <[email-masked]>
Date: Mon, 29 Apr 2002 10:30:11 +0200

Hi Brian,

if a host A has two IP-addresses IP' and IP'' and two associations
from (IP', Port) to a peer (IP, Port) and (IP'', Port) to the peer
(IP, Port) then 
- host A has two IP-addresses
- there are two end-points (IP', Port), (IP'', Port), each of them
  uses only one IP address available at host A.
This 'splits' (in your terminology) host A into two end points.
The difference between IP addresses of the end point and IP addresses
of the host is also the reason why it is valid to say
- you MUST include all IP address of the end point in the INIT INIT-ACK.
- you include a subset of all addresses of the host in the INIT INIT-ACK.

Best regards
Michael

Michael Tuexen    Tel.:   +49 89 722 47210
Siemens AG        Fax:    +49 89 722 48212
ICN WN CC SE 7    E-mail: [email-masked]

> -----Original Message-----
> From:	Brian F. G. Bidulock [SMTP:[email-masked]]
> Sent:	Monday, April 29, 2002 8:50 AM
> To:	Qiaobing Xie
> Cc:	Balani, Sandeep; 'Qiaobing Xie'; [email-masked]; [email-masked]; Khan, Mohammad; [email-masked]
> Subject:	Re: [Tsvwg] End point and association Address conflict
> 
> Qiaobing,
> 
> Multi-homing is OPTIONAL.  Are you saying that a group of
> associations that are not multi-homed (single IP address
> in INIT), and on different IP addresses for the same host
> is somehow splitting the host into multiple end-points?
> I don't see how this is different than for TCP when the
> host has multiple IP addresses: each connection may be
> from a different IP address...  Please explain.
> 
> --brian
> 
> On Fri, 26 Apr 2002, Qiaobing Xie wrote:
> 
> > 
> > I don't think anything needs to be re-defined. We just need more
> > clarifications. To the implementor, a good add/delete-ip API semantics
> > might help to provide a safeguard against misuses. 
> > 
> > SCTP is different from TCP in that it allows a single endpoint to
> > associate with multiple peers (the "fan-out" config). But no matter how
> > many peers the endpoint is concurrently connected to, logically it is
> > _still_ a single endpoint. 
> > 
> > With this being cleared, it should not be hard to understand that it is
> > conceptually wrong to let a user apply add/delete-ip to only a subset of
> > the fan-out concurrent connections on that single endpoint. Because this
> > would in fact result in "splitting" the single endpoint into two
> > different ones. This is NEVER the intention of add/delete-ip - the
> > feature is meant to dynamically modify an endpoint without tearing down
> > all the associations it currently has; it is NOT meant to split a single
> > endpoint into two!
> > 
> > -Qiaobing
> > 
> 
> -- 
> Brian F. G. Bidulock    > ¦ The reasonable man adapts himself to the ¦
> [email-masked]    ¦ world; the unreasonable one persists in  ¦
> http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
>                         ¦ Therefore  all  progress  depends on the ¦
>                         ¦ unreasonable man. -- George Bernard Shaw ¦
> 
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tsvwg

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 29 Apr 2002 04:00:40 -0500

Michael,

> - you include a subset of all addresses of the host in the INIT INIT-ACK.

Why do you call (IPA, Port) one endpoint?  I view an endpoint as
half an association.  When two associations are formed from (IPA, Port),
there are two endpoints, not one.  When adding IPB and IPC and can
add IPB to one endpoint to form (IPB, IPA, Port) and IPC to another
to form (IPC, IPA, Port).  Why restrict this?  Particularly if that is
the way I would have bound them if IPB and IPC where available in the
first place?

I have a host that talks to two other hosts.  IPA is a default and
backup interface on this host.  IPB and IPC are dedicated high-speed
interfaces for talking to HostB and HostC on an engineered network.
Normally I would bind applications serving HostB to IPB as primary
and IPA as secondary.  I would bind applications serving HostC to IPC
as primary and IPA as secondary.  I have a default server which binds
to IPA as primary.  All three servers listen on Port X.

With IPB and IPC down, the default A-server is listening on IPA Port X.
When HostB connects, it spawns a B-server and forms the association
(IPA, Port X) to HostB.  When HostC connects, it spawns an C-server
and forms the association (IPA, Port X) to HostC.  When IPB becomes
availble, the B-server wants it added to its association.  The C-server
does not.  When IPC becomes available, the C-server wants it added to
its association.  The B-Server does not.

So, unless the listener or connecter is actually bound to INADDR_ANY,
there is no reason to force it to add IP addresses just because some
other association happens to be engaged in an association with the
same local addresses and port numbers.

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦

---

From: Qiaobing Xie <[email-masked]>
Date: Mon, 29 Apr 2002 11:49:19 -0500

"Brian F. G. Bidulock" wrote:
...
> half an association.
...snip...

Brian, 

SCTP endpoints exist before an association. Your view of "an endpoint as
half an association" is incorrect.

-Qiaobing