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

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 24 Jan 2007 17:07:10 -0500

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

---

From: "Ulf Bodin" <[email-masked]>
Date: Thu, 25 Jan 2007 09:40:55 +0100

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

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