Hi Jerry,
This will bound the problem - the network will deliver within one minute of the scheduled start time, or declare a fault condition and fall on its sword. We can discuss if this is adequate for V1.0. And what the recovery action should be: release the connection and notify the user? notify the user and continue provisioning? ...?
I think a related, just as important question is, do you extend the termination time? For an application which has to transfer N TBs of data, starting 20 minutes late might be useless if the requested reservation time is shortened by that... I admit a videoconferencing app will prefer to wait. From the protocol point of view, terminating would be the cleanest thing to do. With the right configuration of provisioning times in each domain, a timeout of a minute, say, would indicate a deeper problem, so waiting might be pointless. However, an alternative would be to keep the user (agent/application) in wait state until provisioning successful or termination time - whatever comes first. The user app can then abort if it thinks it's beyond repair, and try to reschedule. But this implies that there is always a status (change) notification to the user agent. Then we can get rid of the timeout, actually. (Note that's not contradicting my earlier statements - the goal remains to provision at the requested time.) Cheers, Artur -- Dr Artur Barczyk California Institute of Technology c/o CERN, 1211 Geneve 23, Switzerland Tel: +41 22 7675801