Subject: SUA Issue #14 (was, SUA v8 : SUA CO message parameters)

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 17 Oct 2001 07:19:35 -0500

Gery,

Verwimp Gery wrote:                         (Wed, 17 Oct 2001 13:35:21)
> Brian,
> 
> Yes and it was accepted too ;)

Not yet: a version just cut into the middle of the argu...err..discussion.

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

See the Connection Identification argument of Q.711.  There was just
no need to have "Sequence Control" for CL and "Connection Identification"
for CO.

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

Then the other SG does not know the SLS selected.  The very next SUA
message might go via the other SG and it will not know what SLS to use.

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

DRN does is not necessarily balanced over all possible values.  Improper
SLS load-balancing will result.

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

For single stream implementations, that stream id will be '0'.  The
receiving SG cannot determine SLS from stream id.  Are you trying to say
that we should require that each SGP/ASP must support at least 257 streams
and that each stream must be selected only on the basis of SLS?  Are you
saying that the SG must select SLS based on incoming stream id?  How is
one ASP to know the other ASP's stream selection?  There are no such
requirements in the draft.

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

Yes it is a problem because sequence will be disrupted on changeover
unless source SLS is maintained.  This is also true for changeback!

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

So why did you say that sequence control is required in all CO messages?

Basically what you wanted to address one problem of Issue 14 has broken
all the other things which addressed Issue 14.

Effectively SUA LC Issue 14 is no longer resolved (it was when John had
CIRE CIDE in the draft draft).  We will have to start addressing multiple
SG problems all over again.

I would just put CIRE/CIDE back in the draft:  all they are is a copy of
the CORE/COAK to the alternate SG and are no big deal.  They do address
all the problems that have been recreated by removing them.

--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: Verwimp Gery <[email-masked]>
Date: Wed, 17 Oct 2001 15:42:15 +0200

Brian,

Another walk around the block ...

--Gery

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: woensdag 17 oktober 2001 14:20
To: sigtran
Cc: [email-masked]
Subject: SUA Issue #14 (was, SUA v8 : SUA CO message parameters)

Gery,

[GV] : I've seen no support for your proposal so far ...

[GV] : Indeed, the reason we have sequence control in the CL, is because the
streamID might not be sufficient. For Protocol class 0, it isn't needed (the
SG can randomize). Same is true for CORE.

[GV] : Which is totally unnecessary. Messages only have to be in sequence
within a connection. Be glad, this improves load balancing options !

[GV] : First : the SG can take other parameters into consideration (for CO
traffic : DPC, StreamID, ...) without breaking the in-sequence-delivery
requirement. Enough bits available to format the SLS. Second : adding a
sequence control parameter doesn't help, because there's no guarantee this
is balanced over all possible values either. Same problem in SS7 : the SG
should not make assumptions on any ASP's capabilities for proper
loadsharing.

[GV] : see above. No requirement on amount of streams.

[GV] : not for CO traffic. Besides, if we pass a sequence control parameter
to the SG, this still isn't the SLS. Or are you requiring the SGs to have
the same SLS selection algorithm and identical SS7 linkset/link
configurations ?

[GV] : That was irony, Brian.

[GV] : You just invent a problem for your solution (although the SG really
has none), and are blind to the new problems you introduce with this
approach. Are we going to vote again and again until one of us dies ? Maybe
I'll start some issues on this Broadcast traffic mode ...

--Gery

---

---

From: "Gradischnig, Klaus" <[email-masked]>
Date: Fri, 19 Oct 2001 07:02:36 -0500

Gery,

in your support let me say that SLS can never be used to address an MTP or
SCCP user. It is used by the network to maintain in sequence "delivery" as
long as the network configuration does not change. If it changes, all bets
are off but the MTP still tries hard to maintain the sequence. In ANSI
networks the SLS value received at the "destination" for a given "stream"
can now be different. This also shows that using SLS in routing keys can be
counter productive. There is certainly no reason whatsoever to co-ordinate
anything regarding SLS between SGs. I am getting tired of running in circles
even if it is a nice block in a nice neighborhood ;-)

Klaus

> From: Verwimp Gery [mailto:[email-masked]]
> Sent: October 17, 2001 9:42 AM
> To: sigtran
> Subject: RE: SUA Issue #14 (was, SUA v8 : SUA CO message parameters)
> 
> 
> Brian,
> 
> > - for COAK etc. : the SG selects SLS based on DRN, so the 
> same SLS is
> always
> > 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.
> 
> 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: Fri, 19 Oct 2001 13:44:24 -0500

Klaus,

You are thinking in the wrong direction.  We a discussing the
SLS value that the SG must place in the transmitted message.

That this is required to be the same across all sent messages
in an SCCP connection is required by the SS7 specifications
and is not open to negotiation or voting here.

--brian

Gradischnig, Klaus wrote:                            (Fri, 19 Oct 2001 07:02:36)
> 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: Mon, 22 Oct 2001 09:48:06 +0200

Brian,

There is no such explicit requirement in the specs. In fact, the SGs are two
*different* origins in the SS7 network. The only thing that really
guarantees the same SLS, is coupling of connection sections. But then you
can't use an alternative SG once you made a choice with CORE ...

____________________________

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

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: vrijdag 19 oktober 2001 20:44
To: sigtran
Cc: [email-masked]
Subject: Re: SUA Issue #14 (was, SUA v8 : SUA CO message parameters)

Klaus,

--brian

Gradischnig, Klaus wrote:                            (Fri, 19 Oct 2001
07:02:36)

-- 
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: Verwimp Gery <[email-masked]>
Date: Mon, 22 Oct 2001 11:01:33 +0200

Brian,

Yes, I agree with the paragraphs you mention (I am aware of them ;), but the
question is where the SLS is assigned. In my opinion, both SG (primary) and
SG (alternative/backup) can select SLS based on the message parameters I
already described without breaking the in-sequence-delivery requirement
(that's the real requirement here isn't it).

My point being that if you're forced to choose another route anyway (primary
SG goes down or looses SS7 connection to the destination, so you have to
take backup SG), there's no need to force the same SLS. Another route may
mean the message travels across other SS7 STPs. And each SS7 MTP transfer
node can also produce a different outgoing SLS, based on incoming SLS +
other parameters (OPC, DPC e.g.) to improve link-loadsharing without
breaking in-sequence-delivery. There's no guarantee these in->out schemes
are the same at every STP, or that the same number of STPs are taken across
different routes.

The context of the paragraphs below is different : it assumes that on one
and the same node (SS7 SEP) you have the User/SCCP/MTP stacks together. This
is clearly not the case here.

The receiving SCCP will certainly not check the received SLS. For one thing,
since the CR message may be routed on Global Title, it may travel a
different route than any subsequent message.

Now, I believe your problem stems from the fact you want the SCCP CO state
machines on the SG instead of the ASP. And to provide redundancy, you need
at least 2 sets of them. This introduces behavior which is not currently
specified anywhere (hence the additional CIRE/CIDE messages). Even though I
don't think this is a good idea, let's take a shot at a scheme for this :

1) ASP sets up a connection :

1.1) as usual to SG 1, CORE (+ sequence control)

1.2) to SG2 as backup, CORE (+ identical sequence control + identical source
reference + "backup" parameter); SG2 immediately acknowledges with COAK but
stays dormant until the end of the connection in normal circumstances.

Note : if CORE is received, the ASP could do the same thing.

2) Data transfer :

2.1) always via SG1, until ...

2.2) SG2 has to take over. It knows simply by receiving CODT messages. It
can start IT procedures as well.

3) Release :

3.1) as usual by RELRE/RELCO exchange.

3.2) here to RELRE (+ "backup" parameter)/RELCO.

In failover/failback situations you might have 2 SGs running IT procedures,
but I don't think this affects SCCP at the other end.

Any further ideas about this ?

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: maandag 22 oktober 2001 10:11
To: sigtran
Cc: [email-masked]
Subject: Re: SUA Issue #14 (was, SUA v8 : SUA CO message parameters)

Gery,

Both ANSI and ITU are clear on the matter:

ANSI T1.112.4 3.1.4.1(1), 3.1.5.1(1), 3.1.6.1(1).
ITU  Q.714    3.1.4.1(1), 3.1.5.1(1), 3.1.6.1(1).

Connection sections do not have to be coupled to require the same SLS
for the entire connection: See 3.1.4.1(1) and 3.1.6.1(1).

The SLS value used on all outgoing messages associated with a connection
(or connection section) must be the same.  It is assigned when a node
goes to establish a connection and assigned when a node accepts a
connection.

But, perhaps you were not aware of the SCCP procedures.

Nevertheless, when an ASP switches from one SG to the other, the
other SG must use the same SLS on outgoing messages that was
used by the first SG.

If SLS is placed in SUA CO messages (Sequence Control) and with
you "label" mechanism, SUA at the SG will reduce to M3UA as the
ASP must have complete SCCP state machines.

--brian

Verwimp Gery wrote:                                       (Mon, 22 Oct 2001
09:48:06)
> Fax: +32 14 25 3212

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

---

---

---

From: Verwimp Gery <[email-masked]>
Date: Mon, 22 Oct 2001 11:10:44 +0200

Brian,

This was my concern when using "decoupled" approach. Remember I first
suggested to use coupled approach only (precisely because of the information
missing in CODT/DT1 etc.), but you talked us in decoupled approach with
loadsharing (and CO state machines on the SG ;).

As you may remember, one note I wanted added to the decoupled approach was
that the RC "must clearly define the signalling relation", i.e. OPC/DPC/SI,
which is/was a drawback (?) for the decoupled approach. If this is the case,
nothing must be changed to the draft.

Anyway, I have just now posted (previous mail) an alternative to the
CIRE/CIDE approach which I think is more in line with the SCCP protocol.

Fire away !

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: maandag 22 oktober 2001 10:43
To: Verwimp Gery
Cc: sigtran
Subject: Re: SUA Issue #14 (was, SUA v8 : SUA CO message parameters)

Gery,

Your proposed label approach although an SG might be able
to route CO messages other than CORE and COAK based on the
DRN label, it appears completely useless in the other direction.

When an ASP switches SGs, how does the new SG know where
to send CODT, RELRE, RELCO, RESCO, RESRE, CODA, COERR and
COIT messages?  These messages have DRN (of the remote SS7
node) and RC only.  That the SG does not have the SLS should
have been your first clue that it also as none of the rest
of the Routing Label.

In fact, the label proposal does not support decoupled
operation or coupled operation under failure in the mutliple
SG as STP case at all.  Only one direction is not enough.

Do you see the problem now?  Or, do you need it spelled out?

A mechanism is required whereby the alternate SG can be told
of all of the attributes of the connection so that it may
route messages in both directions.  This was accomplished
with CIRE/CIDE.

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 22 Oct 2001 04:39:22 -0500

Gery,

Verwimp Gery wrote:                                       (Mon, 22 Oct 2001 11:01:33)
>
> Brian,
> 
> Yes, I agree with the paragraphs you mention (I am aware of them
> ;), but the question is where the SLS is assigned. In my opinion,
> both SG (primary) and SG (alternative/backup) can select SLS based
> on the message parameters I already described without breaking the
> in-sequence-delivery requirement (that's the real requirement here
> isn't it).

But it cannot select OPC/DPC based on DRN/RC.  The alternate SG does
not have enough information to route a received CODT to the SS7
network.  It cannot build an MTP Routing Label (DPC/OPC) even if it
could somehow derive SLS without breaking load distribution.

> My point being that if you're forced to choose another route
> anyway (primary SG goes down or looses SS7 connection to the
> destination, so you have to take backup SG), there's no need to
> force the same SLS.

SS7 specs require same outgoing SLS on all messages, regardless of
which STP those messages traverse.  Choosing a different SLS mid-
connection would negatively impact the QOS of the connection.

> Another route may mean the message travels across other SS7 STPs.
> And each SS7 MTP transfer node can also produce a different
> outgoing SLS, based on incoming SLS + other parameters (OPC, DPC
> e.g.) to improve link-loadsharing without breaking
> in-sequence-delivery.

This type of altering of the SLS across a transfer node is fixed
for each incoming SLS and is based on SLS rotation rules which
keep the SLS from changing mid-connection.  That is different
altogether as it does not negatively impact the QOS of the
connection.

> There's no guarantee these in->out schemes are the same at every
> STP,

SLS rotation and selection across an STP is standardized and are
the very same at every STP.  Do I need to provide chapter and verse?

> or that the same number of STPs are taken across different routes.

I think you need to read up on SS7 a bit.

> The context of the paragraphs below is different : it assumes that
> on one and the same node (SS7 SEP) you have the User/SCCP/MTP
> stacks together. This is clearly not the case here.
> 
> The receiving SCCP will certainly not check the received SLS. For
> one thing, since the CR message may be routed on Global Title, it
> may travel a different route than any subsequent message.

You need to understand something about SS7: it is assured to a high
degree that all messages placed onto the network on the same
combined linkset will arrive insequence with all other messages that
have been placed on to the network on the same combined linkset with
the same SLS.  If you change the SLS, there is no assurance
whatsoever.  SLS rotation rules throughout the network enforce this
same condition.

> Now, I believe your problem stems from the fact you want the SCCP
> CO state machines on the SG instead of the ASP. And to provide
> redundancy, you need at least 2 sets of them. This introduces
> behavior which is not currently specified anywhere (hence the
> additional CIRE/CIDE messages). Even though I don't think this is
> a good idea, let's take a shot at a scheme for this :
> 
> 1.2) to SG2 as backup, CORE (+ identical sequence control +
> identical source reference + "backup" parameter); SG2 immediately
> acknowledges with COAK but stays dormant until the end of the
> connection in normal circumstances.

The CORE does not have sufficient information.  It takes the
combination of the CORE and the COAK to identify the connection
and provide the backup SG with all the information that is
available to the primary.  This includes both calling and called
party addresses, source and destination reference numbers, protocol
class, and outgoing SLS selection.

This is why the CIRE contains the information from both the
CORE and the COAK.

> 
> Note: if CORE is received, the ASP could do the same thing.
> 
> 2) Data transfer :
> 
> 2.2) SG2 has to take over. It knows simply by receiving CODT
> messages. It can start IT procedures as well.

The switch might not occur at the ASP, it might occur in the SS7
network.

Data Transfer:

With only the information from the CORE, the backup SG would be
unable to route messages to the SS7 SEP because it might not know
the DPC (CORE was on GT), and it does not know the DRN of the SS7
SEP at any rate (it was not included in the CORE).

Data cannot be transferred by the backup SG until it knows both
the information from the CORE and from the COAK combined.

> 3.2) here to RELRE (+ "backup" parameter)/RELCO.

RELRE includes the DRN which was not sent to the backup SG
with the CORE.  Just as the backup SG cannot send based on
the information in CODT, cannot send any other connection
oriented messages to the SS7 SEP.

If sent RELRE, the backup SG does not know what to release
because the RELRE contains destination reference number,
where the CORE contained source reference number.

> 
> In failover/failback situations you might have 2 SGs running IT
> procedures, but I don't think this affects SCCP at the other end.
> 

Do you see it yet?  What is required is the information from CORE
and COAK.  This is what CIRE did.  The CIDE can then contain far
less information.

The CIRE requires RC, OPC, DPC, SLS(outgoing), SRN, DRN and Protocol
Class, Credit (possibly Importance and Message Priority).  The CIDE
needs only RC and OPC/SRN or DPC/DRN to identify the connection.

That's it.  When ASP sends/receives CORE and receives/sends COAK it
sends CIRE to any alternate SGs.  When the ASP sends/receives RELCO
it sends CIDE to any alternate SGs.

This works for the alternate SGs in both directions: labels do not.

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 22 Oct 2001 04:45:38 -0500

Gery,

Verwimp Gery wrote:                                       (Mon, 22 Oct 2001 11:10:44)
> loadsharing (and CO state machines on the SG ;).

I was talking with Sandeep about whether multiple SG/STPs (and it is
not just in the decoupled case) would require modifications beneath
the user interface on the SCCP stack at the SG.

My proposal to solve these difficulties yet while having minimal
impact on existing SCCP stack at SG was CIRE/CIDE.

> nothing must be changed to the draft.

The current draft places no such restriction on RC.

> CIRE/CIDE approach which I think is more in line with the SCCP protocol.

You are recreating the CIRE/CIDE approach: poorly.  See my response
to the other note.

> Fire away !

You must admit that the label approach is woefully inadequate.  Remove it
and place CIRE/CIDE back in the draft.

--brian

> 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: Mon, 22 Oct 2001 12:26:43 +0200

Brian,

SLS rotation is only specified in ANSI. In ITU-T networks, there's no such
thing. Perhaps you should read up on the ITU specs ;) We have to support
both, don't we ?

As to the proposal, that's a first draft, so go a little bit easy on it ...
Let's rephrase and see whether we can come up with something that sticks :

1) Connection setup phase (CORE/COAK exchange) :

Only ASP and SG1 are involved. Only when the connection is setup and we know
the remote node's address (suppose CORE is routed on GT, the COAK *must*
contain a responding address) and reference number, we can go ahead and
inform alternative SGs.

I don't care whether we use a modified CORE/COAK sequence, or CIRE/CIRE_Ack,
but at least the alternative SG has to acknowledge it's backup-role. Agreed
?

2) Data transfer phase :

The problem you'd always have (regardless of whether multiple SGs are used
or not) is that CODT only contain destination reference numbers, which are
unique within a signalling relation only (assigned by remote node). This
problem also exists in your approach ! So unless RC somehow defines this
relation, any decoupling is cripple if we don't add source reference to
CODTs as well. Correct me if I'm wrong.

3) Connection release :

Here I also don't care whether we use a modified RELRE/RELCO sequence
towards the alternative SGs or CIDE/CIDE_Ack. It must be made sure the SG
releases it's resources, doesn't it ?

If we can agree on this, the label approach still has value for the
connectionless TCAP messages (TID).

Decoupling still requires to use 24-bit DRNs only, but the label approach
for DRNs can be removed from the draft.

Want to proceed with any text to submit in the draft ?

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: maandag 22 oktober 2001 11:39
To: Verwimp Gery
Cc: sigtran
Subject: Re: SUA Issue #14 (was, SUA v8 : SUA CO message parameters)

Gery,

11:01:33)

Data Transfer:

--brian

> > > in your support let me say that SLS can never be used to address an
MTP
> or
> > > SCCP user. It is used by the network to maintain in sequence
"delivery"
> as
> > > can now be different. This also shows that using SLS in routing keys
can
> > be

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

---

---

From: [email-masked]
Date: Mon, 22 Oct 2001 15:55:43 +0300

Hi Gery & Brian,

Can I suggest that you both decide on an approach for this &
document it?  I see several options:

1) Modified Label approach (Gery's)
2) CIRE approach (Brian's)
3) Mandate a coupled-SG approach in the draft &
   solve the decoupled-SG approach in an extension draft.

Comments?

John

> Decoupling still requires to use 24-bit DRNs only, but the 
> label approach for DRNs can be removed from the draft.
> 

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 22 Oct 2001 14:17:15 -0500

John,

No modified label approach has been proposed that works.

It looks like at least Gery is willing to take a CIRE/CIDE approach.
Too bad we took it out of the draft at the last minute because only
minor modifications would be required.

If we want to go though the draft changing language and restricting
the decoupled case, removing SG/STP diagrams, identifying unsupported
configurations, etc. then we could always leave it for an extension
draft.  I think that will take more work than just removing labels
and putting CIRE/CIDE back in.

--brian

John Loughney wrote:                                         (Mon, 22 Oct 2001 15:55:43)

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

---

---

From: Al Varney <[email-masked]>
Date: Mon, 22 Oct 2001 17:00:51 -0500

At 02:43 PM 10/22/01 -0500, you wrote:
>Verwimp Gery wrote:                                       (Mon, 22 Oct 
>2001 12:26:43)
> >

