Subject: RE: ??: some proposals for UA

From: [email-masked]
Date: Fri, 16 Mar 2001 16:57:29 +0200

Hi Greg,
 
The SUA description is a bit lacking as some of the parameters in M3UA (like
Traffic Mode Type in an ASPAC) have been removed but the procedures are
still there allowing ASP loadsharing within an SSN, perhaps based on TCAP
TRID  (At least I hope isn't ruled out as I intended this from the
beginning!).   An AS can be defined with a Routing Key = SSN1.  Then two
ASPs could be defined within the AS and loadsharing effected.  How the
loadsharing is done within the AS is implementation dependent.  I also don't
see why you couldn't define an AS with a Routing Key based on TCAP TRID
ranges within an SSN but there may be some who disagree.
[<JAL> ] Exactly - some additional explanation is needed & is in the works.

Also, from SUA Section 1.5.1: 

"There exist many proprietary schemes for managing SS7 Address Translation
to IP addresses, and is considered outside of the scope of this document to
specify how this is done."

The SUA probably needs to be expanded to show some more examples.   The M3UA
is not restricted to using only MTP3 parameters in a Routing Key for message
distribution at the SG, or for distributing the traffic to multiple ASPs in
an AS.    So I don't think we can restrict the SUA to only use SCCP elements
(e.g., SSN). 

[<JAL> ]  Agreed

John,  
Why was Traffic Mode Type removed from ASPAC? The procedures depend on it -
did I miss something? 

It was due to a bad cut 'n paste job - it is in version v5.

John

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

---

From: [email-masked]
Date: Fri, 16 Mar 2001 16:57:33 +0200

Hi Ming,

Sorry for the much delayed response.  I have been traveling quite a bit &
the mail piles up.

> 1)TCAP is bound with SCCP and is a transparent layer to SSN.
> 2)SUA only can distribute traffic by SSN,
> because it is the only one identifier of SCCP.
> So, within special SSN, SUA only can support ASP fail-over,
> but ASP loadsharing within special SSN is very useful
> to huge capacity of IP SCP/HLR/SMC.

I understand your point.  Originally, SUA was envisioned to support
loadsharing via TID as an option.  I still think that it is a viable option,
but perhaps some statements need to be added to that affect.

Right now, routing key support isn't detailed in the draft, but I think that
routing key support should be addressed shortly.  

If you have certain requirements and/or text that you'd like to see in the
draft, please let me know.

br,
John

---

---

From: Ming Lin <[email-masked]>
Date: Sat, 17 Mar 2001 09:04:32 +0800

Hi John,

First I correct one error in my early mail,
TUA can distribute traffic by DID not TID.

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?

Please correct me?

Thanks&Regards
Ming Lin
-----Original Message-----

>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: Fri, 16 Mar 2001 21:55:52 -0600

Ming,

> And ASN.1 decoder is most part of TCAP, then why not implement TCAP in SG?

Excellent idea!  TCAP is basically ROSE anyways (an OSI RPC).
Then just use CORBA or something between SG and transaction
database.

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

---