Subject: FW: Where are we on "Dynamic Traffic ?"

From: Jacques Rajchgod <[email-masked]>
Date: Mon, 03 Dec 2001 13:02:08 -0600

We will be testing Interop shortly. Seems to me like there is no formal
position on the matter of Dynamic Traffic (aka "bandwidth-on-demand") other
than the one proposed by Brian on November 15/2K1, whereby we would group
ASP/AS Client-Servers into "Work Groups" where each group would be expected
to work ("behave") per the "Group characteristics"...

I suspect that designing a N/W based on Client-Server "traffic work groups"
will be a difficult task. One will have to accurately anticipate which
Client-Server session will be working when-and-how. I can also see customer
moneys being invested in vendor equipment that will be seldom (never?) used:
Suppose there are three Client-Server sessions in an "Override work Group".
The first session is permanently config'ed to override the "pipe". That
means that the two other sessions in that "Override work group" will never
be asked to work - under normal conditions (i.e: No Fail-Over)...So, if this
is the expected case, why would a customer want to acquire equipment (the
two other logical sessions) that will never be asked to work - under normal
conditions? and Standby is no longer a formal mode anayway - M3UA-09 has
taken it out...So I am not sure where we stand on these Traffic matters.

We need to head-on early toward Dynamic Traffic (Bandwidth-On-Demand) at
some point (like soon....like next...), to make efficient use of equipment
and sound money investments...All modern N/W's do "Bandwidth-on-Demand", so
Client-Server MGC-SG technology would be right into current times.
Also, doing "Bandwidth-on-Demand" would do away with the proposed
Client-Server work groups (and save big moneys to customers), as there would
be no need anymore for "LoadShare groups", "Override Groups"...Any session
needing bandwidth would be served "FIFO"-like...

Beyond that, potential customers need be told that this is the way the
industry will be initially working -> statically (No-Dynamic-Traffic), so
there is no surprise at production time...but I suspect that no customer is
aware of that yet and therefore do anticipate surprises at production
times...

Is the "extension paper" Brian mentioned, on its way shortly?

 Thanks, my appreciation.

Jacques Rajchgod
MCI Worldcom
Next Generation System Evaluation
Tel: [972] 729-7180
E-mail: [email-masked]

-----Original Message-----
From: Verwimp Gery [mailto:[email-masked]]
Sent: Friday, November 16, 2001 2:44 AM
To: sigtran
Subject: RE: Can Traffic Mode be Dynamic?

Hi,

What we need instead of dynamic changes in the TMT, is some congestion/flow
control in the ASPTM messages. ASPs could e.g. refuse to receive new calls
etc.

Also, the TMT itself could be more refined, because sending notifications
and awaiting active/active_ack doesn't cut it if one wants an immediately
available backup that however doesn't get any traffic for the RC under
normal circumstances.

Loadshare mode could be defined as n+k (n ASPs actively loadsharing in
normal conditions, k backups ready to get traffic without further notice),
override mode reduces to 1+k loadshare mode.

Within a loadsharing group, broadcast groups could be defined. All these
groups are defined at configuration/registration time; an ASP cannot alter
this dynamically via ASPTM ... we actually would change the RC then.

Comments ?

____________________________

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

Nov 15/2K1 - From Brian

TMT is optional everywhere.  SG and ASP can always be statically
configured for whatever other traffic distribution patterns their
implementors care to imagine.  I know that doesn't speak much to
interoperability, but where close coupling is required...

Your problem is illustrative of the fact that one might need to
group ASPs.  I have the beginnings of an extension draft which
provides for a load-selector which would describe an ASPs placement
in a load-group.  TMT would be applicable between load groups and
load-selection within a load-group.  This would allow you to pool
ASPs into a load-group yet distribute traffic between groups.
Load-selection within a load-group could be on the basis of fixed
load-selection within the group, loadsharing within the group, or
broadcast within the group.  This would allow for the equivalent
of striping *and* mirroring.  (Now we have only striping *or*
mirroring.)

It is a fairly easy thing to do in extension draft.  All that it
adds is an optional load-selector parameter to RKMM/ASPTM messages
for the ASP to indicate its position within the group (and possibly
the SGP to indicate its position back).

Interested?

--brian

-----Original Message-----
From: Mark Davidson [mailto:[email-masked]]
Sent: donderdag 15 november 2001 22:22
To: sigtran
Subject: Re: Can Traffic Mode be Dynamic?

My understanding of override mode is that it is used for handling
connections to
active/standby
equipment (e.g. MGC) and allows the active portion of the equipment to
direct
traffic towards itself.
In the case of a failover (active MGC fails) the standby becomes active and
sends ASPACT(OVERRIDE).

The M3UA draft does not allow changing between override and standby traffic
modes, since it requires an
error message when a mode different from the currently configured one is
received:

   from 4.3.4.4 ...
   If the SGP determines that the mode indicated in an ASP Active
   message is unsupported or incompatible with the mode currently
   configured for the AS, the SGP responds with an Error message
   ("Unsupported / Invalid Traffic Handling Mode").

Thus you cannot dynamically change between traffic modes.

As for default mode, the draft states

   If the traffic handling mode of the Application Server is not already
known
   via
   configuration data, then the traffic handling mode indicated in the
   first ASP Active message causing the transition of the Application
   Server state to AS-ACTIVE MAY be used to set the mode.

