Subject: Re: [Dime] Update on Diameter Auditing

From: Tina TSOU <[email-masked]>
Date: Tue, 07 Aug 2007 19:44:11 +0800

Just in case the link was missing, I provide the link explicitly again 
adding below.

----- Original Message ----- 
From: "Tina TSOU" <[email-masked]>
To: <[email-masked]>; "Ulf Bodin" <[email-masked]>
Sent: Tuesday, August 07, 2007 7:39 PM
Subject: Re: [Dime] Update on Diameter Auditing

> Hi,
> In ITU-T, it is free with your TIES account now. Cisco is the sector 
> member of ITU-T, so Glen can apply a TIES account.
> Architecture:
>      Y.2111
>     Resource and admission control functions in Next Generation Networks
http://www.itu.int/rec/T-REC-Y.2111-200609-I/en

>      Procedure and Protocol:
>      Q.3301.1
>     Resource control protocol - Protocol at the Rs interface   (with 
> simple audit inside, to check whether the session indicated by the 
> Session-Id in the RAR message is active, not including the state recovery)
http://www.itu.int/rec/T-REC-Q.3301.1/en
http://www.itu.int/rec/T-REC-Q.3301.1-200703-P/en
>
>      Q.3302.1
>     Resource control protocol - Protocol at the Rp interface
http://www.itu.int/rec/T-REC-Q.3302.1/en
http://www.itu.int/rec/T-REC-Q.3302.1-200703-P/en
>
>
>
> In ETSI, it is also free with your ETSI account. Cisco is the member of 
> ETSI, so Glen can apply a ETSI account.
> Architecture:
> http://pda.etsi.org/pda/home.asp?wki_id=m5ClL_vIFdCECIEF7HHwR
>
> B. R.
> Tina
>
> ----- Original Message ----- 
> From: "Ulf Bodin" <[email-masked]>
> To: <[email-masked]>
> Sent: Tuesday, August 07, 2007 7:16 PM
> Subject: RE: [Dime] Update on Diameter Auditing
>
>
> -----Original Message-----
> From: Glen Zorn (gwz) [mailto:[email-masked]]
> Sent: den 6 augusti 2007 18:54
> To: Ulf Bodin
> Cc: [email-masked]
> Subject: RE: [Dime] Update on Diameter Auditing
>
> Ulf Bodin <mailto:[email-masked]> allegedly scribbled on Monday,
> August 06, 2007 5:05 AM:
>
> ...
>
>>
>> [Ulf1: Although the intention of draft-bodin-dime-auditing-reqs-02 is
>> to capture needs for auditing in a wider sense the usage that
>> triggered us writing the draft is the ETSI TISPAN RACS/ITU-T RACF,
>
> Where can I get a copy of the document defining this entity?
>
> [Ulf2: Unfortunately access to specifications published by ETSI and ITU
> requires membership or purchase of each particular publication. The
> documents can most likely be shared using a liason statement issued by
> ETSI and/or ITU in case we need those specifciations for reference (in
> particular for them working for an organization not being member of
> those SDOs). However, the MSF (Multi-Service Forum) has published a
> document giving an overview of this kind of entity that I believe could
> be sufficient
> (http://www.msforum.org/techinfo/reports/MSF-TR-ARCH-005-FINAL.pdf).]
>
>> which is an entity keeping track of resource reservations for IP-based
>
>> networks. The states kept in such entity is mot necessarily present in
>
>> any network device. At failover from active to standby NVRAM does not
>> help. I.e. non-volatile local storage does not help when failing over
>> between physically separted entities.
>> draft-asveren-dime-state-recovery-01 explores the problem of state
>> recovery further and may do a better job in actually defining
>> requirements for state recovery/auditing.]
>
> I'd actually prefer to see a document saying why this is actually needed
> in a real network, rather than one that assumes its necessity as a
> starting point.  BTW, it was the lack of that clear necessity that led
> to the demise of the original resource management work, IIRC.
>
> [Ulf2: Yes, that's my understanding as well for why the work was demised
> a couple of years back. However, given the appearance of RACS/RACF in
> ETSI TISPAN/ITU-T and the widespread usage of Diameter in 3GPP/3GPP2/MSF
> etc. I think this shows that that mechanisms for state recovery is
> actually needed for products now being developed for usage in real
> networks.
>
> And, in TISPAN, H.248 was back in 2005 actually considered as an
> alternative to Diameter to be used for one of the interfaces to RACS
> partly due to its auditing capabilities that also can be used for state
> recovery (H.248 is used in the published architecture, but for a
> different interface).]
>
>
>
>
>
> ...
>
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dime 

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