Subject: RE: [Sigtran] Some SUA Messages Parameters...

From: Verwimp Gery <[email-masked]>
Date: Fri, 3 May 2002 18:37:08 +0200

Hello all,

There are a number of ways to select the ASP handling a TCAP transaction,
e.g.

1) Routing is done on GT (requiring the AMF at the SG)

It is good practice (see also ITU-T Q.716) that only the TC_Begin/TC_Query
is subject to loadsharing across "end nodes", this means for the
TC_Begin/TC_Query there might be a number of ASPs available which are
capable of handling the new transaction. The selection of one of them at the
SG is implementation dependent, e.g. round robin.

The ASP that finally got it, then may return an unambiguous address (new
GT), so that when subsequent messages are received for the ASP, the SG is
able to resolve this address to this unique ASP and loadsharing among ASPs
is no longer an issue.

So we have TC_Begin GT => RC1 => AS1 with several ASPs
           TC_Continue GT' => RC2 => AS2 with single ASP

2) Routing on DPC+SSN

When no specific GT information is present, and DPC+SSN is defined by RCx =>
ASx with several ASPs, no matter how you look at it, you have a distribution
problem at the SG. You have no idea where previous messages for the same
transaction were sent to. Now either:

- you limit DPC+SSN to only specify a single ASP (probably a bad idea).
- you let the ASPs figure it out amongst themselves and choose one randomly
(protocol class 0) or based on SLS (protocol class 1) => this would require
inter-ASP communication or state-sharing, but it could be a valid
possibility.
- the SG knows (somehow) which ASP uses which TID range for a certain ASP
and the SG bases it's distribution decision on this => that was the
TID-label idea, but hey, if some people like to remove it ... it's still an
implementation option.

A complete SLS based solution doesn't make sense, since even TCAP messages
may use protocol class 0.

As for SCCP connections, either you have some kind of peer-to-peer
configuration, meaning you have SCOC state-machines at both SG and ASP; or
you have backhaul, with SCOC state-machines at the SG.

Either way you look at it, you have SCOC state machines at the SG; and at
least some user reference (hey let's call it DRN) by which the ASP
identifies it's application resources.

Once the CR (or CORE) is handled, the RC is fixed and the ASP is chosen; and
it's useless to look again for an RC for subsequent messages (no address
info whatsoever in e.g. a DT1). The connection context is stored at both SG
and ASP.

Now you might consider the SG as a single point of failure here (apart from
the ASP itself), so you may want to come up with some sort of state-sharing
between SGs of an SG-pair, which requires a standard way of doing this
(SG-SG interworking ?) or leaving it internal among the SGPs of a single SG.
Anyway, any option should be transparent for the ASP.

Regards,
Gery

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: donderdag 21 maart 2002 21:51
To: Narendar Goel
Cc: [email-masked]
Subject: Re: [Sigtran] Some SUA Messages Parameters...

Narendar,

The intention of the AMF and TID Label was to distribute over
TCAP applications within SUA at the SG.  For CL traffic if these
are of no use, they might as well both be removed.

--brian

