Subject: Re: Impact of missing changeover

From: Greg Sidebottom <[email-masked]>
Date: Thu, 13 Sep 2001 01:04:56 -0400

Bonjour Francois,

I apologise that I am not following the case you are laying out.  Could you
draw a picture so I can see this in my mind.  I get lost at the part where
you say each "distinct" SG is "connected by an ASP to the same SPMC".

Merci,

   Greg

----- Original Message -----
From: "MOUILLAUD,FRANCOIS (Non-HP-France,ex2)"
<[email-masked]>
To: "sigtran" <[email-masked]>
Sent: Wednesday, September 12, 2001 12:42 PM
Subject: M3UA: Impact of missing changeover

> Hello,
>
> Some time ago (July 11, but I lost the initial mail), the
> issue of missing changeback in M3UA (thread: Changeback Issue)
> was raised. I am wondering what happens in the changeover.
> Sorry if I missed previous debates on this, but I wonder
> what will happen with the current draft text.
>
> In a paralell combined linkset arrangement, SP has SS7 links
> to two distinct SG/STP, each connected by an ASP to the same SPMC.
> The paralell linkset is between the SP and the SPMC
> Say each SG/STP has two SS7 links to the SP. Link 1 of SG1 fails.
> Some of the traffic that was handled by the link say SLS=0010 will
> be diverted to one of SG2 links. A COO message is sent to the SG2.
>
> How do you expect SG2 to react and have this SLS traffic diverted
> by the ASP? I would currently expect SG2 to acknowledge the COO,
> but no message being sent to the ASP, traffic inbalance will occur
> and the SP will keep sending messages with that SLS 0010 for SG1.
> This means SG1 needs a link to SG2 (and if this link is down,
> the messages with SLS 0010 from the ASP will be lost: clearly not
> an acceptable situation).
>
> If now the second link fails as well on SG1, the situation is
> probably better because I expect SG1 to send a DUNA to SP, and so
> the SP will know what to do. SG2 will also acknowledge the new COO,
> but the ASP will have its traffic diverted.
>
> Is the conclusion that SLS arrangements in a combined linksets
> with M3UA MUST be such that SLS can only be diverted within a linkset?
>
> Thanks,
> Francois Mouillaud.
>
>

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 13 Sep 2001 00:54:37 -0500

Greg,

See Figure 19/T1.111.5 and T1.111.5 7.3.2.2.1 Example 4.

                  _____
                 |     |_______
               A | STP |\
                X|_____| \
               X    |     \
                    |      \
       ___   X      |
      /   \ X       |
     | SEP |        |
      \___/ \       |
             \      |
              \     |      /
               \  __|__   /
                \|     | /
               B | STP |/_______
                 |_____|

Simple single A-linkset failure.  COO/COA between SEP and
STP-A are passed over C-links.  No messages are lost or
missequenced.  No delays are added.

Now replace SEP with ASP and STPs with SG/STPs.  When
associations to SG/STP A fail, the ASP has no way of
knowing which messages need to be retransmitted to SG/STP B.

While SG/STP A could send COO/COA on C-links, there is no
way to get information to the ASP.

It this what you were getting at Francois?

--brian

Greg Sidebottom wrote:                           (Thu, 13 Sep 2001 01:04:56)

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

---

---

From: "MOUILLAUD,FRANCOIS (Non-HP-France,ex2)" <[email-masked]>
Date: Thu, 13 Sep 2001 14:03:05 +0200

re-sending........

-----Original Message-----
From: MOUILLAUD,FRANCOIS (Non-HP-France,ex2) 
Sent: Thursday, September 13, 2001 10:11 AM
To: [email-masked]'
Subject: RE: Impact of missing changeover

Brian,
Thanks for following up on this. Please see comments below.
Francois.

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Thursday, September 13, 2001 7:55 AM
> To: sigtran
> Subject: Re: Impact of missing changeover
> Importance: High
> 
> 
> Greg,
> 

For one thing, yes. That's for already transmitted messages,
which will be lost under current implementation. So much for
them, but that's transient.