>In ITU an STP uses a fixed bit-number in the incoming SLS to determine the
>linkset in a combined linkset.  As bit numbers change along the path, this
>has the same effect as SLS rotation.  In the ANSI network, the STP always
>examines the same bit number and rotates the SLS.

    Just a historical note:  ITU-T SS7 cannot rotate the SLS because of 
TUP's (Q.723) use of SLS as part of the CIC.  To accomplish the goal of 
evenly assigning traffic to outgoing links, ITU-T STPs are provisioned to 
use a different view of the SLS than adjacent SEPs and STPs.  As Brian 
says, it accomplishes the same goal.  Aside from TUP, MTP and the 
GTT-portion of SCCP, applications should probably ignore incoming SLS.

Al Varney

---

---

From: Verwimp Gery <[email-masked]>
Date: Tue, 23 Oct 2001 09:58:52 +0200

Brian,

Just a few dots on the i :

1)&2) Connection ID : ok, but then the primary SG should react in the same
way. I think you agree that the DRN is reserved for the reference assigned
by the remote end only (received in the CORE/COAK from the SS7 SEP at least,
and passed to the SCCP-user); and people still may want to work without this
method (clean DRN). So ok, a new parameter (new tag), which replaces the DRN
in subsequent messages (CODT etc.) Simple : when a ConnectionID is returned
by the SG, use this instead of DRN in all the rest.

This introduces some state in the ASP's SUA, to maintain Connection IDs per
connection per SG.

3) CIDE not acked : I was thinking of a "repeat release"-like procedure as
for SCCP; optional (the number of repeats could be zero) just in case the SG
didn't get the chance to process the first for whatever reason.

Well, agreed to remove the label approach from the draft; no protocol
changes required for implementation dependent distribution ... We'll keep
addressing of ASPs for TCAP messages for an Applicability Statement; I
believe everyone agrees now the problem doesn't need solving here.

If John or you could supply me with the (modified) CIRE/CIDE text ?

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: maandag 22 oktober 2001 20:21
To: Verwimp Gery; John Loughney
Cc: sigtran
Subject: Re: SUA Issue #14 (was, SUA v8 : SUA CO message parameters)

Gery,

Please see comments below...

12:26:43)
> but at least the alternative SG has to acknowledge it's backup-role.
Agreed

The ack might be used to return a Connection Identificiation index.

> CODTs as well. Correct me if I'm wrong.

The Connection Identification Index could be included in these messages
instead of DRN.  (I had thought to place it in the DRN parameter.)

> releases it's resources, doesn't it ?

What will you do if the CIDE is not acked?

> connectionless TCAP messages (TID).

It has no value there either.  SG and ASP can agree on whatever loadsharing
they want.

> for DRNs can be removed from the draft.

32 bits will be needed of the DRN is to represent the Connection
Identification.

> Want to proceed with any text to submit in the draft ?

I submitted text for CIRE/CIDE.  Some additions or corrections would be
required.

John?

--brian

[snipped rest of the thread]

---

---

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

Gery,

There might be a better way to do this Connection Id by
reusing Routing Context.

That is, when CORE/COAK/CIRE is sent by the ASP, it is sent
with a Connection Id parameter which contains the new Routing
Context to be used for the connection.  The ASP can select
a routing context per connection if it wishes.

The CORE/COAK/CIRE effectively registers a new RK at the SG.

All data/release/error/test messages within the connection
would be sent with this RC (in both directions).  The RC can
then act as the Connection Identifier.

This is simlar to my initial approach which was to use REG REQ
and DEREG REQ instead of CIRE/CIDE.  As you are interested in
acks, it might be an idea to overload REG REQ and DEREG REQ
with a new RK type (OPC/DPC/SLS/DLR/SLR/PCLS/IMP/MP) that
identifies a connection.  Then the normal REG/DEREG semantics
and procedures would apply.  The REG/DEREG would result in a
new RC value that could be used for the connection as a 
connection identifier.

Thoughts?

--brian

Verwimp Gery wrote:                         (Tue, 23 Oct 2001 09:58:52)
> If John or you could supply me with the (modified) CIRE/CIDE text ?
[snip]

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Tue, 23 Oct 2001 14:14:25 +0200

Brian,

See below. For comments on your proposal, see official thread.

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: dinsdag 23 oktober 2001 11:56
To: Verwimp Gery
Cc: sigtran
Subject: Re: OFFLIST: SUA Issue #14 (was, SUA v8 : SUA CO message
parameters)

Gery,

Verwimp Gery wrote:                                       (Tue, 23 Oct 2001
11:24:18)
> Brian,
> 
> Don't overreact. The point I was making is that in ITU-T, one cannot
predict
> which bit will be used where, because it depends on local agreements (e.g.
> four hops => consec. bits 1,2,3 and 4 of the SLS or bits 1,2,1,2 or
whatever
> scheme). And what the paragraphs don't say, is that the STP MAY change the
> SLS to obtain a better loadsharing.

Wrong.  Unlike IETF RFCs in the ANSI/ITU specs, anything not explicitly
permitted is not permitted.  That is, the STP MUST NOT change SLS.

[GV] : 
- ITU-T : Not on the link, you are correct of course. I wanted to say the
STP uses more than just the bits of the incoming SLS to improve
load-balancing when selecting an outgoing linkset and link within this
linkset. ITU-T doesn't have the luxury of 8-bit SLS fields. And : when
Global Title Translation is invoked, the SLS *is* changed. SCCP GTT has a
fixed, but implementation dependent, mapping of incoming to outgoing SLS.
Still, in-sequence-delivery is maintained over SCCP relay nodes ... even of
different vendors.

- ANSI : SLS rotation, conversion of 5-bit SLS (which some nodes still
generate) to 8-bit SLS.

> 
> Remark that in the figure nodes B and C cannot use the second least
> significant bit anymore for loadsharing if every node connected to it uses
> the same scheme. So some additional measures are taken, e.g. "A" uses
> another SLS bit or the opposite 0,1 decision with the same bit based on
DPC,
> or any node "X" connected to the same STP-pair makes opposite/other SLS
> decisions). Which makes rotation a moot point.
> 
> This being said, I saw no compelling reason why the two SGs couldn't come

Changing SLS will destroy the QOS of the connection.  That is compelling
enough for me.

[GV] : Well, this is still open to debate. When the ASP performs
time-controlled changeover from a failed SG (or SG which has lost all routes
to the SS7 SEP) to it's backup SG, will the SLS matter anything ? The timing
constraint is just there to give the earlier messages some time to arrive at
the SEP first, to minimize the chance that the ones using the other route
overtake them. There's little (nothing) the SLS can do here.

Other people on the list care to comment ?

> out with a different SLS. It's also transparent to the ASP; even when
> keeping the sequence control the same, another SLS may come out depending
on
> SG. A different route = a different ballgame.
> 
> But I'm sure you know all this, too. You can expect the same of me, even
if
> I over-simplify things sometimes (I'm not a native English speaker ;)

You need to work on your understanding of SS7.

[GV] : Oh, I learn something new every day ;))

--brian

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

---

---

From: "Gradischnig, Klaus" <[email-masked]>
Date: Tue, 23 Oct 2001 07:56:16 -0500

True, but -- as experience has shown -- a cumbersome and error prone task,
specifically if interworking between operators is required. There are other
-- arguably better -- ways to achieve the same goal when SLS rotation is not
available.

Klaus

> From: Al Varney [mailto:[email-masked]]
> Sent: October 22, 2001 6:01 PM
> To: sigtran

---

---

From: Verwimp Gery <[email-masked]>
Date: Tue, 23 Oct 2001 15:12:14 +0200

Brian,

Well you know I'm all for keeping the number of parameters to a minimum.
Again, the SLS is killing us :

- the CORE can have another SLS than subsequent messages (e.g. GT routing :
SCCP on the SG may even select one randomly, there's no other message in a
connection able to overtake it).

- the received SLS (whether in a CR or CC) doesn't need to be the same as
for the outgoing direction. It might be unbalanced for one thing. As Klaus
already stated, SLS is not a good idea to define a RK (see also comments
from Al Varney).

- importance and message priority may vary over the types of messages (DT1
"normal", RLSD "high" e.g.)

So what remains for the "temporary" RK parameters is : (Network Appearance),
OPC, DPC, DLR (no SLR in DT1 messages) and PCLS. Hopefully it doesn't
overlap with what other ASPs do (configured not to use the same DLRs => what
my label wanted to make explicit/fixed, but alla).

Let's see what we have, from the SG's point of view :

1) CORE : 

Question : what is the RC used in the CORE ? A default one for PCLS 2/3 ?

Action : just route and forward CR, no special action : real SEP DPC may not
be known because of "route on GT"

2) CC :

Action : create "temporary" RK parameter (Netw, OPC, DPC, DLR) labelled by
RC, store SLR from remote SEP and forward COAK ... to whom ?

3) The reverse case (CR from SS7, COAK from ASP) seems to work, unless with
architectures that use SUA relay nodes.

Brian, I think we need to combine a few things :

- initiate coupling of connection sections at SG as already described in the
draft. This solves a number of protocol issues, when going from one
transport technology to another (e.g. no DRN 24-bit limit anymore, no DRN
"collisions", no fortune-telling RK registration when routing is on GT, nor
strange, temporary RK parameters).

- this coupling is triggered in both primary SG (CORE/CR) AND backup SG
(CIRE); the ASP then has to maintain a reference for both SGs, to be used as
DRN in subsequent messages (if any) to either of them. But I see no issue
here : internally, SUA and SCCP-user have the unique "ConnectionID"
primitive parameter. And the backup SG takes over InactTest procedures as
soon as it gets CODT traffic, or release/reset procedures if applicable.

- put sequence control parameter in CORE and COAK (at least not in every
message) if you're SLS-minded.

- when the connection is released, possible hanging resources at any
(backup) SG are cleared with CIDE.

- for protocol class 3, flow control (sent/received nrs) must be maintained
in the end-points (SEP/ASP).

Well I hope you're convinced those aren't minor changes, difficult to do
without some state in ASP-SUA :))

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: dinsdag 23 oktober 2001 10:50
To: sigtran
Cc: [email-masked]
Subject: Re: SUA Issue #14 (was, SUA v8 : SUA CO message parameters)

