Subject: [Dime] Diameter auditing - PART 1

From: "Ulf Bodin" <[email-masked]>
Date: Fri, 8 Jun 2007 17:58:11 +0200

All, 

I've been looking in whether the original work on Diameter resource
management extensions now captured in
http://www.ietf.org/internet-drafts/draft-bodin-dime-auditing-reqs-02.tx
t [RM-ext] would meet the demands identified in
http://www.ietf.org/internet-drafts/draft-asveren-dime-state-recovery-01
.txt [SR] on Diameter state recovery considerations. Comments on this
analyze are very wellcome. 

Going through section 5.2.1 and 5.2.2 (PART 1) of [SR] and matching
against [RM-ext] I noted the following (remaing sections/PARTs in
following mail): 

1) Having a standby node informing remote peers of the failure of an
active instance (i.e. 5.2.1 in [SR]) is not covered by [RM-ext], not in
any other spec (as far as I know). I'm not sure what kind of message
would be appropriate for this purpose (i.e. a new mesage or an existing
one such as CER). Any views on this? 

2) Synchronizing state (i.e. 5.2.2, first paragraph in [SR]) is not
natively supported by [RM-ext], but could be suppored with a small
change/addition I beleive. E.g. through a flag in the SRQ saying whether
all session information is requested for all active sessions (all
information on all sessions is requested when no Session-Id is provided
in the SRQ), or just the session-Id of all active sesisons (i.e. an SRR
without any Resource-bag AVPs). 

3) Reconstructing session state using application messages (i.e. 5.2.2,
Using Application Messages in [SR]) is generally not supported by
Diameter nor in [RM-ext]. As I understand the protocol a AAR updating an
existing session is identified by that the Session-Id is known by the
server (i.e. is active), while an AAR establishing a new session
provides a new Session-Id not currently being used for any active
session. Hence, a flag indicating that the message is for an existing
sesison (or a separate message) would be needed to facilitate state
reconstruction using mid-session messages. 

4) Reconstructing session state using generic messages (i.e. 5.2.2,
Using a Generic Message in [SR]) is indeed supported by [RM-ext] (i.e.
through SRQ and SRR in which state information for several sessions can
be requested and provided respectively). 

Best regards, 
Ulf 

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
Date: Sun, 17 Jun 2007 13:02:04 +0200

Hi Ulf,
 
Some comments below.
 
BR,
 
Lionel

________________________________

	De : Ulf Bodin [mailto:[email-masked]] 
	Envoyé : vendredi 8 juin 2007 17:58
	À : [email-masked]
	Objet : [Dime] Diameter auditing - PART 1 

	All, 

	I've been looking in whether the original work on Diameter resource management extensions now captured in http://www.ietf.org/internet-drafts/draft-bodin-dime-auditing-reqs-02.txt <http://www.ietf.org/internet-drafts/draft-bodin-dime-auditing-reqs-02.txt>  [RM-ext] would meet the demands identified in http://www.ietf.org/internet-drafts/draft-asveren-dime-state-recovery-01.txt <http://www.ietf.org/internet-drafts/draft-asveren-dime-state-recovery-01.txt>  [SR] on Diameter state recovery considerations. Comments on this analyze are very wellcome. 

	Going through section 5.2.1 and 5.2.2 (PART 1) of [SR] and matching against [RM-ext] I noted the following (remaing sections/PARTs in following mail): 

	1) Having a standby node informing remote peers of the failure of an active instance (i.e. 5.2.1 in [SR]) is not covered by [RM-ext], not in any other spec (as far as I know). I'm not sure what kind of message would be appropriate for this purpose (i.e. a new mesage or an existing one such as CER). Any views on this? 
	[Lionel Morand] CER/CEA are used to initiate a transport connection between diameter peers. In this specific case, we may assume that the Standby node may actually also indicate the active instance failure by sending a CER to the remote peers. The transport connection establishment would be a hint for the remote peers to detect that the Standby node is now active and that therefore the previous active node is down. The only problem is that CER/CAA messages can not be proxied, redirected or relayed i.e. it would be not possible to use this mechanism if a proxy/redirect/relay agent is present in the Diameter path between remote peers and Stanby/active node. This can not be therefore defined as a generic mechanism. 

	2) Synchronizing state (i.e. 5.2.2, first paragraph in [SR]) is not natively supported by [RM-ext], but could be suppored with a small change/addition I beleive. E.g. through a flag in the SRQ saying whether all session information is requested for all active sessions (all information on all sessions is requested when no Session-Id is provided in the SRQ), or just the session-Id of all active sesisons (i.e. an SRR without any Resource-bag AVPs). 
	[Lionel Morand] if needed, I think that this could be easily fulfilled with an optional AVP in SQR e.g. "State Synchronization AVP" of Enumarated type, that would clearly indicate the granularity of requested information about active sessions.

	3) Reconstructing session state using application messages (i.e. 5.2.2, Using Application Messages in [SR]) is generally not supported by Diameter nor in [RM-ext]. As I understand the protocol a AAR updating an existing session is identified by that the Session-Id is known by the server (i.e. is active), while an AAR establishing a new session provides a new Session-Id not currently being used for any active session. Hence, a flag indicating that the message is for an existing sesison (or a separate message) would be needed to facilitate state reconstruction using mid-session messages.  

	4) Reconstructing session state using generic messages (i.e. 5.2.2, Using a Generic Message in [SR]) is indeed supported by [RM-ext] (i.e. through SRQ and SRR in which state information for several sessions can be requested and provided respectively). 

	Best regards,
	Ulf

