Subject: Re: A query

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 30 Aug 2001 02:59:55 -0500

Vaibhav,

Please see additional remarks below...

[email-masked] wrote:               (Thu, 30 Aug 2001 11:50:55)
>
> Hi
>     Thanx for the quick reply but still i have some doubts in mind.
> 
> 1)At the M3UA level, there is no knowledge of the sequence numbers being
> used at SCTP Association level. But if we see the MTP network, then MTP3 has
> knowledge about the sequence numbers being used in MTP2 level and whenever a
> link fails it can move the messages which were to be transferred over the
> failed link to another working link.

I wouldn't really say that MTP3 has a knowledge of MTP2 sequence numbers.
MTP3 has a changeover procedure where a sequence number is received from
the far end of a link and is provided to the local MTP2 to retrieve buffers.
MTP3 doesn't really care what that sequenc number is, nor does it have
any way of checking its validity in the models in the SS7 specifications.
Although MTP COO/COA messages transport the sequence number, it is MTP2's
job to check it for validity and return the necessary buffers to MTP2.
MTP3 also has the time-controlled and emergency changeover procedures
which complete without sequence number use at all.

> So do you really feel M3UA can take care of message duplication without a
> knowledge of the sequence numbers being used in the SCTP level.

Procedures which correspond to time-controlled procedures (which I described)
and emergency changeover (without sequence numbers) can easily be performed
locally and without haveing to involve the SCTP peer.  If Correlation Id is
used, it would provide an M3UA sequence number which is not dependent on any
given association, but which identifies MSUs across associations.  Then it
would not matter if TCP was used as transport.

> 2) We will start buffering at the M3UA level only after we receive an
> indication from SCTP that the SCTP Association is down. Between the time we
> received this notification and the time when the Association actually went
> down, all the messages will have been given to the SCTP Association which
> cannot be retrieved back as of now.

This sounds like an SCTP implementation specific problem.  SCTP supports
the concept of retrieving both untransmitted and unacknowledged messages.
The SCTP socket draft provides a retrieval mechanism across a modified
sockets API.

For SCTP implementations which cannot support retrieval, I proposed that
a Correlation Id Ack be permitted in M3UA so that a separate sequence
number and application level acknowledgement could be performed outside
of SCTP, but Greg told me that this wasn't required for M3UA.  Perhaps
you could ask Greg why M3UA could not benefit from a separate acknowledgement.

> This is in contrast to the MTP implementation in which MTP3 can retrieve
> messages from MTP2 link buffer of the failed link and put it into another
> buffer

Again, this *is* provided for in SCTP, may just not in the implementation
of SCTP that you have at hand.

> ( The MTP things are according to my understanding of the MTP network. They
> might be wrong in some manner) Can't such a standard failover communication
> mechanism be provided between SCTP and M3UA in any way (I think standards
> are much better than implementation dependencies) .

Maybe not too suprisingly SCTP (RFC 2960) does not standardize the SCTP ULP
interface.  It provides some description of the interface that one might use,
but the actualy interface is up to the implementation.  Without an SCTP/ULP
interface standard, it is difficult to describe such mechanisms between
SCTP and M3UA and it is difficult to permit M3UA to rely on mechanisms which
are purely optional for implementation in SCTP.

The SCTP sockets draft provides a mechanism for retrieval near identical
to MTP, but with the added ability to distinguish between messages sent
but not acked and messages not sent.  As these procedures are really optional
in SCTP and M3UA cannot tell the implementation how to meet its performance
requirements (performance and QoS is out of scope) there is not much that
the M3UA draft can do except to say that the implementation should be
wary of loss, duplication and missequencing in its performance of M3uA
procedures (which the draft does say).

Nevertheless, procedures similar to the time-controlled and Correlation Id
procedures which I have described and which do not require the cooperation
of the M3UA peer are IMO more interoperable that the COO/COA procedures of
MTP3 which require close peer-to-peer coordination to be successful.

> 3) it is kind of taking a message from one failed SCTP Association buffer
> and putting it into another SCTP Association buffer.

This is true for override or loadshare AS.  For broadcast AS the message
was in both buffers in the first place and has already been identified with
a Correlation Id.  If you have an SCTP which cannot retrieve buffers, you
should consider using Broadcast mode for the two ASPs because it can handle
changeover without buffer retrieval and has the Correlation Id to ensure
that message loss, missequencing and duplication does not occur (at least
for DATA messages where it counts).

--brian

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

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]