Subject: SUA Decision needed - handling multiple SGs

From: [email-masked]
Date: Wed, 26 Sep 2001 10:01:40 +0300

Hi all,

I need some comments on how SUA can support multiple SGs
seamlessly.  Basically a decision needs to be made whether
to support proposal 1 or proposal 2.

John

There has been some discussion that SUA needs a mechanism to 
transparently support multiple SGs. The problem occurs under 
failure:

                         SG-A                                      
                       ________                                    
                      |        |                                   
                      |        |                                   
                 _____| STP/SG |XXX     SCTP                       
                /     |        |   X Association                   
               /      |________|    X                              
              /           |                                        
    _____    / A-link     |           X       _______              
   /     \  /             |            X     |       |             
  /       \/           C-links          XXXXX|       |             
  |  SEP  |               |              ____|  ASP  |             
  \       /\              |             /    |       |             
   \_____/  \  A-link     |            /     |_______|             
             \            |           /                            
              \        ___|____      /                             
               \      |        |    /   SCTP                       
                \_____|        |___/ Association                   
                      | STP/SG |                                   
                      |        |                                   
                      |________|                                   
                                                                   
                         SG-B                                      

In the coupled case where SG-A has made the coupling, if associations
are lost between the ASP and SG-A, SG-A has no choice but to route to
the ASP-PC over C-links.  SG-B will still get DT1/DT2 for a connection
for which it has no information.  Note that this does not cause any
problems in the equivalent SS7 case (that is 0 connections fail, not 50%).

In the de-coupled case, it is worse.

Proposal 1 (Brian Bidulock):
============================

2 new Connection Oriented messages:

 >   12        Connection Indication Registration (CIRE)
 >   13        Connection Indication Deregistration (CIDE)

3.3.x Connection Indentification Registration (CIRE)

   This message notifies an alternate SG that an ASP has established a
   connection for the identified destination address, destination
   reference number and Routing Context.

      0                   1                   2                   3  
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Tag = 0x0006         |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                       Routing Context                         /
     \                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Tag = 0x0103         |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                     Destination Address                       /
     \                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Tag = 0x0105         |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 Destination Reference Number                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters
     Routing Context                    Mandatory
     Destination Address                Mandatory
     Destination Reference Number       Mandatory

3.3.x Connection Identification Deregistration (CIDE)

   This message notifies an alternate SG that an ASP has released a
   connection for the identified destination address, destination
   reference number and Routing Context.

      0                   1                   2                   3  
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Tag = 0x0006         |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                       Routing Context                         /
     \                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Tag = 0x0103         |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                     Destination Address                       /
     \                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Tag = 0x0105         |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 Destination Reference Number                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters
     Routing Context                    Mandatory
     Destination Address                Mandatory
     Destination Reference Number       Mandatory

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.

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: dinsdag 25 september 2001 15:11
To: sigtran
Subject: RE: [SUA issue 14] Changes and additions required for decoupled
o peration.

Gery,

> If John L. is ok with putting both options in the SUA draft, 
> no problem !

I think that both options would be a bad idea.  I think we
need to stick with one.

John

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

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

---
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: Wed, 26 Sep 2001 03:25:19 -0500

John,

Proposal 2 doesn't fly.

I can have 2^32 RC's, but there are only 2^24-1 Local
References available in SS7.  This restricts configurations
using such an approach to 2^24-1 RC values.

Gery's format does not permit partitioning into less than
255 values (16-bit base and 8 bit variable), so that further
limits the number of usable RC's to 2^16.

Also, if I have the full 2^16 RC's, each RC would only be
able to sustain 255 simultaneous connections, where, in SS7,
each GT is capable of sustaining the full 2^24-1 connections.

2^16 RC's is not very many when you consider that the AMF
can be on GT and that GT's can be 10+ digit phone numbers.

Even if Gery's proposal allowed a 24-bit base and an 8-bit
range, (which would allow 2^24-1 RC values), when all RCs
were used, each RC would only be allowed to support 1
connection.

Partitioning SLR/DLR in this fashion does not scale.

