Subject: [Sigtran] Sigtran extension for network management and association changeover.

From: Xiangsong Cui <[email-masked]>
Date: Thu, 04 Mar 2010 11:48:15 +0800

Re-posted mail, sorry for the duplication.
=========================================

Dear folks,

We submitted two drafts about the sigtran extension, 
Although the Sigtran WG has been concluded, I still would like to 
talk about these topics in sigtran list before the discussion in tsvwg list.

The drafts may be found by

http://tools.ietf.org/id/draft-cui-tsvwg-snm-ps-00.txt
Abstract: 
   Sigtran is widely applied in the telecommunication network but there 
   are still some issues. This document briefly describes some concerned 
   scenarios and presents the association changeover and Sigtran routing 
   management problems. The goal of this document is to analyse the 
   existing shortage of Sigtran and discuss the desirable improvements. 

http://tools.ietf.org/id/draft-cui-tsvwg-assoc-changeover-00.txt
Abstract:
   Sigtran specifies association-level reliable transport for signaling 
   using SCTP, but in some scenarios a single association failure's 
   reliability mechanism is not sufficient to achieve telco reliability. 
   This document specifies procedures for an SCTP association changeover 
   solution which will enable applications to meet a higher degree of 
   availability. Two generic changeover solutions are presented in this 
   document. One is implemented inside the SCTP protocol stack and the 
   other requires SCTP and ULP to work in collaboration. 

These extensions are expected to improve the performance of sigtran 
network, especially for telecommunication network, what do you think
about them?

Any comments are appreciated!

Thanks and best regards
Xiangsong

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 4 Mar 2010 01:08:58 -0700

Xiangsong,

Xiangsong Cui wrote:                      (Thu, 04 Mar 2010 11:48:15)
>   existing shortage of Sigtran and discuss the desirable improvements. 

I believe these issues were already addressed in the 3GPP Liaison
statement of April 2008.  Note that 3GPP (which you cite in the
document) does not permit M3UA RK's at granularity of less than
a signalling point code.

>   other requires SCTP and ULP to work in collaboration. 

http://tools.ietf.org/html/draft-bidulock-sigtran-corid-05 provides
several mechanisms that are completely local and accomplish this
without protocol changes: neither in SCTP nor the UA.  UAs, such as
M3UA, provide CorrelationId/Ack, BEAT/Ack, and ASPTM on data streams
that already accommodate these procedures.

--brian

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

---

From: Xiangsong Cui <[email-masked]>
Date: Thu, 04 Mar 2010 17:17:10 +0800

Dear Brian,

Thanks for your attention, please see inline.

Regards
Xiangsong

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

> document) does not permit M3UA RK's at granularity of less than

If you mean https://datatracker.ietf.org/documents/LIAISON/file552.txt,
I think the issues are not all resolved.
Changeover issue (I guess you agree this is a problem after I see your draft) 
is not mentioned in this liaison and the routing management issue is not 
resolved as you said.
The liaison says "However, this approach has some drawbacks, 
expecially if multiple SGs are used." and "There was some discussion within
the Working Group about potential extensions to overcome these drawbacks,
but no consensus was reached." Do I miss any important information?

In addition, in some practical scenario, even one SG, we also met some troubles.
For example, in the basic case of GSM + softswitch, some BSC devices
can not support multiple adjacent SP, unfortunately the BSCs can't be updated 
too. So the MGW has to share the SP code with the MSC Server, but we need
install SCCP in both MGW (for SGW/STP purpose) and MSC Server (for 
MAP purpose). The duplicated combinations of "SP Code + SCCP User Part" 
bring problems for the network. If we use M2UA for GSM access, the complexity
increases explicitly. Is this also a drawback?

> that already accommodate these procedures.
I am glad to see this draft, but I need some time to read through it.
We can discuss this item later.

Thanks, Xiangsong

---

From: Xiangsong Cui <[email-masked]>
Date: Fri, 05 Mar 2010 10:44:50 +0800

Dear Brian,

I have read the corid draft and have some thought.

> that already accommodate these procedures.

In my understanding, the corid draft and my association-changeover draft are for
the same goal, the main difference is corid draft works in UA (or SPP) layer 
while my association-changeover draft focuses on SCTP layer.

The detailed differences include:
1, Corid draft modifies UA protocols (section 3 Protocol Elements), such as 
    M2UA, M3UA, SUA, ISUA.....
    Association-changeover draft only changes SCTP protocol.