What I was wondering also is whether the situation could not
be much worse. The ASP is not even aware of the changeover.
SO it will keep sending messages for the concerned SLS to
that SG/STP that was handling them. We can hope that this
SG/STP will send this traffic to its C-links after
SLS reassignment, so they should not be lost. However, a
severe and permanent imbalance situation may be the outcome
of this because traffic distribution from the ASPs will not
be globally reassigned to the remaining links.

> It this what you were getting at Francois?

Yes, pretty much so. So as you point it, there are two issues:
1. How do we ensure that unacknowledged messages are re-sent?
2. How can the ASP be aware of the changeover?

For issue 1., the first question is: what is an acknowledged
message? SCTP provides a stream numbering that ensures 
acknowledgement between SCTP peers. But that does not mean
the message went all the way through the remote SS7 link
(and accepted by the latter). The only way to ensure this 
would be a coordination of buffers between ASP Id/Correlation Id 
(or SCTP stream/sequnce identifiers) and the FSN/BSN in MTP2
This means complex numbering and buffer management between the
various links (each with its own Numbering scheme) and the
ASPs. It is indeed complex because BSN/FSN only have a local
link significance and so it is hard to tell which message is
the "last" acknowledged over several links.
I don't think M3UA has currently a way to retrieve 
unacknowledged SCTP streams. SCTP is probably not the right
place to do this anyway.

So a way to do this would be to maintain a (ASP Id/Correlation Id)
vs (Link Id/FSN-BSN) matrix at an SGP and include ASP Id/Correlation
Id in M3UA messages (forward and backward numbers by the way..).
Not a simple thing to do.. 
Is that what you had in mind, Brian?

For issue 2., introducing M3UA changeover would help reduce
traffic imbalance.

Another way around to avoid all these changes would be to firmly
recommend that SLS reassignments be accomplished within a paralell
linkset and not over combined linksets when a link fails.
By doing this we would not avoid transient message loss, but at
least C-link congestion could be avoided.
Any thoughts on this?

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

---

---

From: "MOUILLAUD,FRANCOIS (Non-HP-France,ex2)" <[email-masked]>
Date: Thu, 13 Sep 2001 10:15:19 +0200

re-sending........

-----Original Message-----
From: MOUILLAUD,FRANCOIS (Non-HP-France,ex2) 
Sent: Thursday, September 13, 2001 10:11 AM
To: [email-masked]'
Subject: RE: Impact of missing changeover

Brian,

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 13 Sep 2001 18:54:34 -0500

Hi,

Please see comments/questions below.

   Tolga