The registration approach on the other hand permits anywhere
from 0 to 2^24-1 connections on any of 2^32 RC's, just as
SS7 permits from 0 to 2^24-1 connections on a rather large
number of possible Global Titles.  This is because the LR
is only associated with a RC/GT during the life of a connection.

Proposal 2 attempts to make this association prior to the
formation of a connection and, thus, is inadequate for SS7
purposes.

--brian

John Loughney wrote:                                  (Wed, 26 Sep 2001 10:01:40)
> Fax: +32 14 25 3212
> You are currently subscribed to sigtran as: [email-masked]

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

---

---

From: Coene Lode <[email-masked]>
Date: Wed, 26 Sep 2001 10:30:43 +0200

> Sent: woensdag 26 september 2001 9:02
> To: sigtran
> Subject: SUA Decision needed - handling multiple SGs
> Importance: High
> 
> 
> Hi all,
> 

I am in favour of proposal 2.

Yours sincerly,
Lode

---

---

From: Verwimp Gery <[email-masked]>
Date: Wed, 26 Sep 2001 10:59:32 +0200

Brian,

The number of RC's is totally unrelated to the label restrictions. The label
does not define a RC, it is specified within a RC to build up a static
distribution table in the SGs for this particular RC. And it is
automatically rebuilt each time an SG or an association goes down.
You can define another (or the same) set of labels for any given RC.
Furthermore, the approach is independent of whether transactions/connections
exist or not, or how many, it just tells the SG how to select an ASP if
required.
Labels are related to the layout the ASPs within a RK/RC want to give to
their TID or DRN number space. It does not pose any limitations whatsoever
on the amount of RCs, GTT and AMF entries.

So pardon my French, but your interpretation/mathematics below don't amount
to anything.

Proposal 1 has the obvious flaw of having to tell the alternative SGs (which
is the alternative, which is the main SG ??) on the fly of what is
happening, creating for one thing a lot of superfluous traffic. Also the
amount of transactions/connections going on in parallel is limited by any
SG's dynamic table resources.
It is also very unpredictable what will happen in case of
SG/association/routing failures : did the SG lose it's dynamic table ? Does
the ASP has to (de)register everything again ? How to keep the SGs
synchronized ? So this so-called more flexible approach hides a lot of
complex issues.

Comments from any others besides Brian and me ?

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: woensdag 26 september 2001 10:25
To: sigtran
Cc: [email-masked]
Subject: Re: SUA Decision needed - handling multiple SGs

John,

Proposal 2 doesn't fly.

--brian

John Loughney wrote:                                  (Wed, 26 Sep 2001
10:01:40)

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 26 Sep 2001 05:50:23 -0500

Gery,

Verwimp Gery wrote:                                (Wed, 26 Sep 2001 10:59:32)

> You can define another (or the same) set of labels for any given RC.

Then how can the alternate SG know where to route a message if the
DLR does not uniquely identify an RC?  This does not change the fact
that there are only 2^24-1 DLRs (per DPC) coming from the SS7 network,
yet a DPC can be split into 2^32 RCs.  Statically assigning DLRs or
DLR rnages to RCs limits the usable number of RCs.

> exist or not, or how many, it just tells the SG how to select an ASP if

Consider loadsharing.  The alternative SG cannot know the other SG's
loadshare selection (depends on local conditions), so the alternative
SG cannot know which ASP to select in loadsharing mode unless the ASP
informs it by registration.

> on the amount of RCs, GTT and AMF entries.

It does when they are statically allocated before a connection exists.

> So pardon my French, but your interpretation/mathematics below don't amount

Please tell me how your proposal:

 1.)  Provides for proper selection of ASP at the alternative SG under
      loadsharing.

 2.)  Provides for selecting from 2^32 RCs based on a 2^24-1 DLR received
      in DT1/DT2 from the SS7 network.

If you can ;)

> happening, creating for one thing a lot of superfluous traffic.

Answer the above questions and then think again if it is superfluous.

> Also the amount of transactions/connections going on in parallel is limited
> by any SG's dynamic table resources.

10 Gig in core, 1 Tera w/ swap.  No limit there.

> synchronized ? So this so-called more flexible approach hides a lot of

It is still better than carving up a limited resource.

--brian

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Wed, 26 Sep 2001 14:26:01 +0200

Brian,

See below.

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: woensdag 26 september 2001 12:50
To: sigtran
Subject: Re: SUA Decision needed - handling multiple SGs

Gery,

Verwimp Gery wrote:                                (Wed, 26 Sep 2001
10:59:32)

========>
[GV] : Brian, that's how you want to solve the decoupled approach problem. I
think we were both agreeing not so long ago that TID or DRN values are NOT
to be taken up in the registration parameters (static or dynamic). Now
you're coming back from this ? Remember the RC defines an AS uniquely, so
you would end up on a different AS (hopefully then with the same ASPs)
depending on the TID or DRN assignments ? Bad idea ! And you'd have to come
up with DRN range assignments to RCs to avoid AS/ASP management per
connection.
This was also my note on decoupled approach : the RC must be derived from
NetApp/OPC/DPC/CO traffic parameters only, and not rely on SSN or anything
else because there are no more useable SS7 traffic parameters present in a
DT1 message. In the coupled approach, the RC definition can use any
parameter from the CR message (SSN, GT, ...)

To the second topic, we agreed on adding a note that for SS7 interworking,
decoupled approach (or whatever to be on the safe side), the MSB of the DRN
was to be coded zero anyway (SG-ASP agreement). Again, we are not assigning
DRN ranges to the RC, but just telling the SG how to extract the label
identifying the ASP.

You could have x^n RCs defined by NetApp/OPC/DPC/CO parameters and reusing
the same DRN label for each of them.
<=======[GV]

========>
[GV] : I see no problem here. Both SGs know the RC (by REG[RC]), both SGs
know the ASPs label (by ASPAC[RC]). The ASP loadshares over both SGs
(ASP->SS7), no problem. For traffic coming from SS7, each SG extracts the
label a forwards to the correct ASP. No registration on the fly required.
<========

========>
[GV] : No it doesn't, because you can use the same label for more RCs
without conflict. Also the amount of GTT entries is unrelated to the amount
of RCs. GTT/AMF is used to derive the RC, but there's nothing to prohibit
different GTs (possibly a whole range of them) yielding the same RC. Same
thing in SS7, just the first few digits are considered.
<========

=========>
[GV] : see answer above. Trivial: both SGs get the same information. You're
sending REG[RC]/ASPAC[RC] to both of them, right ? I'm getting the
impression you're going for an in-the-fly REG[RC] procedure as well, this is
seriously messing up the AS/ASP concepts.
<=========

=========>
[GV] : I already explained, DLR does not define RC. And Brian, 2^32 RCs
means 2^32 AS and #ASP * #SG * 2^32 RC registrations.  Not even counting the
AS/ASP state machines on each host. Most ASPs will be happy just supporting
a few 1000 RCs, that's already more than enough administration.
<=========

If you can ;)

[GV] : What ? You don't trust me ?

========>
[GV] : The way you're going, this limit is reached in no time flat. And even
so, memory and bandwidth are not for free; you'll make a few operators very
happy I would say.
<========

========>
[GV] : Memory and bandwidth are the limited resources. There are ample bits
for the label in either TID or DRN. Get your priorities straight :

#RCs = thousands (not millions, be serious) => still manageable (REG, ASPSM,
ASPTM)
#parallel transactions/connections = millions => please restrict yourself to
the existing SUA CL/CO messages !
<========

--gery

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 26 Sep 2001 09:13:42 -0500

Gery,

Please see comments below...

Verwimp Gery wrote:                                       (Wed, 26 Sep 2001 14:26:01)
> [GV]: Brian, that's how you want to solve the decoupled approach problem. I

DRN range assignments does not need your label structure, it can be
provisioned on the SG.

> parameter from the CR message (SSN, GT, ...)

RC does not necessarily uniquely identify the ASP upon which the connection
has been made, particularly under loadsharing.

> the same DRN label for each of them.

Well, no.  Not by NA/OPC/DPC, the DLR is only significant per NA/DPC.
Even multiple NA/DPCs is unlikely.

> [GV]: I see no problem here. Both SGs know the RC (by REG[RC]), both SGs

Other way around, Gery.  The SG loadshares over the ASPs.  The RC does
not uniquely identify the ASP as the ASPs register for the same RC.

> [GV]: No it doesn't, because you can use the same label for more RCs
> without conflict.

How does the SG know which RC to map a DLR to if the same label is
used for more than one RC?  And that doesn't help the SG select ASP!

> Also the amount of GTT entries is unrelated to the amount
> different GTs (possibly a whole range of them) yielding the same RC.

Or different RCs.

> Same thing in SS7, just the first few digits are considered.

SS7 does not have an RC, and all the digits are often used (haven't you
heard of LNP? ;)

> [GV]: see answer above. Trivial: both SGs get the same information. You're

Please provide an example when the SGs are loadsharing to multiple ASPs.

> [GV]: I already explained, DLR does not define RC.

Then what does it define?  Please provide an example.

> And Brian, 2^32 RCs means 2^32 AS and #ASP * #SG * 2^32 RC registrations.

Registration is an OPTIONAL procedure.  Static allocation (even algorithmic)
is possible and not precluded by the draft.

> Not even counting the AS/ASP state machines on each host. Most ASPs will be
> happy just supporting a few 1000 RCs, that's already more than enough
> administration.

Static algorithmic assignment could use, say, 6 million RCs easily.

Registriation merely duplicates CORE and COAK.  There is little overhead
for the failure resilience that it allows and use for decoupled approaches.

Coupling requires horrendous (per message) overheads at the SG.

Please provide an example of how your DRN partitioning (err... labeling)
is supposed to work.

--brian

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

---

---

From: Amish Chana <[email-masked]>
Date: Wed, 26 Sep 2001 15:45:20 +0100

Brian, John, Gery

>     _____    / A-link     |           X       _______

What communication protocol are we using between the SGs?

Amish

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 26 Sep 2001 10:03:54 -0500

Amish,

Amish Chana wrote:                                          (Wed, 26 Sep 2001 15:45:20)
> What communication protocol are we using between the SGs?

Only SS7 C-links are shown.  The protocol would be SS7.

--brian

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Wed, 26 Sep 2001 17:34:13 +0200

Brian,

To show you how it would work (loadsharing of SG over several ASPs within an
AS), following example : 2 SGs and 2 ASPs.

1. Setup phase (association coming up, ASPUP, REG and ASPAC sequence) :

ASP1 -> SG1 : REG(NAx,DPCy,CO traffic)
     -> SG2 : REG(NAx,DPCy,CO traffic)
ASP2 -> SG1 : REG(NAx,DPCy,CO traffic)
     -> SG2 : REG(NAx,DPCy,CO traffic)

Only 1 AS, defined by NAx,DPCy,CO traffic RK parameters. Both ASPs register
for it to both SGs.

SG1  -> ASP1 : REG_Ack(RC1)
     -> ASP2 : REG_Ack(RC1)
SG2  -> ASP1 : REG_Ack(RC2)
     -> ASP2 : REG_Ack(RC2)

