Subject: FW: RE some proposals for UA

From: Coene Lode <[email-masked]>
Date: Mon, 2 Apr 2001 15:06:18 +0200

It seems that I have become a e-mail router
(Or the "united federation of computers and networks" has put Gery on the
Blacklist also) 

-----Original Message-----
From: Verwimp Gery 
Sent: maandag 2 april 2001 15:01
To: Coene Lode
Subject: FW: FW: some proposals for UA

Lode, kunt gij deze mail ne keer op de sigtran lijst gooien ? Dat ding
weigert gewoon om nog mails van mij door te sturen (en opnieuw registreren
heeft enkel het effect dat ik sommige mails nu dubbel krijg !!)

____________________________
-----Original Message-----
From: Verwimp Gery 
Sent: maandag 2 april 2001 13:46
To: [email-masked]'
Cc: 'Ming Lin'; 'Benjamin J. Wilson'
Subject: RE: FW: some proposals for UA

Hello Ming, Ben,

I had something in mind like this :

- loadsharing is not avoided, but only applied to TC_Begin/TC_Query. Yes,
the TCAP message type must be considered, but as M3UA can look at the CIC
value without implementing ISUP, SCCP can also look at the TC message type
and DTID without implementing TCAP. A round robin mechanism (or whatever)
would do just fine, mechanisms based on other parameters (OTID) always carry
the risk of having a load-imbalance. But I guess this is perfectly
implementation dependent.

- other TC messages are to be relayed to the same ASP which received the
TC_Begin/Query, and this is based on DTID, taking into account the policy of
TID assignment by the ASPs. So this is actually "loadsharing after the
fact". The real loadsharing thus occurs with the Begin or Query only !

- we need to make a distinction between RK parameters (which just determine
the AS for this traffic partition, and are more or less "static" parameters
e.g. OPC, SI, SSN) and parameters to select the right ASP for correlated
messages in a call-sequence or transaction. These will tend to be
dynamically assigned parameters (TID, Call-ID ?) which DO NOT determine the
routing key, but are necessary for loadsharing-after-the-fact; it all
amounts to avoiding state in the SG.

- you don't really need to implement TCAP at the SG, furthermore, you'll
have an addressing problem (you also need to implement the TCAP
applications, because TCAP cannot exist on its own); and you'll have to use
something like TC_Transfer, which isn't a standard TCAP function ...

Best regards,

____________________________

Gery Verwimp
> SIEMENS ATEA
> ICN D CS D5
> Tel. : +32 14 25 3424
Fax : +32 14 25 3212
mailto:[email-masked]
____________________________________

-----Original Message-----
From: Ming Lin [mailto:[email-masked]]
Sent: maandag 30 april 2001 10:58
To: [email-masked]
Subject: Re: FW: some proposals for UA

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

>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
>
>[email-masked] wrote:
>>
>> > 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 ?
>> >
>
>
>---
>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]

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