Gery,

Thoughts?

--brian

[snip]

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

---

---

---

From: "Gradischnig, Klaus" <[email-masked]>
Date: Tue, 23 Oct 2001 08:37:55 -0500

Gery,

I could have hardly expressed it better myself. Just two points
- the fixed mapping in SCCP is of course not needed for class 0
- regarding loadsharing beyond simple SLS, look into the proceedings of DRCN
2000:
	Loadsharing - A key to the reliability for SS7 networks
  gives you some indication of what's possible without violating Q.706
requirements

Klaus

> Sent: October 23, 2001 8:14 AM
> To: sigtran

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 23 Oct 2001 13:47:52 -0500

Gery,

Please see additional comments below...

Verwimp Gery wrote:                       (Tue, 23 Oct 2001 14:14:25)
>
> > Brian,
> > 
> > Don't overreact. The point I was making is that in ITU-T, one cannot predict
> > four hops => consec. bits 1,2,3 and 4 of the SLS or bits 1,2,1,2 or whatever
> [GV]: 

GTT is not performed after the connection has been made.  So it is
moot (the SGs do not send data until receiving COAK after issuing
CORE).

> > another SLS bit or the opposite 0,1 decision with the same bit based on DPC,
> [GV]: Well, this is still open to debate.

The SS7 specs do not leave it open for debate.  If you would like to
debate the matter, I suggest you do it in the SS7 forums.

> When the ASP performs time-controlled changeover from a failed SG (or SG
> which has lost all routes to the SS7 SEP) to it's backup SG, will the SLS
> matter anything ?

Nowhere in the draft is any time-controlled changeover at the ASP mentioned.
An SG cannot rely upon the ASP peforming an unspecified procedure.

> The timing constraint is just there to give the earlier messages some time
> to arrive at the SEP first, to minimize the chance that the ones using the
> other route overtake them.

SS7 uses time-controlled changeover as a last resort.  Normal changeover
only assures sequence preservation for messages with the same SLS.

You must also consider that losing communication between (what you call)
the "primary" SG and the ASP that will cause traffic to traverse the
alternate SG.  If a signalling linkset is out between the SG and the
SS7 network, messages will traverse the alternative SG.  The (normal)
changeover that occus then the SG loses SS7 B/D-links to the SS7 network
could result in one or both directions of traffic to be redirected via the
alternate SG without the ASPs knowlege.

So don't rely on some unspecified time-controlled procedure at the ASP.

> There's little (nothing) the SLS can do here.

The SLS does plenty.  It is the ASPs inability in M3UA and SUA to handle
changeover correctly that will cause a QOS problem even in normal situations.
Handling of changeover is an outstanding issue for both M3UA and SUA.

> Other people on the list care to comment ?

Al commented.   You missed the fact that the SS7 network only provides
assurances where the SLS is the same.  Also, you missed the fact that
no matter what SLS load-balancing scheme an STP uses, it is identical
to its mate, and the same incoming SLS will always generate the same
outgoing SLS.  This is true for both ITU and ANSI.

> > keeping the sequence control the same, another SLS may come out depending on
> > But I'm sure you know all this, too. You can expect the same of me, even if
> [GV]: Oh, I learn something new every day ;))

Because you seem to have some misconceptions as to the role of time-
controlled changeover procedures in the SS7 network as it relates to
quality of service and insequence delivery assurances, I suggest you
read up on changover now: particularly the stuff in Clause 5 related
to time-controlled procedures, where they should and should not be
applied, and possiblity of mis-sequencing in various configurations
involving STPs.

--brian

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

---

---

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

Klaus,

None of which break the guarantee of determinate mapping of incoming
SLS to outgoing SLS across mated STPs I presume.

--brian

Gradischnig, Klaus wrote:                            (Tue, 23 Oct 2001 07:56:16)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 23 Oct 2001 14:13:57 -0500

Gery,

Verwimp Gery wrote:                                       (Tue, 23 Oct 2001 15:12:14)
> Again, the SLS is killing us :

SLS is killing you.  If the ASP wishes to stand back from two SGs acting
as mated STPs, it must coordinate some things that were done by the standalone
SG.  This is true in M3UA as well.

You have not even touched on the fact that the ASP must maintain routing
tables and process DRST (as does M3UA).

> connection able to overtake it).

It can, but in SS7 it doesn't.  So the matter is moot.  Transparency must
be assured.

> already stated, SLS is not a good idea to define a RK (see also comments

We do not have incoming SLS reported to the ASP.  Why would we add it?

> "normal", RLSD "high" e.g.)

You are missing the point that the MP is assigned to DT1, DT2, CR and AK.
We don't need to send MP on each DT1, DT2 because there is no need to send
one DT1 with MP=0 and another with MP=1 in the same connection.  Once the
MP has been chosen for the connection, that is sufficient.  This is why
it will be necessary to include MP with CIRE.  Importance also does not
vary between DT1 within a connection, so it is sufficient to establish this
at registration/connection time.

> OPC, DPC, DLR (no SLR in DT1 messages) and PCLS.

Hello.  SLR is required so that the alternate SG can route messages to
the ASP.  The DLR in DT1 messages in the SG to ASP direction is the SLR
of the ASP.  The DLR in DT1 messages in the ASP to SG direction is the
DLR the ASP has for the SEP.  It requires that the LR of both ends DLR/SLR
be specified to the alternate SG.

> Hopefully it doesn't overlap with what other ASPs do (configured not to use
> the same DLRs => what my label wanted to make explicit/fixed, but alla).

The only problem is you have it wrong.  DLR and SLR are required.

> Let's see what we have, from the SG's point of view :

Do you mean CR here or CORE?

> 
> Question: what is the RC used in the CORE ? A default one for PCLS 2/3 ?

If you are going with the concept that RC is CI, then the ASP would select
one.

> 
> Action: just route and forward CR, no special action : real SEP DPC may not

Do you mean COAK here or CC?

> 
> Action: create "temporary" RK parameter (Netw, OPC, DPC, DLR) labelled by

RK parameter is NA/OPC/DPC/DLR/SLR, SLS/MP/IMP/PCLS/CREDIT are attributes
of the connection that the alternate SG needs to know.  

> draft.

SCCP runs uncoupled.  Further, even in the coupled case, messages can
switch across SGs due to a single link failure in the SS7 network.
It is unacceptable to lose have ones SCCP connections coincident
with a single link failure, so even in the coupled case this registration
will be necessary.  We went over this before.

> This solves a number of protocol issues, when going from one

Right, also no redunancy, no reliability.

> here: internally, SUA and SCCP-user have the unique "ConnectionID"

Coupling of connection sections is different.  It has impact on Protocol
Class 3, flow control, and expedited data transfer, and reliability.

> without some state in ASP-SUA :))

Aside from sequence numbers, it is nothing that the SCCP/SCCP-User interface
is not already doing.

I object far more strongly to SCCP state machines that run before the
connection is identified and the per-connection state machines invoked.
This is because if the SCCP state machines common to all connections
exist on the ASP, then all the SCCP state machines exist on the ASP and
SUA is not even required (M3UA can be used easily).

If at least the connection common SCCP state machines are on the SG,
then there is at least something for the SG to do with reagards to
SCCP in these arrangements.

Besides, the only other option is to exclude the multiple SG configuration
from SUA, making SUA rather unusable between networks.

--brian

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Wed, 24 Oct 2001 11:58:22 +0200

Brian,

You seem to have missed some points, but let's first specify more clearly
what I mean with this "time-controlled change-over" procedure in the ASP :
it *is* a last resort, because SCTP (multihoming and such) is already
resilient enough to "change-over" to another IP-route. So we're talking real
serious failure : SG or SCTP association go down. As such, it was already
suggested on the list some time ago we add it to the drafts. At this point,
all CO (and CL) traffic would be rerouted to the "backup" (what else you
wanna call it) which may have to pick-up midd-SCCP/SUA connection.

Now we have the single SCCP connection-problem, to a particular SEP (DPC),
and the "primary" SG (= the one the ASP will always choose as long as it's
available) looses connection (=normal routesets unavailable) to it.

1) Do we have to solve this ? The "primary" SG may use a C-linkset type
route via the "backup" SG, so the ASP can be shielded from such problems.
Everything with the SLS is hunky-dory, because there's no rotation on the
C-linkset.

"Primary" SG sends DRST to the ASP (if you insist we drag all ASP procedures
into this discussion), but this will only affect "new" connections (=
selection of SG on CORE-sending time). The rest on the existing SCCP
connections continues following the sub-optimal route.

2) If the backup SG also looses SEP availability, it's end-of-story : DUNA
is sent to the ASP, which may release every SCCP connection outstanding with
the APC (=SEP), or relies on IT (inactivity test) procedures to do so.

We can't rely on the SSNM messages, the ASP might only be concerned about
the SG-statusses.

And now some points on the new "RC" method, which you didn't address (I saw
a lot of smoke, though) :

1) The parameters of the incoming SS7 message (DT1, RLSD, ...) etc. are
checked against the available RKs. Do you guarantee every message sent from
the SEP for this connection, will always contain the same IMP, MP and such ?
These clearly depend on message type, instead of being constants over the
entire connection. And hello, SLR is not part of a DT1, so you can't
possibly use it in a RK.

2) The "temporary" RK can only be defined when the connection is accepted
(CC/COAK) for a number of reasons :

2.1) CORE (from ASP->SG) may be routed on GT, no final GT translation in the
SG. So we don't know the SEP who will accept. Or even from SG->ASP, with no
final GTT in SG.

2.2) Protocol class 3 may be downturned to 2 in the COAK/CC.

3) Previous point brings up the killer :

=> how can the SG correlate a received CC with the initial CORE, if there's
no RK ? The DLR in the CC is insufficient.

