Subject: SUA v8 : SUA CO message parameters

From: Verwimp Gery <[email-masked]>
Date: Mon, 15 Oct 2001 16:07:31 +0200

John,

In CORE and COAK messages, the sequence number parameter is NOT present.

In CORE though, there must be a sequence control parameter.

Regards,

____________________________

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

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

---

From: [email-masked]
Date: Tue, 16 Oct 2001 20:49:14 +0300

Hi Gery,

Let me make sure I understand you correctly.

> In CORE and COAK messages, the sequence number parameter is 

In CORE & COAK, I should remove the Sequence Number Parameter.

> In CORE though, there must be a sequence control parameter.

In CORE I should add the Sequence Number Parameter - correct?

John

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 16 Oct 2001 16:51:49 -0500

John,

CORE:  Remove "Sequence Number", add "Sequence Control (mandatory)".
COAK:  Remove "Sequence Number", add "Sequence Control (mandatory)".

Again: Sequence _*_Number_*_ must NOT be in these messages.
       Sequence _*_Control_*_ must be in these messages and mandatory.

--brian

John Loughney wrote:                                         (Tue, 16 Oct 2001 20:49:14)
> In CORE I should add the Sequence Number Parameter - correct?
                                    ^^^^^^ Control
And COAK as well.

I think you just mis-labeled Sequence Control as Sequence Number
in CORE and COAK.

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Wed, 17 Oct 2001 10:53:34 +0200

John,

See below.

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: dinsdag 16 oktober 2001 19:49
To: sigtran
Subject: RE: SUA v8 : SUA CO message parameters

Hi Gery,

[GV] : Yes, segmentation (More indicator etc.) only needed for CODT
messages.

[GV] : Strike that. CORE cannot be sent out of sequence so any SLS selected
at SG will do. For subsequent CO messages, the destination reference number
can be used to select an SLS.

John

---
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, 17 Oct 2001 04:31:47 -0500

Gery,

Please see comments below...

Verwimp Gery wrote:                                       (Wed, 17 Oct 2001 10:53:34)
> Fax: +32 14 25 3212
> [GV]: Yes, segmentation (More indicator etc.) only needed for CODT
> messages.
> 
> [GV]: Strike that. CORE cannot be sent out of sequence so any SLS selected

Let's not go around the block on this again: Sequence Control is required
in both CORE and COAK for multiple SG operation.  Otherwise one SG cannot
possibly know the SLS selection of the other SG for the connection.

Sequence Number in CORE and COAK should simply be changed to Sequence Control.

--brian

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Wed, 17 Oct 2001 12:13:07 +0200

Brian,

Why don't we need it then in all other CO messages as well ?

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: woensdag 17 oktober 2001 11:32
To: Verwimp Gery
Cc: sigtran
Subject: Re: SUA v8 : SUA CO message parameters

Gery,

Verwimp Gery wrote:                                       (Wed, 17 Oct 2001
10:53:34)

Sequence Number in CORE and COAK should simply be changed to Sequence
Control.

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 17 Oct 2001 05:23:54 -0500

Gery,

Well, with CIRE and CIDE the Sequence Control was
registered with the alternate SG, but someone decided
to try partitioning local reference numbers instead ;)

With the paritioned SLR approach, sequence control
and even protocol class would have to be included in
all CO messages as well.  Essentially all the state
of the connection would have to be included in each
and every CO message.

With the CIRE and CIDE approach, the connection state
information (protocol class, sequence control, ...)
is registered against a SLR in the alternate SG and
does not need to be sent with every message.

What's worse, is that these parameters would have to
be mandatory in all CO messages under multiple SGs.

Care to reconsider paritioning vs. registration?

--brian

Verwimp Gery wrote:                                       (Wed, 17 Oct 2001 12:13:07)
> You are currently subscribed to sigtran as: [email-masked]

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Wed, 17 Oct 2001 13:35:21 +0200

Brian,

Yes and it was accepted too ;)

But I don't see any need to have this parameter in any CO message. The SG
certainly doesn't need to keep track of selected SLS values :

- for CORE : the SG may select any SLS. Messages only need to be kept in
sequence within a connection, and CORE is the first. COAK must be received
first before sending anything else.

- for COAK etc. : the SG selects SLS based on DRN, so the same SLS is always
selected for messages sent within the connection.

- the SGs need not synchronize anything, because :
	- the same SG/SGP (and streamID !) is selected by the ASP because of
the in-sequence-delivery requirement,
	- in case of SG failure, messages are rerouted to the backup after a
certain changeover delay; it is no problem when this leads to a different
SLS (same in SS7 network when routing via an alternative path).

Registering is just for the backward direction SG->ASP. The SG does not have
to keep state about any connection, and is perfectly capable of selecting an
appropriate SLS.

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: woensdag 17 oktober 2001 12:24
To: sigtran
Cc: [email-masked]
Subject: Re: SUA v8 : SUA CO message parameters

Gery,

--brian

12:13:07)

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

---

---

---

From: [email-masked]
Date: Thu, 18 Oct 2001 00:08:30 +0300

Hi Brian,

>        Sequence _*_Control_*_ must be in these messages and mandatory.

Got it.  Changes made.

John

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 17 Oct 2001 18:27:16 -0500

John,

Errr.  I'd like that, but Gery was objecting to adding Sequence
Control in CORE and COAK.  (Removing Sequence Number is fine...)
We need to still settle out handling of SLS over multiple SGs
as STPs.  Removing CIRE/CIDE from the spec has caused a good
number of problems resolved by them in  Issue 14 (Decoupled
Support) to resurface.

In all fairness, hold off on adding Sequence Control until we
can come to some resolution on Issue 14.

--brian

John Loughney wrote:                                         (Thu, 18 Oct 2001 00:08:30)

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Thu, 18 Oct 2001 09:54:36 +0200

Well, the discussion is about adding a sequence control parameter in (all)
CO messages or not. Brian's proposal with the CIRE/CIDE already encountered
a good deal of opposition, because this opens a new can of worms. Let's not
go down that lane again ...

This is the *problem* case : multiple SG, SG failure. Brian's argument comes
down (if I understand correctly) to having to coordinate the SGs so that the
CO messages with the same sequence control parameter enter the SS7 network
with the same SLS.

I don't follow this requirement, because :

- full duplex communication (CODT etc.) on a connection is only allowed
after the CORE/COAK exchange. The SLS value for CORE messages can be random
(equal to protocol class 0).

- COAK, CODTs etc. cannot overtake each other when each SG makes use of
appropriate parameters to determine the SLS. The point is each SG can make
this decision independently. DRN, DPC, SCTP association ID, streamID, ...
all of this can be used. At least with a 24-bit DRN it should be easy to
calculate an evenly distributed 8 bit SLS. An additional sequence control
parameter is overkill here.

- When rerouting over another SG (the one normally selected by the ASP for
the connection, fails), another route into the SS7 network is followed, so
keeping the SLS in synch over the SGs serves no purpose anyway. Furthermore,
each SG might have his own idea of how to map sequence control (or
connection reference or whatever) onto SLS values.

So basically, no further action required on the draft.

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: donderdag 18 oktober 2001 1:27
To: sigtran
Cc: [email-masked]
Subject: Re: SUA v8 : SUA CO message parameters

John,

--brian

John Loughney wrote:                                         (Thu, 18 Oct
2001 00:08:30)

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 18 Oct 2001 03:50:01 -0500

Verwimp,

Verwimp Gery wrote:                                       (Thu, 18 Oct 2001 09:54:36)
> go down that lane again ...

Then we are going down the Issue #14 lane again because all of the CO
problem which are addressed by CIRE/CIDE are no longer address with its
removal.  SUA cannot transparently support multiple SG without addressing
this issue.

> This is the *problem* case : multiple SG, SG failure.

It does not take SG failure to cause the problem.  Only the failure
of a single linkset in the network between the SG and the network.
This can cause changover to the alternate SG of an entire SLS.

> Brian's argument comes down (if I understand correctly) to having to
> coordinate the SGs so that the CO messages with the same sequence control
> parameter enter the SS7 network with the same SLS.

It comes down to both SG's having to know the outgoing SLS for each
message.

> (equal to protocol class 0).

When a switch between SG is done at the ASP, the alternate SG must know
the SLS to send messages for the connection.  The existing approach has
no mechanism which permits the alternate SG to know the SLS value for
a connection established via the other SG.  CIRE would inform if of this
value.