> [mailto:[email-masked]]
> Sent: Thursday, September 13, 2001 4:15 AM
> To: sigtran
[TOLGA] When the SCTP association is down. Or am I missing something?
> the message went all the way through the remote SS7 link
[TOLGA] Why do you think that acknowledgement on SCTP is not enough. Isn't it enough, if unacknowledged messages of the lost SCTP association are sent via another SCTP association for the scenario described. Probably changeover mechanisms should be enhanced for M3UA but it seems we should be more concerned for changeover among two ASPs.
> You are currently subscribed to sigtran as: [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 13 Sep 2001 22:00:41 -0500

Tolga,

Asveren, Tolga wrote: (Thu, 13 Sep 2001 18:54:34)
> > > 
> > > While SG/STP A could send COO/COA on C-links, there is no way to
> > > get information to the ASP.
> > > 

Yes, when the SCTP association fails.

> > acknowledgement between SCTP peers. But that does not mean the
> > message went all the way through the remote SS7 link
>
> [TOLGA] Why do you think that acknowledgement on SCTP is not enough.
> Isn't it enough, if unacknowledged messages of the lost SCTP
> association are sent via another SCTP association for the scenario
> described. Probably changeover mechanisms should be enhanced for M3UA
> but it seems we should be more concerned for changeover among two
> ASPs.

When an SS7 link fails between SEP and STP, the message in SS7 link
TB/RTB are in one of the following states:

        Sender's Information       Receiver's Condition
        --------------------       --------------------
    (1) Buffered    (TB)       (1) Not Received (-)
    (2) Transmitted (RTB)      (1) Not Received (-)
    (2) Transmitted (RTB)      (2) Buffered     (RB)
        --------------------       --------------------
    (2) Transmitted (RTB)      (3) Delivered    (MTP3)
    (3) SS7  Ack    (-)        (3) Delivered    (MTP3)
        --------------------       --------------------

The sending SS7 distinguishes between messages which were delivered to
the remote MTP3 and those that were not using the changeover procedures
(the receiver tells the sender which messages it has received).  Thus
the sender can retransmit messages in transmitter states states (1), (2)
by purging messages from the RTB that are in receiver state (3).

When an association fails between ASP and SGP (SCTP CDI), the messages
in SCTP buffers are in one of the following states:

        Sender's Information       Receiver's Condition
        --------------------       --------------------
    (1) Buffered    (TB)       (1) Not Received (-)
    (2) Transmitted (RTB)      (1) Not Received (-)
    (2) Transmitted (RTB)      (2) Buffered     (RB)
    (3) SCTP Ack    (-)        (2) Buffered     (RB)
        --------------------       --------------------
    (2) Transmitted (RTB)      (3) Delivered    (UA)
    (3) SCTP Ack    (-)        (3) Delivered    (UA)
        --------------------       --------------------

The SCTP sender cannot determine on its own whether transmitted or
acknowledged messages were delivered to the remote UA or not.  Note that
even if it could determine this, the messages are no longer available
for retransmission in some cases.  Retransmitting messages in
transmitter states (1) and (2) can result in both message loss and
message duplication.  Retransmitting only messages in transmitter states
(1) and (2) stands a higher probability of message loss.

So to answer your question: no, it is not enough for SCTP to retransmit
unacknowledged messages on another association.

Using Coorelation Id and the ASP Id/Coor Id procedure, the situation as
provided by SS7 could be partially restored.  (The only way to fully
restore it would be a full UA-level acknowledgement.)

--brian

>
> > (and accepted by the latter). The only way to ensure this would be a
> > coordination of buffers between ASP Id/Correlation Id (or SCTP
> > stream/sequnce identifiers) and the FSN/BSN in MTP2 This means
> > complex numbering and buffer management between the various links
> > (each with its own Numbering scheme) and the ASPs. It is indeed
> > complex because BSN/FSN only have a local link significance and so
> > it is hard to tell which message is the "last" acknowledged over
> > several links.  I don't think M3UA has currently a way to retrieve
> > unacknowledged SCTP streams. SCTP is probably not the right place to
> > do this anyway.
> > 
> > Not a simple thing to do..  Is that what you had in mind, Brian?
> > 

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

---

---

From: "MOUILLAUD,FRANCOIS (Non-HP-France,ex2)" <[email-masked]>
Date: Fri, 14 Sep 2001 09:41:00 +0200

Brian, Tolga
Please see comments below.
Francois.

> Sent: Friday, September 14, 2001 5:01 AM
> To: sigtran

[FM] No, that is not what I meant. Changeover is a pure SS7 procedure
not supported in M3UA. The event here is an SS7 link going down on the SG.
The SCTP association is fine. The point is, since the ASP is not aware 
of the changeover, it will keep sending messages to SG1 while they should
be sent to SG2 (for some given SLS values). If SG1 can still reach the 
SS7 network the message will be rerouted (e.g. C-links) but otherwise,
it will be lost.
Brian has a new and interesting scenario. I wouldn't call it changeover
but it's also an interesting one.

> > but it seems we should be more concerned for changeover among two

[FM] Again, no SCTP association is lost here. The risk is, if the 
messages sent to the SG were not transmitted to SS7 because of the
changeover, they will probably not be retransmitted at all by the
ASP and will therefore be lost.

>         Sender's Information       Receiver's Condition

[FM] That's a different scenario than mine, but another oversight
that you've caught!

> restore it would be a full UA-level acknowledgement.)

[FM] Another way would be to tie SCTP delivery with SS7 delivery at
the SG, but that would be probably very complex.
Brian, what action plan do you recommend? Documenting clearly the
different issues could be a first step, leading to recommendations
wrt to linkset arrangement. 

> would be a

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 14 Sep 2001 03:32:43 -0500

Francois,

Please see comments below...

MOUILLAUD,FRANCOIS (Non-HP-France,ex2) wrote:  (Fri, 14 Sep 2001 09:41:00)
> > > > > While SG/STP A could send COO/COA on C-links, there is no way
> > > > > to get information to the ASP.
> > > > > 
> not supported in M3UA. The event here is an SS7 link going down on the
> SG.  The SCTP association is fine. The point is, since the ASP is not
> aware of the changeover, it will keep sending messages to SG1 while
> they should be sent to SG2 (for some given SLS values).

ASP should be informed by SG1 using DRST.  ASP will controlled reroute
traffic to SG2.

> If SG1 can still reach the SS7 network the message will be rerouted
> (e.g.  C-links) but otherwise, it will be lost.

If SG1 has no C-links either it should have sent DUNA to ASP.  ASP will
force reroute traffic to SG2.

These are not problem situations.

> Brian has a new and interesting scenario. I wouldn't call it
> changeover but it's also an interesting one.

> > > [TOLGA] Why do you think that acknowledgement on SCTP is not
> > > enough.  Isn't it enough, if unacknowledged messages of the lost
> > > SCTP association are sent via another SCTP association for the
> > > scenario described. Probably changeover mechanisms should be
> > > enhanced for M3UA but it seems we should be more concerned for
> > > changeover among two ASPs.
> > 
> 
> changeover, they will probably not be retransmitted at all by the ASP
> and will therefore be lost.

This is no different from the normal SS7 case.  Normally STP would
send TFR/TFP in these circumstances.  STP/SG1 just sends DRST/DUNA
to ASP in the same situations.  No additional message loss probability
or imbalance of traffic over that experienced in the SS7 network
need result.

> > acknowledged messages were delivered to the remote UA or not.  Note
> > that even if it could determine this, the messages are no longer
> > available for retransmission in some cases.  Retransmitting messages
> > in transmitter states (1) and (2) can result in both message loss
> > and message duplication.  Retransmitting only messages in
> > transmitter states (1) and (2) stands a higher probability of
> > message loss.
> > 
> > So to answer your question: no, it is not enough for SCTP to
> > retransmit unacknowledged messages on another association.
> 
> [FM] That's a different scenario than mine, but another oversight that
> you've caught!

I think I have completely misunderstood your scenario.  What is your
scenario?  That handled by DRST/DUNA?

> > 
> > Using Coorelation Id and the ASP Id/Coor Id procedure, the situation
> > as provided by SS7 could be partially restored.  (The only way to
> > fully restore it would be a full UA-level acknowledgement.)
> 
> the SG, but that would be probably very complex.  Brian, what action
> plan do you recommend? Documenting clearly the different issues could
> be a first step, leading to recommendations wrt to linkset
> arrangement. 

The scenario I describe above has been discusssed at length.  Only
an ULP-level sequence numbering (Correlation Id) per association
or stream will solve the difficulty.  This problem exists in M2PA,
IUA, M3UA and SUA.  Note that M2UA has Correlation Id and Ack on
data, so M2UA is the only one without a problem.  Text already 
exists in M2UA.  Only minor changes would be required to support
M3UA and SUA.

--brian

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

---

---

From: "MOUILLAUD,FRANCOIS (Non-HP-France,ex2)" <[email-masked]>
Date: Fri, 14 Sep 2001 14:51:29 +0200

Brian,

On second thought, you are right, my scenarios have the same 
impact as in an SS7 infrastructure. There could only be specific
problems if we tried to load share traffic between a pure SS7 link
and an SS7/M3UA arrangement, which is hopefully not the
scope of M3UA.
Your case was much more interesting and the use of Correlation
Id could be made optional for those implementors what would
require this feature.

Francois.

> Sent: Friday, September 14, 2001 10:33 AM
> To: sigtran

---