4) Remark that from SS7 point of view, this ASP (or AS, i.c. multiple ASPs)
must have a point code, reachable via both SG1 and SG2. MTP3 on both SG1 and
SG2 recognizes this PC as it's own (multiple PC feature). This brings us to
another issue : if we want to provide redundancy from SS7 -> ASP as well,
both SG1 and SG2 should include OPC=AS (their "secondary" point code instead
of their "true" point code). So we may have to deal with the case that the
CC arrives on SG2 instead (SEP will continue to use the OPC received in the
CR message). If so, we have to rely on SG1-SG2 communication because SG2
won't know anything about this connection (multiple ASPs in AS, SRN assigned
by this ASP, ...).

5) Let me rephrase my "coupling" alternative (I should use another term,
since you immediately associate it with lack of redundancy ...) with an
example : ASP, SG1, SG2 configuration.

Connection setup by ASP, CORE message routed on GT :
=====================================================

- ASP selects SG1 and sends CORE (SRN=101, GT=12345)
- SG1 accepts and stores some necessary connection data : SRN=101 from ASP.
It assigns it's own SLR=300.
- SG1 sends out CR (possibly after GTT, or to a default STP-pair), CR
(SLR=300, GT=12345, OPC=AS)

- SEP accepts and sends back CC (SLR=987, DLR=300, OPC=SEP, DPC=AS)
- SG1 accepts and completes the connection data : SLR=987, DPC = SEP. It
sends COAK to ASP :
	(SRN=300, OPC=SEP, SLR=987) Remark that the presence of the SLR
parameter tells the ASP it can have redundancy with a mated pair. The CC
might have been forwarded by SG2 ("unknown DLR for AS").

- ASP wants redundancy for the connection and wants SG2 as backup. It sends
CIRE to SG2 :
	(SRN=101, SLR=300, DLR=987, DPC=SEP)
- SG2 acknowledges and sends CIRE_Ack back to ASP : (DRN=101). Remark that
both SGs have to use the same SLR, i.e. their SLR "name space" is
synchronized (per AS).

- Further messages are sent from ASP to SG1, e.g. CODT (DRN=300)
- SG1 accepts and formats the DT1 (OPC=SG1, DPC=SEP, DLR=987) from it's
connection data (and the CODT of course).
- SEP sends DT1s back (OPC=SEP, DPC=SG1, DLR=300)
- SG1 formats CODT (DRN=101)

- same thing for SG2, if it's gets to handle traffic.

As a final remark : if you think you have a less complex solution, let's see
it step-by-step. But by the way, in ITU-T one always takes the coupling of
connection sections approach when going from one transport technology to
another. We're trying to do something else here, so don't try and tell me
it's easy.

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: dinsdag 23 oktober 2001 21:14
To: sigtran
Cc: [email-masked]
Subject: Re: SUA Issue #14 (was, SUA v8 : SUA CO message parameters)

Gery,

15:12:14)

SLS is killing you.  If the ASP wishes to stand back from two SGs acting
as mated STPs, it must coordinate some things that were done by the
standalone
SG.  This is true in M3UA as well.

--brian

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 24 Oct 2001 06:51:04 -0500

Gery,

Verwimp Gery wrote:                              (Wed, 24 Oct 2001 11:58:22)
> wanna call it) which may have to pick-up midd-SCCP/SUA connection.

See threads "M3UA: Impact of missing changeover", "Impact of
missing changeover", "IPSP cases", "M3UA: Changeback Issue",
"M3UA: Changeover between ASPs".

When an SCTP association goes down because of SCTP CDI messages
will get lost or duplicated.  A time-controlled procedure is
insufficient.  What was recommended was the addition of a
Correlation Id/Ack to permit the SGP and ASP pools to exchange
correlation numbers for streams in a manner similar to SS7's
changeover mechanism (the "normal" one).

> connections continues following the sub-optimal route.

For decoupled operation with SG/STPs, when the ASP sends CR via
one SG/STP, the CC can come back to the other.  While DT1 is sent
to one SG/STP, the DT1s coming back might be via the other SG/STP.
Neither the ASP nor the SG has any control over to which STP the
messages return when decoupled.  There is no such thing as a
"primary" for decoupled connections.  So, for example:

                  (B)            (D)                           
                 _____          ________                       
                |     |________|        |                      
               /| STP |\      /| STP/SG |\                     
              / |_____| \    / |________| \    _____           
        ___  /     |     \  /     |        \__/     \          
       /   \/      |      \/      |         __| ASP |          
      | SEP |      |      /\      |        /  \_____/          
       \___/ \   __|__   /  \   __|_____  /                    
              \ |     | /    \ |        |/                     
        (A)    \| STP |/______\| STP/SG |                      
                |_____|        |________|                      
                                                               
                  (C)            (E)                           

The ASP sends CORE to (D) which sends CR to (A) via (C).  The
SEP replies with CC along the path (B) (E) to the ASP.  When
the ASP sends CODT it follows the path (D)(C)(A).  When the SEP
replies with DT1, it follows the path (A)(B)(E).

For the SEP and ASP to form a connection, both STP/SGs must be
informed.  There is no primary or secondary.  Any changeover or
changeback in the network (or congestion for that matter) can
change the SG via which the ASP receives messages for the
connection.  Originating SLS is the same and in-sequence delivery
is assured in the SS7 network, but not necessarily between SG
and ASP: see thread "M3UA: Changeback Issue".

Let's look at the case of SCTP CDI.  Say that the SCTP association
between SG (E) and the ASP fails.  STP (E) can no longer reach the
ASP's PC without routing over C-links, so it sends TFR to the
network.  Traffic from SEP (A) which was travelling to the ASP via
STP (E) and then over C-links via STP (D) gets diverted to route
from the SEP along (A)(B)(D).

Loss of an A-link can lead to a switch in the STP/SG traversed
to get to the ASP.  You cannot tell which one return messages
are going to appear at regardless of which STP/SG to which
messages are being sent.

As the connection is formed, both SG/STPs must be informed of
the attributes of the connection.  This includes all the parameters
sent or received in all the messages of the connection as well as
the MTP3 routing label.

> entire connection. And hello, SLR is not part of a DT1, so you can't

Both the forward and reverse RK must be known at the SG.  The normal SG
to ASP RK so that the SG can route received messages to the ASP.  The
reverse RK so that the SG can populate the MTP Routing Label and (gee,
DLR... not SLR) in messages sent to the network.

DLR and SLR are not good terminology to use because it depende in
which direction you are talking as to which is which.  It is like
saying source port and destination port.  The SG needs to know both
the Local Reference for the remote SEP and for the ASP.

Once that is done you could pretty much remove the DRN parameter
from the CO messages in SUA.  The Routing Context could suffice.

I might point out that message priority is not used in an RK either.
Also, protocol class is not used in a RK for CO messages, however,
the SG needs to know it to perform its function.

As to MP in connection-oriented messages, the NSD does not provide for
the alteration of QOS parameters on a per-DATA message basis.  That is,
when MP is assigned to the connection, all DT1/DT2 messages go with the
same MP.  They are not altered from one DT1 to another within the same
connection.  You didn't know this, did you?

> (CC/COAK) for a number of reasons :

Not a good idea.  When a CORE is sent via one SG, the CC could come
to the other.  How will the other SG know to send the COAK to the ASP
that sent the CORE?  You can't even get a connection going decoupled
without letting the other SG know what is going on.

> 2.2) Protocol class 3 may be downturned to 2 in the COAK/CC.

So?  Reregister.

> no RK ? The DLR in the CC is insufficient.

When an ASP sends CORE it will have to register with the alternate SG.

> won't know anything about this connection (multiple ASPs in AS, SRN assigned

When an ASP sends CORE it will have to register with the alternate SG.

> example: ASP, SG1, SG2 configuration.
> 

This is not coupled if OPC=AS, it is decoupled.

> might have been forwarded by SG2 ("unknown DLR for AS").

Because you sent CR with OPC=AS, the CC can go to SG2 depending on
the SEP's SLS selection and the state of affairs in the SS7 network.
SG2 knows nothing of the connection and cannot route the CC.

> both SGs have to use the same SLR, i.e. their SLR "name space" is

Too late.  The CC already came to SG2.  The ASP must send CORE to SG1 and
CIRE to SG2.  It must also send COAK in the same fashion.

> it step-by-step.

First, if you think you have a correct solution, let's hear it.  The
above situation does not work.  The CC is returned half the time to 
the opposite SG.

> But by the way, in ITU-T one always takes the coupling of connection
> sections approach when going from one transport technology to another. We're
> trying to do something else here, so don't try and tell me it's easy.

SUA is supposed to be "transparent" to SCCP.  I didn't set the objectives.

--brian

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Wed, 24 Oct 2001 16:45:48 +0200

Brian,

Funny, you answer with the same problems I was pointing out (no means to
tell on which SG the CC comes back).

And yes, I did know the MP of DT1's is not going to be changed (set by the
MP of CR), but what about ED (expedited data) or IT/RLSD ? See T1.111.5,
Table B4. Good you dumped it from the RK.

So to solve the CC problem, you say the ASP sends CORE to SG1 and CIRE to
the other in parallel : a few snags ...

- this is supposing the CIRE gets processed before a CC actually does arrive
(you never can tell)
- the forward (or backward ?) RK needs to be updated/created/registered with
the information from the CC message (actual SEP when CR routing was on GT,
agreed protocol class and such) with the poor SG that didn't get the CC.
Another CIRE ?

=> Suppose the ASPs of the AS all have registered (before going active) to
the SGs with RK (DPC=AS,PKLS=2or3) as default. Wouldn't it be a better
option to let the SG getting the CC make the check "no SLR/DLR registered
for this RK/AS" and if yes, forward it to its mate. Then wait for the
regular CIRE/Ack procedure as described in my previous mail, AFTER the CR/CC
exchange ?

Additional fine-tuning : the SGs of course use the SRN from the ASP (SLR in
forward direction, DLR in backward direction, as registered via the
CORE/CIRE message). So the CIRE_Ack (and COAK) returns a "forward" RC to be
used by in the subsequent messages from ASP->SG ... ok.

Some further comments below.

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: woensdag 24 oktober 2001 13:51
To: sigtran
Cc: [email-masked]
Subject: Re: SUA Issue #14 (was, SUA v8 : SUA CO message parameters)

Gery,

