SCTP Abort case-TCB destroyed

From sigtran-bounces@ietf.org Mon Apr 03 21:28:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQaLJ-0001X4-MZ; Mon, 03 Apr 2006 21:28:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQaLH-0001Wu-T5 for sigtran@ietf.org; Mon, 03 Apr 2006 21:28:23 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQaLH-0000iG-2k for sigtran@ietf.org; Mon, 03 Apr 2006 21:28:23 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k341R5YZ011637 for ; Tue, 4 Apr 2006 04:27:07 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Apr 2006 04:28:11 +0300 Received: from daebe102.NOE.Nokia.com ([10.241.35.115]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Apr 2006 20:28:06 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C65787.064B57BB" Date: Mon, 3 Apr 2006 20:28:03 -0500 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: SCTP Abort case-TCB destroyed Thread-Index: AcZXhwR7JcGrzirKRvmPLWqul16X8Q== From: To: X-OriginalArrivalTime: 04 Apr 2006 01:28:06.0805 (UTC) FILETIME=[06826C50:01C65787] X-Spam-Score: 0.2 (/) X-Scan-Signature: 343d06d914165ffd9d590a64755216ca Subject: [Sigtran] SCTP Abort case-TCB destroyed X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C65787.064B57BB Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C65787.064B57BB" ------_=_NextPart_002_01C65787.064B57BB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi sigtran gurus, I am seeing this in an ASP-SGP scenario=20 EndPoint A EndPoint B SCTP-INIT-------------------> <----------------------INIT_ACK COOKIE-ECHO-----------> <---------------------SCTP-ABORT In the ABORT CHUNK I see the T-Bit set to 0 (TCB destroyed).=20 I have attached the above four packets expanded in a text file for your reference. <>=20 Why is the ABORT being sent in this case? Is it being treated as an OOTB packet? Thanks =20 Edwin=20 ------_=_NextPart_002_01C65787.064B57BB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable SCTP Abort case-TCB destroyed

Hi sigtran gurus,

I am seeing this in an ASP-SGP scenario =

EndPoint = A      =         EndPoint B
SCTP-INIT------------------->
        <----------------------INIT_ACK
COOKIE-ECHO----------->
        <---------------------SCTP-ABORT

In the ABORT CHUNK I see the T-Bit set = to 0 (TCB destroyed).

I have attached the above four packets = expanded in a text file for your reference.

= <<sctp_abort_case.txt>>
Why is the ABORT being sent in this = case?

Is it being treated as an OOTB = packet?

Thanks &= nbsp; &n= bsp; &nb= sp; &nbs= p;

Edwin=20

------_=_NextPart_002_01C65787.064B57BB-- ------_=_NextPart_001_01C65787.064B57BB Content-Type: text/plain; name="sctp_abort_case.txt" Content-Transfer-Encoding: base64 Content-Description: sctp_abort_case.txt Content-Disposition: attachment; filename="sctp_abort_case.txt" RnJhbWUgNDYgKDgyIGJ5dGVzIG9uIHdpcmUsIDgyIGJ5dGVzIGNhcHR1cmVkKQ0KICAgIEFycml2 YWwgVGltZTogQXByICAzLCAyMDA2IDE5OjM3OjAyLjAwOTAwMDAwMA0KICAgIFRpbWUgZGVsdGEg ZnJvbSBwcmV2aW91cyBwYWNrZXQ6IDIuMDAyMDAwMDAwIHNlY29uZHMNCiAgICBUaW1lIHNpbmNl IHJlZmVyZW5jZSBvciBmaXJzdCBmcmFtZTogOTQuMDA5MDAwMDAwIHNlY29uZHMNCiAgICBGcmFt ZSBOdW1iZXI6IDQ2DQogICAgUGFja2V0IExlbmd0aDogODIgYnl0ZXMNCiAgICBDYXB0dXJlIExl bmd0aDogODIgYnl0ZXMNCkV0aGVybmV0IElJLCBTcmM6IDAwOjAwOjUwOjE5OmQ2OjM1LCBEc3Q6 IDAwOjE0OjZhOmZkOjM1OjIwDQogICAgRGVzdGluYXRpb246IDAwOjE0OjZhOmZkOjM1OjIwICgw MDoxNDo2YTpmZDozNToyMCkNCiAgICBTb3VyY2U6IDAwOjAwOjUwOjE5OmQ2OjM1IChSYWRpc3lz XzE5OmQ2OjM1KQ0KICAgIFR5cGU6IElQICgweDA4MDApDQpJbnRlcm5ldCBQcm90b2NvbCwgU3Jj IEFkZHI6IDEwLjEzLjY1LjE0NyAoMTAuMTMuNjUuMTQ3KSwgRHN0IEFkZHI6IDEwLjE4Ny4yNS4y MTIgKDEwLjE4Ny4yNS4yMTIpDQogICAgVmVyc2lvbjogNA0KICAgIEhlYWRlciBsZW5ndGg6IDIw IGJ5dGVzDQogICAgRGlmZmVyZW50aWF0ZWQgU2VydmljZXMgRmllbGQ6IDB4MDAgKERTQ1AgMHgw MDogRGVmYXVsdDsgRUNOOiAweDAwKQ0KICAgICAgICAwMDAwIDAwLi4gPSBEaWZmZXJlbnRpYXRl ZCBTZXJ2aWNlcyBDb2RlcG9pbnQ6IERlZmF1bHQgKDB4MDApDQogICAgICAgIC4uLi4gLi4wLiA9 IEVDTi1DYXBhYmxlIFRyYW5zcG9ydCAoRUNUKTogMA0KICAgICAgICAuLi4uIC4uLjAgPSBFQ04t Q0U6IDANCiAgICBUb3RhbCBMZW5ndGg6IDY4DQogICAgSWRlbnRpZmljYXRpb246IDB4NzM0MiAo Mjk1MDYpDQogICAgRmxhZ3M6IDB4MDANCiAgICAgICAgMC4uLiA9IFJlc2VydmVkIGJpdDogTm90 IHNldA0KICAgICAgICAuMC4uID0gRG9uJ3QgZnJhZ21lbnQ6IE5vdCBzZXQNCiAgICAgICAgLi4w LiA9IE1vcmUgZnJhZ21lbnRzOiBOb3Qgc2V0DQogICAgRnJhZ21lbnQgb2Zmc2V0OiAwDQogICAg VGltZSB0byBsaXZlOiA2NA0KICAgIFByb3RvY29sOiBTQ1RQICgweDg0KQ0KICAgIEhlYWRlciBj aGVja3N1bTogMHg5NmM1IChjb3JyZWN0KQ0KICAgIFNvdXJjZTogMTAuMTMuNjUuMTQ3ICgxMC4x My42NS4xNDcpDQogICAgRGVzdGluYXRpb246IDEwLjE4Ny4yNS4yMTIgKDEwLjE4Ny4yNS4yMTIp DQpTdHJlYW0gQ29udHJvbCBUcmFuc21pc3Npb24gUHJvdG9jb2wNCiAgICBTb3VyY2UgcG9ydDog NDkxNTINCiAgICBEZXN0aW5hdGlvbiBwb3J0OiAyOTA1DQogICAgVmVyaWZpY2F0aW9uIHRhZzog MHgwMDAwMDAwMA0KICAgIENoZWNrc3VtOiAweGZjYjc1M2JlIChjb3JyZWN0IENSQzMyQykNCiAg ICBJTklUIGNodW5rIChPdXRib3VuZCBzdHJlYW1zOiAyLCBpbmJvdW5kIHN0cmVhbXM6IDIwNDgp DQogICAgICAgIENodW5rIHR5cGU6IElOSVQgKDEpDQogICAgICAgICAgICAwLi4uIC4uLi4gPSBC aXQ6IFN0b3AgcHJvY2Vzc2luZyBvZiB0aGUgcGFja2V0DQogICAgICAgICAgICAuMC4uIC4uLi4g PSBCaXQ6IERvIG5vdCByZXBvcnQNCiAgICAgICAgQ2h1bmsgZmxhZ3M6IDB4MDANCiAgICAgICAg Q2h1bmsgbGVuZ3RoOiAzNg0KICAgICAgICBJbml0aWF0ZSB0YWc6IDB4ODFjNTA3MTENCiAgICAg ICAgQWR2ZXJ0aXNlZCByZWNlaXZlciB3aW5kb3cgY3JlZGl0IChhX3J3bmQpOiAxMzQ2NTYNCiAg ICAgICAgTnVtYmVyIG9mIG91dGJvdW5kIHN0cmVhbXM6IDINCiAgICAgICAgTnVtYmVyIG9mIGlu Ym91bmQgc3RyZWFtczogMjA0OA0KICAgICAgICBJbml0aWFsIFRTTjogMzEzMjkwNTY4OA0KICAg ICAgICBTdXBwb3J0ZWQgYWRkcmVzcyB0eXBlcyBwYXJhbWV0ZXIgKFN1cHBvcnRlZCB0eXBlczog SVB2NCwgSVB2NikNCiAgICAgICAgICAgIFBhcmFtZXRlciB0eXBlOiBTdXBwb3J0ZWQgYWRkcmVz cyB0eXBlcyAoMHgwMDBjKQ0KICAgICAgICAgICAgICAgIDAuLi4gLi4uLiAuLi4uIC4uLi4gPSBC aXQ6IFN0b3AgcHJvY2Vzc2luZyBvZiBjaHVuaw0KICAgICAgICAgICAgICAgIC4wLi4gLi4uLiAu Li4uIC4uLi4gPSBCaXQ6IERvIG5vdCByZXBvcnQNCiAgICAgICAgICAgIFBhcmFtZXRlciBsZW5n dGg6IDgNCiAgICAgICAgICAgIFN1cHBvcnRlZCBhZGRyZXNzIHR5cGU6IElQdjQgYWRkcmVzcyAo NSkNCiAgICAgICAgICAgIFN1cHBvcnRlZCBhZGRyZXNzIHR5cGU6IElQdjYgYWRkcmVzcyAoNikN CiAgICAgICAgRUNOIHBhcmFtZXRlcg0KICAgICAgICAgICAgUGFyYW1ldGVyIHR5cGU6IEVDTiAo MHg4MDAwKQ0KICAgICAgICAgICAgICAgIDEuLi4gLi4uLiAuLi4uIC4uLi4gPSBCaXQ6IFNraXAg cGFyYW1ldGVyIGFuZCBjb250aW51ZSBwcm9zZXNzaW5nIG9mIHRoZSBjaHVuaw0KICAgICAgICAg ICAgICAgIC4wLi4gLi4uLiAuLi4uIC4uLi4gPSBCaXQ6IERvIG5vdCByZXBvcnQNCiAgICAgICAg ICAgIFBhcmFtZXRlciBsZW5ndGg6IDQNCiAgICAgICAgRm9yd2FyZCBUU04gc3VwcG9ydGVkIHBh cmFtZXRlcg0KICAgICAgICAgICAgUGFyYW1ldGVyIHR5cGU6IEZvcndhcmQgVFNOIHN1cHBvcnRl ZCAoMHhjMDAwKQ0KICAgICAgICAgICAgICAgIDEuLi4gLi4uLiAuLi4uIC4uLi4gPSBCaXQ6IFNr aXAgcGFyYW1ldGVyIGFuZCBjb250aW51ZSBwcm9zZXNzaW5nIG9mIHRoZSBjaHVuaw0KICAgICAg ICAgICAgICAgIC4xLi4gLi4uLiAuLi4uIC4uLi4gPSBCaXQ6IERvIHJlcG9ydA0KICAgICAgICAg ICAgUGFyYW1ldGVyIGxlbmd0aDogNA0KDQpGcmFtZSA0NyAoNDU4IGJ5dGVzIG9uIHdpcmUsIDQ1 OCBieXRlcyBjYXB0dXJlZCkNCiAgICBBcnJpdmFsIFRpbWU6IEFwciAgMywgMjAwNiAxOTozNzow Mi4wMjkwMDAwMDANCiAgICBUaW1lIGRlbHRhIGZyb20gcHJldmlvdXMgcGFja2V0OiAwLjAyMDAw MDAwMCBzZWNvbmRzDQogICAgVGltZSBzaW5jZSByZWZlcmVuY2Ugb3IgZmlyc3QgZnJhbWU6IDk0 LjAyOTAwMDAwMCBzZWNvbmRzDQogICAgRnJhbWUgTnVtYmVyOiA0Nw0KICAgIFBhY2tldCBMZW5n dGg6IDQ1OCBieXRlcw0KICAgIENhcHR1cmUgTGVuZ3RoOiA0NTggYnl0ZXMNCkV0aGVybmV0IElJ LCBTcmM6IDAwOjE0OjZhOmZkOjM1OjIwLCBEc3Q6IDAwOjAwOjUwOjE5OmQ2OjM1DQogICAgRGVz dGluYXRpb246IDAwOjAwOjUwOjE5OmQ2OjM1IChSYWRpc3lzXzE5OmQ2OjM1KQ0KICAgIFNvdXJj ZTogMDA6MTQ6NmE6ZmQ6MzU6MjAgKDAwOjE0OjZhOmZkOjM1OjIwKQ0KICAgIFR5cGU6IElQICgw eDA4MDApDQpJbnRlcm5ldCBQcm90b2NvbCwgU3JjIEFkZHI6IDEwLjE4Ny4yNS4yMTIgKDEwLjE4 Ny4yNS4yMTIpLCBEc3QgQWRkcjogMTAuMTMuNjUuMTQ3ICgxMC4xMy42NS4xNDcpDQogICAgVmVy c2lvbjogNA0KICAgIEhlYWRlciBsZW5ndGg6IDIwIGJ5dGVzDQogICAgRGlmZmVyZW50aWF0ZWQg U2VydmljZXMgRmllbGQ6IDB4MDAgKERTQ1AgMHgwMDogRGVmYXVsdDsgRUNOOiAweDAwKQ0KICAg ICAgICAwMDAwIDAwLi4gPSBEaWZmZXJlbnRpYXRlZCBTZXJ2aWNlcyBDb2RlcG9pbnQ6IERlZmF1 bHQgKDB4MDApDQogICAgICAgIC4uLi4gLi4wLiA9IEVDTi1DYXBhYmxlIFRyYW5zcG9ydCAoRUNU KTogMA0KICAgICAgICAuLi4uIC4uLjAgPSBFQ04tQ0U6IDANCiAgICBUb3RhbCBMZW5ndGg6IDQ0 NA0KICAgIElkZW50aWZpY2F0aW9uOiAweDc5ZTkgKDMxMjA5KQ0KICAgIEZsYWdzOiAweDA0DQog ICAgICAgIDAuLi4gPSBSZXNlcnZlZCBiaXQ6IE5vdCBzZXQNCiAgICAgICAgLjEuLiA9IERvbid0 IGZyYWdtZW50OiBTZXQNCiAgICAgICAgLi4wLiA9IE1vcmUgZnJhZ21lbnRzOiBOb3Qgc2V0DQog ICAgRnJhZ21lbnQgb2Zmc2V0OiAwDQogICAgVGltZSB0byBsaXZlOiA2MQ0KICAgIFByb3RvY29s OiBTQ1RQICgweDg0KQ0KICAgIEhlYWRlciBjaGVja3N1bTogMHg1MWE2IChjb3JyZWN0KQ0KICAg IFNvdXJjZTogMTAuMTg3LjI1LjIxMiAoMTAuMTg3LjI1LjIxMikNCiAgICBEZXN0aW5hdGlvbjog MTAuMTMuNjUuMTQ3ICgxMC4xMy42NS4xNDcpDQpTdHJlYW0gQ29udHJvbCBUcmFuc21pc3Npb24g UHJvdG9jb2wNCiAgICBTb3VyY2UgcG9ydDogMjkwNQ0KICAgIERlc3RpbmF0aW9uIHBvcnQ6IDQ5 MTUyDQogICAgVmVyaWZpY2F0aW9uIHRhZzogMHg4MWM1MDcxMQ0KICAgIENoZWNrc3VtOiAweDQ1 ZmQwZmQ0IChjb3JyZWN0IENSQzMyQykNCiAgICBJTklUX0FDSyBjaHVuayAoT3V0Ym91bmQgc3Ry ZWFtczogMTAsIGluYm91bmQgc3RyZWFtczogMikNCiAgICAgICAgQ2h1bmsgdHlwZTogSU5JVF9B Q0sgKDIpDQogICAgICAgICAgICAwLi4uIC4uLi4gPSBCaXQ6IFN0b3AgcHJvY2Vzc2luZyBvZiB0 aGUgcGFja2V0DQogICAgICAgICAgICAuMC4uIC4uLi4gPSBCaXQ6IERvIG5vdCByZXBvcnQNCiAg ICAgICAgQ2h1bmsgZmxhZ3M6IDB4MDANCiAgICAgICAgQ2h1bmsgbGVuZ3RoOiA0MTINCiAgICAg ICAgSW5pdGlhdGUgdGFnOiAweDBkNzk0ZmIyDQogICAgICAgIEFkdmVydGlzZWQgcmVjZWl2ZXIg d2luZG93IGNyZWRpdCAoYV9yd25kKTogMTYzODQNCiAgICAgICAgTnVtYmVyIG9mIG91dGJvdW5k IHN0cmVhbXM6IDEwDQogICAgICAgIE51bWJlciBvZiBpbmJvdW5kIHN0cmVhbXM6IDINCiAgICAg ICAgSW5pdGlhbCBUU046IDIyNjA1NDA2Ng0KICAgICAgICBTdGF0ZSBjb29raWUgcGFyYW1ldGVy IChDb29raWUgbGVuZ3RoOiAzNjAgYnl0ZXMpDQogICAgICAgICAgICBQYXJhbWV0ZXIgdHlwZTog U3RhdGUgY29va2llICgweDAwMDcpDQogICAgICAgICAgICAgICAgMC4uLiAuLi4uIC4uLi4gLi4u LiA9IEJpdDogU3RvcCBwcm9jZXNzaW5nIG9mIGNodW5rDQogICAgICAgICAgICAgICAgLjAuLiAu Li4uIC4uLi4gLi4uLiA9IEJpdDogRG8gbm90IHJlcG9ydA0KICAgICAgICAgICAgUGFyYW1ldGVy IGxlbmd0aDogMzY0DQogICAgICAgICAgICBTdGF0ZSBjb29raWU6IDgxQzUwNzExMDAwMjBFMDAw MDBBMDAwRkJBQkM1OEQ4Li4uDQogICAgICAgIElQdjQgYWRkcmVzcyBwYXJhbWV0ZXIgKEFkZHJl c3M6IDEwLjE4Ny4yNS4xOTYpDQogICAgICAgICAgICBQYXJhbWV0ZXIgdHlwZTogSVB2NCBhZGRy ZXNzICgweDAwMDUpDQogICAgICAgICAgICAgICAgMC4uLiAuLi4uIC4uLi4gLi4uLiA9IEJpdDog U3RvcCBwcm9jZXNzaW5nIG9mIGNodW5rDQogICAgICAgICAgICAgICAgLjAuLiAuLi4uIC4uLi4g Li4uLiA9IEJpdDogRG8gbm90IHJlcG9ydA0KICAgICAgICAgICAgUGFyYW1ldGVyIGxlbmd0aDog OA0KICAgICAgICAgICAgSVAgVmVyc2lvbiA0IGFkZHJlc3M6IDEwLjE4Ny4yNS4xOTYgKDEwLjE4 Ny4yNS4xOTYpDQogICAgICAgIElQdjQgYWRkcmVzcyBwYXJhbWV0ZXIgKEFkZHJlc3M6IDEwLjE4 Ny4yNS4yMTIpDQogICAgICAgICAgICBQYXJhbWV0ZXIgdHlwZTogSVB2NCBhZGRyZXNzICgweDAw MDUpDQogICAgICAgICAgICAgICAgMC4uLiAuLi4uIC4uLi4gLi4uLiA9IEJpdDogU3RvcCBwcm9j ZXNzaW5nIG9mIGNodW5rDQogICAgICAgICAgICAgICAgLjAuLiAuLi4uIC4uLi4gLi4uLiA9IEJp dDogRG8gbm90IHJlcG9ydA0KICAgICAgICAgICAgUGFyYW1ldGVyIGxlbmd0aDogOA0KICAgICAg ICAgICAgSVAgVmVyc2lvbiA0IGFkZHJlc3M6IDEwLjE4Ny4yNS4yMTIgKDEwLjE4Ny4yNS4yMTIp DQogICAgICAgIFVucmVjb2duaXplZCBwYXJhbWV0ZXIgcGFyYW1ldGVyDQogICAgICAgICAgICBQ YXJhbWV0ZXIgdHlwZTogVW5yZWNvZ25pemVkIHBhcmFtZXRlciAoMHgwMDA4KQ0KICAgICAgICAg ICAgICAgIDAuLi4gLi4uLiAuLi4uIC4uLi4gPSBCaXQ6IFN0b3AgcHJvY2Vzc2luZyBvZiBjaHVu aw0KICAgICAgICAgICAgICAgIC4wLi4gLi4uLiAuLi4uIC4uLi4gPSBCaXQ6IERvIG5vdCByZXBv cnQNCiAgICAgICAgICAgIFBhcmFtZXRlciBsZW5ndGg6IDEyDQogICAgICAgICAgICBGb3J3YXJk IFRTTiBzdXBwb3J0ZWQgcGFyYW1ldGVyDQogICAgICAgICAgICAgICAgUGFyYW1ldGVyIHR5cGU6 IEZvcndhcmQgVFNOIHN1cHBvcnRlZCAoMHhjMDAwKQ0KICAgICAgICAgICAgICAgICAgICAxLi4u IC4uLi4gLi4uLiAuLi4uID0gQml0OiBTa2lwIHBhcmFtZXRlciBhbmQgY29udGludWUgcHJvc2Vz c2luZyBvZiB0aGUgY2h1bmsNCiAgICAgICAgICAgICAgICAgICAgLjEuLiAuLi4uIC4uLi4gLi4u LiA9IEJpdDogRG8gcmVwb3J0DQogICAgICAgICAgICAgICAgUGFyYW1ldGVyIGxlbmd0aDogNA0K ICAgICAgICAgICAgICAgIFBhcmFtZXRlciBwYWRkaW5nOiA4MDAwMDAwNA0KDQpGcmFtZSA0OCAo NDEwIGJ5dGVzIG9uIHdpcmUsIDQxMCBieXRlcyBjYXB0dXJlZCkNCiAgICBBcnJpdmFsIFRpbWU6 IEFwciAgMywgMjAwNiAxOTozNzowMi4wMjkwMDAwMDANCiAgICBUaW1lIGRlbHRhIGZyb20gcHJl dmlvdXMgcGFja2V0OiAwLjAwMDAwMDAwMCBzZWNvbmRzDQogICAgVGltZSBzaW5jZSByZWZlcmVu Y2Ugb3IgZmlyc3QgZnJhbWU6IDk0LjAyOTAwMDAwMCBzZWNvbmRzDQogICAgRnJhbWUgTnVtYmVy OiA0OA0KICAgIFBhY2tldCBMZW5ndGg6IDQxMCBieXRlcw0KICAgIENhcHR1cmUgTGVuZ3RoOiA0 MTAgYnl0ZXMNCkV0aGVybmV0IElJLCBTcmM6IDAwOjAwOjUwOjE5OmQ2OjM1LCBEc3Q6IDAwOjE0 OjZhOmZkOjM1OjIwDQogICAgRGVzdGluYXRpb246IDAwOjE0OjZhOmZkOjM1OjIwICgwMDoxNDo2 YTpmZDozNToyMCkNCiAgICBTb3VyY2U6IDAwOjAwOjUwOjE5OmQ2OjM1IChSYWRpc3lzXzE5OmQ2 OjM1KQ0KICAgIFR5cGU6IElQICgweDA4MDApDQpJbnRlcm5ldCBQcm90b2NvbCwgU3JjIEFkZHI6 IDEwLjEzLjY1LjE0NyAoMTAuMTMuNjUuMTQ3KSwgRHN0IEFkZHI6IDEwLjE4Ny4yNS4yMTIgKDEw LjE4Ny4yNS4yMTIpDQogICAgVmVyc2lvbjogNA0KICAgIEhlYWRlciBsZW5ndGg6IDIwIGJ5dGVz DQogICAgRGlmZmVyZW50aWF0ZWQgU2VydmljZXMgRmllbGQ6IDB4MDAgKERTQ1AgMHgwMDogRGVm YXVsdDsgRUNOOiAweDAwKQ0KICAgICAgICAwMDAwIDAwLi4gPSBEaWZmZXJlbnRpYXRlZCBTZXJ2 aWNlcyBDb2RlcG9pbnQ6IERlZmF1bHQgKDB4MDApDQogICAgICAgIC4uLi4gLi4wLiA9IEVDTi1D YXBhYmxlIFRyYW5zcG9ydCAoRUNUKTogMA0KICAgICAgICAuLi4uIC4uLjAgPSBFQ04tQ0U6IDAN CiAgICBUb3RhbCBMZW5ndGg6IDM5Ng0KICAgIElkZW50aWZpY2F0aW9uOiAweDczNDQgKDI5NTA4 KQ0KICAgIEZsYWdzOiAweDA0DQogICAgICAgIDAuLi4gPSBSZXNlcnZlZCBiaXQ6IE5vdCBzZXQN CiAgICAgICAgLjEuLiA9IERvbid0IGZyYWdtZW50OiBTZXQNCiAgICAgICAgLi4wLiA9IE1vcmUg ZnJhZ21lbnRzOiBOb3Qgc2V0DQogICAgRnJhZ21lbnQgb2Zmc2V0OiAwDQogICAgVGltZSB0byBs aXZlOiA2NA0KICAgIFByb3RvY29sOiBTQ1RQICgweDg0KQ0KICAgIEhlYWRlciBjaGVja3N1bTog MHg1NTdiIChjb3JyZWN0KQ0KICAgIFNvdXJjZTogMTAuMTMuNjUuMTQ3ICgxMC4xMy42NS4xNDcp DQogICAgRGVzdGluYXRpb246IDEwLjE4Ny4yNS4yMTIgKDEwLjE4Ny4yNS4yMTIpDQpTdHJlYW0g Q29udHJvbCBUcmFuc21pc3Npb24gUHJvdG9jb2wNCiAgICBTb3VyY2UgcG9ydDogNDkxNTINCiAg ICBEZXN0aW5hdGlvbiBwb3J0OiAyOTA1DQogICAgVmVyaWZpY2F0aW9uIHRhZzogMHgwZDc5NGZi Mg0KICAgIENoZWNrc3VtOiAweDI4MjMxZjg3IChjb3JyZWN0IENSQzMyQykNCiAgICBDT09LSUVf RUNITyBjaHVuayAoQ29va2llIGxlbmd0aDogMzYwIGJ5dGVzKQ0KICAgICAgICBDaHVuayB0eXBl OiBDT09LSUVfRUNITyAoMTApDQogICAgICAgICAgICAwLi4uIC4uLi4gPSBCaXQ6IFN0b3AgcHJv Y2Vzc2luZyBvZiB0aGUgcGFja2V0DQogICAgICAgICAgICAuMC4uIC4uLi4gPSBCaXQ6IERvIG5v dCByZXBvcnQNCiAgICAgICAgQ2h1bmsgZmxhZ3M6IDB4MDANCiAgICAgICAgQ2h1bmsgbGVuZ3Ro OiAzNjQNCiAgICAgICAgQ29va2llOiA4MUM1MDcxMTAwMDIwRTAwMDAwQTAwMEZCQUJDNThEOC4u Lg0KDQpGcmFtZSA0OSAoNjAgYnl0ZXMgb24gd2lyZSwgNjAgYnl0ZXMgY2FwdHVyZWQpDQogICAg QXJyaXZhbCBUaW1lOiBBcHIgIDMsIDIwMDYgMTk6Mzc6MDIuMDQ5MDAwMDAwDQogICAgVGltZSBk ZWx0YSBmcm9tIHByZXZpb3VzIHBhY2tldDogMC4wMjAwMDAwMDAgc2Vjb25kcw0KICAgIFRpbWUg c2luY2UgcmVmZXJlbmNlIG9yIGZpcnN0IGZyYW1lOiA5NC4wNDkwMDAwMDAgc2Vjb25kcw0KICAg IEZyYW1lIE51bWJlcjogNDkNCiAgICBQYWNrZXQgTGVuZ3RoOiA2MCBieXRlcw0KICAgIENhcHR1 cmUgTGVuZ3RoOiA2MCBieXRlcw0KRXRoZXJuZXQgSUksIFNyYzogMDA6MTQ6NmE6ZmQ6MzU6MjAs IERzdDogMDA6MDA6NTA6MTk6ZDY6MzUNCiAgICBEZXN0aW5hdGlvbjogMDA6MDA6NTA6MTk6ZDY6 MzUgKFJhZGlzeXNfMTk6ZDY6MzUpDQogICAgU291cmNlOiAwMDoxNDo2YTpmZDozNToyMCAoMDA6 MTQ6NmE6ZmQ6MzU6MjApDQogICAgVHlwZTogSVAgKDB4MDgwMCkNCiAgICBUcmFpbGVyOiAwMDAw MDAwMDAwMDAwMDAwMDAwMA0KSW50ZXJuZXQgUHJvdG9jb2wsIFNyYyBBZGRyOiAxMC4xODcuMjUu MjEyICgxMC4xODcuMjUuMjEyKSwgRHN0IEFkZHI6IDEwLjEzLjY1LjE0NyAoMTAuMTMuNjUuMTQ3 KQ0KICAgIFZlcnNpb246IDQNCiAgICBIZWFkZXIgbGVuZ3RoOiAyMCBieXRlcw0KICAgIERpZmZl cmVudGlhdGVkIFNlcnZpY2VzIEZpZWxkOiAweDAwIChEU0NQIDB4MDA6IERlZmF1bHQ7IEVDTjog MHgwMCkNCiAgICAgICAgMDAwMCAwMC4uID0gRGlmZmVyZW50aWF0ZWQgU2VydmljZXMgQ29kZXBv aW50OiBEZWZhdWx0ICgweDAwKQ0KICAgICAgICAuLi4uIC4uMC4gPSBFQ04tQ2FwYWJsZSBUcmFu c3BvcnQgKEVDVCk6IDANCiAgICAgICAgLi4uLiAuLi4wID0gRUNOLUNFOiAwDQogICAgVG90YWwg TGVuZ3RoOiAzNg0KICAgIElkZW50aWZpY2F0aW9uOiAweDc5ZWEgKDMxMjEwKQ0KICAgIEZsYWdz OiAweDA0DQogICAgICAgIDAuLi4gPSBSZXNlcnZlZCBiaXQ6IE5vdCBzZXQNCiAgICAgICAgLjEu LiA9IERvbid0IGZyYWdtZW50OiBTZXQNCiAgICAgICAgLi4wLiA9IE1vcmUgZnJhZ21lbnRzOiBO b3Qgc2V0DQogICAgRnJhZ21lbnQgb2Zmc2V0OiAwDQogICAgVGltZSB0byBsaXZlOiA2MQ0KICAg IFByb3RvY29sOiBTQ1RQICgweDg0KQ0KICAgIEhlYWRlciBjaGVja3N1bTogMHg1MzNkIChjb3Jy ZWN0KQ0KICAgIFNvdXJjZTogMTAuMTg3LjI1LjIxMiAoMTAuMTg3LjI1LjIxMikNCiAgICBEZXN0 aW5hdGlvbjogMTAuMTMuNjUuMTQ3ICgxMC4xMy42NS4xNDcpDQpTdHJlYW0gQ29udHJvbCBUcmFu c21pc3Npb24gUHJvdG9jb2wNCiAgICBTb3VyY2UgcG9ydDogMjkwNQ0KICAgIERlc3RpbmF0aW9u IHBvcnQ6IDQ5MTUyDQogICAgVmVyaWZpY2F0aW9uIHRhZzogMHg4MWM1MDcxMQ0KICAgIENoZWNr c3VtOiAweGM3ZmMzMmZkIChjb3JyZWN0IENSQzMyQykNCiAgICBBQk9SVCBjaHVuaw0KICAgICAg ICBDaHVuayB0eXBlOiBBQk9SVCAoNikNCiAgICAgICAgICAgIDAuLi4gLi4uLiA9IEJpdDogU3Rv cCBwcm9jZXNzaW5nIG9mIHRoZSBwYWNrZXQNCiAgICAgICAgICAgIC4wLi4gLi4uLiA9IEJpdDog RG8gbm90IHJlcG9ydA0KICAgICAgICBDaHVuayBmbGFnczogMHgwMA0KICAgICAgICAgICAgLi4u LiAuLi4wID0gVC1CaXQ6IFRDQiBkZXN0cm95ZWQNCiAgICAgICAgQ2h1bmsgbGVuZ3RoOiA0DQo= ------_=_NextPart_001_01C65787.064B57BB Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran ------_=_NextPart_001_01C65787.064B57BB-- From sigtran-bounces@ietf.org Mon Apr 03 23:27:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQcC5-0001BZ-P5; Mon, 03 Apr 2006 23:27:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQcC4-0001BR-J7 for sigtran@ietf.org; Mon, 03 Apr 2006 23:27:00 -0400 Received: from gw.openss7.com ([142.179.199.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQcC0-0005rZ-HQ for sigtran@ietf.org; Mon, 03 Apr 2006 23:27:00 -0400 Received: from ns.pigworks.openss7.net (IDENT:wMvhAEFbKUEsyFi754luiJEGmXGGF9Sa@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k343Qaq16936; Mon, 3 Apr 2006 21:26:36 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k343Q9Y21701; Mon, 3 Apr 2006 21:26:09 -0600 Date: Mon, 3 Apr 2006 21:26:08 -0600 From: "Brian F. G. Bidulock" To: Edwin.Premkumar@nokia.com Subject: Re: [Sigtran] SCTP Abort case-TCB destroyed Message-ID: <20060403212608.A21478@openss7.org> Mail-Followup-To: Edwin.Premkumar@nokia.com, sigtran@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from Edwin.Premkumar@nokia.com on Mon, Apr 03, 2006 at 08:28:03PM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sigtran-bounces@ietf.org Edwin.Premkumar, Edwin.Premkumar@nokia.com wrote: (Mon, 03 Apr 2006 20:28:03) > > Hi sigtran gurus, > > I am seeing this in an ASP-SGP scenario > > EndPoint A EndPoint B > SCTP-INIT-------------------> > <----------------------INIT_ACK > COOKIE-ECHO-----------> > <---------------------SCTP-ABORT > > In the ABORT CHUNK I see the T-Bit set to 0 (TCB destroyed). > > I have attached the above four packets expanded in a text file for > your reference. > > <> > Why is the ABORT being sent in this case? No application listening on port 2905? --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Apr 05 06:46:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR5Ww-0004mh-2B; Wed, 05 Apr 2006 06:46:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR5Wv-0004mC-BU for Sigtran@ietf.org; Wed, 05 Apr 2006 06:46:29 -0400 Received: from [192.217.199.58] (helo=linkbit2.linkbit.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR5Wu-0007zu-QW for Sigtran@ietf.org; Wed, 05 Apr 2006 06:46:29 -0400 Received: from smikhailov (vallitek.ll.edunet.ru [213.184.131.30]) by linkbit2.linkbit.com (8.13.3/8.13.3) with SMTP id k35AgXNZ040777 for ; Wed, 5 Apr 2006 03:42:34 -0700 (PDT) (envelope-from smikhailov@linkbit.com) Message-ID: <005f01c6589e$2e6eacc0$150f0f0a@smikhailov> From: "Sergey Mikhailov" To: "SIGTRAN" References: Subject: Re: [Sigtran] SCTP Abort case-TCB destroyed Date: Wed, 5 Apr 2006 14:46:15 +0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Status: No, score=-8.0 required=5.0 tests=BAYES_00,HTML_MESSAGE autolearn=no version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on linkbit2.linkbit.com X-Scanned-By: MIMEDefang 2.49 on 192.168.10.6 X-Virus-Scanned: ClamAV 0.87.1/1376/Tue Apr 4 22:51:25 2006 on linkbit2 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Cc: X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0761895032==" Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============0761895032== Content-Type: multipart/alternative; boundary="----=_NextPart_000_005C_01C658BF.B0F74230" This is a multi-part message in MIME format. ------=_NextPart_000_005C_01C658BF.B0F74230 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable SCTP Abort case-TCB destroyedEdwin, Section 5.1 of RFC2960 states: "If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk but decides not to establish the new association due to missing mandatory parameters in the received INIT or INIT ACK, invalid parameter values, or lack of local resources, it MUST respond with an ABORT chunk. It SHOULD also specify the cause of abort, such as the type of the missing mandatory parameters, etc., by including the error cause parameters with the ABORT chunk. The Verification Tag field in the common header of the outbound SCTP packet containing the ABORT chunk MUST be set to the Initiate Tag value of the peer." So, the reasons listed above may have led to this ABORT. Absence of any = error cause, like in this ABORT actually sent in your case, may point to = deviation from behavior, recommended above. Regards, Sergey. ----- Original Message -----=20 From: Edwin.Premkumar@nokia.com=20 To: sigtran@ietf.org=20 Sent: Tuesday, April 04, 2006 5:28 AM Subject: [Sigtran] SCTP Abort case-TCB destroyed Hi sigtran gurus,=20 I am seeing this in an ASP-SGP scenario=20 EndPoint A EndPoint B=20 SCTP-INIT------------------->=20 <----------------------INIT_ACK=20 COOKIE-ECHO----------->=20 <---------------------SCTP-ABORT=20 In the ABORT CHUNK I see the T-Bit set to 0 (TCB destroyed).=20 I have attached the above four packets expanded in a text file for = your reference.=20 <>=20 Why is the ABORT being sent in this case?=20 Is it being treated as an OOTB packet?=20 Thanks =20 Edwin=20 -------------------------------------------------------------------------= ----- _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran ------=_NextPart_000_005C_01C658BF.B0F74230 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable SCTP Abort case-TCB destroyed

Edwin,

Section 5.1 of RFC2960 = states:

   "If an = endpoint receives=20 an INIT, INIT ACK, or COOKIE ECHO chunk but
   decides not = to=20 establish the new association due to missing mandatory
  =20 parameters in the received INIT or INIT ACK, invalid = parameter
  =20 values, or lack of local resources, it MUST respond with an=20 ABORT
   chunk. It SHOULD also specify the cause of = abort,=20 such as the type
   of the missing mandatory parameters, = etc., by=20 including the error
   cause parameters with the ABORT = chunk. =20 The Verification Tag field in
   the common header of the = outbound=20 SCTP packet containing the ABORT
   chunk MUST be set to = the=20 Initiate Tag value of the peer."

So, the reasons listed above may have = led to this=20 ABORT. Absence of any error cause, like in this ABORT actually sent = in your=20 case, may point to deviation from behavior, recommended = above.

Regards,

Sergey.

----- Original Message -----

From:=20 Edwin.Premkumar@nokia.com =

To: sigtran@ietf.org

Sent: Tuesday, April 04, 2006 = 5:28=20 AM

Subject: [Sigtran] SCTP Abort = case-TCB=20 destroyed

Hi sigtran gurus,

I am seeing this in an ASP-SGP scenario =

EndPoint = A     =20         EndPoint B
SCTP-INIT------------------->=20
        <----------------------INIT_ACK
COOKIE-ECHO----------->=20
        <---------------------SCTP-ABORT

In the ABORT CHUNK I see the T-Bit set = to 0 (TCB=20 destroyed).

I have attached the above four packets = expanded in=20 a text file for your reference.

<<sctp_abort_case.txt>>=20
Why is the ABORT being sent in = this=20 case?

Is it being treated as an OOTB = packet?

Thanks &nbs= p; = ; = &= nbsp; =20

Edwin

_______________________________________________
Sigtran = mailing=20 = list
Sigtran@ietf.org
https://www1.ietf.org/mailman/listinfo/sigtra= n
------=_NextPart_000_005C_01C658BF.B0F74230-- --===============0761895032== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============0761895032==-- From sigtran-bounces@ietf.org Sat Apr 08 09:44:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSDjm-0001hI-K8; Sat, 08 Apr 2006 09:44:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSDjl-0001bU-Bb for sigtran@ietf.org; Sat, 08 Apr 2006 09:44:25 -0400 Received: from gw.openss7.com ([142.179.199.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSDjj-0004a2-Hq for sigtran@ietf.org; Sat, 08 Apr 2006 09:44:25 -0400 Received: from ns.pigworks.openss7.net (IDENT:swVpATT2xRYfVTr3bet5dyaGcYnShmsW@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k38DiMq10181; Sat, 8 Apr 2006 07:44:22 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k38DiKf22131; Sat, 8 Apr 2006 07:44:20 -0600 Date: Sat, 8 Apr 2006 07:44:20 -0600 From: "Brian F. G. Bidulock" To: devayya Message-ID: <20060408074420.A21886@openss7.org> Mail-Followup-To: devayya , Mark Butler , sigtran@ietf.org References: <44362D55.1040806@alcatel.com> <24A3ABE8-1B4B-4127-8AF9-70BEAD16801C@lurchi.franken.de> <44365568.2010902@alcatel.com> <44366FF9.7020801@middle.net> <443736E6.6050004@alcatel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <443736E6.6050004@alcatel.com>; from devayya.bopaiah@alcatel.com on Sat, Apr 08, 2006 at 09:37:02AM +0530 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: sigtran@ietf.org, Mark Butler Subject: [Sigtran] Re: [Tsvwg] SCTP multi-homing association X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sigtran-bounces@ietf.org devayya, Well, if you push the connection beyond its capacity, delay will increase. When delay increases beyond T7, M2PA will consider the signalling link unusable. Delay under load, however, can be aggravated if you are sending a SACK or a retransmission to the failed interface by mistake. This is probably a question for SIGTRAN instead of TSVWG, so I have redirected it there. --brian devayya wrote: (Sat, 08 Apr 2006 09:37:02) > Hi Mark, > > Please see inline comments. > > > Mark Butler wrote: > > > First of all, can you tell us which OS and SCTP implementation you are > > using? If not a common one, 'internal/proprietary' is fine. > > I am using Lynx RTOS(version 3.0.0) and the SCTP implementation is done > inhouse according to the rfc2960, with some changes from SCTP > implementors guide version 14. > > > A few comments: > > > > 1. Normally in SCTP, associations do not go active / inactive, paths > > do. 2. Delayed ACK timer expiry is a normal event that is not an > > indication of a failure, > > Here I was talking about the Upper Layer links(M2PA) going ACTIVE and > INACTIVE. and also the delay ACK timer is the Upper Layer delay ack > timer(T7 timer). I had metioned in my first mail that the SCTP > association remains in ESTABLISHED state, but the Upper Layer link(M2PA) > goes INACTIVE, probably due to no-delivery of the message from SCTP. > I am sorry, that everybody misunderstood this as SCTP delay ack timer > expiry. My mistake, I should have been more clear. > > > 3. If a DATA chunk is lost, either a later SACK or the T3 timer will > > eventually trigger a retransmission, which is supposed to be on an > > alternate path if available. > > I agree. > > > > > 4. If a DATA chunk is received but a SACK is lost, and there are no > > follow on SACKs, the DATA chunk will also be retransmitted in the same > > manner, but ignored since it was already received. > > This could be one of the reason. > > > 5. Max.Burst probably doesn't have anything to do with your problem. > > I agree. > > > > > - Mark B. > > > > > Thanks and regards, > devayya > > >>> On Apr 7, 2006, at 11:13 AM, devayya wrote: > >>> > >>>> Hi, > >>>> > >>>> I have a question on SCTP multi-homing, > >>>> > >>>> My SCTP multi-homing test set up is as follows, > >>>> There are two etherenet ports with different ip address are > >>>> configured for one endpoint(say endpont A). and similarly I have > >>>> another endpoint (say endpoint B) with two ethernet ports with > >>>> different ip addresses. The association between two endpoints is > >>>> ESTABLISHED. > >>>> > >>>> Using a test tool I transmit traffic between these two endpoints. > >>>> With less amount of traffic flowing, if one of the ethernet port > >>>> IP address is lost, then the association between these two > >>>> endpoints remain ACTIVE and the traffic flows on the second > >>>> ethernet port.(As per multi-homing requirement) > >>>> With increase in traffic flowing, if one of the ethernet port IP > >>>> address is lost, then the association between these two endpoints > >>>> goes to INACTIVE. and there is traffic loss. Although the SCTP > >>>> association is still present, the ULP association goes down, with > >>>> the reason "delay ACK timer expiry". Can anybody help find out why? > >>>> > >>>> As per SCTP implemtors guide, there is mention of updation of > >>>> cwnd when user tries to transmit DATA, cwnd should be modified > >>>> depending on the flightsize and a newly introduced MAX.BURST.(not > >>>> present in RFC) > >>>> if((flightsize + Max.Burst*MTU) < cwnd) > >>>> cwnd = flightsize + Max.Burst*MTU > >>>> > >>>> Is it really needed to implement this MAX.BURST? > >>>> Will addition of this MAX.BURST solve the earlier problem > >>>> mentioned by me? > >>>> > >>>> Thanks and regards, > >>>> devayya > >>>> > >>>> P.s: For your reference I have attached a text file of the set up. > >>>> > > -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Apr 13 07:42:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU0DX-0005Vv-FK; Thu, 13 Apr 2006 07:42:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU0DW-0005Vq-GB for sigtran@ietf.org; Thu, 13 Apr 2006 07:42:30 -0400 Received: from web37405.mail.mud.yahoo.com ([209.191.87.58]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FU0DV-0001Gz-QX for sigtran@ietf.org; Thu, 13 Apr 2006 07:42:30 -0400 Received: (qmail 19508 invoked by uid 60001); 13 Apr 2006 11:42:29 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=C4//nRtyrC6i3B2WBlHNV3aSg9MV9R+COZ72jssB1Q7QUNWENEUBEwrGljxqCnffBGq9kvzZmcgSgNLj1GmrapAIAUdAhdrgRzyS8HxOUerMrrBaE3QYncfIqhbX5sZcEHLJtYFOZS8ul/wUMK8sQDcmSKpi9a4PnCknbv1HEgo= ; Message-ID: <20060413114229.19506.qmail@web37405.mail.mud.yahoo.com> Received: from [203.145.132.252] by web37405.mail.mud.yahoo.com via HTTP; Thu, 13 Apr 2006 04:42:29 PDT Date: Thu, 13 Apr 2006 04:42:29 -0700 (PDT) From: ash kat To: sigtran@ietf.org MIME-Version: 1.0 X-Spam-Score: 1.1 (+) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Subject: [Sigtran] SCTP : ambiguity in handling invalid cookie in COOKIE ECHO chunks X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1024429685==" Errors-To: sigtran-bounces@ietf.org --===============1024429685== Content-Type: multipart/alternative; boundary="0-499522563-1144928549=:18184" Content-Transfer-Encoding: 8bit --0-499522563-1144928549=:18184 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi All I was looking at the behavior of SCTP stack when the COOKIE ECHO chunk contains the invalid cookie. The following section of RFC2960 are conflicting each other: Section 4 (Page# 50) Notes: 1) If the State Cookie in the received COOKIE ECHO is invalid (i.e., failed to pass the integrity check), the receiver MUST silently discard the packet. Or, if the received State Cookie is expired (see Section 5.1.5), the receiver MUST send back an ERROR chunk. In either case, the receiver stays in the CLOSED state. Section 5.1 (Page# 52) If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk but decides not to establish the new association due to missing mandatory parameters in the received INIT or INIT ACK, invalid parameter values, or lack of local resources, it MUST respond with an ABORT chunk. It SHOULD also specify the cause of abort, such as the type of the missing mandatory parameters, etc., by including the error cause parameters with the ABORT chunk. The Verification Tag field in the common header of the outbound SCTP packet containing the ABORT chunk MUST be set to the Initiate Tag value of the peer. Section 5.1.5 (Page# 56) 2) Authenticate the State Cookie as one that it previously generated by comparing the computed MAC against the one carried in the State Cookie. If this comparison fails, the SCTP packet, including the COOKIE ECHO and any DATA chunks, should be silently discarded. Please help me resolving this conflict. In my point of view there should be only one of these three actions, which should be specified when the SCTP receive the COOKIE ECHO chunk with an invalid cookie. i) MUST silently discard ii) MUST respond with an ABORT iii) should be silently discarded. ---------- K. �sh ---------- --------------------------------- How low will we go? Check out Yahoo! Messenger�s low PC-to-Phone call rates. --0-499522563-1144928549=:18184 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Hi All

I was looking at the behavior of SCTP stack when the COOKIE ECHO chunk contains the invalid cookie.

The following section of RFC2960 are conflicting each other:

Section 4 (Page# 50)
Notes:

   1) If the State Cookie in the received COOKIE ECHO is invalid (i.e.,
      failed to pass the integrity check), the receiver MUST silently
      discard the packet. Or, if the received State Cookie is expired
      (see Section 5.1.5), the receiver MUST send back an ERROR chunk.
      In either case, the receiver stays in the CLOSED state.

Section 5.1 (Page# 52)

   If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk but
   decides not to establish the new association due to missing mandatory
   parameters in the received INIT or INIT ACK, invalid parameter
   values, or lack of local resources, it MUST respond with an ABORT
   chunk. It SHOULD also specify the cause of abort, such as the type
   of the missing mandatory parameters, etc., by including the error
   cause parameters with the ABORT chunk. The Verification Tag field in
   the common header of the outbound SCTP packet containing the ABORT
   chunk MUST be set to the Initiate Tag value of the peer.

Section 5.1.5 (Page# 56)

   2) Authenticate the State Cookie as one that it previously generated
      by comparing the computed MAC against the one carried in the State
      Cookie. If this comparison fails, the SCTP packet, including the
      COOKIE ECHO and any DATA chunks, should be silently discarded.

Please help me resolving this conflict.

In my point of view there should be only one of these three actions, which should be specified when the SCTP receive the COOKIE ECHO chunk with an invalid cookie.

i) MUST silently discard

ii) MUST respond with an ABORT

iii) should be silently discarded.

----------

K. �sh

----------

How low will we go? Check out Yahoo! Messenger�s low PC-to-Phone call rates. --0-499522563-1144928549=:18184-- --===============1024429685== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============1024429685==-- From sigtran-bounces@ietf.org Fri Apr 14 05:00:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUKAU-0001f0-Rp; Fri, 14 Apr 2006 05:00:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUKAS-0001en-Q4; Fri, 14 Apr 2006 05:00:40 -0400 Received: from mail.sbs.be ([193.109.72.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUKAQ-0001aS-7X; Fri, 14 Apr 2006 05:00:40 -0400 Received: from bruc001x.sbs.be (bruc001x.sbs.be [193.210.175.38]) by mail.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k3E8vcbX026329; Fri, 14 Apr 2006 10:57:38 +0200 Received: from bru0007a.ww018.siemens.net (bru0007a.ww018.siemens.net [193.210.175.161]) by bruc001x.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k3E8va4b015567; Fri, 14 Apr 2006 10:57:36 +0200 Received: from BRU0038A.ww018.siemens.net ([193.210.175.64]) by bru0007a.ww018.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Apr 2006 10:57:33 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Apr 2006 10:57:31 +0200 Message-ID: <67043E463DDBFD4A8087ED940BFF756B9CDDCF@BRU0038A.ww018.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Sctp on Microsoft Windows machines Thread-Index: AcZfoXaK4ZIa2uKVQ4SPApTWDYgspg== From: "Coene, Lode" To: , , , X-OriginalArrivalTime: 14 Apr 2006 08:57:33.0074 (UTC) FILETIME=[77CA0720:01C65FA1] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Michael.Tuexen@micmac.franken.de Subject: [Sigtran] Sctp on Microsoft Windows machines X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sigtran-bounces@ietf.org The SCTP library user land implementation( http://www.sctp.de ) developed by the=20 University of Essen and the University of Munster is also able to be compiled and=20 used on a Microsoft Windows operating system.=20 I've tested it on a Windows XP machne and have made a Windows Installer for it. It should install on a Windows XP SP2 and also on Windows 2000.=20 You can find the Windows installer for SCTPlib at http://www.sctp.be/sctplib It contains the compiled sctplib library, some sample program and the source code.=20 The source code can also be downloaded at http://www.sctp.de Many thanks to Michael Tuxen and associates for making this possible. If there are problems with the installer, send a mail to email:sctp@sctp.be=20 or to the discussion forum at http://www.sctp.de (Watch out: download at .be, discussion at .de) Yours sincerely, Lode Coene Siemens COM atealaan 34 2200 Herentals, Belgium E-mail: lode.coene@siemens.com Tel: +32-14-252081 Fax: +32-14-253212 _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran