Subject: RE: SUA Decision needed - handling multiple SGs

From: [email-masked]
Date: Mon, 1 Oct 2001 09:38:21 +0300

Hi all,

It seems that Gery's proposal has gotten the consensus for the
way to handle this functionality.  I shall try to summarize
the text changes in a mail today.  

John

> Proposal 2 (Gery Verwimp)
> =========================
> 
> We at least need a simple mechanism to allow SG distribution of TCAP or
SCCP
> CO messages to the correct ASP.
> 
> Therefor, I repeat my proposed parameter, to be included optionally in the
> ASPAC (TID and DRN stuff doesn't belong in the REG procedures) :
> 
> TID-label
> 
> +--------+--------+--------+--------+
> |   tag = 0x????  |   length = 8    |
> +--------+--------+--------+--------+
> | start  |  end   |   label value   |
> +--------+--------+--------+--------+
> 
> DRN-label
> 
> +--------+--------+--------+--------+
> |   tag = 0x????  |   length = 8    |
> +--------+--------+--------+--------+
> | start  |  end   |   label value   |
> +--------+--------+--------+--------+
> 
> This allows the SG to build up/update the distribution table for a certain
> RC, any time the association is established and/or the ASP goes active.
The
> SG has to perform some trivial plausibility checks :
> 
> - start, end between 0 and 31 (between 0 and 23 for DRN with decoupled
> approach)
> - 0 < (start - end + 1) <= 16 (label maximum 16-bit)
> - start/end values are the same for each ASP which goes active for this RC
> - TID resp. DRN label values must be different for each ASP
> 
> If any of these checks fail, the ASP cannot go active (neg ack with error
> "invalid label"). It is clear from RC (CL, CO or both) which labels must
be
> present. If it is not required for the SG to perform distribution, no
labels
> are present in any ASPAC for this RC.
> 
> If an ASP is not available, the SG may generate (X)UDTS "routing failure",
> if CL with return option is used. For CO, either IT or flow control
> procedures are adequate; SG simply has to discard the message.

---
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: Mon, 1 Oct 2001 04:03:49 -0500

John,

John Loughney wrote:                                         (Mon, 01 Oct 2001 09:38:21)
> the text changes in a mail today.  

You might try to answer some of the unanswered questions below:

--brian

Brian F. G. Bidulock wrote:                               (Wed, 26 Sep 2001 11:43:59)
> 
> Ok.  Now let's throw in the failure.  ASP1 to SG1 fails.  SG1 moves all
> traffic (label1 and label2) to ASP2.  ASP2 either has state to handle
> established connections from ASP1 (or likely does not).  New connections
> are established on label1 but to ASP2 (ASP1 is not available to SG1).
> When ASP1 to SG1 recovers, connections are SG1 to ASP2 for label1 and
> label2.  It is unacceptable to throw away connections when ASP1 recovers.
> (It may be somewhat acceptable when it fails, but not when it recovers.)
> 
> Does ASP2 send both label1 and label2 to both SG's now?
> 
> To mix it up, if SG1 to ASP2 also fails, SG1 will route over C-links to
> SG2 and then on to ASP2.  But now label1 is going to ASP1 and label2
> is going to ASP2 again, even though connections were established to ASP2
> on label1 from SG1.
> 
> This is applicable to both coupled and decoupled.
> 
> How are you going to synchronize state?
> 
> With registration, ASP1 can register and deregister with SG2 as required.
> 
> Registration permits the connection to terminate on the same ASP as it
> was formed regardless of which DRN was used for establishement.  Static
> assignment does not.  Registration has superior performance in the face
> of failures.
> 

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

---

---

From: [email-masked]
Date: Wed, 3 Oct 2001 14:05:10 +0300

Hi Gery,

Do you think you can address Brian's concern?

John

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Wed, 3 Oct 2001 14:40:52 +0200

Hi John,

I already replied to this. See earlier mail on the thread. The long and the
short of it was :

- SG is updated automatically with ASPTM,... procedures (ASP
available/unavailable to handle traffic),
- other ASPs cannot steal or handle traffic for another ASP's label,
- loss of (messages of) connections/transactions can only be avoided if the
SGs work together to reroute; online synchronization always leave gaps and
is therefor avoided in my approach,
- the SCCP CO state/event tables cannot be split over multiple SGs, this
would break the SCCP end-to-end protocol.

Regards,
____________________________

Gery Verwimp
> SIEMENS ATEA
> ICN D CS D5
> Tel. : +32 14 25 3424
Fax : +32 14 25 3212
mailto:[email-masked]
____________________________________

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: woensdag 3 oktober 2001 13:05
To: sigtran
Subject: RE: SUA Decision needed - handling multiple SGs

Hi Gery,

John

> > assignment does not.  Registration has superior performance 

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

---

---

From: "Haresign, Lincoln" <[email-masked]>
Date: Wed, 3 Oct 2001 15:30:28 -0400

I believe that there is another concern with regards to handling multiple
SGs that is not being addressed and that is the case of missequencing in
case of failure of an association and switching over to another association.

Assume ASP1 has a path to the SS7 network through SG1 and SG2. 
Assume you are sending, back to back, two class 1 messages for a particular
dialog from ASP1 to SG1.  
Assume that the association fails between ASP1 and SG1 immediately after the
first message is sent.

If ASP1 then immediately decides to route the second message through SG2,
there is a possibility that SG2 will route this message in to the SS7
network before SG1 routes it's message.  This will result in missequencing
in the SS7 network.

I believe that you need to put some delay on the ASP side.  Perhaps after an
association fails, the ASP needs to queue messages to that failed
association for some time T.  After that timer T expires, all unsent
messages can be redirected over a different route (very similar to Change
Over/Change Back in MTP L3).

You have similar concerns about associations coming back up.

Regards,
LIncoln Haresign

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, October 03, 2001 7:05 AM
To: sigtran
Subject: RE: SUA Decision needed - handling multiple SGs

Hi Gery,

John

> > assignment does not.  Registration has superior performance 

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Fri, 5 Oct 2001 17:24:30 +0200

Hi Lincoln,

Those are valid concerns, also in the SG -> ASP direction (the SG could e.g.
route via a mated SG). However, would any such procedures fit together with
the SCTP ? Suppose we could retrieve unacknowledged messages on a per
streamID basis, still, loss of an acknowledgement could lead to duplication
on the SS7 side.

Note : the UA on the ASP wouldn't queue any messages, just select the SCTP
association and streamID and deliver it to SCTP.

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Haresign, Lincoln [mailto:[email-masked]]
Sent: woensdag 3 oktober 2001 21:30
To: sigtran
Subject: RE: SUA Decision needed - handling multiple SGs

Regards,
LIncoln Haresign

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, October 03, 2001 7:05 AM
To: sigtran
Subject: RE: SUA Decision needed - handling multiple SGs

Hi Gery,

John

---

---

---

---

From: "Haresign, Lincoln" <[email-masked]>
Date: Fri, 5 Oct 2001 13:51:17 -0400

Gery,

If we wanted to get in to retrieval of unacknowledged messages, we would
have to replicate the entire Changeover and possibly Change back procedures
done in MTP L3.  We would have to exchange messages with the remote end to
determine what messages had successfully arrived.  

Perhaps this is an implementation specific issue, but I really think that
the SUA layer should, at best, just retrieve messages from the SCTP layer
that have not been transmitted yet if we want to avoid message loss.  If we
want to do any more, we need to greatly enhance the requirements of SUA.

With regards to queuing at the UA, you state that the UA does not queue any
messages.  I understand that today there is no requirement to do that.  I'm
saying that if you want to avoid missequencing while reducing message loss,
you MUST queue at the SUA layer.  OR, you could continue to route to a
failed SCTP connection and at some point later, retrieve all messages that
did not go out over the association.  You are effectively doing the queuing
at the SCTP layer.

Regards,
Lincoln

-----Original Message-----
From: Verwimp Gery [mailto:[email-masked]]
Sent: Friday, October 05, 2001 11:25 AM
To: sigtran
Subject: RE: SUA Decision needed - handling multiple SGs

Hi Lincoln,

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Haresign, Lincoln [mailto:[email-masked]]
Sent: woensdag 3 oktober 2001 21:30
To: sigtran
Subject: RE: SUA Decision needed - handling multiple SGs

Regards,
LIncoln Haresign

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, October 03, 2001 7:05 AM
To: sigtran
Subject: RE: SUA Decision needed - handling multiple SGs

Hi Gery,

John

---

---

---

---

---

From: [email-masked]
Date: Mon, 8 Oct 2001 11:12:57 +0300

Hi Lincoln,

> Perhaps this is an implementation specific issue, but I 
> really think that the SUA layer should, at best, just retrieve 
> messages from the SCTP layer that have not been transmitted yet 
> if we want to avoid message loss.  If we want to do any more, we 
> need to greatly enhance the requirements of SUA.

I think that this is an implementation detail - however, as I just
released SUA, please review the text & see if you would
have any suggestions for text to be added to fufill your needs.

SUA has completed WG last call, so at this point, I think we are not
able to add new requiremnts.

John

---