Subject: RE: [AAA-WG]: Extension over base api as a separate process

From: [email-masked]
Date: Wed, 28 Mar 2001 11:57:50 -0600

Hi,

Per the concerned draft
(http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-01.txt), Each
DIAMETER implementation is at least one extension (since base protocol is
never used by itself, but must be extended for use of some kind). Also,
since DIAMETER is a peer to peer protocol (ref. section 1 of the same
draft), both the client portion (that initiates authentication and/or
authorization requests) and the server portion (that proxies or performs the
requested authentication and/or authorization) have to be implemented as the
base protocol.

The above implication is further consolidated by the DIAMETER API draft's
AAAOpen specification
(http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-01.txt, section
4.4.1.1), that after calling AAAOpen, a process is ready to accept requests
on a specific port.

Also, since the DIAMETER API draft defines command callbacks as local
callbacks (objects in Java, functions in C), it is necessary that all
extensions deployed on a host have to be part of the same process. A few
different scenarios to achieve some kind of distributed processing are
outlined below:

	1. Within a single address space, the callbacks and/or separate
threads related to the extensions handle communication with corresponding
"agent" processes (e.g. a QoS agent does a lot of other stuff, using
DIAMETER protocol for AA being a small part of its overall functionality).

	   The down-side of this approach is that addition of new extensions
is static and tedious (requires modification of existing source base); it is
possible to achieve dynamic addition of extensions using demand loading of
shared library objects (or Java classes), but still it is a lot of burden on
agent processes implementations to incorporate IPC of some kind to the
DIAMETER server process. 

	2. Each extension is a process by itself; but then all of them can
not accept requests on the same specific port: thus, this alternative is not
really an option

	3. The implementation itself involves multiple processes, each
linked with the base API; one of the processes performs part of DIAMETER
server function (proxying within the host only), while the others perform
the other server function (performing authentication and/or authorization
per requests routed by the aforementioned proxying server process) and other
client functions.

	   Clearly, this involves a lot of complication on routing requests
(by the proxying server process) by means of IPC, sharing dictionary and
other data, presenting one DIAMETER peer image to other peers, etc.

Comments?

Regards,
Sreenivas

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Tuesday,March 27,2001 14:22
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [AAA-WG]: Extension over base api as a separate process

Hello,

Does anybody have tried to implement extension(s) over base API. I have a
question, whether AAA Base protocol implementation and extension(s) have to
be in a single process or they can be separate processes.

We are planning to implement extensions that will be separate processes from
AAA Diameter base implementation. And we would like to have some guidelines
from API specification.

Yogesh Solanki

---

From: "Ruslan R. Laishev" <[email-masked]>
Date: Wed, 28 Mar 2001 22:13:12 +0400

Hello !

> 4.4.1.1), that after calling AAAOpen, a process is ready to accept requests
	It's expected that this API will universal for all platform?
	Is there a hope to get AST-driven API ? Or it will be a traditional unix-style coded
blocking calls?

-- 
Cheers, Ruslan.
+---------------pure personal opinion-----------------------+
    RADIUS Server for OpenVMS project - www.radiusvms.com
      [email-masked] - Forum for ISP running OpenVMS
		Mobile: +7 (901) 971-3222