Subject: [AAA-WG]: Issue #5: Boot Id

From: Pat Calhoun <[email-masked]>
Date: Tue, 15 May 2001 07:21:42 -0700

This particular issue has to be with how the access device can inform the
home server that a reboot has occured. There were several proposals, and
instead of attempting to paraphrase, I will simply include Paul's e-mail.

PatC
----
(from http://www.merit.edu/mail.archives/aaa-wg/2001-05/msg00135.html)

Allow me to recast the summary. But first, a description of the 
architectural framework:

Multiple NASes are clients of an aggregating server. Some sessions 
are local and use resources on the aggregating server. Other sessions 
are proxied by the aggregating server to other home servers, and use 
resources on those home servers.

1       Paul's proposal

In Paul's proposal, a DRI would include a Boot-Id AVP, which could be a 
monotonically increasing number (increases upon each reboot). When an 
aggregating server receives a DRI from a NAS with a higher Boot-Id than 
before, the aggregating server can then release all resources for 
that NAS's local sessions. It MAY, if it so chooses, clean up all 
sessions globally, by issuing STRs on behalf of that NAS for all 
sessions that were proxied, each directed to the appropriate home 
server.
 
2. Pat's proposal.

In Pat's proposal, each auth (and acct) message would include a Boot-Id AVP.
So the next time that a message was sent to the home Diameter Server, the
server could determine whether the NAS has rebooted since the last time
it received a message from it.

3. Mark's proposal

Mark's proposal (I'm taking liberties here) is the same as Paul's proposal, 
except that there would be a new command, say Client-Reboot-Request or 
Client-Reboot-Indication, that would contain the FQDN and Boot-Id of the 
restarted NAS. The aggregating server MAY issue this command to each home 
server for which there is at least one open session. Thus, only a single 
message per home server, rather than a message for each session, would have 
to be issued in order to clean up state globally.

The first thing to note is that these proposals are not mutually 
exclusive.

I think we should at least adopt Paul's proposal, since it allows an 
aggregating server to clean up local state efficiently, and provides at 
the least the option for the aggregating server to clean up state globally 
via STR or Mark's new command. It is a requirement of Mark's proposal 
anyway, and it is a sufficiently minor addition to Pat's proposal (just a 
single AVP in DRI) that it would make sense to avail ourselves of it in 
any case.

Mark's proposal of a new command would reduce traffic over the use of 
individual STRs in Paul's proposal. However, the reduction may not be 
dramatic. The number of non-local sessions may be a fraction of the total 
number of sessions, and if the non-local are widely distributed, the 
tradeoff of STRs against his more powerful command may not be compelling. 
Plus, it requires that a new command be supported.

Both Paul's and Mark's proposals required that the aggregating server keep 
session state for non-local sessions in order to clean them up. Pat's 
proposal, as he notes, has the advantage that non-local sessions can get 
cleaned up even if the aggregating server does not keep their state, in 
fact, even if the aggregating server itself goes down. However, it is 
non-deterministic, and depends on the accident of the NAS starting a 
session on the same home server after it is rebooted.

So my feeling is that we should at least adopt my humble proposal, and 
possibly all three. That's the strongest opinion I can muster.