2, Corid draft brings many transport functionalities into UA layer, such as corid 
    (section 4.1.2.1), flow id (section 4.1.2.2), tagging (section 4.1.3) and buffering
    (section 4.1.4). These features bring complex and repeated job into UA layer 
    and would make UA hard to work.
    Association-changeover draft incorporates SS7 changeover functionality in Sigtran,
    the peers exchange sequence information, and the sender resends the 
    unacknowledged messages.
3, Determining which messages have already been acknowledged?
    Corid draft accomplishes it in UA layer (<5>  IMPLEMENTATION NOTE of 
    corid draft), it is out of the scope of corid draft but that is really difficult.
    Association-changeover draft accomplishes it in SCTP layer by TSN, it is very easy.
4. Corid draft requires all traffic packets to include id information (section 4.1.3), 
    which would waste bandwidth of the network.
    Association-changeover draft takes normal traffic transport procedure.
5. Corid resends all undetermined messages (including the acknowledged messages) 
    to the peer, and the messages are determined by the peer node.
    Association-changeover resends only the unacknowledged messages to the peer.

Are those right?

Thanks and regards
Xiangsong

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 4 Mar 2010 22:53:54 -0700

Xiangsong,

No, that is not right.  You are coming at this rather late in
the game.  M2PA first attempted to use SCTP's transport layer
ack in its functionality but it became impossible.
Modifications to SCTP were not seen to be appropriate when an
application level ack would suffice.  Not even all SIGTRAN
layers require this capability, and modifications to SCTP would
force the capability on all applications.

I quite frankly agree with the consensus that was taken by tsvwg
in these M2PA discussions and am resistant to a draft that would
go against that consensus now.

The corid draft does not require any changes to protocol
elements.  See the section entitled "Interworking".  The
approaches used in this section do no require any changes to the
protocol or even for the peer to support the procedures.  This
approach (similar to the time-controlled changeover and
changeback procedures of SS7) is used by a number of commercial
implementations of M3UA.  Standardization has not been necessary
because the procedures are local, only rely on existing protocol
elements and procedures, do not rely on implementation of the
procedures at the peer, are largely implementation related, and
are performance based implementation options.

I resubmitted the corid and about 8 or so other extension drafts
for 5 to 7 years while the working group was active and none
were taken up as WG items.  For example:

 http://tools.ietf.org/html/draft-bidulock-sigtran-aspcong-01
 http://tools.ietf.org/html/draft-bidulock-sigtran-aspext-05
 http://tools.ietf.org/html/draft-bidulock-sigtran-corid-05
 http://tools.ietf.org/html/draft-bidulock-sigtran-isua-04
 http://tools.ietf.org/html/draft-bidulock-sigtran-loadgrp-05
 http://tools.ietf.org/html/draft-bidulock-sigtran-loadsel-05
 http://tools.ietf.org/html/draft-bidulock-sigtran-m2pa-test-08
 http://tools.ietf.org/html/draft-bidulock-sigtran-m2ua-ss7test-03
 http://tools.ietf.org/html/draft-bidulock-sigtran-regext-04
 http://tools.ietf.org/html/draft-bidulock-sigtran-tua-05

The necessary (but not all) protocol elements for corid-05 and
regext-04 made their way into the UAs.  loadgrp-05 and
loadsel-05 are not supported in any way, leaving SLS as the only
rational basis for loadsharing.  The connection id components of
regext-04 are not supportted, making connection-oriented SCCP in
SUA useless.

After 8 years of banging my head on that, I think it unlikely
that there will be a rally around these concepts now that the WG
is shut down.  There is no charter, and these types of drafts do
not seem sufficient to create one.  For example, far more
important items (the lack of an M3UA MIB, and MIBs for any other
SIGTRAN UAs) cannot keep open or resurrect the WG.  You can
likely get more traction in forums that use SIGTRAN such as
ITU-T and 3GPP.

My advise (whether you want it or not) is to find procedures
such as those in the corid Interworking section that fits your
implementation.  Do not use any proprietary protocol elements.
Do not require any optional procedure of the peer.  Corid shows
that it is possible (if not preferred) in the Interworking
section.  If the corid procedures seem too complex for you, make
your implementation simpler.  If after that you want to share
all your work with the IETF, put forth a draft that describes
your implementation as an INFORMATIONAL RFC.

I won't even consider reviewing a draft that attempts to provide
protocol elements or requires changes in procedures at the peer,
either at SCTP or UA levels; because my first criticism will be
that it requires protocol elements and requires changes in
procedures at the peer: neither of which are possible nor
necessary at this point.

--brian

