Subject: RE: [Dime] The Auditing Problem : Ownership of resources

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 5 Feb 2007 11:56:27 -0500

Hi Ulf,

With that type of model, how are they going to deal with rogue endpoints,
for example if a SIP UA advertises certain voice codec in SDP but actually
pumps much larger amounts of traffic? This would impact traffic for other
endpoints as well.

I think one would need a per flow reservation mechanism, where the standard
5-tuple and corresponding QoS characteristics are fed to the entity which
actually receives the IP packets. My understanding of RACS Functional
Architecture specified in ETSI ES 282 003 was also in that direction. With
that mode of operation, IP packet processor (RCEF in ETSI terminology) would
have knowledge about all existing bandwith QoS reservations.

    Thanks,
    Tolga

> -----Original Message-----
> From: Ulf Bodin [mailto:[email-masked]]
> Sent: Thursday, January 25, 2007 3:41 AM
> To: [email-masked]
> Subject: RE: [Dime] The Auditing Problem : Ownership of resources
>
>
> Hi Tolga,
>
> I absolutely agree to that your scenario as of below is valid and I also
> agree that the physical device can be expected to correctly
> approve/disapprove new reservation requests after a failover of a
> Diameter server controlling the device.
>
> The model defined by ETSI TISPAN differs from the above scenario in the
> sence that the Diameter server bing the so called A-RACF is a booking
> system for resources. It keeps knowledge of aggregate resources in the
> underlying transport network (e.g. bandwidth allocated to the DiffServ
> EF PHB on network interfaces) and may install policies for traffic
> conditioning in transport devices dedicated to that task (e.g. a BRAS).
> This means that reservations of resources are not knowned by network
> devices (i.e. except policies for traffic conditioning) and consequently
> the Diameter server cannot rely on states kept in network devices to
> correctly answer reservation reqiuests (before and after a failover).
>
> Best regards,
> Ulf
>
>
> -----Original Message-----
> From: Tolga Asveren [mailto:[email-masked]]
> Sent: den 24 januari 2007 23:07
> To: [email-masked]
> Subject: [Dime] The Auditing Problem : Ownership of resources
>
> Hi Ulf,
>
> I wanted to dig in a bit more into the ownership of resources concept,
> which came up during the last couple of e-mails we exchanged for
> auditing problem.
> This again is probably a relatively side-issue but still it could be
> good to clarify it.
>
> I see the following elements in this problem:
> a) User to physical address mapping
> I guess, in the context of this problem we assume this is already done
> and this mapping data can be accessed by other entities.
>
> b) Delivery of user resource reservation request This will happen with a
> Diameter request from Diameter client to Diameter server.
>
> c) Policy enforcement
> Diameter server enforces policy based on user identity and the policy
> applicable for the user.
>
> d) Reserving/Providing the physical resource The Diameter server queries
> the physical mapping for the user and requests reservation of the
> resources from the physical device providing the resource (e.g. a
> router). Depending on the answer received from the device providing the
> resource, Diameter server generates the answer to the Diameter client.
>
> In this model, physical device would always have the information of all
> reservations for which it is providing the resources. Even after a
> Diameter server restart/backup takeover, physical device can
> approve/disapprove new reservation requests based on that information,
> i.e. the check to make sure that resources are not overbooked can be
> done on the physical resource provider (Diameter server still would
> perform policy enforcement)
>
> It could be the case that c) and d) is performed in the same entity. In
> such a case failure of that entity would cause the resources to be
> unavailable and after a restart all of the resources would be available.
>
> I am not claiming this is the only way of reserving the resources, nor
> the best way. I just wanted to clarify the model I had in mind regarding
> ownership/reservation of resources.
>
>     Thanks,
>     Tolga
>
>
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dime
>
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dime

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

---

From: "Ulf Bodin" <[email-masked]>
Date: Wed, 7 Feb 2007 08:30:22 +0100

Hi Tolga, 

Yes, endpoints that cannot be trusted certainly need to be controlled in
some way (e.g. through traffic conditioning). Basically the A-RACF has
potentially two sources of information for retreving reservation states
being lost; a) network devices performing per-flow traffic conditioning
and b) the application functions that originally requested the resource
reservations (e.g. SIP proxies). As I see it, which one of a) and b)
that is best suited to deliver the desired information depends on the
actual scenario in question. Reasons for why a) is less suitable than b)
include that; 
1) the endpoints are trusted and there are therefore no traffic
conditioning implemented in the network, 
2) traffic conditioning is performed on a per-aggregate basis (e.g. for
performance and/or scalability reasons), 
3) the failover between A-RACF entities is accompanied by a network
failover resulting in states being lost also in the network devices
performing traffic conditioning (i.e. the A-RACF may even need to
rebuild states in the network), and
4) network devices are not aware of all the properties of the
reservation states in the A-RACF (e.g. admission priorities and/or
virtual resource partitioning affecting the admission control process
but not the traffic conditioning). 

Best regards, 
Ulf 

-----Original Message-----
From: Tolga Asveren [mailto:[email-masked]] 
Sent: den 5 februari 2007 17:56
To: [email-masked]
Subject: RE: [Dime] The Auditing Problem : Ownership of resources

Hi Ulf,

With that type of model, how are they going to deal with rogue
endpoints, for example if a SIP UA advertises certain voice codec in SDP
but actually pumps much larger amounts of traffic? This would impact
traffic for other endpoints as well.

I think one would need a per flow reservation mechanism, where the
standard 5-tuple and corresponding QoS characteristics are fed to the
entity which actually receives the IP packets. My understanding of RACS
Functional Architecture specified in ETSI ES 282 003 was also in that
direction. With that mode of operation, IP packet processor (RCEF in
ETSI terminology) would have knowledge about all existing bandwith QoS
reservations.

    Thanks,
    Tolga

> I absolutely agree to that your scenario as of below is valid and I 
> also agree that the physical device can be expected to correctly 
> The model defined by ETSI TISPAN differs from the above scenario in 
> the sence that the Diameter server bing the so called A-RACF is a 
> booking system for resources. It keeps knowledge of aggregate 
> resources in the underlying transport network (e.g. bandwidth 
> allocated to the DiffServ EF PHB on network interfaces) and may 
> install policies for traffic conditioning in transport devices
dedicated to that task (e.g. a BRAS).
> devices (i.e. except policies for traffic conditioning) and 
> consequently the Diameter server cannot rely on states kept in network

> devices to correctly answer reservation reqiuests (before and after a
failover).

> b) Delivery of user resource reservation request This will happen with

> a Diameter request from Diameter client to Diameter server.
>
> c) Policy enforcement
> d) Reserving/Providing the physical resource The Diameter server 
> queries the physical mapping for the user and requests reservation of 
> the resources from the physical device providing the resource (e.g. a 
> router). Depending on the answer received from the device providing 
> the resource, Diameter server generates the answer to the Diameter
client.
>
> In this model, physical device would always have the information of 
> all reservations for which it is providing the resources. Even after a

> It could be the case that c) and d) is performed in the same entity. 
> In such a case failure of that entity would cause the resources to be 

> the best way. I just wanted to clarify the model I had in mind 
> regarding ownership/reservation of resources.
>
>     Thanks,
>     Tolga
>
>