Re: Something improper with ASP state change procedures.

Naveen,

The M3UA layer at the ASP should never see this second ASP UP ACK. The ASP is still active.

From your description, the second ASP UP ACK is an SCTP retransmission. This means it has the same TSN as the original ASP UP ACK. The SCTP layer at the ASP should recognize this as a duplicate chunk and should not pass it on to the M3UA layer.

Andrew

[email protected] wrote: -----

To: [email protected]
From: Naveen Kottapalli
Sent by: [email protected]
Date: 11/23/2010 09:36AM
Subject: [Sigtran] Something improper with ASP state change procedures.

Hi All,



We are seeing some strange in the M3UA ASP state change procedures. Please find the description of the problem below.



ASP SGP

=======================================

ASPUP --------------> Processes ASPUP and sends ASPUP_ACK



Move ASP to

INACTIVE state <------------- ASPUP_ACK



SCTP-SACK

for ASPUP_ACK -------------> Missed or lost in the network



ASPAC --------------> Processes ASPAC and sends ASPAC_ACK




Move ASP to

ACTIVE state <------------- ASPAC_ACK




SCTP-SACK

for ASPAC_ACK -------------> Missed or lost again in the network




Move ASP to

INACTIVE state <------------- SCTP layer at SGP retransmits the ASPUP_ACK, ASPAC_ACK because of lost SACKs.

because of

ASPUP_ACK

in ACTIVE state



SCTP-SACK -------------> Reached the SCTP layer of SGP




In the above behavior the M3UA at SGP thinks that the ASP is in ACTIVE state whereas it is not the case. Since ASP is in INACTIVE state, all the data packets that were sent by SGP will be dropped (without sending any error message back to network). The above problem will lead to a potential message loss in the network.



Considering the above behavior, I think the state machine should be tuned accordingly.



Please pass on the comments on this.




Thanks & Regards,
Naveen.


_______________________________________________
Sigtran mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sigtran

_______________________________________________
Sigtran mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sigtran