Narendar Goel wrote:                                     (Thu, 21 Mar 2002
15:05:23)
> Brian,
>   From SUA point of view it is one application.How you distribute traffic
> per SSN is implementation dependent and is done inside TCAP for CL
messages.
> Narender
> 
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Thursday, March 21, 2002 3:04 PM
> To: Narendar Goel
> Cc: [email-masked]
> Subject: Re: [Sigtran] Some SUA Messages Parameters...
> 
> 
> Narendar,
> 
> On Thu, 21 Mar 2002, Narendar Goel wrote:
> 
> >
> > Brian,
> >  If SUA cannot support one TCAP application per AS, then I think there
is
> > serious flaw. But I still think it is possible.
> > If incoming message contains only SSN and we don't have control over it
> then
> > there is limitation of single AS per SSN. Which will make RC unique.
> 
> This would make AMF useless (but I agree that AMF is pretty useless
anyway).
> However, what makes you think that one TCAP applicatoin runs on one SSN?
> Each SSN can support multiple TCAP applications (e.g, AIN/CS).
> 
> --brian
> 
> >
> >  Thanks,
> > Narender
> >
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: Thursday, March 21, 2002 2:04 PM
> > To: Narendar Goel
> > Subject: Re: [Sigtran] Some SUA Messages Parameters...
> >
> >
> > Narendar,
> >
> > On Thu, 21 Mar 2002, Narendar Goel wrote:
> >
> > > Brian,
> > >  CDPA can differ but it won't. Because I will tell the SS7 application
> to
> > > keep it same.
> >
> > That is far from seamless.  Because intermediate CONT packages have
> > a CDPA which is SSN only once the dialogue has begun, this means that
> > the only way to keep CDPA the same is to alway use SSN only.  That
> > means that AMF is useless.  RC is based on DPC+SSN only.  That is what
> > I said: if you only use AMF (RK) of DPC+SSN only there is not problem.
> > But SUA is not specified that way.
> >
> > > If I don't do that I have to register multiple AS for a single
> > > application.
> >
> > There is no required mapping between an AS and an application.
> >
> > > I might not want that.
> >
> > I agree, you might not want that.  But I cannot see that AMF can work
> > on GT, nor do I see that TID label can work either.
> >
> > > Also CDPA normaly do not change in TCAP transaction.
> >
> > This is not true.  The BEGIN normally has CDPA with global title.  CONT
> > and onwards have CDPA with SSN only.
> >
> > > I believe single apllication should ideally belong to single AS
> > > and have unique RC.
> >
> > Perhaps, but SUA is not specified that way.
> >
> > > Also corrId are never matched to TID label. TID is mandatory parameter
> in
> > > TCAP and is always present and is unique for each transaction end
point.
> >
> > But multiple TCAP dialogues can make up a application exchange, and this
> > is true for almost all TCAP applications.
> >
> > What is better, and will be addressed by an extension draft for both
> > SUA and TUA, is the ability for the ASP to indicate to multiple SG which
> > DLRs and TID are currently associated with which RCs.  That permits your
> > one application to obtain what it wants on a single AS and RC value.
> >
> > --brian
> >
> > >
> > >  Thanks,
> > > Narender
> > >
> > >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]On Behalf
Of
> > > Brian F. G. Bidulock
> > > Sent: Thursday, March 21, 2002 1:00 PM
> > > To: Narendar Goel
> > > Cc: Steve Clark; [email-masked]
> > > Subject: Re: [Sigtran] Some SUA Messages Parameters...
> > >
> > >
> > > Narendar,
> > >
> > > Narendar Goel wrote:                                     (Thu, 21 Mar
> 2002
> > > 12:39:08)
> > > > Brian,
> > > >  I said loadsharing within a AS. In that case RC will be same if I
we
> > use
> > > > TID label or not.
> > >
> > > Ah.  But how do you define an RK for this TCAP AS?  GT?  Subsequent
> > > messages in the dialogue will not have the same CDPA as the BEGIN.
> > > Thus, the AMF maps them to different RC.  If you do away with the AMF
> > > altogether and just assign RC values on the basis of DPC+SSN then
there
> > > would not be a problem; however, that is not the way that SUA is
> > > specified.
> > >
> > > > Also even if corrid or linkedId are different they wil
> > > > belong to same transaction and and hence make no difference.
> > >
> > > The AMF can man the BEGIN and onto different RC than the CONT.  This
> > > is because the CDPA differs.
> > >
> > > --brian
> > >
> > > It makes a difference if they don't match the label.
> > >
> > > >
> > > > -Narender
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: [email-masked] [mailto:[email-masked]]On
Behalf
> Of
> > > > Brian F. G. Bidulock
> > > > Sent: Thursday, March 21, 2002 11:50 AM
> > > > To: Narendar Goel
> > > > Cc: Steve Clark; [email-masked]
> > > > Subject: Re: [Sigtran] Some SUA Messages Parameters...
> > > >
> > > >
> > > > Narendar,
> > > >
> > > > Narendar Goel wrote:                                     (Thu, 21
Mar
> > 2002
> > > > 09:42:46)
> > > > > Brian,
> > > > >  I was thinking TID label was meant to loadshare incoming(fromm
SS7
> > side
> > > > at
> > > > > SG TCAP transactions between ASPs within a AS. If this is not true
> > than
> > > > how
> > > > > can we distribute incoming TCAP(other than Begin Dialogue)
traffic
> > > beween
> > > > > ASPs within a AS. In this case it is possible that ASP which did
not
> > > > > initiate TCAP dialogue may receive a response and abort the TCAP
> > > dialogue.
> > > > >  Thanks,
> > > > > Narender
> > > > >
> > > >
> > > > TID Label can't help you here.  The question becomes the same: what
RC
> > > > value is assigned to subsequent messages in the diagogue?  SUA would
> > > > have us assigned RC based on the AMF, while SCCP CL routing delivers
> > > > on SSN only.  Any what kind of a rational basis is TID?
Conversations
> > > > can have linked and correlation id's different from the local
> > transaction
> > > > id associated with the begin.  Distribution based on SLS is better:
at
> > > > least all class 1 transaction components will be sent to the same
ASP.
> > > >
> > > > Otherwise, if you want to distribute TCAP messages over ASPS, I
> suggest
> > > > you look at TUA.
> > > >
> > > > --brian
> > > >
> > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: [email-masked] [mailto:[email-masked]]On
> Behalf
> > Of
> > > > > Brian F. G. Bidulock
> > > > > Sent: Thursday, March 21, 2002 4:09 AM
> > > > > To: Steve Clark
> > > > > Cc: [email-masked]
> > > > > Subject: Re: [Sigtran] Some SUA Messages Parameters...
> > > > >
> > > > >
> > > > > Steve,
> > > > >
> > > > > Steve Clark wrote:
> > (Wed,
> > > 20
> > > > > Mar 2002 21:20:13)
> > > > > >
> > > > > >  Hi All,
> > > > > >         I have read the SUA draft
> > > > > > draft-ietf-sigtran-sua-12.txt , in that
> > > > > > 1) i was not able to understand the TID Label and DRN
> > > > > > Label parameters used in ASP Active message.
> > > > >
> > > > > These Labels are SUA's half-hearted attempt at supporting
> > > > > decoulped transactions and connections over multiple SGs
> > > > > acting as STPs.  It doesn't work, so I wouldn't worry
> > > > > about them too much.  An extension draft will address the
> > > > > multple SG as STP configuration thoroughly.  I asked for
> > > > > this broken behavior to be removed from the draft, but,
> > > > > alas, it has not.  As it stands it is completely optional,
> > > > > so will likely fall out of use.
> > > > >
> > > > > As it stands, CO support is weak in SUA.  It is a big
> > > > > question just what RC value will be assigned to CO
> > > > > messages other than CORE.
> > > > >
> > > > >
> > > > > > 2)Also, the Routing key parameter has an Parameter
> > > > > > Address Range in which it is again mentioned source
> > > > > > Address and Destination Address, which is already
> > > > > > there in the Routing key Identifier. So, what's the
> > > > > > purpose of that and why it is needed.
> > > > >
> > > > > The Address Range parameter represents a range of
> > > > > source addresses or a range of destination addresses.
> > > > > The source and destination address parameters do not
> > > > > represent a range.  This is so that a Routing Key
> > > > > can represent a range of global titles, for example.
> > > > >
> > > > > --brian
> > > > >
> > > > >
> > > > > >
> > > > > > can anyone give me the explanation for these two
> > > > > > things.
> > > > > >
> > > > > > regards
> > > > > > Steve
> > > > > >
> > > > > >
> > > > > > __________________________________________________
> > > > > > Do You Yahoo!?
> > > > > > Yahoo! Movies - coverage of the 74th Academy Awards®
> > > > > > http://movies.yahoo.com/
> > > > > >
> > > > > > _______________________________________________
> > > > > > Sigtran mailing list
> > > > > > [email-masked]
> > > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > >
> > > > > --
> > > > > Brian F. G. Bidulock
> > > > > [email-masked]
> > > > > http://www.openss7.org/
> > > > >
> > > > > _______________________________________________
> > > > > Sigtran mailing list
> > > > > [email-masked]
> > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > >
> > > > --
> > > > Brian F. G. Bidulock
> > > > [email-masked]
> > > > http://www.openss7.org/
> > > >
> > > > _______________________________________________
> > > > Sigtran mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > >
> > > --
> > > Brian F. G. Bidulock
> > > [email-masked]
> > > http://www.openss7.org/
> > >
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> >
> > --
> > Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
> > [email-masked]    ¦ world; the unreasonable one persists in  ¦
> > http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
> >                         ¦ Therefore  all  progress  depends on the ¦
> >                         ¦ unreasonable man. -- George Bernard Shaw ¦
> 
> --
> Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
> [email-masked]    ¦ world; the unreasonable one persists in  ¦
> http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
>                         ¦ Therefore  all  progress  depends on the ¦
>                         ¦ unreasonable man. -- George Bernard Shaw ¦

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

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran