headers
Edwin.Premkumar | 4 Apr 2006 03:28
Picon

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                                                   

Edwin 

Frame 46 (82 bytes on wire, 82 bytes captured)
    Arrival Time: Apr  3, 2006 19:37:02.009000000
    Time delta from previous packet: 2.002000000 seconds
    Time since reference or first frame: 94.009000000 seconds
    Frame Number: 46
    Packet Length: 82 bytes
    Capture Length: 82 bytes
Ethernet II, Src: 00:00:50:19:d6:35, Dst: 00:14:6a:fd:35:20
    Destination: 00:14:6a:fd:35:20 (00:14:6a:fd:35:20)
    Source: 00:00:50:19:d6:35 (Radisys_19:d6:35)
    Type: IP (0x0800)
Internet Protocol, Src Addr: 10.13.65.147 (10.13.65.147), Dst Addr: 10.187.25.212 (10.187.25.212)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 68
    Identification: 0x7342 (29506)
    Flags: 0x00
        0... = Reserved bit: Not set
        .0.. = Don't fragment: Not set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 64
    Protocol: SCTP (0x84)
    Header checksum: 0x96c5 (correct)
    Source: 10.13.65.147 (10.13.65.147)
    Destination: 10.187.25.212 (10.187.25.212)
Stream Control Transmission Protocol
    Source port: 49152
    Destination port: 2905
    Verification tag: 0x00000000
    Checksum: 0xfcb753be (correct CRC32C)
    INIT chunk (Outbound streams: 2, inbound streams: 2048)
        Chunk type: INIT (1)
            0... .... = Bit: Stop processing of the packet
            .0.. .... = Bit: Do not report
        Chunk flags: 0x00
        Chunk length: 36
        Initiate tag: 0x81c50711
        Advertised receiver window credit (a_rwnd): 134656
        Number of outbound streams: 2
        Number of inbound streams: 2048
        Initial TSN: 3132905688
        Supported address types parameter (Supported types: IPv4, IPv6)
            Parameter type: Supported address types (0x000c)
                0... .... .... .... = Bit: Stop processing of chunk
                .0.. .... .... .... = Bit: Do not report
            Parameter length: 8
            Supported address type: IPv4 address (5)
            Supported address type: IPv6 address (6)
        ECN parameter
            Parameter type: ECN (0x8000)
                1... .... .... .... = Bit: Skip parameter and continue prosessing of the chunk
                .0.. .... .... .... = Bit: Do not report
            Parameter length: 4
        Forward TSN supported parameter
            Parameter type: Forward TSN supported (0xc000)
                1... .... .... .... = Bit: Skip parameter and continue prosessing of the chunk
                .1.. .... .... .... = Bit: Do report
            Parameter length: 4

Frame 47 (458 bytes on wire, 458 bytes captured)
    Arrival Time: Apr  3, 2006 19:37:02.029000000
    Time delta from previous packet: 0.020000000 seconds
    Time since reference or first frame: 94.029000000 seconds
    Frame Number: 47
    Packet Length: 458 bytes
    Capture Length: 458 bytes
Ethernet II, Src: 00:14:6a:fd:35:20, Dst: 00:00:50:19:d6:35
    Destination: 00:00:50:19:d6:35 (Radisys_19:d6:35)
    Source: 00:14:6a:fd:35:20 (00:14:6a:fd:35:20)
    Type: IP (0x0800)
Internet Protocol, Src Addr: 10.187.25.212 (10.187.25.212), Dst Addr: 10.13.65.147 (10.13.65.147)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 444
    Identification: 0x79e9 (31209)
    Flags: 0x04
        0... = Reserved bit: Not set
        .1.. = Don't fragment: Set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 61
    Protocol: SCTP (0x84)
    Header checksum: 0x51a6 (correct)
    Source: 10.187.25.212 (10.187.25.212)
    Destination: 10.13.65.147 (10.13.65.147)
