Subject: RE: some proposals for UA

From: [email-masked]
Date: Sat, 17 Mar 2001 07:57:59 +0200

Hi Ming,

If SUA want to find TID in TCAP message, it has to use ASN.1 decoder.
And ASN.1 decoder is most part of TCAP, then why not implement TCAP in SG?
[<JAL> ] You raise a really good point.  I believe that the SG should not
parse the TCAP message.  However, I still think that SG could do loadsharing
based upon the origination point.  Let me think about how to add text to
cover this.  
 
Would this sufficient?  The TCAP transaction IDs are not really meaningful
on their own, so as long as we can do some loadsharing between ASPs
(multiple ASPs could share the same SSN).  The SG will just have to manage
this.
 
best regards,
John 

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: "Sidebottom, Greg [BCNR:7M01:EXCH]" <[email-masked]>
Date: Wed, 21 Mar 2001 02:58:38 -0500

Hi Ming, John,

I'm not a big fan of looking in the TCAP at an SG SUA either but I think
that we probably don't want to say that the SG CANNOT do one
routing/loadsharing thing or another.  I'd prefer to leave it implementation
dependent like in the M3UA as I have seen customer applications for SG TRID
routing/loadsharing. 

However, when it comes to REG/DEREG definition in the SUA (if this is to be
added), then I wouldn't support TCAP based Routing Keys there.  All the
Routing Key permutations that we may end up supporting in an SUA REG/DEREG
protocol will be a subset of the implementation possibilities at an SG.

Cheers,

   Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Saturday, March 17, 2001 12:58 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: some proposals for UA

Hi Ming,

best regards,
John

---

---

From: [email-masked]
Date: Thu, 22 Mar 2001 14:40:12 +0200

Hi Greg,
 
I'm not a big fan of looking in the TCAP at an SG SUA either but I think
that we probably don't want to say that the SG CANNOT do one
routing/loadsharing thing or another.  I'd prefer to leave it implementation
dependent like in the M3UA as I have seen customer applications for SG TRID
routing/loadsharing. 
[<JAL> ] I wouldn't want to dig through a TCAP message in an SG either.  I
think that routing/loadsharing on TRID may not be real issue, but rather a
distributed SCP (for example) be goal.  In order to achieve this, we want to
enable that ongoing TCAP transactions be handled by the same ASP, for
example.  Therefore, I'd suggest we don't specifically highlight
routing/loadsharing on TRID values, but we don't prohib it either.

[<JAL> ] Agreed.

John 

---

---

From: [email-masked]
Date: Wed, 28 Mar 2001 12:44:11 +0300

Hi all,

Gery tried to send this to the list, but seems to be having
trouble ...

