RE: [Lksctp-developers] Re: Error code issue for addip draft 8

[Gao, K. <kev...@in...>]

> On Thu, 13 Nov 2003, Gao, Kevin wrote:
>=20
> > > On Tue, 11 Nov 2003, Gao, Kevin wrote:
> > >
> > > > In addip draft 8,
> > > > 4.1
> > > >  A7) If an error response is received for a TLV=20
> parameter, all TLVs
> > > >       with no response before the failed TLV are considered
> > > successful
> > > >       if not reported.  All TLVs after the failed response are
> > > >       considered unsuccessful unless a specific success
> > > indication is
> > > >       present for the parameter.
> > > >
> > > > In spec, we know the parameter after the failed response is
> > > considered
> > > > unsuccessfully, but which default error code we should=20
> use? You know
> > > > we process error parameter with different way, maybe discard it,
> > > > maybe never send any ASCONF chunk, or abort the association.
> > > > So if there is no failed response, but we should considered it
> > > > unsuccessfully, which way we should choose to process the old
> > > > bindx request?
> > > >
> > > > I think we should define a default error code for it.
> > >
> > > While sending an ASCONF_ACK chunk, only in the case of "Out
> > > of Resource" error,
> > > later TLV parameters are not processed. So an ASCONF_ACK with
> > > error response
> > > parameter other than "Out of Resource" error should have=20
> the success
> > > indication/error cause indication parameters for the later TLVs.
> > >
> > > I guess the best option is to ABORT an association if we
> > > receive a failed
> > > response of "Out of Resource" error. Other cases discard
> > > seems to be the
> > > right option.
> > >
> > > Thanks
> > > Sridhar
> > >
> >
> > I am afraid the spec does not give all description for how=20
> to do when
> > receiving ASCONF_ACK with the error codes. So we need to make
> > terms of it.
> >
> > SCTP_ERROR_RSRC_LOW: (Abort the association.)
> OK
>=20
> > SCTP_ERROR_DEL_LAST_IP: (I think we only discard it.)
> > SCTP_ERROR_DEL_SRC_IP: (I think we only discard it.)
> I think we have to do more than just a simple discard.
> When the sender sends an ASCONF with delete IP address=20
> parameter, we need
> to mark this ip address in the bind address list as not=20
> eligible to be used as
> a source address. We don't do this yet. One way to do this is=20
> to add a new
> field "disable_src" to struct sctp_sockaddr_entry and set it=20
> before sending
> the ASCONF chunk.
> So if we receive the above error causes in ASCONF_ACK, we should reset
> 'disable_src' field so that we can start using it as a source address.

I think we have the same idea. That's just what I means :)

Thanks

-Kevin

>=20
> > SCTP_ERROR_REQ_REFUSED: (This is not defined in our code, I will
> > 				  add it in my new patch. I think
> > forbidden
> > 				  to send any subsequent asconf chunk
> >                                                   of that=20
> parameter.)
> > SCTP_ERROR_INV_PARAM: (Do not send any subsequent asconf chunk
> >                                               of that parameter)
> looks OK
>=20
> >
> > invalid asconf_ack but error code  (We only discard it.)
> > is not given(condition as my prev
> > letter's description):
> If you are referring to the case where we received an=20
> ASCONF_ACK indicating a
> failed TLV with no error code, i think we should do the same=20
> as i suggested
> above for SCTP_ERROR_DEL_LAST_IP and DEL_SRC_IP.
>=20
> Thanks
> Sridhar
>=20