Stream Control Transmission Protocol
    Source port: 2905
    Destination port: 49152
    Verification tag: 0x81c50711
    Checksum: 0x45fd0fd4 (correct CRC32C)
    INIT_ACK chunk (Outbound streams: 10, inbound streams: 2)
        Chunk type: INIT_ACK (2)
            0... .... = Bit: Stop processing of the packet
            .0.. .... = Bit: Do not report
        Chunk flags: 0x00
        Chunk length: 412
        Initiate tag: 0x0d794fb2
        Advertised receiver window credit (a_rwnd): 16384
        Number of outbound streams: 10
        Number of inbound streams: 2
        Initial TSN: 226054066
        State cookie parameter (Cookie length: 360 bytes)
            Parameter type: State cookie (0x0007)
                0... .... .... .... = Bit: Stop processing of chunk
                .0.. .... .... .... = Bit: Do not report
            Parameter length: 364
            State cookie: 81C5071100020E00000A000FBABC58D8...
        IPv4 address parameter (Address: 10.187.25.196)
            Parameter type: IPv4 address (0x0005)
                0... .... .... .... = Bit: Stop processing of chunk
                .0.. .... .... .... = Bit: Do not report
            Parameter length: 8
            IP Version 4 address: 10.187.25.196 (10.187.25.196)
        IPv4 address parameter (Address: 10.187.25.212)
            Parameter type: IPv4 address (0x0005)
                0... .... .... .... = Bit: Stop processing of chunk
                .0.. .... .... .... = Bit: Do not report
            Parameter length: 8
            IP Version 4 address: 10.187.25.212 (10.187.25.212)
        Unrecognized parameter parameter
            Parameter type: Unrecognized parameter (0x0008)
                0... .... .... .... = Bit: Stop processing of chunk
                .0.. .... .... .... = Bit: Do not report
            Parameter length: 12
            Forward TSN supported parameter
                Parameter type: Forward TSN supported (0xc000)
                    1... .... .... .... = Bit: Skip parameter and continue prosessing of the chunk
                    .1.. .... .... .... = Bit: Do report
                Parameter length: 4
                Parameter padding: 80000004

Frame 48 (410 bytes on wire, 410 bytes captured)
    Arrival Time: Apr  3, 2006 19:37:02.029000000
    Time delta from previous packet: 0.000000000 seconds
    Time since reference or first frame: 94.029000000 seconds
    Frame Number: 48
    Packet Length: 410 bytes
    Capture Length: 410 bytes
Ethernet II, Src: 00:00:50:19:d6:35, Dst: 00:14:6a:fd:35:20
    Destination: 00:14:6a:fd:35:20 (00:14:6a:fd:35:20)
    Source: 00:00:50:19:d6:35 (Radisys_19:d6:35)
    Type: IP (0x0800)
Internet Protocol, Src Addr: 10.13.65.147 (10.13.65.147), Dst Addr: 10.187.25.212 (10.187.25.212)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 396
    Identification: 0x7344 (29508)
    Flags: 0x04
        0... = Reserved bit: Not set
        .1.. = Don't fragment: Set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 64
    Protocol: SCTP (0x84)
    Header checksum: 0x557b (correct)
    Source: 10.13.65.147 (10.13.65.147)
    Destination: 10.187.25.212 (10.187.25.212)
Stream Control Transmission Protocol
    Source port: 49152
    Destination port: 2905
    Verification tag: 0x0d794fb2
    Checksum: 0x28231f87 (correct CRC32C)
    COOKIE_ECHO chunk (Cookie length: 360 bytes)
        Chunk type: COOKIE_ECHO (10)
            0... .... = Bit: Stop processing of the packet
            .0.. .... = Bit: Do not report
        Chunk flags: 0x00
        Chunk length: 364
        Cookie: 81C5071100020E00000A000FBABC58D8...

