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

From: Steve Clark <[email-masked]>
Date: Wed, 20 Mar 2002 21:20:13 -0800 (PST)

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

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 21 Mar 2002 03:08:49 -0600

Steve,

Steve Clark wrote:                                                (Wed, 20 Mar 2002 21:20:13)
> 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.

> 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

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

---

From: "Narendar Goel" <[email-masked]>
Date: Thu, 21 Mar 2002 09:09:35 -0500

Hi Brian,
 Regarding RC value in CO messages othere than CORE I think -
 If SUA initiates the CORE than SUA should put same RC value in all
subsequent messages corresponding to this connection(SRN).I know subsequent
messages contain DRN and not SRN but it is up to the implementation to find
correct RC for a given DRN. DRN is unique for a DPC and DPC is linked to RC.

For address range it is true that all combinations of dest/src addresses do
not form valid ranges. But it is upto SG to decide which combination is not
valid for its use. If range combination is not valid SG can return error
message.  In other cases I think this parameter is useful. But use of this
parameter varies with SG implementation. It is possible to generate SSN
range and GTT range with some combinations.

 Thanks,
Narnder

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

--brian

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

---

From: "Narendar Goel" <[email-masked]>
Date: Thu, 21 Mar 2002 09:42:46 -0500

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

-----Original Message-----

Steve,

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 21 Mar 2002 10:40:05 -0600

Narendar,

Please see comments below...

Narendar Goel wrote:                                     (Thu, 21 Mar 2002 09:09:35)
> correct RC for a given DRN. DRN is unique for a DPC and DPC is linked to RC.

I afraid you'll have to explain what you mean here.  In SCCP CL
messages and CR are delivered to the user based on SSN.  In SCCP
CO messages other than CR are delivered to the user based on DLR.
Are you saying that CO messages other then CORE should be delivered
to the same user as CORE?  That would accomplish nothing.  Either
the entire SCOC state machines have to be present at the ASP
(reducing SUA to M3UA) or CO messages other than CORE must be
delivered to the "accepting" interface, not the "listening"
interface.  To distinguish between listening and accepting interfaces
the RC in all messages other than CORE needs to be different that
the RC in CORE.  This is particularly weak in the SUA spec.  And
DRM Label does not help.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 21 Mar 2002 10:50:21 -0600

Narendar,

Narendar Goel wrote:                                     (Thu, 21 Mar 2002 09:42:46)
> initiate TCAP dialogue may receive a response and abort the TCAP dialogue.

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

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

---

From: "Narendar Goel" <[email-masked]>
Date: Thu, 21 Mar 2002 12:32:47 -0500

Brian,
 I agree some of the SCOC work needs to be done at ASP. At least ASP should
maintain a context for each connection at ASP based on its local refrence
number. But draft does not talk about it.
But I don't understand how CO was intended to work in SUA without this.

 Thanks,
Narender

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Brian F. G. Bidulock
Sent: Thursday, March 21, 2002 11:40 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:09:35)

--brian

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

---

From: "Narendar Goel" <[email-masked]>
Date: Thu, 21 Mar 2002 12:39:08 -0500

Brian,
 I said loadsharing within a AS. In that case RC will be same if I we use
TID label or not. Also even if corrid or linkedId are different they wil
belong to same transaction and and hence make no difference.

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

09:42:46)

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 21 Mar 2002 12:01:53 -0600

Narendar,

Some?  All of SCOC.

The way to get around this is to register each connection section
with multiple SGs under its own RC value.  The the SG runs SCOC
and the ASP merely routes primitives to and from the interface (AS)
identified by the RC.

The concept of back-haul as expounded in the SIGTRAN architecture
and framework document is that the SIGTRAN UA merely exports the
SCCP-User/SCCP interface.  That would not include placing SCOC
functionality in the ASP.

--brian

On Thu, 21 Mar 2002, Narendar Goel wrote:

> From: Brian F. G. Bidulock [mailto:[email-masked]]

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 21 Mar 2002 12:00:01 -0600

Narendar,

Narendar Goel wrote:                                     (Thu, 21 Mar 2002 12:39:08)
> 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

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.

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

---

From: "Narendar Goel" <[email-masked]>
Date: Thu, 21 Mar 2002 13:44:55 -0500

Brian,
 CDPA can differ but it won't. Because I will tell the SS7 application to
keep it same. If I don't do that I have to register multiple AS for a single
application.I might not want that. Also CDPA normaly do not change in TCAP
transaction. I believe single apllication should ideally belong to single AS
and have unique RC.
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.

 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,

12:39:08)

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 21 Mar 2002 13:05:06 -0600

Narendar,

On Thu, 21 Mar 2002, Brian F. G. Bidulock wrote:

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

---

From: "Narendar Goel" <[email-masked]>
Date: Thu, 21 Mar 2002 14:45:48 -0500

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.

 Thanks,
Narender

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Brian F. G. Bidulock
Sent: Thursday, March 21, 2002 2:05 PM
To: [email-masked]
Subject: Re: [Sigtran] Some SUA Messages Parameters...

Narendar,

On Thu, 21 Mar 2002, Brian F. G. Bidulock wrote:

> > > >  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
> > > > Steve Clark wrote:
(Wed,
> > 20

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 21 Mar 2002 14:04:09 -0600

Narendar,

> 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

> Sent: Thursday, March 21, 2002 2:04 PM
> To: Narendar Goel

---

From: "Narendar Goel" <[email-masked]>
Date: Thu, 21 Mar 2002 15:05:23 -0500

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,

--brian

> > > > From: [email-masked] [mailto:[email-masked]]On
Behalf
> Of

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 21 Mar 2002 14:51:07 -0600

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 F. G. Bidulock
[email-masked]
http://www.openss7.org/