Xiangsong Cui wrote:                      (Fri, 05 Mar 2010 10:44:50)
> the same goal, the main difference is corid draft works in UA (or SPP) 
> layer while my association-changeover draft focuses on SCTP layer.
> 
> 2, Corid draft brings many transport functionalities into UA layer, such as 
> corid (section 4.1.2.1), flow id (section 4.1.2.2), tagging (section 
>    4.1.3) and buffering
>    (section 4.1.4). These features bring complex and repeated job into UA 
>    layer and would make UA hard to work.
> 4. Corid draft requires all traffic packets to include id information 
> (section 4.1.3), which would waste bandwidth of the network.
> 5. Corid resends all undetermined messages (including the acknowledged 
> messages) to the peer, and the messages are determined by the peer node.

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

---

From: Xiangsong Cui <[email-masked]>
Date: Fri, 05 Mar 2010 14:57:56 +0800

Dear Brian,
Thanks for the discussion, comments inline.

Regards
Xiangsong

----- Original Message ----- 
From: "Brian F. G. Bidulock" <[email-masked]>
To: "Xiangsong Cui" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, March 05, 2010 1:53 PM
Subject: Re: [Sigtran] Sigtran extension for network management and association changeover.

> ack in its functionality but it became impossible.

I don't think so, it seems the M2PA is reusing the functionality
of MTP2, just using BSN to acknowledge the peer's FSN.

> force the capability on all applications.

They are for different purpose (vs application level ack) and 
compatible, association changeover is harmless to any application.

> go against that consensus now.

I'm very interseted in the *consensus*, will find out the discussion 
and read it.

> protocol or even for the peer to support the procedures.  This

I guess you are refering to section 4.3 Interworking Procedures,
but not section 5.6 Interworking. Section 4.3 says
 "Because the CORID procedures provided here rely upon close
  synchronization of Correlation Number between SPP, if one of the SPP
  does not support these CORID procedures, neither SPP is able to take
  advantage of the full benefits of the procedures."
In fact, if the peer doesn't support CORID, the only benefit relies on
the buffer of local SPP. However, most UA SPPs don't provide buffering
function, so what can these UA SPPs get in this situation?

> are performance based implementation options.

I can't agree changeover is a local feature. If you only want 
time-controlled changeover, you may use SCTP Receive Unsent 
Message primitive defined in RFC4960, ignoring the sent but not 
acknowledged messages, why buffer the unsent messages in UA 
layer?

> http://tools.ietf.org/html/draft-bidulock-sigtran-tua-05

Thanks a lot for the contribution, I will read them carefully.

> your implementation as an INFORMATIONAL RFC.

Thank you very much for your comments and advise!

> procedures at the peer: neither of which are possible nor

As you said in your draft, local implementation is not engough
for the expected benefit, and we do wish a feasible solution for 
the high-performance Sigtran network.
Thanks again,
Xiangsong

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 5 Mar 2010 01:54:46 -0700

Xiangsong,

Please see comments below:

Xiangsong Cui wrote:                      (Fri, 05 Mar 2010 14:57:56)
> of MTP2, just using BSN to acknowledge the peer's FSN.

Check M2PA before draft 4.

> compatible, association changeover is harmless to any application.

Additional complexity and performance impact is not harmless.

> function, so what can these UA SPPs get in this situation?

Standards compliant UAs must buffer to support AS-PENDING state.

> acknowledged messages, why buffer the unsent messages in UA 

No you cannot because you risk message duplication which is 3
orders of magnitude worse than message loss for SS7.

> the high-performance Sigtran network.

No, that's not what I said.  Local implementation is not enough
for the _full_ benefit.  Nevertheless there is still _benefit_
to be had by one or both ends performing the Interworking Procedures.

--brian

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

---

From: Xiangsong Cui <[email-masked]>
Date: Fri, 05 Mar 2010 17:41:20 +0800

Dear Brian,

Please see in line.

Thanks, Xiangsong

----- Original Message ----- 
From: "Brian F. G. Bidulock" <[email-masked]>
To: "Xiangsong Cui" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, March 05, 2010 4:54 PM
Subject: Re: [Sigtran] Sigtran extension for network management and association changeover.

> Check M2PA before draft 4.

I will check that, but I don't understand its relation with our dicussion,
in you previous mail, " M2PA first attempted to use SCTP's transport
layer ack in its functionality but it became impossible."
How does the impossibility impact association changeover?

> Additional complexity and performance impact is not harmless.