It doesn't give any means for dynamically changing the mode.

One of our concerns is when there is too much traffic for a single ASP to
handle, but
we want to use an active/standby configuration.  I.e., need override mode,
but
need to switch
between sets of ASPs rather than single ASPs. Suggestions?

-Mark Davidson
[email-masked]

----------------------------------------
Jacques Rajchgod <[email-masked]> on 11/15/2001 11:34:47 AM

Please respond to [email-masked]

To:   "sigtran" <[email-masked]>
cc:    (bcc: Mark Davidson/Raleigh/TEKELEC)
Subject:  Can Traffic Mode be Dynamic?

 A question has arisen during our test cycle of M3UA, that probably applies
to all "UA's":

Traffic mode assignment is done at ACT time. The mode is specified as a
param attached to the ACT message:
ASPACT(LdShr). Please, kindly advise:

My impression is, that traffic mode defaults at init time to "LdShr". This
allows all ASPs to traffic as needed.Then:
When an ASP determines that a sudden pressure exists at its bearers (the
MGW), it ACTs with an OVERRIDE request to monopolize all traffic resources
thereafter, until pressure at its bearers has subsided. Then, once the
pressure has subsided, the OVERRIDING ASP is supposed to revert to normal
traffic mode so as to allow other ASPs to traffic...

How would an ASP request "bandwidth" dynamically - would it perform as
follows?

1) ACTs as LdShr at Init time.
2) Detects pressure at bearers, then generates ASPIA to get out of LdShr.
3) Generates ACT(Override) to re-enter traffic as lone trafficker to handle
its sudden pressure.
4) Everybody is out except the overrider.
5) Pressure has subsided.The Overrider detects that traffic no longer
requires a lot of "bandwidth".
6) It generates ASPIA to get out of OVERRIDE so to allow other ASPs to begin
trafficking.
7) It generates ACT(LdShr) to get out of OVERRIDE.

Is this how an ASP would do it? Or would an ASP sends ACT's(Traffic_mode=x)
w/o "logging-out"?
Is this the way "Bandwidth-on-demand" would work at an ASP?

Thanks,

Jacques Rajchgod
MCI Worldcom
Next Generation System Evaluation
Tel: [972] 729-7180
E-mail: [email-masked]

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

---

From: Greg Sidebottom <[email-masked]>
Date: Wed, 5 Dec 2001 15:02:51 -0500

Greetings Jacques,

I have no problem with an extension draft from Brian in Sigtran but I wonder
if the work of the Rserpool Working Group should be considered for this
issue.  I haven't been following rserpool for a while but it seems to have a
mandate that covers your concerns (from
http://www.ietf.org/html.charters/rserpool-charter.html ) :

         " The WG will address client access mechanisms for server pools,
specifically:

            1) An access mechanism that allows geographically dispersed
servers in the pool

            2) A client-server binding mechanism that allows dynamic
assignment of client to servers
                based on load balancing or application specific assignment
policies.

            3) Support of automatic reconfiguration of the client/server
binding in case of server
                failure or administrative changes. "

I'd previously thought that the output of this group would eventually
replace the rudimentary ASPM and Registration component of M3UA quite
cleanly (i.e., it would be quite easy for M3UA to hook into a Server Pool
Name).  In any case, any Sigtran extension draft should at least consider
some of the issues already discussed in rserpool.  Lyndon is Co-Chair of
Rserpool so maybe he can give us a quick update on how the work is going
there.

Not sure if this is the answer for "Bandwidth on Demand" but it sounds like
a start.

Cheers,

    Greg

----- Original Message -----
From: "Jacques Rajchgod" <[email-masked]>
To: "sigtran" <[email-masked]>
Sent: Monday, December 03, 2001 2:02 PM
Subject: FW: Where are we on "Dynamic Traffic ?"

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

---

---

From: "Ong, Lyndon" <[email-masked]>
Date: Wed, 5 Dec 2001 16:36:17 -0800

Hi Folks,

As Greg mentions, the Rserpool group is looking at the 
general problem of contacting members of a server pool,
tracking member status and joining/leaving the pool.

Rserpool will be meeting in Salt Lake City if anyone is
interested.  Currently the group has a document on requirements
that is "tentatively approved" by IESG (draft-ietf-rserpool-reqts-03.txt)
and has two protocol documents currently under study
(draft-ietf-rserpool-asap-01.txt and draft-ietf-rserpool-enrp-01.txt).
There's an architecture document and a comparisons document but
those are pretty fluid at the moment.

The group has spent most of the last period looking at Service
Location Protocol to see if that could be borrowed/stolen but
it currently looks like there's too much excess baggage that
would come along with it...

Cheers,

L. Ong

-----Original Message-----
From: Greg Sidebottom [mailto:[email-masked]]
Sent: Wednesday, December 05, 2001 12:03 PM
To: sigtran
Subject: Re: Where are we on "Dynamic Traffic ?"

Greetings Jacques,

Cheers,

    Greg

----- Original Message -----
From: "Jacques Rajchgod" <[email-masked]>
To: "sigtran" <[email-masked]>
Sent: Monday, December 03, 2001 2:02 PM
Subject: FW: Where are we on "Dynamic Traffic ?"

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

---