I will agree with Jeff on this. Generally I would say that there are several styles of time-related parameters that the client can provide to the NSI. Let's say desired start time is T, duration is D, bandwidth is B. And let me have a new parameter X represents a hard "expiration date" of the request i.e. the time by which provisioning MUST have happened otherwise the reservation should be failed. I assume that each NSI agent would know at least roughly how long it takes it to provision its own network, so if it receives a request that arrives too close to time X to provision, it will reject it. Here are a couple of use cases: - Video conference at a known time: would have an X very close to T - Bulk data transfer: could have a large difference between X and T. (we could also express the duration - bandwidth parameters as their product with floor & ceiling constraints for B and D.. but I digress) - Immediately-or-fail reservation: would have an X very close to now() - As-soon-as-possible reservation: would have an X that is somewhat in the future The main idea I think should be that we let the user expressly define user-related constraints, and not hard-wire them in the protocol. Not that we shouldn't provide reasonable default values, of course.. On Apr 13, 2010, at 9:11 AM, Jeff W.Boote wrote:
I'd like to encourage everyone to consider this more from the client perspective instead of from the provisioning perspective... The reason to make a circuit reservation is not in isolation. The client is doing this because they want to make some kind of data transfer that certainly involves other resources that also need to be scheduled.
In that context, I think the required semantics become more clear. Give the two-phase commit cycle that is happening anyway, I would expect something like:
1) Reservation request is for a given time T, and duration D. The semantics of this request from the client perspective should be, I would like to use the circuit at time T. (After all, the client is trying to reserve other resources to use the circuit at that same time.)
2) The provider determines how 'close' to time T they can actually provision the circuit (after requesting down-stream if chaining). The response should be: you can have reservation time T+delta. (Where delta MUST be as small as the provider can make it.) If T=='now' that would likely produce a greater 'delta' than a T in the more distant future.
When developing the actual protocol, it may also be necessary to also return another time indicating how quickly the client must initiate the second phase of the commit or the reservation automatically nullifies...