[GV] : True. One can have the local SCTP give the info, up to what sequence
number in each stream the DATA chunks were acknowledged ... but can you
trust this of an association that has just gone down ...

                  (B)            (D)                           
                 _____          ________                       
                |     |________|        |                      
               /| STP |\      /| STP/SG |\                     
                                                               
                  (C)            (E)                           

[GV] : Aha, a C-link between the SGs ...

So?  Reregister.

[GV] : Coupled/decoupled is not the right terminology here either. Decoupled
(at least in my book) is running completely "stateless" without any
knowledge of existing connections. Kind of the default RK with DPC=AS,
PKLS=2/3 and let the pool of ASPs sought out who's handling the connection.
As long as the SG selects the same ASP based on OPC/DPC/SLS of the incoming
SS7 message.

Coupling is done with 1 and only 1 SG (OPC=SG1 xor SG2).

This is something in the middle, and requires additional messages (CIRE
etc.) Let's say "synchronized" approach ...
======

--brian

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 24 Oct 2001 14:13:16 -0500

Verwimp,

Verwimp Gery wrote:                                       (Wed, 24 Oct 2001 16:45:48)
> regular CIRE/Ack procedure as described in my previous mail, AFTER the CR/CC

And how does the SG get the CC to it's mate?  Sending over C-links would
violate SS7 protocol.  If you are going to force the SG's to talk to each
other then they are one SG.  What is needed is for the one SG to send this
information to the other via the ASP.  This is what is accomplished with
COAK to the ASP and then CIRE to the other SG(s).

> used by in the subsequent messages from ASP->SG ... ok.

Forward RC == Reverse RC.  There is only one AS/Connection and it only needs
be labeled once.

> [GV]: True. One can have the local SCTP give the info, up to what sequence

You can trust it of a link that has gone down.  The last TSN or SID/SSN
or Correlation Id within a stream received is simply that.  This is
what is communicated to the peer via another path so that the peer knows
which messages to discard from its retransmission buffer on the failed
association before collecting and sending other messages.

If you can't trust an SCTP association of an implementation to go up and
down without messing things about, that SCTP implementation would be
pretty useless for SIGTRAN applications.

> [GV]: Aha, a C-link between the SGs ...

Which can't be used except as specified in the SS7 Specifications.
If you want to use SG-SG communication in another way, you will
need a G-Link (that's Gery-Link).

> [GV]: Coupled/decoupled is not the right terminology here either. Decoupled

Let's make it something that works.

--brian

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Thu, 25 Oct 2001 08:54:21 +0200

Hm, strike that G-err C-link ...

There's still a number of issues :

1) SG1 gets CORE from ASP; SG2 receives CC (and possibly already some DT1's)
from SEP => Hold up CORE until CIRE/Ack with SG2 is done ? And how long do
we wait for the Ack then ??

2) SG1/2 is down at the start, but recovers in the middle of the connection.
And of course, it happened to be in the preferred path from SEP to ASP
(PC=AS) => Use PC=SG2/1 in these cases ? But then ... 3)

3) SG1/2 goes down and comes up again, information about existing
connections is lost => re-registering (for all existing connections ?) may
be too late. I don't see a definitive (let alone elegant) solution here,
even when associations are restored before SS7 links ...

4) CORE was routed on GT, so SEP PC information must come via the CC => a
second CIRE/Ack exchange required ? This means we might have to delay CODTs
until and Ack is received again ...

On the other hand, we already have 2 ways of interworking :

1) Completely coupled. ASP can selects SG1 or 2 with each connection setup
and then sticks with it.

2) Completely decoupled. The SGs have RK [DPC=AS, PKLS=2or3] and pick a
fixed ASP (or ASP based on OPC,DPC,SLS or whatever DLR scheme agreed with
the ASPs in the AS).

So, do we really need this third (complex) approach ? I say 1) & 2) is more
than enough.

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: woensdag 24 oktober 2001 21:13
To: Verwimp Gery
Cc: sigtran
Subject: Re: SUA Issue #14 (was, SUA v8 : SUA CO message parameters)

Verwimp,

Verwimp Gery wrote:                                       (Wed, 24 Oct 2001
16:45:48)

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 25 Oct 2001 04:08:36 -0500

Gery,

Verwimp Gery wrote:                                       (Thu, 25 Oct 2001 08:54:21)
> we wait for the Ack then ??

Why wait for Ack?  You're the one that wanted the Ack: why do you
want to wait for it?

> even when associations are restored before SS7 links ...

You mean the whole SG/STP node goes down and up?  Aside from the
fact that we are talking about less than about a minute a year, the
STP must go through MTP Restart procedures and then need not send
TFA for the ASP's Point Codes until the SGs are ready and
configured.  If you think that re-registering connections will take
some time, look at the MTP Restart procedure.  It will take some
time before the STP can even be used.

> until and Ack is received again ...

Perhaps a second CIRE, but why wait for the Ack?

> 1) Completely coupled. ASP can selects SG1 or 2 with each connection setup

And what happens when SG1/2 goes down and come up again? A: 50% of
the connections are lost.  What happens when SG1 or 2 can no longer
communicate with the ASPs? A: 50% of the connections are lost.  What
happens when an ASP looses communication with an SG: A: 50% of its
connections are lost.

As 50% failure is considered a system failure and subscriber
services rely on the connections,  FCC or even Congressional
hearings start.  Your CEO is asked to testify as to why you didn't
use a decoupled approach.  He answers (honestly) that Gery didn't
want to complicate matters by trying to be transparent with SS7...  ;)

Now, let's compare SUA's coupled approach to SS7's:

In SS7, (yes, even when coupling to change transports) we have the
following scenario:

               _______                
              |       |               
       _______|  STP  |               
             /|   A   |\_             
            / |_______|  \_     ___   
           /      |        \_  /   \  
                  |          \| SEP | 
                  |         _/|  X  | 
           \   ___|___    _/   \___/  
            \ |       | _/            
       ______\|  STP  |/              
              |   B   |               
              |_______|               

Half of SEP X's connections are coupled thru STP A, the other half
thru STP B.  When STP A goes down, all of the SEP X's connections
thru STP A go down with it.  This is the same as your SUA coupling.
However, when the links between SEP X and STP A go down, all
connections are maintained.  This is because SEP X now routes STP A
connection traffic to STP A via STP B and the C-links.  And STP A
routes connection traffic to SEP X across C-links and via STP B.
Even though the connection is coupled through STP A, it is still
available to be "transfered" through STP B.

Facility failure is far more probable than node failure (the back-
hoe factor).  Also, communication between SEP X and STP A is not
worse than if SEP X is an ASP and STP A is an SG (after all, we are
talking about the same facilities).  Therefore, SUA performs worse
than SS7 because its concept of coupling does not include the
redundancy provided by the STPs.

In essense, SUA is more equivalent to this arrangement: (because
path redundancy is not provided for).

               _______          ___   
              |       |        /   \  
       _______|  STP  |_______| SEP | 
             /|   A   |       |  X1 | 
            / |_______|        \___/  
           /      |                   
                  |                   
                  |                   
           \   ___|___          ___   
            \ |       |        /   \  
       ______\|  STP  |_______| SEP | 
              |   B   |       |  X2 | 
              |_______|        \___/  

So, now, fixing the problems with SUA's half-baked "coupled"
approach and what you call the "decoupled" solution are the same.
SG A and SG B must both know about the ASP's connections.  Then it
doesn't matter if the connection is coupled at STP A or whether they
are coupled elsewhere in the SS7 network or whether the connection
section ends at the SEP.

SG/STP B will still need to know the reference number (and point
codes and all that other info) that SG/STP A assigned to the
connection to be able to process messages to and from the ASP.

SUAs coupled approach does not address SG/STP configurations
properly.  I might be able to be made adequate with the same
CIRE/CIDE technique.

> fixed ASP (or ASP based on OPC,DPC,SLS or whatever DLR scheme agreed with

This is M3UA.  There is nothing stoping M3UA from routing on DPC/DLR
in the fashion you described.  SUA offers nothing in this case.

> So, do we really need this third (complex) approach ? I say 1) & 2) is more

1) is inadequate because adding an STP/SG does not significantly
   increase reliablity as it does in SS7.  This is due to SUA's
   half-baked decoupled approach.

2) is M3UA.

So, I don't think we're talking about a 3rd approach here.  We are
talking about a complete solution instead of a half a solution which
does not address multiple SG/STPs in SUA's view of "coupling" being
far less that actual coupling in SS7.

--------

One of the problems is that SUA keeps trying to make a linkset out
of an association with an SG.  That is the MTP to MTP-User interface
and not the SCCP to SCCP-User interface.  Trying to force the
association to be a linkset is always evidenced by the disappearance
of SCCP state machine functions on the SG and appearance of the SCCP
state machine functions on the ASP.  When all or most of the SCCP
state machines have been moved to the ASP, the association can be
indeed treated as a linkset, but you wind up with M3UA.

One way to ensure that one doesn't wind up with M3UA is to make sure
that all or almost all SCCP state machine functionality remains at
the SG and that it is only the SCCP/SCCP-User interface which is
exported to the ASP.

SUA doesn't seem to have problems with CL.  That's because CL user
interfaces are simple: open, bind, send, recv, close.  It is once
SUA gets to CO that it messes up.  CO user interfaces are more
complicated: open, bind, listen, accept, connect, send, recv,
shutdown, close.

When an SG receives a CR, it has to find an AS that is bound and
"listening" for connection indications and inform an ASP supporting
that AS of the connection indication.  When the ASP receives this
connection indication (CORE), it accepts the connection by
indicating which AS is accepting the connection (COAK).  If we do
not permit one AS to listen and another to accept that we cannot
support an SCCP-User from the SG.  The COAK currently does not
identify the AS that is "accepting" the connection.  This is why the
COAK needs a "Connection Identification" parameter that takes the
form of an RC.

Accepting the connection must be performed to all SGs that support
the connection identifying the AS and connection indication
information.  That is, it registers with the information from the CR
and the information for the CC as well as the AS which has performed
the passive connection.  This is done with a CIRE that must contain
the info from the CORE and the COAK as well as the "Connection
Identification" to identify the accepting AS.