Firstly, the changeover does happen in very special situation, maybe 
less than 0.01% probability, even there is some impact, it is very little.
Comparing with corid approach (each message tagging and buffering, 
etc.),  is it a heavy load?
Secondly, exchanging a chunk pair and updating the buffer queue with
the selceted acknowledged information, will those bring burden to SCTP?
these are basic operations in SCTP.
I think this is much less the quasi-transport function in SPP layer.

> Standards compliant UAs must buffer to support AS-PENDING state.

We are talking changeover, which does only happen in initiating-active state.
I don't think it is appropriate to expand the AS-pending operations 
(e.g. buffer) to active state.

> orders of magnitude worse than message loss for SS7.

I don't understand your comment here, if you retrieve unsent messages
and resend them, how does the peer get duplicated message?

> to be had by one or both ends performing the Interworking Procedures.

*We* expect the higher benefit. Before the huge Time-Bandwidth Product,
time-controlled changeover is near to non-changeover, because there are
too much sent but unacknowledged messages, undetermined in the floating way.

Regards, Xiangsong

---

From: "David Laight" <[email-masked]>
Date: Fri, 5 Mar 2010 09:52:24 -0000

> and resend them, how does the peer get duplicated message?

Because you need to retrieve messages which the far end hasn't received,
not those you have not received an ack for.
In general all messages will have been sent (limited by the TX window),
so there will almost never be unsent messages.

The MTP3 retrieval procedures collect the sequence number of the last
received message through an alternate channel (another signalling link)
so that duplicates are avoided.

Clearly and implementation which tied SCTP and M2PA together could
obtain
the relevant messages from one set of saved buffers - but that would be
hidious layer-breaking.

The main problem I see with using SCTP as a replacement for MTP2 (even
as M3UA - never mind M2PA) is that, at least with the default timers,
the
detection of broken network links is exceptionally lethargic.
SCTP also seems to have a habit of sending data down unverified
(by heartbeat or other response) network links.

	David

---

From: Xiangsong Cui <[email-masked]>
Date: Fri, 05 Mar 2010 18:01:41 +0800

Dear David,

Thank you for your response.

I want to say there is another primitive, Receive Unacknowledged Message.
If we just retrieve unsent messages, but not unacknowledged messages,
duplication will never happen.
If there is no unsent messages, then the sender will resend nothing.

The duration of association failure detection is another issue, I agree it does impact the changeover performance.

Regards
Xiangsong

----- Original Message ----- 
From: "David Laight" <[email-masked]>
To: "Xiangsong Cui" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, March 05, 2010 5:52 PM
Subject: RE: [Sigtran] Sigtran extension for network management and association changeover.

David

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 5 Mar 2010 06:05:51 -0700

Xiangsong,

Diversion of traffic does not always occur as a result of
association failure.  It can also result from:

 deactivation of an AS at an ASP (ASPIA, ASPDN)
 deactivation of an AS at an SGP (unsolicited ASPIA Ack or ASPDN Ack)
 activation of an AS at an ASP or SGP (ASPAC, ASPAC Ack)

In these cases where the association has not failed, and because
retrieving unsent messages is only defined for SCTP after
association failure, these approaches will risk loss and
duplication.

SCTP acknowledgements only acknowledge that the SCTP peer
received a portion of a message.  They do not acknowledge that
the UA peer received the message at all.  For example, the UA
peer could close a failed association, losing all messages in
the receive buffer.

Withholding SCTP acknowledgement until the message is actually
read from the receive buffer by the ULP is not something that
tsvwg wanted to do.  Putting another layer of end-to-end
acknowledgement in SCTP to acknowledge on a per-stream basis is
not necessary for most other applications.  Instead of
performing this layering, an application layer acknowledgement
from ULP-to-ULP is more appropriate.  This is the concensus that
was reached.

When SCTP detects a restart condition, it is permitted by the
SCTP specification to discard all queued (send and receive)
messages.  Once an SCTP restart has occurred, the SCTP can no
longer acknowledge messages from the previous association;
however, the UA can.

SCTP does not stop messages from being placed into the receive
buffer that cannot be acknowledged to the far end (e.g. because
the association has already failed).

A UA level acknowlegement (Correlation Id/Ack) and flushing
(BEAT/ACK) handles all these cases, and in particular the ones
where the association has not failed.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 5 Mar 2010 06:25:43 -0700

Xiangsong,

Xiangsong Cui wrote:                      (Fri, 05 Mar 2010 17:41:20)
> too much sent but unacknowledged messages, undetermined in the floating way.

