- From: Tuexen Michael <Michael.Tuexen AT icn.siemens.de>
- To: "'discussion AT sctp.de'" <discussion AT sctp.de>
- Cc: "'???'" <sjy14 AT samsung.com>
- Subject: RE: [SCTP-Discussion] Validity of INIT ACK
- Date: Tue Jul 2 16:02:02 2002
- List-id: SCTP Discussions <discussion.sctp.de>
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
>
Archive powered by MHonArc 2.6.19+.