Subject: Re: [AAA-WG]: [issue] Boot-Id

From: David Spence <[email-masked]>
Date: Wed, 06 Jun 2001 05:23:35 +0200

Please note the editorial change offered below.

Paul Funk wrote:
> 
> Submitter name: Paul Funk
> Submitter email address: [email-masked]
> Date first submitted: May, 20001
> Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-05/msg00135.html
> Document: Base
> Comment Type: Technical
> Priority: 1 or 2 (?)
> Section: Somewhere in section 6
> Rationale/Explanation of issue:
> Servers need to know if a NAS has rebooted, to be able to
> clean up state. A new connection is not necessarily and
> indication of reboot, since it could be a reconnect after a
> connection was broken.
> 
> Requested change:
> 
> The interim group felt that, of the three proposals in the foot-fetish
> thread, Paul's and Pat's should be adopted. Briefly, a Boot-Id is passed
> in DRI to allow a server to determine when a peer has rebooted, and
> Boot-Id is also passed in other messages, to allow downstream
> servers more than one hop away to glean this information.
> 
> Randy suggested that the name of the AVP be changed from Boot-Id to
> State-Id, since a server may retain state across reboots. Therefore,
> a new id is really indicative of fresh state. I suggest we in fact
> call it Origin-State-Id, to emphasize its relationship to Origin-FQDN.
> 
> Origin-State-Id will have to be added to the ABNF for DRI as well as all
> other messages, as an optional AVP.
> 
> Suggested language:
> 
> [add the following somewhere in the DRI section:]
> 
> Origin-State-Id AVP
> 
> The Origin-State-Id AVP (AVP Code ?), of type Unsigned32, is a
> monotonically increasing value that is advanced whenever a Diameter
> entity restarts with loss of previous state, for example upon reboot.
> Origin-State-Id MAY be included in any Diameter message, including
> DRI.
> 
> A Diameter entity issuing this AVP MUST create a higher value for
> this AVP each time its state is reset. A Diameter entity MAY set
> Origin-State-Id to the time of startup, or it MAY use an incrementing
> counter retained in non-volatile memory across restarts.
> 
> The Origin-State-Id, if present, MUST reflect the state of the
> entity indicated by Origin-FQDN. If a proxy modifies Origin-FQDN,
> it MUST either remove Origin-State-Id or modify it appropriately as
> well.
> 
> Typically, Origin-State-Id is used by an access device that always
> starts up with no active sessions; that is, any session active prior
> to restart will have been been lost. By including Origin-State-Id in
> a message, it allows other Diameter entities to infer that sessions
> associated with a lower Origin-State-Id are no longer active. If an
> access device does not intend for such inferences to be made, it
> MUST either not include Origin-FQDN in any message, or set its value
                          ^^^^^^^^^^^
==========>               Origin-State-Id

> to 0.
> 
> [add the following to the Session Termination section:]
> 
> 10.10 Inferring Session Termination from Origin-State-Id
> 
> Origin-State-Id is used to allow rapid detection of terminated
> sessions for which no STR would have been issued, due to unanticipated
> shutdown of an access device.
> 
> By including Origin-State-Id in DRI messages, an access device allows
> a next-hop server to determine immediately upon connection whether the
> device has lost its sessions since the last connection.
> 
> By including Origin-State-Id in request messages, an access device
> also allows a server with which it communicates via proxy to make
> such a determination. However, a server that is not directly connected
> with the access device will not discover that the access device has
> been restarted unless and until it receives a new request from the
> access device. Thus, use of this mechanism across proxies is
> opportunistic rather than reliable, but useful nonetheless.
> 
> When a Diameter server receives a Origin-State-Id that is greater
> than the Origin-State-Id previously received from the same issuer,
> it may assume that the issuer has lost state since the previous
> message and that all sessions that were active under the lower
> Origin-State-Id have been terminated. The Diameter server MAY clean
> up all session state associated with such lost sessions, and MAY also
> issues STRs for all such lost sessions that were authorized on
> downstream servers, to allow session state to be cleaned up globally.
> 
> Paul
> 
> Paul Funk
> Funk Software, Inc.
> 617 497-6339
> [email-masked]

-- 
David Spence                            email: [email-masked]
Interlink Networks, Inc.                phone: (734) 821-1203
775 Technology Drive, Suite 200         fax:   (734) 821-1235
Ann Arbor, MI 48108           
U.S.A.

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 6 Jun 2001 06:55:37 -0700

> Please note the editorial change offered below.

I had already fixed this in -05 :)

PatC