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

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

Gery,

Please see comments below...

Verwimp Gery wrote:                                       (Mon, 22 Oct 2001 12:26:43)
> 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
> ?

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

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

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

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

What will you do if the CIDE is not acked?

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

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

> Decoupling still requires to use 24-bit DRNs only, but the label approach
> 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

> 
> ____________________________
> 
> 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: maandag 22 oktober 2001 11:39
> To: Verwimp Gery
> Cc: sigtran
> Subject: Re: SUA Issue #14 (was, SUA v8 : SUA CO message parameters)
> 
> 
> 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) 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.
> 
> 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.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.
> 
> 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) Release :
> > 
> > 3.1) as usual by RELRE/RELCO exchange.
> > 
> > 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.
> > 
> > Any further ideas about this ?
> 
> 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
> 
> > 
> > ____________________________
> > 
> > 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: 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)
> > > 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,
> > > 
> > > 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)
> > > > 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
> > > > 
> > > > > -----Original Message-----
> > > > > 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,
> > > > > 
> > > > > 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,
> > > > > 
> > > > > 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.
> > > > > 
> > > > > [GV] : I've seen no support for your proposal so far ...
> > > > > 
> > > > > > 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.
> > > > > 
> > > > > [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.
> > > > > 
> > > > > > - 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.
> > > > > 
> > > > > [GV] : Which is totally unnecessary. Messages only have to be 
> > > > > in sequence
> > > > > within a connection. Be glad, this improves load balancing options !
> > > > > 
> > > > > > - 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.
> > > > > 
> > > > > [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.
> > > > > 
> > > > > > - 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.
> > > > > 
> > > > > [GV] : see above. No requirement on amount of streams.
> > > > > 
> > > > > > 	- 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!
> > > > > 
> > > > > [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 ?
> > > > > 
> > > > > 
> > > > > > 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?
> > > > > 
> > > > > [GV] : That was irony, Brian.
> > > > > 
> > > > > 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.
> > > > > 
> > > > > [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
> > > > > 
> > > > > 
> > > > > ---
> > > > > You are currently subscribed to sigtran as: 
> > > > > [email-masked]
> > > > > To unsubscribe send a blank email to 
> > > > > [email-masked]
> > > > > 
> > > > 
> > > > 
> > > > ---
> > > > You are currently subscribed to sigtran as: [email-masked]
> > > > To unsubscribe send a blank email to
> > > [email-masked]
> > > 
> > > -- 
> > > 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]
> > > 
> > > 
> > > ---
> > > You are currently subscribed to sigtran as: [email-masked]
> > > To unsubscribe send a blank email to
> > [email-masked]
> > 
> > -- 
> > 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]
> > 
> > 
> > ---
> > You are currently subscribed to sigtran as: [email-masked]
> > To unsubscribe send a blank email to
> [email-masked]
> 
> -- 
> 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]

-- 
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: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 22 Oct 2001 14:43:11 -0500

Gery,

> thing. Perhaps you should read up on the ITU specs ;) We have to support

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.  In ITU networks, the
bit number which is use to select linkset changes from STP to STP.  The two
procedures have the same effect and are quite similar.  ANSI has the advantage
that bit numbers do not need to be assigned to STPs.

Neither method requires any particular support in either M3UA or SUA except
that M3UA and SUA must select the proper SLS value on outgoing messages.
In-sequence delivery is something which is done by the SS7 network and is
transparent to the SEP.  The SEP need only assign the same outgoing SLS for
all messages that it wants delivered to the distant end in sequence.  This is
the same for ANSI and ITU networks.

I suggest you read ANSI T1.111.5 7.3 and particuarly 7.3.1.  You will find the
same format of section describing the same thing in Q.705 A.3 with
particular attention to A.3.2.  There is, in fact, little difference between
the ANSI approach and the ITU approach.  The ITU approach uses different
bit positions at each node without rotating the SLS.  The ANSI approach uses
the same bit position at each node and rotates the SLS.  Both approaches
yeild the same result.

Anyone who has worked with MTP in both environments knows this.

There is "such a thing in ITU". :P

It would assist the process if one doesn't spread misinformation about SS7.

--brian

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

---