Subject: [AAA-WG]: Recap of our foot fetish thread

From: Pat Calhoun <[email-masked]>
Date: Tue, 8 May 2001 17:35:05 -0700

All,

Here is an attempt to recap the recent Boot-Id thread.

Problem:

How does a Home Diameter server know when a particular NAS has rebooted? This
is actually quite important if the home server maintains session state.

The problem is actually not as bad as it seems, though. Unlike RADIUS, 
Diameter sessions have a limited lifetime, set by the home Diameter server.
When a re-auth isn't received by the time a session expires, the home
server can clean up resources.

However, a more pro-active approach is being discussed in the mailing list.

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 a proxy
server receives a DRI, the DRI is "proxied" to all home servers that the
proxy is in communication with. Of course, a DRI is "probably" the wrong
message to send, but something needs to be sent.

Home Servers receiving this could then lookup which one of their users
were serviced by the particular NAS, and clean up session state.

The only drawback that I have here is that the first hop proxy needs to
maintain some state as to which home's it has communicated with in the past.
If the proxy was to reboot, then all bets are off.

2. Pat's proposal.

In my 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.

This seems to have the least amount of protocol impact, but it does only
work when a message is sent to the home server. In cases where traffic
is light for a particular home server, sessions would have to be cleaned up
via soft state.

In this proposal, if the proxy reboots, it is irrelevant.

Both of the above protocols are MAYs, since sending how flaky one's network
is apparently not a good idea :)

As Barney warns, this doesn't fix the NAS caught fire problem. Of course, one
would hope that technology has advanced in the past few years, and products
that do catch fire are rather rare, but it could still occur. In these 
cases, the home Diameter server would have to clean up via soft state.

Have I missed any other proposals?  

Thanks,

PatC

---

From: Paul Funk <[email-masked]>
Date: Wed, 09 May 2001 01:30:24 -0400

Pat,

Summarizing is a good idea. But yes, you have missed a proposal. What 
you characterized as my proposal is actually a combination of mine 
and Mark Jones'.

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.

Paul

>Have I missed any other proposals?  

Paul Funk
Funk Software, Inc.
617 497-6339
[email-masked]

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 9 May 2001 06:51:23 -0700

> you characterized as my proposal is actually a combination of mine 

[snio]

I guess now is probably the right time to ask whether this is a bug fix,
or a new feature. The WG agreed in Minn that no new "features" would be
added after the last meeting, but only fixes.

So, which one is this, bug or feature?

PatC

---

From: Paul Funk <[email-masked]>
Date: Wed, 09 May 2001 18:48:57 -0400

Pat,

Bug, bug, bug, bug ...

Not handling this situation means a capability available in RADIUS will 
not be available in Diameter. 

If there's a concern about adding stuff at this point, we should go with 
my simple fix. Just add a Boot-ID to DRI. The aggregating server can 
do something with it or not, just as in RADIUS.

Paul

Paul Funk
Funk Software, Inc.
617 497-6339
[email-masked]

---

From: "Mark Jones" <[email-masked]>
Date: Wed, 9 May 2001 22:51:01 -0400

Thanks for the summary, Paul.

> session state for non-local sessions in order to clean them up.

My proposal does not require the aggregating server keep session state in
order to clean up the non-local sessions. It could use the less elegant
but equally effective method of sending the Proxied-DRI to next hop
servers regardless of whether the rebooted NAS was hosting their sessions.

However, your colleague Ammo did bring up a valid point in that
post-reboot session requests may arrive at a home server before the
Proxied-DRI and so get cleaned up in error. I considered requiring the
aggregating server to wait until the Proxied-DRI had been acknowledged by
the home server(s) before sending its own DRI back to the NAS but the
delay would be unacceptable for long proxy chains. I also rejected the
solutions using timestamps since they require tight time synchronization
between the aggregating server and home server(s). Admittedly this same
issue exists in RADIUS today with Acct-On/Off but I don't want to
propagate it to Diameter.

I am not overly enthusiastic about a mechanism which requires that the
aggregating server keep session state for non-local sessions in order to
clean them up. Keeping accurate session state despite failover is
non-trivial so we need to be careful about introducing mechanisms which
mandate it. We may end up requiring a routing proxy server to keep session
state purely for the sake of handling reboot events.

My objection to Pat's proposal was it required the addition of a new
Boot-Id AVP in every session request but it appears reliable and is simple
to implement. Would it be possible to include the boot identifier in the
Session-Id AVP format? This would also ensure that the Session-Id AVP is
globally unique over time rather than relying on the random value assigned
to the 'monotonically increasing 32-bit value' on reboot. The Session-Id
AVP format remains a SHOULD so those manufacturing devices that reboot
frequently can avoid using it ;)

Regards,
       Mark

---

From: "Mark Jones" <[email-masked]>
Date: Wed, 9 May 2001 22:51:03 -0400

Pat,

> So, which one is this, bug or feature?

I think it is a bug that the DRI is missing an AVP which indicates the
reason for the capabilities exchange (with device reboot being one of the
reasons). I think we should address this bug even if the WG does not reach
consensus on the foot fetish proposals.

Regards,
       Mark

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 10 May 2001 07:12:45 -0700

On Wed, May 09, 2001 at 10:51:01PM -0400, Mark Jones wrote:
> mandate it. 

agreed.

> frequently can avoid using it ;)

I'd prefer to NOT include the Boot-Id in the Session-Id. When my implementation
receives a packet, it must perform a lookup based on the Session-id, and
making that string longer than it currently is will only hurt performance.

I'd rather have the Boot-Id as a separate, and well defined, AVP

Thanks,

PatC