The SGs recognize ASP1 and ASP2 are registering for the same AS (same RK
parameters); they don't have to necessarily attach the same value to it
(each SG decides on it's own, right ?) Also, I assume a 1-1 relationship
between RC and AS so each SG returns the same RC value to each ASP. It could
be done 1-1 between (SCTP association, RC) - AS but that's not the issue
here.

ASP1 -> SG1 : ASPAC(RC1,label1)
     -> SG2 : ASPAC(RC2,label1)
ASP2 -> SG1 : ASPAC(RC1,label2)
     -> SG2 : ASPAC(RC2,label2)

Each ASP goes active for the AS and announces it's label to each SG. After
acknowledging the ASPAC's, the SG tables look as follows :

SG1 : AS(NAx,DPCy,CO traffic)  <=> RC1
      Available ASP list for AS  : ASP1, label1
                                   ASP2, label2

SG2 : AS(NAx,DPCy,CO traffic)  <=> RC2
      Available ASP list for AS  : ASP1, label1
                                   ASP2, label2

The same steps are repeated if the ASPs want to register for another
AS(NAq,DPCp,CO traffic); the "available ASP list" would look the same on
each SG (just another RC value). The ASPs can even reuse their label.

2. Loadsharing on SG1 or SG2 for incoming SS7 messages, destined for the
ASPs :

e.g. incoming DT1 

2.1 AS selection at SG
=> routing parameters NAx (network appearance, derived from NI bits and
incoming linkset), DPCy (from MTP routing label) and CO traffic (DT1 message
type) match the AS RK parameters !! RC1 (or RC2 on SG2, analogous
processing) is determined !!

2.2 ASP selection at SG
DT1 cannot be routed round-robin around the available ASPs, but the DLR from
the DT1 message is checked.
If DLR(extract label bits start->end) = label1 => route to ASP1
                                      = label2 => route to ASP2
                                      = other => failure (unknown ASP),
discard

Et voila, you have decoupled loadsharing in SG->ASP direction ! Same scheme
for CL TCAP messages, other than TC_Query.

Gery Verwimp
Fax : +32 14 25 3212

---

---

From: Verwimp Gery <[email-masked]>
Date: Wed, 26 Sep 2001 17:46:58 +0200

Brian,

There's a hole in your approach : what's there to prevent the ASPs to assign
the same DRN ?

Then the SG would be at a loss when it has to select the correct ASP : the
SCTP association (ASP) info from which the CORE was received is not
available in the DT1 received from SS7. You'd end up with splitting the DRN
ranges over the ASPs within an AS anyway ...

--regards,

Gery Verwimp
Fax : +32 14 25 3212

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 26 Sep 2001 11:34:44 -0500

Gery,

What's to stop your ASPs from assigning the same label, or sending
the same DRN?

The ASPs must behave correctly.  Static partitioning is not the
best solution.  For example, with ASP-ASP communication, the ASPs
may negotiate with each other for "blocks" of DRNs.  This would
allow one ASP to use all the DRNs if required (i.e. the others
are idle).  Not being able to register precludes this.

In your approach, how does the SG know whether a connection exists
or not for the reveived DT1?  Without registration, the ASP must
run the lower end SCCP state machines.  This breaks the backhaul
architecture.

--brian

Verwimp Gery wrote:                                       (Wed, 26 Sep 2001 17:46:58)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 26 Sep 2001 11:43:59 -0500

Gery,

Verwimp Gery wrote:                                       (Wed, 26 Sep 2001 17:34:13)
> SG1: AS(NAx,DPCy,CO traffic)  <=> RC1
> SG2: AS(NAx,DPCy,CO traffic)  <=> RC2
> ASPs:

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

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Thu, 27 Sep 2001 09:10:17 +0200

Brian,

Labels must be unique across the AS. The SG can check this "before" any
traffic is sent. Even in my approach the ASPs may negotiate first and split
up the DRN range any way they want (or even use no label at all).

And really, the SG doesn't have to know anything about connection or
transaction state. Don't fool yourself in thinking you can put the SCCP CO
state/event stuff in the (multiple) SGs. You'd be breaking the end-to-end
SCCP protocol, and leave a lot of issues on how the SGs should react ...

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: woensdag 26 september 2001 18:35
To: sigtran
Subject: Re: SUA Decision needed - handling multiple SGs

Gery,

--brian

17:46:58)

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

---

---

---

From: Verwimp Gery <[email-masked]>
Date: Thu, 27 Sep 2001 09:55:07 +0200

Brian,

You already made a wrong assumption in the first line. But let's discuss the
failures :

1) association ASP1 - SG1 fails : then the following happens

SG1 can only forward messages with label2 (to ASP2), messages with label1
cannot be forwarded any more, disrupting any existing connections between
SEP and ASP1 routed via SG1. ASP1 still handles the (existing or new)
connections (label1 always) via SG2. The same happens in your approach BTW;
you didn't address the real problem : SG1 cannot send "PC unavailable" to
SEP, in either approach. So you'd lose messages too, if SG1 receives ASP1's
registered DRN.

ASP2 never gets connections with label1, since it only assigns label2 in his
DRNs. All connections with label2 are unaffected, routed via either SG1 or
SG2.

With dynamic registration, you don't solve this problem, you only make it
worse ! You even assume that ASP2 can, just like that, take over the
connections handled by ASP1 ... If they really shared state, there would
even be no point in using registration, or any label, because the SGs can
just perform round robin selection of the ASPs then.

