Subject: [Sigtran] M3UA ASP UP message format

From: [email-masked]
Date: Sat, 11 Feb 2006 13:40:26 -0600

Hi,

I have a question regarding the format of the M3UA ASP UP message
initiated by the ASP to the SGP.

I wanted to know if this is a valid format according to the specs. RFC
3332 section 4.3.4 ASPM Procedures for Peer-to-Peer Messages mentions
that M3UA ASP UP can be retransmitted after Timer T(ack) expires.
"When the ASP sends an ASP Up message it starts timer T(ack). If the ASP
does not receive a response to an ASP Up message within T(ack), the ASP
MAY restart T(ack) and resend ASP Up messages until it receives an ASP
Up Ack message. T(ack) is provisionable, with a default of 2 seconds."

No.     Time                       Source          Destination
Protocol Info
23 2006-01-27 23:04:37 10.4.82.54      10.169.97.204         M3UA (RFC
3332) ASPUP ASPUP ASPUP ASPUP ASPUP ASPUP ASPUP ASPUP ASPUP ASPUP ASPUP
ASPUP ASPUP ASPUP ASPUP ASPUP ASPUP ASPUP ASPUP ASPUP ASPUP ASPUP ASPUP
ASPUP ASPUP 

The entire packet expanded has been attached in the text file.

 <<m3ua_aspup.txt>> 
Thanks
Edwin
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 11 Feb 2006 13:39:59 -0700

Edwin,

A little more information is in order:  are these ASPUP messages (TSNs)
being sent for the first time?  If so, perhaps the designer took the
"and resend ASP Up messages until it receives an ASP Up Ack message"
too literally; the intention was to resend one ASP Up with each timer
expiry.  If they are being retransmitted (e.g. because the peer host
crashed), it could be more normal.

The retransmission of ASPUP is a purely optional procedure (the "MAY"),
and is questionable at best on a reliable transport.  (The M3UA spec
leaves the door open, a crack, for unreliable transport.)

A better procedure for reliable transport is to notify management on
expiry of the timer rather than resending ASP Up (but note clearly the
"MAY" on the procedure).  Also, once the timer has expired a number of
times, (say 60), generate a more critical alarm (but keep waiting).

--brian

[email-masked] wrote:              (Sat, 11 Feb 2006 13:40:26)

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: [email-masked]
Date: Sat, 11 Feb 2006 16:01:01 -0600

Brian,

Actually the traces were taken after the peer host crashed. 

Since the M3UA ASPUP message is sent only after the lower layer SCTP
association is established (SCTP INIT and SCTP INIT ACK), does the
sending of the M3UA ASPUP message in this scenario indicate that the
SCTP association has been already established or is that undeterminable
on account of the peer host crashing. 

Does it mean that the behavior of the ASP client in this case is normal
considering that the host had crashed? 

Thanks 
Edwin

>-----Original Message-----
>From: ext Brian F. G. Bidulock [mailto:[email-masked]] 
>Sent: Saturday, February 11, 2006 2:40 PM
>To: Premkumar Edwin (Nokia-NET/Dallas)
>Cc: [email-masked]
>Subject: Re: [Sigtran] M3UA ASP UP message format
>
>Edwin,
>
>A little more information is in order:  are these ASPUP 
>messages (TSNs) being sent for the first time?  If so, perhaps 
>the designer took the "and resend ASP Up messages until it 
>receives an ASP Up Ack message"
>too literally; the intention was to resend one ASP Up with 
>each timer expiry.  If they are being retransmitted (e.g. 
>because the peer host crashed), it could be more normal.
>
>The retransmission of ASPUP is a purely optional procedure 
>(the "MAY"), and is questionable at best on a reliable 
>transport.  (The M3UA spec leaves the door open, a crack, for 
>unreliable transport.)
>
>A better procedure for reliable transport is to notify 
>management on expiry of the timer rather than resending ASP Up 
>(but note clearly the "MAY" on the procedure).  Also, once the 
>timer has expired a number of times, (say 60), generate a more 
>critical alarm (but keep waiting).
>
>--brian
>
>
>> "When the ASP sends an ASP Up message it starts timer T(ack). If the 
>> ASP does not receive a response to an ASP Up message within T(ack), 
>> the ASP MAY restart T(ack) and resend ASP Up messages until it 
>> receives an ASP Up Ack message. T(ack) is provisionable, 
>with a default of 2 seconds."
>> 
>> 3332) ASPUP ASPUP ASPUP ASPUP ASPUP ASPUP ASPUP ASPUP ASPUP ASPUP 
>> ASPUP ASPUP ASPUP ASPUP ASPUP ASPUP ASPUP ASPUP ASPUP ASPUP ASPUP 
>> ASPUP ASPUP ASPUP ASPUP
>>

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 11 Feb 2006 15:31:44 -0700

Edwin,

If you see traces like this every two seconds or so (or T(ack)):

  M3UA ASPUP
  M3UA ASPUP ASPUP
  M3UA ASPUP ASPUP ASPUP
  M3UA ASPUP ASPUP ASPUP ASPUP
  etc.

then the fact that the peer crashed probably means that the SCTP
association is dead and the sender just doesn't know about it yet.
Under the right conditions it could take several minutes for the
SCTP sender to mark the association down.

An SCTP stack that performs receipt verification could inform the
M3UA layer that the original ASPUP has not even been acknowleged
by SCTP at the peer and avoid sending all these ASPUPs.

Because there are so many ways in which the peer can crash (SCTP
alive M3UA dead, IP alive SCTP dead M3UA dead) it appears that the
implementation is behaving correctly.  It certainly is behaving
better than the peer that crashed.

--brian

[email-masked] wrote:              (Sat, 11 Feb 2006 16:01:01)

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/