---

From: "Ulf Bodin" <[email-masked]>
Date: Wed, 20 Jun 2007 15:29:03 +0200

Hi Lionel, 
 
Pls find replies below [Ulf1]. 
 
Best regards, 
Ulf 

From: MORAND Lionel RD-CORE-ISS
[mailto:[email-masked]] 
Sent: den 17 juni 2007 13:02
To: Ulf Bodin; [email-masked]
Subject: RE: [Dime] Diameter auditing - PART 1 

Hi Ulf,
 
Some comments below.
 
BR,
 
Lionel

	All, 

	I've been looking in whether the original work on Diameter
resource management extensions now captured in
http://www.ietf.org/internet-drafts/draft-bodin-dime-auditing-reqs-02.tx
t
<http://www.ietf.org/internet-drafts/draft-bodin-dime-auditing-reqs-02.t
xt>  [RM-ext] would meet the demands identified in
http://www.ietf.org/internet-drafts/draft-asveren-dime-state-recovery-01
.txt
<http://www.ietf.org/internet-drafts/draft-asveren-dime-state-recovery-0
1.txt>  [SR] on Diameter state recovery considerations. Comments on this
analyze are very wellcome. 

	Going through section 5.2.1 and 5.2.2 (PART 1) of [SR] and
matching against [RM-ext] I noted the following (remaing sections/PARTs
in following mail): 

	1) Having a standby node informing remote peers of the failure
of an active instance (i.e. 5.2.1 in [SR]) is not covered by [RM-ext],
not in any other spec (as far as I know). I'm not sure what kind of
message would be appropriate for this purpose (i.e. a new mesage or an
existing one such as CER). Any views on this? 
	[Lionel Morand] CER/CEA are used to initiate a transport
connection between diameter peers. In this specific case, we may assume
that the Standby node may actually also indicate the active instance
failure by sending a CER to the remote peers. The transport connection
establishment would be a hint for the remote peers to detect that the
Standby node is now active and that therefore the previous active node
is down. The only problem is that CER/CAA messages can not be proxied,
redirected or relayed i.e. it would be not possible to use this
mechanism if a proxy/redirect/relay agent is present in the Diameter
path between remote peers and Stanby/active node. This can not be
therefore defined as a generic mechanism.  

	[Ulf1] You're right of course. Informing remote peers of the
failure of an active instance would henece require a new message I
guess. that is, a message the be sent immediately after the CER/CAA
message exchange directly following the detection of that an Active
instance has become permanetly inavailable. 

	2) Synchronizing state (i.e. 5.2.2, first paragraph in [SR]) is
not natively supported by [RM-ext], but could be suppored with a small
change/addition I beleive. E.g. through a flag in the SRQ saying whether
all session information is requested for all active sessions (all
information on all sessions is requested when no Session-Id is provided
in the SRQ), or just the session-Id of all active sesisons (i.e. an SRR
without any Resource-bag AVPs). 
	[Lionel Morand] if needed, I think that this could be easily
fulfilled with an optional AVP in SQR e.g. "State Synchronization AVP"
of Enumarated type, that would clearly indicate the granularity of
requested information about active sessions. 

	[Ulf1] Yes. I agree. I forsee a potential value in having a set
of predefined values for different granularities. For example, (a) all
information on all active sessions, (b) session ids only for all active
sessions, (c) all information or session ids only for all sessions
that'll time out with x seconds, (d) all information or session ids only
for all sessions with application property x (related to one or more
application specific AVPs), etc. While I see a clear need for
differentiating between (a) and (b), I think (c) and (d) type of values
would be interesting to discuss to found out whether that can be useful
or just makes the solution more complex.  

	3) Reconstructing session state using application messages (i.e.
5.2.2, Using Application Messages in [SR]) is generally not supported by
Diameter nor in [RM-ext]. As I understand the protocol a AAR updating an
existing session is identified by that the Session-Id is known by the
server (i.e. is active), while an AAR establishing a new session
provides a new Session-Id not currently being used for any active
session. Hence, a flag indicating that the message is for an existing
sesison (or a separate message) would be needed to facilitate state
reconstruction using mid-session messages.  

	4) Reconstructing session state using generic messages (i.e.
5.2.2, Using a Generic Message in [SR]) is indeed supported by [RM-ext]
(i.e. through SRQ and SRR in which state information for several
sessions can be requested and provided respectively). 

	Best regards,
	Ulf