The only thing that can solve this problem, is having an association between
the SGs (yes, C-link like as in SS7) as backup route. And here you have your
first use of an SUA relay function ;) The procedure is simple :

- setup of SCTP association between SG1 and SG2 (that would generally be a
good idea); pity we chucked out the ASP capabilities as a RK parameter e.g.
with value "mated SG".

- SG1 forwards messages with label1 now to SG2, which can still forward them
to ASP1. Disruption cleared.

2) association ASP2 - SG1 fails :

A C-link is an alternative, also in above case, but a costly one compared to
an SCTP association ... it's easier to solve this in SUA on the SG itself :

- SG1 sends DRST(RC2) to SG2 (assuming they know each others RCs, otherwise
we can use the RK parameters themselves).

- SG1 forwards all messages to SG2.

Don't you think this is a neat solution ?

Further comment :

In case 1) (single failure), for new connections, SG1 will only select ASP2;
which lowers the traffic to ASP1. SG2 can choose either, the
in-sequence-delivery of protocol class 2 assures SG2 is used for these
connections.

In case 2) (double failure), SG1 will forward everything to SG2 : both ASPs
will route via SG2 anyway, and traffic to SG1 will also drop, since the new
connections will run via SG2 mostly.

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: woensdag 26 september 2001 18:44
To: sigtran
Subject: Re: SUA Decision needed - handling multiple SGs

Gery,

17:34:13)

--brian

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

---

---

---

From: Segal Niranjan-FNS001 <[email-masked]>
Date: Thu, 27 Sep 2001 09:44:12 -0500

John et al,
My apologies for a late response. 
I agree with Jery's approach. Please see the reference architecture below. I
think we need to rethink the SUA inter-working with SGs. If we allow
ourselves to orient to this reference architecture, we would have a very
clear picture of how a clean SUA <-> SUA and SIF<-> SUA interfaces could be
defined.
Best regards,
Niranjan

 <<...OLE_Obj...>> 

-----Original Message-----
From: Verwimp Gery [mailto:[email-masked]]
Sent: Thursday, September 27, 2001 2:55 AM
To: sigtran
Subject: RE: SUA Decision needed - handling multiple SGs

Brian,

Further comment :

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: woensdag 26 september 2001 18:44
To: sigtran
Subject: Re: SUA Decision needed - handling multiple SGs

Gery,

--brian

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

---

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

---

---

From: Segal Niranjan-FNS001 <[email-masked]>
Date: Thu, 27 Sep 2001 09:55:21 -0500

Here is the word document showing the reference architecture.
Niranjan

-----Original Message-----
From: Segal Niranjan-FNS001 [mailto:[email-masked]]
Sent: Thursday, September 27, 2001 9:44 AM
To: sigtran
Subject: RE: SUA Decision needed - handling multiple SGs

John et al,

 <<...OLE_Obj...>> 

-----Original Message-----
From: Verwimp Gery [mailto:[email-masked]]
Sent: Thursday, September 27, 2001 2:55 AM
To: sigtran
Subject: RE: SUA Decision needed - handling multiple SGs

Brian,

Further comment :

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: woensdag 26 september 2001 18:44
To: sigtran
Subject: Re: SUA Decision needed - handling multiple SGs

Gery,

--brian

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

---

---

---

---

---

From: "Gradischnig, Klaus" <[email-masked]>
Date: Thu, 27 Sep 2001 16:17:38 -0500

John and all:

First, I am not convinced that we really have to solve this problem. Anybody
using anything but DPC to address an AS cannot expect to receive the same
QoS as in an SS7 network when using multiple SGs.
I also feel strongly that any "SCCP" state belongs into the actual endpoint,
not into the SG.

That said, I do not find the first proposal acceptable. The second proposal
is acceptable and will work just fine if AS addressing is done on DPC basis,
i.e. the AS has its own DPC.

Klaus

> Sent: September 27, 2001 3:55 AM
> To: sigtran
> > To show you how it would work (loadsharing of SG over 
> several ASPs within
> an
> > between RC and AS so each SG returns the same RC value to 
> each ASP. It
> could
> > DT1 cannot be routed round-robin around the available ASPs, 
> but the DLR
> from
> You are currently subscribed to sigtran as: 
> [email-masked]

---