Chronological Thread 

< Chronological >      < Thread >

---

Dear Jye,

see my comments below.

Best regards
Michael

Michael Tuexen Tel.: +49 89 722 47210
Siemens AG Fax: +49 89 722 48212
ICN WN CC SE 7 e-Mail:
Michael.Tuexen AT icn.siemens.de


> -----Original Message-----
> From:
> sjy14 AT samsung.com
>
> [mailto:sjy14 AT samsung.com]
> Sent: Tuesday, July 02, 2002 2:03 AM
> To:
> discussion AT sctp.de
> Subject: [SCTP-Discussion] Validity of INIT ACK
>
>
> Hi,
>
> I've been testing Multihoming functionality of SCTP with
> sctplib-pre17 and found something strange with establishing
> associations.
You should upgrade to pre18. Please subscribe to the
announce AT sctp.de
list to get notified about new releases.
>
> My testbed topology is simple as follows:
>
> INIT
> ---------->
> ---------------------
> | 1.1 1.2 |
> --------- ---------
> | Host A | | Host B |
> --------- ---------
> | 2.1 2.2 |
> ---------------------
>
> Routing tables
> A: 1.1-->1.2 B: 1.2-->1.1
> 2.1-->2.2 2.2-->2.1
>
>
> Both ends are multihomed and directly connected to each other
> through a pair of links.
> Under the normal circumstaces, everything works fine. Link
> failover worked great when I cut off 1.1-1.2 link.
> What I mean by the normal circumstances is that the IP setup
> of SCTP is like this:
>
> Host A(Client) : Primary=1.1 Secondary=2.1 Destination=1.2
> Host B(Server): Primary=1.2 Secondary=2.2
>
>
> But, if I try to make a connection using only one IP of one
> end, the connection ends up with INIT ACK discarded at the
> one that sent INIT in some cases.
> In one of those cases, the setup is like this:
>
> Host A(Client) : Primary=1.1 Secondary=none Destination=2.2
> Host B(Server) : Primary=1.2 Secondary=2.2
>
In the network shown above you have set up the routing as follows
1.1 <-> 1.2
2.1 <-> 2.2
If you disable 2.1, how can communicate with 2.2? There is no way for
1.1 <-> 2.2. This is a problem which results in 'unexpected' behaviour
of the network.
> The way the connection failed is:
> 1) Host A: INIT is sent from 1.1 through 2.1 to 2.2
> 2) Host B: INIT ACK is sent from 1.2 to 1.1 due to the
> routing table of Host B
> 3) Host A: INIT ACK is discarded because INIT ACK is regarded
> to be coming from 1.2 by looking at the src IP of INIT ACK
pre18 looks also in the INIT-ACK. This should help you here.
But it is always 'less than optimal' to have such a setup. But the
implementaters guide states that you MUST look also into the
address list.
See
http://www.sctp.de/internet-drafts/draft-ietf-tsvwg-sctpimpguide-06.html#anchor69
for the description.
> 4) Association fail
>
> I don't know whether you've designed sctplib this way on
> purpose or already noticed this problem.
It has even been address in the imlpementors guide.
> However, this problem should be fixed because I see some
> other Association failure from the same reason when the
> routing tables of Host A and Host B are "cross-
> matched".
Once again, upgrade to pre18. If you still encounter the problem,
please let us know.
>
> I won't describe the detail of it now. If you need more
> detail, let me know then I'll post it here later.
>
> The possible fix for this seems like this:
> When the INIT sender checks the IP address of INIT ACK from
> the other end to validate the INIT ACK, every multihoming IP
> address contained in the payload of INI
> T ACK should be checked.
>
Correct and implemented.
> In the expample above, INIT ACK is supposed to have the
> multihoming IP addresses of 1.2 and 2.2, and the Host A will
> check the validity by looking at those add
> ress contained in the payload, not the IP address(1.2) of IP header.
>
>
> I would like you to clear this up and possibly fix it.
>
Thank you for bringing up that point. Please test pre18.
> Thank you.
>
> Jye
> SCTP research from Samsung
> _______________________________________________
> discussion mailing list
> discussion AT sctp.de
> http://www.sctp.de/mailman/listinfo/discussion
>

---

• [SCTP-Discussion] Validity of INIT ACK, 송제영, 07/02/2002
  • Re: [SCTP-Discussion] Validity of INIT ACK, Andreas Jungmaier, 07/02/2002
  • <Possible follow-up(s)>
  • RE: [SCTP-Discussion] Validity of INIT ACK, Tuexen Michael, 07/02/2002

---

Archive powered by MHonArc 2.6.19+.