Re: Sigtran extension for network management and association changeover.

Dear Brian,

Thanks a lot for the detailed discussion,
please see my comments inline.

Regards
Xiangsong

----- Original Message ----- 
From: "Brian F. G. Bidulock" <[email protected]>
To: "Xiangsong Cui" <[email protected]>
Cc: <[email protected]>
Sent: Monday, March 08, 2010 7:13 PM
Subject: Re: [Sigtran] Sigtran extension for network management and association changeover.


> Xiangsong,
> 
> Please see comments below:
> 
> Xiangsong Cui wrote:                      (Sun, 07 Mar 2010 19:16:32)
>> Dear Brian,
>> 
>> > Suppose that SGP1 in SG2 fails causing associations
>> > ASP1-SG2/SGP1 and ASP2-SG2/SGP1 to be lost.  SG2 must
>> 
>> I'm not very sure about your case.
>> 
>> If the broken-down SGP in your assumption means the SGP hardware,
>> including SCTP and M3UA protocol stack, sequenced changeover can not
>> be achieved anyway.
> 
> Yes it can, see below.
> 
>> If the broken-down SGP means the SGP process of M3UA protocol, SCTP
>> process should be still active, and, association should still be in
>> established state, and association changeover is unnecessary.  This is
>> very like the Processor Outage of MTP.  SCTP buffers the messages and
>> maybe some messages would be lost (queue overflow, etc.), this depends
>> on the error in M3UA SGP. maybe corid approach would not be available
>> either, because there is error in the SPP process.
>> 
>> If the SGP failure means SCTP process crashes down fully while SGP
>> process of M3UA protocol is active, this is infrequent and I cann't
>> see the exact scenario.  On the other hand, it is similiar to MTP2
>> terminal error, MTP3 cann't get sequence information of MSU, sequenced
>> changeover is impossible.  Notice this is seldom case, and MTP3 will
>> not append message buffer in MTP3 layer for the extreme changeover.
>> So association changeover approach loses nothing than MTP changeover.
> 
> We are talking about SIGTRAN here; nevertheless, these assertions about
> SS7 are untrue.  There is no requirement in SS7 to implement the
> retransmission buffer in the signaling terminal.  Also the sequence
> number transmitted in a COO or COA is the sequence of the last MSU
> accepted by MTP-3.  This information also is not required to be
> maintained in the signaling terminal, but may be maintained in MTP-3.
> Therefore, a signaling terminal can fail and MTP-3 may still be able to
> both update the retranmission buffer as well as provide the last BSNT in
> the COO or COA.  So, an SS7 implementation may capable of performing a
> sequenced changeover even under a signaling terminal failure.

I am wondering whether we are reading the same SS7 specifications.
In ITU-T Q.704 (section 5.1) it says:
"For this purpose, in the normal case the changeover procedure includes 
buffer updating and retrieval, which are performed before reopening the 
alternative signalling link(s) to the diverted traffic. Buffer updating consists 
of identifying all those messages in the retransmission buffer of the unavailable 
signalling link which have not been received by the far end."
And, section 5.4.3 of Q.704 says:
"Upon reception of a changeover order or changeover acknowledgement, 
the retransmission buffer of the unavailable signalling link is updated 
(except as noted in 5.6), according to the information contained in the 
message."
And more, section 5.5 of Q.704 says:
"the signal traffic already stored in the transmission buffers and retransmission
buffer of the unavailable signalling link is sent directly towards the new 
signalling link(s), according to the modified routing."
Do those mean message retrieval is between MTP3 and MTP2 signalling link?
If the MTP2 terminal is down, how can message retrieval happen?

> 
> Now back to SIGTRAN.  The case I was presenting was where the SGP fails.
> This includes SCTP, M3UA and everything else at the SGP.  However, the
> NIF has not failed (because it does not reside in the SGP).  CORID
> permits the NIF to maintain both the "retransmission buffer" and the
> "sequence number" for the failed SGP.  Because the messages sent via the
> alternate SGP contain tags identifying the "sequence numbering", CORID
> is capable of lossless changover in this case.

Let me repeat, this is seldom case, and MTP3 will  not append message 
buffer in MTP3 layer for the extreme changeover.
Association changeover approach loses nothing than MTP changeover.

