On Mar 10, 2011, at 7:03 PM, WangWeiguo wrote:
> Hi all,
> Anyone can help with this SCTP multi-homing question? I've read the spec. (RFC 4960) and googled, but still it's quite hard to really understand the essentials of the multi-homing.
>
> The question is based on the diagram as following, which is a SCTP association beteen End Point A and B, on each End Point has two IP addresses serving this SCTP association:
>
> Node A Node B
> IP A1 ------- IP B1
> \ /
> \ /
> /\
> / \
> IP A2 ------ IP B2
>
> In this way, there are actually 4 physical links in this single association: A1 -> B1, A2 -> B2, A1 -> B2, and A2 -> B1.
>
> The question is: among these 4 links, how many can be defined as Prime?
Typically, one of the remote peers addresses is considered a primary path (and the source address
will be selected based on the routing table). Also remote addresses are supervised using HEARTBEATs.
> From the spec., it looks like only one pair of IP addresses (ig. A1->B1) can be defined as prime so all traffic actually
The SCTP stack will select the primary address. Using the socket API, the application can
also specify which remote address should be the primary.
> just goes on this link only, however in this way it means that among the 4 available links, only one is bearing traffic in normal cases and all other 3 are standby in case of prime failure, it doesn't look like make sense if compare to the
Please note, that each node will supervise two remote addresses.
> possibility of having 2 out of 4 as prime and other 2 as standby. Furthermore, in case of prime (say A1-> B1) failure, which of the other three will take over and how are they prioritized?
The socket API does not provide a way to indicate where to failover to.
However, the application can handle notifications indicating that a path state
changes to UNREACHABLE and then set a new primary path.
The socket API I'm referring to is available at
http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket
which is implemented (partly) by FreeBSD, Linux and Solaris.
Best regards
Michael
>
> Thanks.
>
> Kevin. Wong.
>
>
>
> ___________________________________________________________________________
> Sent via: Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
> Archives: http://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
> mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