In the other direction, for an AS to establish a connection, it
first needs to bind to a local address (PC/SLR) and set some options
(PCLS/SLS/MP/etc).  This can be performed by registering with the
SG.  (Gee, you don't see a bind primitive in the NSD or SCCP.  Why
is that?  You see the bind primitive in all implementations of the
NSD...)  This is a REG REQ to establish a RK to which the AS has
bound.  This is performed with all SGs.

When the AS sends CORE to establish a connection, the alternate SG
must be informed of the state change of the interface with a CIRE
with the info from the CORE.  All SGs then  know that the AS is
awaiting confirmation of the connection request.  When the
connection is confirmed to the AS with COAK and the connection is
established, the alternative SGs need to be informed with a CIRE
that contains the inform from the COAK.

There is little critical timing here: the COAK and any subsequent
DT1 will take the same path, and even if there is an SS7 network
disruption between COAK and DT1s, the DT1s taking the alternate SG
path will be delayed (up to seconds) as a result of delay taken to
detect failure and changeover times.

So, what's the big deal: AS need to register (or be distributed in
some appriori fashion) with multiple SG whether connections are
coupled or not.  AS need to be able to listen independently of
accepting passive connections whether connections are coupled or
not.  AS need to be able to actively connect whether connections or
coupled or not.  And AS need both redundant paths AND redundant SGs
whether connections are coupled or not.

Can we get the SCCP/SCCP-User CO interface correct for the single SG
case and then add a few CIRE/CIDE type messages to allow the
redundancy in the multiple SG case (whether coupled or not)?

Please?

--brian

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Thu, 25 Oct 2001 13:30:59 +0200

Brian,

Summary of my remarks at the end, some notes in between.

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: donderdag 25 oktober 2001 11:09
To: sigtran
Cc: [email-masked]
Subject: Re: SUA Issue #14 (was, SUA v8 : SUA CO message parameters)

Gery,

Verwimp Gery wrote:                                       (Thu, 25 Oct 2001
08:54:21)

[GV] : To make sure SG2 processed the info before it can ever get CC and a
stream of DT1s ... of course, chances are slim but the association with SG2
may be congested, while the CR/CC are on a "free" highway.

[GV] : Fine for me. But just assume you had 1'000'000 or more connections
going on ... oops !

[GV] : probably there's no reason to wait for the ack here. The CIRE must
have been processed before any other message in the forward direction.

[GV] : Nice prospect.

               _______                
              |       |               
       _______|  STP  |               
             /|   A   |\_             
            / |_______|  \_     ___   
           /      |        \_  /   \  
                  |          \| SEP | 
                  |         _/|  X  | 
           \   ___|___    _/   \___/  
            \ |       | _/            
       ______\|  STP  |/              
              |   B   |               
              |_______|               

               _______          ___   
              |       |        /   \  

[GV] : Well, I see no reason why we can't put an SUA association between the
mated SGs and making the ASP specify the detour somehow (it knows what
association it is using). Backward direction no problem, PC=SG1 is used
(same as in SS7). Would be a nice feature for a mated-pair SUA relay node in
all-IP as well. Why not have redundancy of SCTP associations from SG->ASP as
well if we're worried about facilities failure ? Little has to be done here
in terms of procedures and message formats/parameters.

[GV] : When routing on DPC, yes, there's not much SUA nor SCCP can offer
over M3UA/MTP3. Consider routing on hostname or IP-address or whatever.

2) is M3UA.

--------

[GV] : SCCP requires no binding/registering with any instance before
establishing a connection; either the application sorts out it's
communication partner (DPC/SSN) or it's sorted out on the fly (GT).

Please?

[GV] : Phew, finally at the end. In summary,

1) Coupled approach as it stands is insufficient (although still an option,
single SG). I see 2 solutions :

1.1) Use the CIRE/CIDE mechanism. Pain : timing assumptions made and
additional CIRE/CIDE procedures at both ASP and SG. Gain : it delivers both
"facilities" and "node" redundancy. However, ... see remark below.

1.2) Use a mated-pair SG concept. Pain : it requires an additional SCTP
association and SG procedure in forward and backward direction. And it only
provides "facilities" redundancy, equivalent to SS7 though. Gain : no
additional messages, nor timing considerations (restart, connection setup).
It also provides facilities redundancy from SG->ASP.

=> Brian, with 1.1) it is still a concern that even when the association
SG1<->ASP is down, SG1 is reachable from SS7, so there's no reason
(insequencedelivery) why messages from SEP wouldn't be routed to SG1.
There's no way to signal "RK unavailable" to SS7. So no "facilities"
redundancy in backward direction.

2) Decoupled : this is still an option, which requires complete CO
state/event machines at the ASP. No additions to the draft required.

Please consider 1.2) ?

--gery

---

---

From: [email-masked]
Date: Thu, 25 Oct 2001 15:56:17 +0300

Hi Gery & Brian,

It seems that we are coming closer to agreement on this issue, slowly -
and after many emails.

Brian, do you stand by your original proposal (attached)?  Gery,
What do you think needs to be added/subtracted from this.

Both Brian & Gery - do you feel that any text needs to be added to
chapter 4 to describe this?

thanks,
John

------
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]
Subject: Re: [SUA issue 14] Changes and additions required for decoupled o
	  peration.
Date: Tue, 11 Sep 2001 11:36:11 +0300

John,

Here's a proposal which is different that the REG REQ proposal.
(complete with text ;)

--brian
      
   Connection-Oriented Messages  
    
     0         Reserved 
     1         Connection Request (CORE)  
     2         Connection Acknowledge (COAK) 
     3         Connection Refused (COREF)  
     4         Release Request (RELRE)  
     5         Release Complete (RELCO)  
     6         Reset Confirm (RESCO)  
     7         Reset Request (RESRE)  
     8         Connection Oriented Data Transfer (CODT) 
     9         Connection Oriented Data Acknowledge (CODA) 
     10        Connection Oriented Error (COERR) 
     11        Inactivity Test (COIT) 
 >   12        Connection Indication Registration (CIRE)
 >   13        Connection Indication Deregistration (CIDE)
 |   14 - 127  Reserved by the IETF 
     128 - 255 Reserved for IETF-Defined Message Class Extensions 

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Thu, 25 Oct 2001 15:26:09 +0200

Hi John,

I'd like first to await Brian's answer to my previous mail.

The reason is the CIRE/CIDE approach does solve the ASP->SG node and
"facilities" (i.e. SCTP association) redundancy problem, but in the backward
direction (SG->ASP) we are still left with a single SCTP association and no
way to signal the SS7 network
when it goes down (multiple ASPs, so the AS is not unavailable, only a
single ASP). So it is pending ...

As an alternative, I proposed a mated-SG pair concept in SUA, with an
additional SCTP association between the SGs. Which would also solve the
reassembly issues we had at the SG before.

--gery

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: donderdag 25 oktober 2001 14:56
To: sigtran
Subject: RE: SUA Issue #14 (was, SUA v8 : SUA CO message parameters)

Hi Gery & Brian,

thanks,
John

------

John,

--brian

     0         Reserved 

      0                   1                   2                   3  

   Parameters

      0                   1                   2                   3  

   Parameters

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 26 Oct 2001 05:37:26 -0500

Gery,

1.2 is not good for several reasons:

  - operators are taken to placing different brands (vendor) STPs
    in mated pairs to avoid syndromes (like those that took out
    North American calling for about 9 hours a ways back).  Therefore,
    if there is an SG to SG communication, it needs to be specified
    and interoperable.  That will take more time than 1.1 and, on
    the contrary, will require many "additional" messages.

  - it does not solve any timing issues.  It does not matter whether
    SG2 discovers something from SG1 or from the ASP.  The same sequence of
    events needs to be considered.  So timing doesn't go away either.

  - it removes control from the ASP against WG principles.  SG1 and 2
    can communicate and alter traffic without considering or involving
    the ASP.  1.1 approach keeps the ASP in control.

  - you have to consider what happens if STP/SG1 gets isolated on all
    facilities.  Then ASP can no longer reach SG1 and 50% loss again.
    In SS7 if one STP gets isolated, the other takes the full load
    and no connections are lost.  Approach 1.2 reduces redundancy over
    approach 1.1 and SS7.

1.1. approach is superior in all these regards.

--brian

See also below...

Verwimp Gery wrote:                                       (Thu, 25 Oct 2001 13:30:59)

[snip]
> 
> [GV]: Phew, finally at the end. In summary,
> 

STP1 knows that the ASP's point code is only accessible via C-links and
messages for ASP's PC are routed to SG2.  SS7 handles this quite fine and
needs no "RK unavailable" as it has PC unavailable.

> state/event machines at the ASP. No additions to the draft required.

No SUA draft required at all in this case: just M3UA.

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 26 Oct 2001 05:39:43 -0500

John,

This text will have to be updated to reflect the results of
current discussions.  We will reword it once we get a little
closer to resolution.

--brian

John Loughney wrote:                                         (Thu, 25 Oct 2001 15:56:17)

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

---

---

From: [email-masked]
Date: Fri, 26 Oct 2001 13:44:33 +0300

Hi Brian,

> current discussions.  We will reword it once we get a little

I'm leaning towards supporting your proposal.  However, I believe
that we need to craft text in Chapter 4 to discuss the usage
of the CIRE/CIDE messages.  My feeling is that the text details
these messages to be optional (something like: When an ASP is
connected to more than one SG, the CIRE SHOULD be sent ...).

Comments?
John

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 26 Oct 2001 06:02:35 -0500

John,

John Loughney wrote:                        (Fri, 26 Oct 2001 13:44:33)
> connected to more than one SG, the CIRE SHOULD be sent ...).

That was always my intention.

--brian

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Fri, 26 Oct 2001 13:14:10 +0200

Brian,

See below ...

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: vrijdag 26 oktober 2001 12:37
To: sigtran
Cc: [email-masked]
Subject: Re: SUA Issue #14 (was, SUA v8 : SUA CO message parameters)

Gery,

[GV] : Well, bring up the SCTP association between them with ASPUP/ACK.
Capabilities = SG-mate.

