Subject: nasreq Resource Management Requirement

From: "[email-masked]" <[email-masked]>
Date: Mon, 3 Apr 2000 19:39:22 -0700 (PDT)

All,

I remember sending a comment to -02 of criteria draft while it was in last
call, and I do remember sending some comments in regards to Resource
Management. Although I could dig them up from the archive, I will simply
re-state them.

Back in 1996, when I started some research in the area of Resource Management,
we did an implementation, and did some trials. The client code was in a NAS,
while the server code was in the Merit Server (actually, I believe that the
code is still in the server source, if you care to see).

Although Resource Management CAN be made to work in an intra-domain case, it
really doesn't scale AT ALL in an inter-domain case. Short of creating a
protocol that would propagate queries to ALL of the NASes in the Internet, we
needed to create a solution that maintained state in each proxy. This became
increasingly unscalable the larger the network(s) grew.

Let's take an example. A server dies and restarts. It needs to retrieve state
from its peers. If all of the proxies maintain state, this would be a single
AAA hop away. If the NASes were responsible for this, then we would need the
reboot message to be propagated throughout the Internet to all NASes (at least
to all NASes within a Roaming Consortium).

Quite simple to see how hard this problem really is, isn't it?

So, here are some things that some of us have come up with over the years. It
isn't perfect, but it sure as hell is simpler:

1. Each authentication/authorization has a session lifetime. This requires
that the NAS re-authenticate/authorize the user after a specified timeout
(controlled by the Home AAA Server). This ensures that over time, state will
be rebuilt. This *could* lead to a situation where a user does get two
sessions, for a time...

2. A Authorization/Authentication disconnect message. This can be initiated by
the NAS to inform the server that the session is no longer active. This
information, similar to accounting info, can be kept in static memory,
ensuring that it can be retrieved after a reboot. When a NAS comes up, for all
accounting sessions that it had still pending, one of these messages would be
generated. This eliminates the tie to the Accounting Sub-system, and makes the
protocol much cleaner (and still works with batched accounting).

The above provides *some* reasonable resource management. Perhaps not as good
as a Internet-wide distributed database, but it is possible.

I would like the WG to REALLY think about the Resource Management requirement.
Further, if you all *still* think that it is necessary, PLEASE define exactly
what you need Resource Management to do. The current text is very vague, and
does not match the definition of the requirement in the AAA reqs draft. If we
decide to delete it, then we need to tell the AAA folks.

Thanks,

PatC

---

From: "David Mitton" <[email-masked]>
Date: Thu, 27 Apr 2000 10:59:24 -0400

Pat,

         Fair enough.  The Nasreq Criteria has a single vague 
sentence.  The AAA NA Requirements had much more text.

I feel this requirement should be addressed. Your concerns are valid, but I 
don't want to design it out here.

How about this? (replaces Nasreq Criteria section 8.3.1.2)

         - Dave.

.NH 4
.R
Resource Management
.LP

Resource Management MUST be supported on demand by the NAS or AAA Server at 
any time during the course of a user session.  This would be the ability 
for the NAS to allocate and deallocate shared resources from a AAA server 
servicing multiple NASes.  These resources may include, but are not limited 
to; IP addresses, concurrent usage limits, port usage limits, and tunnel 
limits. This capability should have error detection and synchronization 
features that will recover state after network and system failures. This 
may be accomplished by session information timeouts and explicit interim 
status and disconnect messages.   There should not be any dependencies on 
the Accounting message stream, as per current practices.

.LP
This feature is primarily intended for NAS-local network resources. In a 
proxy or multi-domain environment, resource information should only be 
retained by the server doing the allocation, and perhaps it's backups. 
Authorization resources in remote domains should use the dynamic 
authorization features to change and revoke authorization status.

-----

>decide to delete it, then we need to tell the AAA folks.

---------------------------------------------------------------
David Mitton                                  ESN: 248-4570
Advisor, Nortel Networks                      978-288-4570 Direct
Carrier Packet Solutions, Preside             978-288-3030 FAX
Billerica, MA 01821                    [email-masked]