> 
> So, it appears that association-changover is the only approach that is
> incapable of lossless changeover in this circumstance.
> 
>> OK, we come to the last case, some protocol error happen.
>> The association is terminated and it is also a failure
>> in the SGP. At this time the SCTP process and M3UA 
>> process are both active, and the SCTP process (in the SGP)
>> can also cache the final status and buffered messages 
>> of the broken-down association when it detects the 
>> failure.
> 
> No.  It is not the case that the association has broken down.  The
> association is fully functional and is processing traffic for other AS.
> An isolation has occurred causing one AS via the one SGP to be
> deactivated only.  The remainder of the description of this case (below)
> is invalid because the association is still active and messages cannot
> be retrieved from SCTP for an active association.
> 
>> The SCTP process in SGP can select the alternative association (i.e.,
>> the association between ASP1 and SGP2 of SG2, the two associations are
>> both between the same node pair and both provide service to M3UA). The
>> ASP1 would also detecet the assciation failure, cache the status and
>> the buffered messages of the broken-down association and select the
>> alternative association (in this case ASP1 and SG2 would select the
>> same alternative association, in the draft different alternative
>> associations are allowed in different direction). By now, both
>> endpoint cache the enough infoamtion and they can exchange the
>> acknowledged sequence number in the alternative association.  So the
>> SCTP process of the both endpoint can know well which messages are
>> received by the peer and which messages are sent but not received by
>> the peer, and they locally know clearly which messages are not sent to
>> the peer. In addition, they both know well which messages are received
>> by local SCTP process but not moved to the ULP. The M3UA process can
>> utilize the retrieve primitive defined in RFC4960 to retrieve the
>> messages and resend them to SCTP layer.  At this time, M3UA has knowen
>> the association failure and would update the load sharing set. And the
>> M3UA process resend the retrieved messages as it send normal message
>> to SCTP layer. Of course, the later messages that containing same CIC
>> with the retrieved messages should also be use the same association
>> (i.e., the alternative association). So lossing, duplication and
>> mis-sequence would never happen in the sender. In the receiver side,
>> the cumulative acknowledged message in the receive queue (if there is,
>> the ULP has not accepted them) would be moved to the receive queue of
>> the alternative association (still for the same ULP, this point need
>> clarification in the draft), selected acknowledged messages are
>> reneged and would be resent by the peer, unacknowledged would also be
>> resent by the peer.  So lossing, duplication and mis-sequenc would not
>> happen in the receiver either.
>>
>> Well, changeover is finished and later is changeback.  Changeback is
>> not in the scope of the draft because the operations has been
>> implemented in current protocol implementations. For example, in the
>> load sharing mode, e.g.  n+k, if the number of active ASP changes from
>> m (m<n) to n, some traffic would be moved to the new activated
>> ASP/association. and the signalling transport has already been
>> lossless, non-dplication and sequenced.
> 
> M3UA provides no mechanism to avoid missequencing.  Messages transmitted
> on the new association can arrive in advance of messages still
> outstanding on the old association.  CORID provides explicit procedures
> (even interworking procedures) to avoid missequencing, as does SS7.

I didn't say M3UA protocol provide this function, I said current implementations
have already considered this case. when the device changes from 1 active ASPs 
to 2 active ASPs, some traffic would be re-balanced in dynamic manner.
Even there is no changeover, it also works well.

> 
>> As a conclusion, assocaiton changeover approach is designed to provide
>> changeover functionality like MTP (eliminating the gap between sigtran
>> and MTP) and improve the performance of sigtran network.
> 
> And yet, association-changover does not handle these scenarios.  The
> only situation that it might handle is association failure where the
> SCTP remains available at both ends, which field experience in SIGTRAN
> has shown to be the least likely case of failure.  Even in that case,
> CORID approaches are better suited to deal with association failures and
> do not require any changes whatsoever to SCTP.
> 
> I am sorry, but I, for one, am unable to support the
> association-changeover draft.  It fails to address scenarios already
> handled by other approaches, provides no solution not also already
> handled by other approaches, and requires unnecessary changes to SCTP.
> 
> Can you point out a likely scenario that the association-changeover
> draft can handle that CORID cannot?

I agree corid can deal with these cases, the problem is not that corid is not
powerful, but is that it too complex and expensive, and maybe guyes don't 
want such a PA level solution?

> 
> If not, why would you believe that fundamental changes to the
> requirements of SCTP are necessary?

The reason is we can get MTP-similar changeover mechanism,
with a much easy extension in SCTP level, without any modification
in adaptation layer.

Xiangsong

> 
> --brian
> 
> -- 
> Brian F. G. Bidulock
> [email protected]
> http://www.openss7.org/