[GV] : There are no timing issues. If SG1 didn't do the coupling, it must
have been SG2. No CC/DT1/etc. can be received before SG2 sent out CR.

[GV] : the ASP has control, based on it's knowledge of the SG used and SCTP
association availability.

[GV] : That's the node failure case (less than 1 minute/year) which also
isn't solved in SS7 SCCP procedures.

[GV] : That's not true. If the SG1-ASP association goes down, 100% of the
connections may be affected. SG1 is not able to forward received CO messages
to the ASP anymore. "PC unavailable" doesn't work, unless you want to assign
separate point codes to each and every ASP. Which means you abandone host
redundancy on the ASP side.

--gery

See also below...

13:30:59)

[snip]

[GV] : RK is linked to AS, and can go no finer than a PC if you rely on PC
unavailable. What happened to the multiple ASP concept ? SG1 simply does not
send PC-unavailable if only 1 ASP in the AS goes down. Unless you want to
change procedures here too ?

[GV] : If one only has SUA in the SG, one would be happy if this still works
as well.

--gery

---

---

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

John is a bit too optimistic. CIRE/CIDE still looks like a quarter-baked
solution to me ;))

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: vrijdag 26 oktober 2001 13:03
To: sigtran
Cc: [email-masked]
Subject: Re: SUA Issue #14 (was, SUA v8 : SUA CO message parameters)

John,

--brian

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

---

---

---

From: [email-masked]
Date: Mon, 29 Oct 2001 13:31:38 +0200

Gery,

> John is a bit too optimistic. CIRE/CIDE still looks like a 
> quarter-baked solution to me ;))

In the spirit of progress, I suggest we adopt Brian's 
proposal.  We add disclaimers to the text (when this 
functionality is needed & for those who choose not to implement
it).  I think that in an SUA (or UA) Applicability 
statement, we could outline how to handle the functionality 
with a mated-pair approach.

Without evidence of any other solid proposals for this 
issue, I hope Brian could quickly turn around suitable
text and we can close this issue out.

thanks,
John

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 29 Oct 2001 06:02:05 -0600

John,

John Loughney wrote:                                         (Mon, 29 Oct 2001 13:31:38)
> text and we can close this issue out.

M2PA interop starts today at Alcatel in Plano.  I'm not sure
how much I can turn around this week...

--brian

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Tue, 30 Oct 2001 10:53:44 +0100

John,

This is too premature. Let me spell out the problem with CIRE/CIDE :

Consider the scenario multiple SG and multiple ASPs in the AS :

- single SG is no issue
- when each ASP wields an SS7 PC, it's a straightforward decoupled approach,
and there's no need for anything else.

1) With coupled approach, 1 SG is selected during connection setup
(sending/receiving CORE/CR). When the SG, or the association towards it, 50%
of the connections currently handled by this single ASP fail. However, the
service is still available and new connections are possible, on this ASP and
the others in the AS. Traffic to the affected ASP might even be reduced.

This is essentially no different from SS7 procedures with coupling. Both the
SS7 and the IP network (multihoming !) have redundant routes towards the SG
to minimize facilities failure. The SG's pointcode is used throughout in the
SS7 network.

2) With CIRE/CIDE, redundancy of SGs is guaranteed (both SGs can take over).
However, there is no control over the backward path : a response may arrive
on any SG (asymmetrical routing, a capability PC is used in the SS7 network
to route via either SG, providing redundancy of SGs). So if one association
fails, every connection handled by this ASP is prone to disruption. It
cannot even be guaranteed that new connections can be setup by this ASP
(CORE sent out, but CC never arrives). So the advantage over 1 backfires and
turns into a nasty hole.

The SG in question cannot send PC unavailable to the SS7 network, for the
simple reason it is not : there's other ASPs handling traffic for it. And
suppose another ASP lost association with the second SG : we'd loose service
when only 2 out of n associations are lost (n = 2 * #ASP * #SG in a fully
redundant environment).

1) is both more simple (no risk of timing issues e.g.), aligned with SS7
procedures, and even superior in behavior.

Regards,

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: maandag 29 oktober 2001 12:32
To: sigtran
Subject: RE: SUA Issue #14 (was, SUA v8 : SUA CO message parameters)

Gery,

thanks,
John

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 30 Oct 2001 04:25:41 -0600

Verwimp,

Verwimp Gery wrote:                                       (Tue, 30 Oct 2001 10:53:44)
> to minimize facilities failure. The SG's pointcode is used throughout in the

Wrong.  Go back and read previous note.  When A-link fails between SEP
and coupled STP, messages are routed to coupled STP via decoupled STP.
Without registration, when associations to coupled SG fail, it is not
possible for the ASP to send to the other SG.  This is way worse than
SS7 and causes 50% connection failiure as a result of the loss of
communication between two geographic points and represents a SPOF.

> (CORE sent out, but CC never arrives). So the advantage over 1 backfires and

Very wrong. Go back and read previous note.  Because ASP PC is separate from
STP/SG PCs, the STPs can always reach the PC if it is reachable at all.
It will use C-links and invoke transfer retricted procedures back to the
network if required.

> when only 2 out of n associations are lost (n = 2 * #ASP * #SG in a fully

Is you have 1 and only 1 ASP serving a connection you have a SPOF.  That
would be an implementation decision.   It is quite possible to have at
least two ASPs available on separate associations for each connection.
Don't confuse SG redundancy with ASP redundancy.

> procedures, and even superior in behavior.

Inferior to SS7 in same failure situations, as described in previous
notes.

--brian

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Tue, 30 Oct 2001 11:42:19 +0100

Brian,

See below ...

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: dinsdag 30 oktober 2001 11:26
To: sigtran
Cc: [email-masked]
Subject: Re: SUA Issue #14 (was, SUA v8 : SUA CO message parameters)

Verwimp,

Verwimp Gery wrote:                                       (Tue, 30 Oct 2001
10:53:44)

[GV] : 50% of connections handled by the ASP, not 50% of the ones handled by
the AS.

[GV] : Yes, and it will go via either SG. No way to predict which, so 50%
chance it takes the SG which has no association with the ASP anymore. There
are no links between the SGs as it stands. Also, it's the AS PC (multiple
ASPs). Once you attach PCs to each single ASP, straightforward decoupling is
possible (gee, M3UA without ASP redundancy). C-link nor transfer restricted
can be invoked. Besides, C-link is no general solution, if you use more than
2 SGs (Extended Access STP pair ?).

--brian

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 30 Oct 2001 04:54:30 -0600

Verwimp,

More below...

Verwimp Gery wrote:                                       (Tue, 30 Oct 2001 11:42:19)
> [GV]: 50% of connections handled by the ASP, not 50% of the ones handled by
> the AS.

Depends on network configuration: for typical networks 50% of all
connections, not just one ASP.  SS7 fails 0% in the same scenario.

> [GV]: Yes, and it will go via either SG. No way to predict which, so 50%
> chance it takes the SG which has no association with the ASP anymore.

An SG which has no association with an ASP serving one connection is an
ASP redundancy problem not an SG redundancy problem.  Add another ASP.

> There are no links between the SGs as it stands. Also, it's the AS PC
> (multiple ASPs). Once you attach PCs to each single ASP, straightforward
> decoupling is possible

> (gee, M3UA without ASP redundancy).

That right: SPOF.

> C-link nor transfer restricted can be invoked. Besides, C-link is no general
> solution, if you use more than 2 SGs (Extended Access STP pair ?).

Use STP quads if you'd like: they have links between them.

> Don't confuse SG redundancy with ASP redundancy.

You didn't wish to comment on this?

--brian

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

---

---

From: [email-masked]
Date: Tue, 30 Oct 2001 16:04:04 +0200

Gery,

> This is too premature. 

I suggest that we get agreement quite soon.

There are these options:

1) Leave multiple SG support an implementation dependent issue.
2) CIRE/CIDE approach
3) Coupled approach

Comments that I have recieved have indicated that 1) is not
sufficient.

Choice 2) seems to be the best documented, and can be made
optional.

Choice 3) seems to be feasible, with some reservations.

Now, I believe that 2) allows for a decoupled approach, while
3) uses a coupled approach.  I think that the use of either
is best left to an applicability statement.

Now, I think the way foward is to allow the decoupled 
approach & allow the coupled approach (I'll give each
a paragraph or 2 in chapter 4) and we get some operational
experience on these.  Somehow, I feel that choosing
a coupled vs. decoupled approach may well be a network
administrative decision.

best regards,
John

---

---

From: Verwimp Gery <[email-masked]>
Date: Wed, 31 Oct 2001 12:30:12 +0100

Brian,

See below ...

------
Verwimp,

More below...

11:42:19)

[GV2] : Both SGs are available, just the association between SG1 and ASP1 is
down.

1) Coupling : 50% of connections handled by ASP1 is lost. All new
connections with ASP1 (ASP1 sends CORE) will be setup via SG2. SG1 will
distribute received CRs to the other ASPs in the AS.

2) CIRE/CIDE : for SG1 it's unclear what to do, does it keep the
registration data ? It has to, to be able to reroute messages destined for
ASP1 via SG2. Otherwise all connections with ASP1 can be affected since we
can't predict the return path taken back from SS7 SEP. But connections may
be released in the mean time, how does SG1 gets updated (no CIDE possible) ?
Also, new connections can't be setup if we can't get a CIRE to SG1 (and it
might get the CC).

[GV2] : That doesn't solve the problem of what to do with the existing
connections handled by ASP1, for which messages might still be received at
SG1 (due to ASP redundancy, there's no PC unavailable sent into the SS7
network).

That right: SPOF.

[GV2] : Quads (or in general more than 2 STP/SGs) introduce another problem
: how does one STP/SG (the one who has lost association with ASP1) know what
other STP/SG still has an active association ? Could be the ASP1 got totally
isolated. The STP/SGs would start a merry-go-round rerouting between one
another ...

[GV2] : if we had 2 ASPs to handle the same connection (state sharing
whatever), then how do you want to register this with the SGs ? We don't
have 2 separate connections to the SEP ...

--gery

---