From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wei Yongjun Subject: Re: [PATCH net-next-2.6 v4 4/5] sctp: Add ASCONF operation on the single-homed host Date: Mon, 25 Apr 2011 10:02:10 +0800 Message-ID: <4DB4D622.9050702@cn.fujitsu.com> References: <3BDA3586-6A7C-4305-9D41-F146575AC951@sfc.wide.ad.jp> <4DB0FD45.2050709@cn.fujitsu.com> <4DB0FFB1.3010006@cn.fujitsu.com> <4DB4C6FB.1020803@cn.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org, lksctp-developers@lists.sourceforge.net To: Michio Honda Return-path: Received: from cn.fujitsu.com ([222.73.24.84]:56203 "EHLO song.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1757968Ab1DYCCe (ORCPT ); Sun, 24 Apr 2011 22:02:34 -0400 In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: > Hi, > > Such operation would not be supported by specification, in Sec.5.3 in RFC 5061: > F1) When adding an IP address to an association, the IP address is > NOT considered fully added to the association until the ASCONF- > ACK arrives. This means that until such time as the ASCONF > containing the add is acknowledged, the sender MUST NOT use the > new IP address as a source for ANY SCTP packet except on > carrying an ASCONF Chunk. > > I think this means we cannot send ASCONF-ACK from the new address even if it bundles ASCONF... If so, both side do not have valid address to send the such ASCONF-ACK, and can not recv ASCONF-ACK. > - Michio > > On Apr 25, 2011, at 9:57 , Wei Yongjun wrote: > >>> On Apr 22, 2011, at 13:10 , Wei Yongjun wrote: >>> >>>>> Since the sender MUST NOT use the new IP address as a source for ANY SCTP >>>>> packet except on carrying an ASCONF Chunk. And ASCONF chunk can be bundled. >>>>> How about this change. If so, you do not need change to sctp_outq_tail(); >>>>> >>>>> diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c >>>>> index 1c88c89..bd6cc9c 100644 >>>>> --- a/net/sctp/outqueue.c >>>>> +++ b/net/sctp/outqueue.c >>>>> @@ -754,6 +754,13 @@ static int sctp_outq_flush(struct sctp_outq *q, int rtx_timeout) >>>>> */ >>>>> >>>>> list_for_each_entry_safe(chunk, tmp, &q->control_chunk_list, list) { >>>>> + /* RFC 5061, 5.3 >>>>> + * F1) This ... >>>>> + */ >>>>> + if (q->asoc->src_out_of_asoc_ok && >>>>> + chunk->chunk_hdr->type != SCTP_CID_ASCONF) >>>> SCTP_CID_ASCONF_ACK should be also allowed, the peer may >>>> send ASCONF to do the same thing at the same time. >>> Sorry for my bad understanding, >>> Do you mean the situation: "the peer (ASCONF receiver) may send ASCONF-ACK to the unconfirmed destination"? >>> Or do you mean following situation? >>> 1. the pear sends ADD/DEL ASCONF to me, >>> 2. I receive it, >>> 3. I migrate to the other network and get new address, >>> 4. I send ASCONF-ACK to the peer from the new address >> Yes, If both side send ADD/DEL ASCONF to del the last one >> address at the same time like this: >> >> ASCONF ----- ------ASCONF >> (ADD/DEL) \ / (ADD/DEL) >> \/ >> /\ >> <----/ \-----> >> ASCONF-ACK---\ /------ASCONF-ACK >> \/ >> /\ >> <----/ \-----> >> >> But I do not test for it. Not sure we need to do this, can you >> check this before commit your new patchset? >> >> >>>>> + continue; >>>>> + >>>>> list_del_init(&chunk->list); >>>>> >>>>> /* Pick the right transport to use. */ >>>>> @@ -881,6 +888,9 @@ static int sctp_outq_flush(struct sctp_outq *q, int rtx_timeout) >>>>> } >>>>> } >>>>> >>>>> + if (q->asoc->src_out_of_asoc_ok) >>>>> + goto sctp_flush_out; >>>>> + >>>>> /* Is it OK to send data chunks? */ >>>>> switch (asoc->state) { >>>>> case SCTP_STATE_COOKIE_ECHOED: >>>>> >>>>> >>>>> >>>> -- >>>> To unsubscribe from this list: send the line "unsubscribe netdev" in >>>> the body of a message to majordomo@vger.kernel.org >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> -- >>> To unsubscribe from this list: send the line "unsubscribe netdev" in >>> the body of a message to majordomo@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >> -- >> To unsubscribe from this list: send the line "unsubscribe netdev" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >