Re: [M2UA, IUA] Stream to be used for ASPTM messages

"Brian F. G. Bidulock" <[email protected]>
Newsgroups gmane.ietf.sigtran
Organization http://www.openss7.org/
Message-ID <[email protected]>
Santhana,

Please see comments below:

Santhana wrote:                            (Wed, 03 Mar 2010 19:26:09)

---X--snip--X---
> On section 1.5.4.1  SCTP Stream Management
>    SCTP Stream '0' SHOULD NOT be used for MTP2 User Adaptation (MAUP)
>    messages (see Section 3) since stream '0' SHOULD only be used for ASP
>    Management (ASPM) messages (see Section 4.3.3).
> And RFC explains all the ASPSM/ASPTM messages as ASPM messages. So there seems 
> to be a contradiction here in RFC.
> 
>    ===>As per this ASPTM should be sent on stream 0

Yes, ASPM should read ASPSM in section 1.5.4.1 above.

> And for IUA is SCTP stream management aligned(same as) with M2UA ?

No.

The reasons for sending ASPTM and BEAT/ACK on a traffic stream
are primarily to avoid message loss due to deactivation of the
AS (at SGP or ASP) before the last data message has arrived for
the deactivated traffic.  Sending the messages last and
sequenced on the data stream ensures that, once the acknowledge
is received, no messages are in transit to the peer UA.

This is important to meet SS7's stringently low message loss
requirements.

See http://tools.ietf.org/html/draft-bidulock-sigtran-corid-05
for other procedures that can reduce message loss that are in
fitting with this use of ASPTM and BEAT/ACK.

ISDN has far less stringent requirments and, thus, the procedures
are not necessary for IUA and IUA sends all ASPM messages on
stream 0.

Historically, IUA was written first and M2UA came second
borrowing a lot from IUA.  Section 4.2.1 was updated correctly,
but Section 1.5.4.1 still uses the IUA statements, which do
not apply to M2UA.

Please submit an Errata against RFC 3331 for this.

--brian


-- 
Brian F. G. Bidulock
[email protected]
http://www.openss7.org/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.