> all of this can be used.

> At least with a 24-bit DRN it should be easy to calculate an evenly
> distributed 8 bit SLS.

This assertion is not correct.  The duration of a connection, its traffic
use, an any information local to the SG can be used to more evenly spread
SLS assignments for load sharing that just mapping off of DRN.  This info
has not been shared with the alternate and may derive off of information
which is not synchronized between SG.  Also, existing implemenations of
SCCP that will be used for SGs do not assign SLS in this fashion.  I don't
think that they should have to be fudged in this way.

There is no guarantee that a DRN is evenly distributed.  In fact, depending
on the SLR selection at the distant (real SS7) point codes, they may even
be correlated to the worst possible distribution making SCCP not meet its
obligations for SLS load-sharing at the SG.  Example: there are 10 remote
point codes.  Each has no connections.  The AS establishes connections to
each.  Each remote point code assigns DRN=1 to the connection.  Each
connection goes over the same SLS.  The load is completely imbalanced.

Sorry, you will need another way of informing the alternate SG of the SLS
value.

> An additional sequence control parameter is overkill here.

Because you cannot come up with a way of informing (registering) the
SLS value with the alternate SG, a parameter which can be used for
loadsharing will have to be added to all CO messages or we can always
revert to CIRE/CIDE.

> the connection, fails), another route into the SS7 network is followed,

This is not true.  The same route based on SLS is taken into the SS7
network.

> so keeping the SLS in synch over the SGs serves no purpose anyway.

SLS must be kept in sync to obtain order delivery in SS7.  It must
not be changed in the middle of an SCCP connection, otherwise SCCP
is not providing the services expected of it by its users.

> Furthermore, each SG might have his own idea of how to map sequence
> control (or connection reference or whatever) onto SLS values.

That is correct.  But the alternate SG needs to be told which SLS
value the primary has selected.

> So basically, no further action required on the draft.

Wrong.

--brian

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Thu, 18 Oct 2001 14:30:03 +0200

Brian,

You seem to contradict yourself here : if a linkset fails, another route
*is* followed by subsequent messages even if the SLS is equal. Failing over
to another SG is by definition another route, because I don't think both SGs
use the same linksets. Otherwise, it seems to me the SS7 procedures are
broke, too. The alternate STP doesn't have to know the SLS originally
selected by his mate either. Or do you depend on SLS rotation rules in STPs
for this one ?

CIRE/CIDE requires state to be kept and synchronized at each of the SGs.
This is not needed, and introduces problems even on the protocol level.
Besides, Brian, this requires CO state machines on the ASP because you have
to remember which SG to register to/deregister from. And I don't suppose
you're letting the SGs do the inactivity test (mandatory SCCP CO procedure).

Further comments see below.

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: donderdag 18 oktober 2001 10:50
To: Verwimp Gery
Cc: sigtran
Subject: Re: SUA v8 : SUA CO message parameters

Verwimp,

Verwimp Gery wrote:                                       (Thu, 18 Oct 2001
09:54:36)

[GV] : How, using broadcast ? There's no requirement whatsoever.

[GV] : The alternate SG can choose any other SLS he likes. The routing path
is changed anyway.

[GV] : SLS distribution is an old sore in existing SS7 networks (more in
4-bit SLS ITU than in 8-bit SLS ANSI networks I might add). Whatever method
you use, the STP/SG is powerless against unbalanced SLS distributions,
unless you "fudge" with it : in ITU e.g. OPC/DPC/CIC is taken into
consideration as well to produce a better balanced outgoing SLS. For SCCP CO
traffic, OPC/DPC/DRN can be taken into consideration. This doesn't have to
be synchronized over the SGs, because these values are constant for messages
sent within a connection. Anyway, load-balancing and in-sequence-delivery
are 2 separate topics. We first have to focus on the latter.

[GV] : There's no need to come up with such a way.

[GV] : Unless the SGs share the same linksets, the statement is true.

[GV] : It will happen in SS7 networks too, if due to linkset failure another
path is chosen. As long as it doesn't affect the in-sequence-delivery (and
it doesn't), who cares what the SLS of the received message is ? SCCP does
not generate an SLS error as far as I know ...

[GV] : Again, I see no reason why.

Wrong.

--brian

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

---