Then you do not want SS7 either.  International SS7 and many national
variants (e.g. ETSI) permit an MTP implementation to _always_ use
time-controlled changeover instead of sequenced changeover.  (This
includes satellite links by the way.)  This is because there are
cases where message missequencing can occur when changing over.  It
was never the intention of SIGTRAN to improve upon SS7 in this way.
If you try to use SIGTRAN in an environment where even traditional SS7
will not work, it is likely to fail.

There are implementors in this WG that swear by the time-controlled
method, and that is one of the reasons why the corid draft never
moved forward.

An example where sequenced changeover will not work is where the failed
association has a long delay and the alternate association has a short
delay.  See other examples in section 1.4.5 in the corid draft.

Because SCTP does not know anything about the traffic flows driving its
streams, messages received last on the failed or deactivated association
might be processed after the first messages received on the new association, 
resulting in significant message mis-sequencing.  Again, message discard
or message delay is better than mis-sequencing for SS7, so time-controlled
or flushing (BEAT/ACK) approaches are better in this regard.

I don't think that you have thought this out.

--brian

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

---

From: Xiangsong Cui <[email-masked]>
Date: Sat, 06 Mar 2010 13:36:08 +0800

Dear Brian,

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

> activation of an AS at an ASP or SGP (ASPAC, ASPAC Ack)

Deactivation is the courtyard of AS-pending buffer, changeover is
unnecessary at this time. UA layer can deal with that.
And, does activation need changeover?

> peer could close a failed association, losing all messages in

I agree this point, but this doesn't impact association changeover.
Association failure may be terminal/endpoint error/failure or 
connection error/failure. If it is connection error, the ULP
of course can restore the messages cached in the receive buffer
queue (in the terminal) of the failure association, no message 
lossing. If it is the termainal/endpoint error, some messages 
would be lost. This situation is very similar to MTP2. If it is
a link error, sequenced chaneover is OK, but if it is the MTP2 
terminal error, MTP3 can not retrieve the sequence number, and 
only time-controlled changeover can be appllied. messages lossing
can not be avoided.

> tsvwg wanted to do.  

I agree this.

Putting another layer of end-to-end
> from ULP-to-ULP is more appropriate.  This is the concensus that

I am wonderring at this point.
Do you mean user adaptation is unappropriate and we need 
peer-to-peer adaptation? If that is yes, I agree your corid
draft is appropriate for that (note local implementation is 
almost helpless because of the huge TBP), while association 
changeoveris is only for user adaptation.

> longer acknowledge messages from the previous association;

Restart is another issue, not in the scope of association 
changeover.

> where the association has not failed.

Yes, but maybe "A PA level" (peer-to-peer) is more exact.

Regards, Xiangsong

---

From: Xiangsong Cui <[email-masked]>
Date: Sat, 06 Mar 2010 13:39:03 +0800

Dear Brian,

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

> > >to be had by one or both ends performing the Interworking 
> Procedures.> 
> > *We* expect the higher benefit. Before the huge Time-Bandwidth 
> Product,> time-controlled changeover is near to non-changeover, 
> because there are

I can't agree this logic, we prefer sequenced changeover not means
we are against time-controlled changeover, we just expect better
result, on the basis of time-controlled changeover.

> method, and that is one of the reasons why the corid draft never

I think it is because you are designing a peer-to-peer adaption, 
however, user adaption has been widely applied in the network,
and it is very difficult to update the complex implementation.
There is not any relation to time-controlled changeover.

> 
> An example where sequenced changeover will not work is where the 
> failedassociation has a long delay and the alternate association 
> has a short
> streams, messages received last on the failed or deactivated 
> associationmight be processed after the first messages received on 
> the new association, 
> resulting in significant message mis-sequencing.  Again, message 
> discardor message delay is better than mis-sequencing for SS7, so 
> time-controlled

It is not as you thought, if you read the draft you would find that
sequence delivery has been considerred in the draft.

Regards, Xiangsong

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 6 Mar 2010 05:11:01 -0700

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-masked]
http://www.openss7.org/

---

From: Xiangsong Cui <[email-masked]>
Date: Sun, 07 Mar 2010 19:16:32 +0800

Dear Brian,

> 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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 8 Mar 2010 04:13:21 -0700

Xiangsong,

Xiangsong Cui wrote:                      (Sun, 07 Mar 2010 19:16:32)
> 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.

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.

So, it appears that association-changover is the only approach that is
incapable of lossless changeover in this circumstance.

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

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

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

--brian

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

---

From: Xiangsong Cui <[email-masked]>
Date: Mon, 08 Mar 2010 20:51:59 +0800

Dear Brian,

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

Regards
Xiangsong

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

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

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

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

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

> 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