Re: Sigtran extension for network management and association changeover.

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.

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.

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. 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.

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.

Do I explain the procedure clearly?

Regards
Xiangsong

----- 原邮件 -----
发件人: "Brian F. G. Bidulock" <[email protected]>
日期: 星期六, 三月 6日, 2010 下午8:11
主题: Re: [Sigtran] Sigtran extension for network management and association changeover.
收件人: Xiangsong Cui <[email protected]>
抄送: [email protected]

> Xiangsong,
> 
> I read draft-cui-tsvwg-assoc-changeover-00 and I can
> really see no use for it in SIGTRAN UAs.
> 
> Take the following example for M3UA (fairly typical
> arrangement):
>                           ______________
>                          |  _______     |
>                        __|_|  SGP  |    |
>                       / _|_|   1   |    |
>                      / / | |_______|    |
>                     / /  |  _______ NIF |
>                    / / __|_|  SGP  |    |
>                   / / / _|_|   2   |    |
>   _______ _______/ / / / | |_______|    |
>  |  ASP  |________/_/ /  |______________|
>  |   1   |____   /   /        SG1
>  |_______|___ \ /   /
>   _______ ___\_X___/
>  |  ASP  |____X \
>  |   2   |____ \ \        ______________
>  |_______|___ \ \ \      |  _______     |
>              \ \ \ \_____|_|X SGP X|    |
>               \ \_\______|_|X  1  X| fails
>                \   \     | |X_____X|    |
>                 \   \    |  _______ NIF |
>                  \   \___|_|  SGP  |    |
>                   \______|_|   2   |    |
>                          | |_______|    |
>                          |______________|
>                               SG2
> 
> Each ASP and each SGP is a separate SCTP endpoint.  Only
> one association exists between any given ASP and any
> given SGP.  (The above shows 8 associations where 4 are
> really adequate.)
> 
> Suppose that SGP1 in SG2 fails causing associations
> ASP1-SG2/SGP1 and ASP2-SG2/SGP1 to be lost.  SG2 must
> now changeover traffic from these failed associations to
> ASP1-SG2/SGP2 and ASP2-SG2/SGP2 in a load-sharing
> fashion.  ASP1 must also changeover traffic from failed
> ASP1-SG2/SGP1 to ASP1-SG2/SGP2 and ASP2 must changeover
> traffic from failed ASP2-SG2/SGP1 to ASP2-SG2-SGP2.
> 
> How does your draft keep messages from being lost,
> duplicated or mis-sequenced at the NIF at SG2 and at
> each of ASP1 and ASP2?
> 
> Suppose that SGP1 in SG2 recovers.  Traffic must now
> change back to SGP1 in SG2 when associations
> ASP1-SG2/SGP1 and ASP2-SG2/SGP1 are reformed and
> activated.
> 
> How does your draft keep messages from being lost,
> duplicated, or mis-sequenced during the changeback?
> 
> Suppose that instead of SG2/SGP1 failing, that SG2/SGP1
> becomes isolated from the NIF at SG2 for the AS (causing
> unsolicited ASPIA Ack).  Associations ASP1-SG2/SGP1 and
> ASP2-SG2/SGP1 do not fail and are carrying other
> traffic.  Nevertheless, the same changeover for the AS
> must be performed as though SGP1 failed.
> 
> How does your draft keep messages from being lost,
> duplicated or mis-sequenced at the NIF at SG2 and at
> each of ASP1 and ASP2?
> 
> If your draft cannot handle these simple scenarios, it
> is not of much use.
> 
> --brian
> 
> --
> Brian F. G. Bidulock
> [email protected]
> http://www.openss7.org/
>

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

begin:vcard
n:Cui;Xiangsong
fn:Xiangsong Cui
version:2.1
email;internet:[email protected]
end:vcard