RE: [Tsvwg] EndPoint and Association Address conflict

[Tuexen Michael <[e-mail]>]

Brian,

looking at the definition of SCTP end point on page 13 of
RFC 2960 an SCTP endpoint can be identified by a set of 
IP-addresses and a port number.

So for me it is a pair consisiting of a non empty set of
IP-addresses and a pot number. Endpoint = ({IP1, ..., IPn}, Port).

Using that definition your example is not valid if you consider
Add-IP working on end point base. It is valid if you consider 
Add-IP working on assciation base.

Best regards
Michael

Michael Tuexen    Tel.:   [phone]
Siemens AG        Fax:    [phone]
ICN WN CC SE 7    E-mail: [e-mail]

> -----Original Message-----
> From:	Brian F. G. Bidulock [SMTP:[e-mail]]
> Sent:	Monday, April 29, 2002 10:44 AM
> To:	Jacob Heitz
> Cc:	Khan, Mohammad; '[e-mail]'; Pillai, Hari
> Subject:	Re: [Tsvwg] EndPoint and Association Address conflict
> 
> Jacob,
> 
> True, in the examples I gave, the Host was one SCTP endpoint, but the
> same is true for the Peer Hosts in Mohammad's example:
> 
> > > > >     E1(IPA and PortX)                       Peer Hosts
> > > > >     A1(E1)                                  IPB and Port X
> > > > >     A2(E1)                                  IPC and Port X
> > > > >     A3(E1)                                  IPD and Port X
> 
> If one defines an Endpoint as a vector of IP addresses and a single
> SCTP port number, what is to stop IP address vectors for distinct
> associations from being disjoint or overlapping in any way the
> implementation sees fit.  How one distinguishes endpoints is rather
> arbitrary.
> 
> I don't see what is stopping this:
> 
> Before:
>      Host                                    Peer Hosts
>      A1(IPA and PortX)                       IPB and Port Y
>      A2(IPA and PortX)                       IPC and Port Y
>      A3(IPA and PortX)                       IPD and Port Y
> 
> After adding IPX, IPY, IPZ:
>      Host                                    Peer Hosts
>      A1(IPA, IPX and PortX)                  IPB and Port Y
>      A2(IPA, IPY and PortX)                  IPC and Port Y
>      A3(IPA, IPZ and PortX)                  IPD and Port Y
> 
> I could see a problem binding that way in the first place, but
> for a fully formed association what does it matter?  Why define
> the endpoint for the associations as EP1 just because they start
> out life with the same IPA and PortX?
> 
> --brian
> 
> 
> On Mon, 29 Apr 2002, Jacob Heitz wrote:
> 
> > Brian,
> > 
> > You are assuming that a host is equivalent to an SCTP endpoint.
> > That is, that if a host has 3 IPs, then any SCTP endpoint in that
> > host must have the same 3 IPs. IMO, an SCTP endpoint may be
> > constructed with only a subset of the IPs of it's host. ie,
> > this host with 3 IPs may contain an SCTP endpoint that has just
> > two of those IPs.
> > 
> > "Brian F. G. Bidulock" wrote:
> > > 
> > > Mohammad,
> > > 
> > > Please see comments below...
> > > 
> > > On Mon, 29 Apr 2002, Khan, Mohammad wrote:
> > > 
> > > > Hi Brian,
> > > >
> > > > -----Original Message-----
> > > > From: Brian F. G. Bidulock [mailto:[e-mail]]
> > > > Sent: Monday, April 29, 2002 12:26 PM
> > > > To: Khan, Mohammad
> > > > Cc: '[e-mail]'; Pillai, Hari
> > > > Subject: Re: [Tsvwg] EndPoint and Association Address conflict
> > > >
> > > >
> > > > Khan,,
> > > >
> > > > On Sun, 28 Apr 2002, Khan, Mohammad wrote:
> > > >
> > > > > Hi All,
> > > > > I could make the following observations from the ongoing discussions about
> > > > > Endpoint and Association address conflict for SCTP.
> > > > >
> > > > > 1)INIT chunk shall contain all the addresses bound to the Endpoint.
> > > >
> > > > RFC 2960 permits non-multihoming.  It also permits the addresses in
> > > > the INIT to be a subset of the addresses available to an Endpoint.
> > > > A user process starting an association might not have permission to
> > > > all the addresses owned by a host.  How do you propose to make this> 
> > > > requirement stick?
> > > >
> > > > If you mean that when an association happens to be bound with
> > > > INADDR_ANY and an IP is added, and the host determines in some
> > > > implementation dependent fashion that a new dynamic address should
> > > > be subsequently added to this association, that it should perform
> > > > the ADDIP procedures on behalf of the association, then there might
> > > > not be a problem.  But the above seems to rule out many features of
> > > > SCTP that are already implemented and being used.
> > > >
> > > > This is what Randell mentioned in one of his comments
> > > > "
> > > > Why did you not include IPb in the INIT or INIT-ACK that setup A1. You
> > > > are supposed to tell the peer of all your addresses that are bound to
> > > > your endpoint.  You really MUST tell the peer of all your endpoint's
> > > > addresses.
> > > > R
> > > > "
> > > 
> > > Doesn't say that in RFC 2960 or anywhere else.  Here is a reason for
> > > not including all the addresses:
> > > 
> > > I have a Signalling Gateway and an MGC, both of which have 3 interfaces:
> > > two are high-speed interfaces on an Engineered network for signalling
> > > applications; one is a low-speed interface which also acts as a default
> > > route which is used for adminstrative tasks only (such as configuration,
> > > SNMP, etc).  Although the SG can talk to the MGC on the default
> > > interface, associations which are formed for signalling between the SG
> > > and MGC can only use the interfaces dedicated to signalling on the
> > > engineered network.
> > > 
> > > Now, it may be that the adminstrative interface is using DHCP on both
> > > boxes.  When a DHCP lease time is renewed and a new IP address is
> > > generated (e.g., on the SG), there is NO WAY that I am adding the new
> > > address to the associations which are used for signalling.
> > > 
> > > An IPV6 example:  I have three interfaces which are connected to three
> > > different service providers.  I place high-volume traffic on the two
> > > service provided with which I can obtain the best rate for bulk traffic.
> > > I place low-volume, low-latency traffic on the third service provider.
> > > All 3 interfaces are DHCP.  I am NOT adding the low-volume service
> > > provider interface to associations sending high-volume traffic.
> > > 
> > > I'm sorry but the INADDR_ANY approach does not work in many real-world
> > > situations.
> > > 
> > > > >
> > > > > 2)Addition and deletion of IP address shall be on Endpoint not on
> > > > > Association.
> > > > >
> > > > > For the point 2) suppose an Endpoint E1(IPA and Port X) has multiple
> > > > > associations A1, A2 and A3 with three different peers.
> > > > >
> > > > >     E1(IPA and PortX)                       Peer Hosts
> > > > >     A1(E1)                                  IPB and Port X
> > > > >     A2(E1)                                  IPC and Port X
> > > > >     A3(E1)                                  IPD and Port X
> > > > > As per the assumption 2) to add an IPZ at E1 SCTP has to send ASCONF chunk
> > > > > on all the A1, A2 and A3 associations and it shall not consider this
> > > > address
> > > > > as added till it receives success from all the associations. If failure is
> > > > > received is received from any of the associations then this Add-IP request
> > > > > shall be discarded.
> > > >
> > > > Huh?  Why must it fail for all if it fails for one?  That doesn't
> > > > sound too wise.  For example, if the receiver of the ASCONF does not
> > > > like the new destination (perhaps it does not meet security criteria)
> > > > it would not be able to reject it?
> > > >
> > > > Seems quite annoyed. If u are accepting ADD/DELETE IP as successfull even if
> > > > ADD/DELETE IP is not successful for all the associations then again u will
> > > > end up in having two instances of one transport address between two
> > > > associations of same endpoint.> 
> > > 
> >>  > So what's the matter with that?  This is permitted by RFC 2960 in its
> > > current form, with or without ADDIP.
> > > 
> > > --brian
> > > 
> > > > That is what we all had been discussing till now.
> > > > ---kashif
> > > >
> > > > --brian
> > > >
> > > >
> > > > >
> > > > > Same procedure is to be adopted to delete an address from an endpoint.
> > > > > Please comment.
> > > > >
> > > > > Regards
> > > > > kashif
> > 
> > -- 
> > // Jacob Heitz. Tel:[phone]
> 
> -- 
> Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
> [e-mail]    ¦ 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/tsvwg

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