> From: ext Verwimp Gery [mailto:[email-masked]] 
> Sent: March 28, 2001 12:38
> To: [email-masked]'
> When one goes into the details of loadsharing based on TCAP TID (and
> actually, it's on DID as Lin Ming pointed out, which means 
> the SG has to
> know the "internal" layout of the normally opaque TID), one 
> ends up with
> some kind of "SUA allocation function". Analogous to how SCCP 
> allocation
> works within a lot of systems, I presume, but this time we 
> need to show
> what's inside and come up with a standard procedure to make 
> interworking
> possible.
> 
> The same is true for ISUP CIC codes ... so I fear we cannot leave this
> implementation dependent ... at least we have to specify, 
> along with the
> definition of a routing key, what should be provisionable ... 
> but I might be
> shooting in my own foot here ...
> 
> As a brain teaser, has anyone thought of what happens if ASPs 
> go in and out
> of service ? Right, the TID allocation policy has to extend 
> to any ASP in
> the AS, whatever it's state. And a few other things regarding 
> ASP management
> :
> 
> - when all TIDs ranges are allocated, no additional ASP can 
> be added to the
> AS otherwise conflicts will arise.
> 
> - when an ASP goes inactive, all stable TCAP transactions 
> with this ASP are
> lost. All the SG can do is send (X)UDTS'es back with 
> "unrecognized TID" on
> further incoming messages. But I guess that's acceptable.
> 
> I'll try to come up with a fairly simple but general 
> solution, something
> along the lines of :
> 
> - using a mask to identify relevant bits in the TID
> 
> - each ASP gets a single, non-interrupted range of DIDs (no added
> functionality if we use several non-adjacent ranges is there 
> ?) to process.
> 
> The above info should be provisionable on a AS (routing key) basis.
> 
> Any thoughts ?
> 
> P.S. I wouldn't be worried about the ASN.1 decoding : the TIDs are on
> well-defined positions in the TCAP message header (regardless of
> application) and we are not interested in the rest of the 
> message. So no
> TCAP functionality as per Q.771-774 needs to be present in the SG.
> 
> ____________________________
> 
> Gery Verwimp
> > SIEMENS ATEA
> > ICN D CS D5
> > 
> > Tel. : +32 14 25 3424
> Fax : +32 14 25 3212
> mailto:[email-masked]
> ____________________________________
> 
> 
> Sent: donderdag 22 maart 2001 13:40
> You are currently subscribed to sigtran as: 
> [email-masked]
> To unsubscribe send a blank email to
> [email-masked]
> 

---

---

From: "Benjamin J. Wilson" <[email-masked]>
Date: Wed, 28 Mar 2001 13:14:47 -0500

Gery,

If I understand this correctly, I agree.  Are you saying that it might
be easier
to avoid loadsharing altogether and break the AS/routing key into
logical parts
which support override mode?

i.e RK ( DPC = 1.1.1, TID 1-100, Loadsharing 2 + 1 ) might be better off
being
    configured as RK1 ( DPC = 1.1.1, TID 1 - 49, Override ) and
    RK2 ( DPC = 1.1.1, TID 50-100, Override ).

Cheers,

Ben

---

---

From: Ming Lin <[email-masked]>
Date: Wed, 28 Mar 2001 16:40:50 +0800

Hi all,
Please see comments below....
-----Original Message-----
发件人: [email-masked] <[email-masked]>
收件人: [email-masked]
<[email-masked]>
日期: 2001年3月22日 20:41
主题: RE: some proposals for UA

>distributed SCP (for example) be goal.

I think there is no other way to achieve distributed IP SCP/HLR/SMSC
other than routing/loadsharing on DID or TID.
And distributing traffic is one of the most important advantages of sigtran,
if one UA can not distribut traffic, this UA lose the most important
useness.

>In order to achieve this, we want to

If SUA want to route/loadshare on TRID, it has to look into TCAP message.
SUA will perform ASN.1 decoding, which is most part of TCAP.
So I think we need another UA, i.e. TUA(TCAP User Adapter Layer).

>You are currently subscribed to sigtran as: [email-masked]

---

---

From: Ming Lin <[email-masked]>
Date: Mon, 30 Apr 2001 16:57:39 +0800

Hi all,

If SUA wants to route/loadshare by TID(Transaction ID),
OTID(Origin TID) and DTID(Destination TID)
should be considered carefully.

SUA should look at the message type of TCAP message,
and decides whether DTID is there.
If DTID is there, routing/loadsharing should be done
by DTID; if not, like BEGIN message,
routing/loadsharing should be done by OTID;
and if there is not DTID and OTID, what should SUA do?

The routing key of DTID and OTID shoud be configed
or registered together.

I still think TUA is needed, so we can implement
TCAP in SG, and route/loadshare traffic by DID(dialog ID).
Is there someone interesting in TUA?

Thanks&Regards
Ming Lin

-----Original Message-----
发件人: Benjamin J. Wilson <[email-masked]>
收件人: [email-masked]
<[email-masked]>
日期: 2001年3月29日 2:21
主题: Re: FW: some proposals for UA

---