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

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

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]

---

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

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/

---