Frame 49 (60 bytes on wire, 60 bytes captured)
    Arrival Time: Apr  3, 2006 19:37:02.049000000
    Time delta from previous packet: 0.020000000 seconds
    Time since reference or first frame: 94.049000000 seconds
    Frame Number: 49
    Packet Length: 60 bytes
    Capture Length: 60 bytes
Ethernet II, Src: 00:14:6a:fd:35:20, Dst: 00:00:50:19:d6:35
    Destination: 00:00:50:19:d6:35 (Radisys_19:d6:35)
    Source: 00:14:6a:fd:35:20 (00:14:6a:fd:35:20)
    Type: IP (0x0800)
    Trailer: 00000000000000000000
Internet Protocol, Src Addr: 10.187.25.212 (10.187.25.212), Dst Addr: 10.13.65.147 (10.13.65.147)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 36
    Identification: 0x79ea (31210)
    Flags: 0x04
        0... = Reserved bit: Not set
        .1.. = Don't fragment: Set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 61
    Protocol: SCTP (0x84)
    Header checksum: 0x533d (correct)
    Source: 10.187.25.212 (10.187.25.212)
    Destination: 10.13.65.147 (10.13.65.147)
Stream Control Transmission Protocol
    Source port: 2905
    Destination port: 49152
    Verification tag: 0x81c50711
    Checksum: 0xc7fc32fd (correct CRC32C)
    ABORT chunk
        Chunk type: ABORT (6)
            0... .... = Bit: Stop processing of the packet
            .0.. .... = Bit: Do not report
        Chunk flags: 0x00
            .... ...0 = T-Bit: TCB destroyed
        Chunk length: 4

_______________________________________________
Sigtran mailing list
Sigtran <at> ietf.org
https://www1.ietf.org/mailman/listinfo/sigtran
Permalink | Reply | 2 comments |
headers
Brian F. G. Bidulock | 4 Apr 2006 05:26
Favicon

Re: SCTP Abort case-TCB destroyed

Edwin.Premkumar,

Edwin.Premkumar <at> 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.
> 
>    <<sctp_abort_case.txt>>
>    Why is the ABORT being sent in this case?

No application listening on port 2905?

--brian

--

-- 
Brian F. G. Bidulock
bidulock <at> openss7.org
http://www.openss7.org/
Permalink | Reply | 0 comments |
headers
Sergey Mikhailov | 5 Apr 2006 12:46
Favicon

Re: SCTP Abort case-TCB destroyed

Edwin,
 
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 -----
Sent: Tuesday, April 04, 2006 5:28 AM
Subject: [Sigtran] 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                                                   

Edwin

_______________________________________________
Sigtran mailing list
Sigtran <at> ietf.org
https://www1.ietf.org/mailman/listinfo/sigtran
_______________________________________________
Sigtran mailing list
Sigtran <at> ietf.org
https://www1.ietf.org/mailman/listinfo/sigtran
Permalink | Reply | 0 comments |
headers
Brian F. G. Bidulock | 8 Apr 2006 15:44
Favicon

Re: [Tsvwg] SCTP multi-homing association

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 <at> openss7.org
http://www.openss7.org/
Permalink | Reply | 2 comments |
headers
ash kat | 13 Apr 2006 13:42
Picon
Favicon

SCTP : ambiguity in handling invalid cookie in COOKIE ECHO chunks

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
  &n bsp;   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. 
_______________________________________________
Sigtran mailing list
Sigtran <at> ietf.org
https://www1.ietf.org/mailman/listinfo/sigtran
Permalink | Reply | 0 comments |
headers
Coene, Lode | 14 Apr 2006 10:57
Picon

Sctp on Microsoft Windows machines

The SCTP library user land implementation( http://www.sctp.de )
developed by the 
University of Essen and the University of Munster is also able to be
compiled and 
used on a Microsoft Windows operating system. 

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. 

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. 

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 <at> sctp.be 
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 <at> siemens.com
Tel: +32-14-252081
Fax: +32-14-253212
Permalink | Reply | 1 comment |

Gmane