Hi Guy- I think the question is a bit different: The resources have been successfully reserved for the appropriate window. But the user requested Auto-Start and an In-Service Start Time at a specific time. The NSA reserved the resources for some Estimated Provisioning Time in advance of the requested start time. But when provisioning began, the estimated provisioning time was insufficient and provisioning did not complete before the requested start time. What should be done? My discussions with Inder suggested that this is indeed an error, but an error does not necessarily mean we shut down and Cancel the connection or the reservation. Inder suggests (and I believe this is sensible) an error condition should generate a Notify message toward the user to inform them of the error. But beyond that Notify msg, we should not assume the the connection is no longer useable or desired. The user can Cancel the request if missing the start time is/was unacceptable. Or the user could absorb and ignore the error and just keep going. Or some other action could be performed. But automatically tearing down the connection should not be the automatic reaction. Hope this helps Jerry Guy Roberts wrote:
John,
Right, I think that the provider should reserve the resources from the start-provisioning time to the end-releasing time. This is a longer period than the start and end times which relate to the in-service state. If all the required resources are not available from start-provisioning to end-releasing , then the provider should reject the connection request.
Guy
*From:* John MacAuley [mailto:john.macauley@surfnet.nl] *Sent:* 21 April 2010 14:25 *To:* nsi-wg@ogf.org *Subject:* Re: [Nsi-wg] advanced reservation
One quick question - if a provider cannot achieve the desired start time do to guard band overrun I assume we reject it?
On 10-04-21 5:51 AM, Guy Roberts wrote:
Hello all,
Following on from last week's conference call and discussions, Tomohiro, Inder, Jerry, Chin and Vangelis and I have come up with a new proposal for advanced reservation in v1.0. This is essentially a refinement on the existing proposal in the architecture document.
Some text describing this proposal is included in the attached document.
In essence this includes:
1PC
All request require a pass/fail response from the Provider NSA
Advanced reservation are supported with start time, end time, duration
Times exchanged on the protocol reflect targets for the in-service time.
It is the responsibility of the provider to achieve the start and end times. This is done using guard bands unique to each provider NSA and are validated as constraints in path finding.
Immediate reservation is supported with start time = asap
Provisioning may be signalled by the requestor or local initiated by the provider
I would like to see if we can get consensus on this proposal in today's call.
Regards,
Guy
------------------------------------------------------------------------------------------------------------------
Guy Roberts, Ph.D
Network Engineering & Planning
DANTE - www.dante.net <http://www.dante.net/>
Tel: +44 (0)1223 371 316
City House, 126-130 Hills Road
Cambridge, CB2 1PQ, UK
------------------------------------------------------------------------------------------------------------------
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org <mailto:nsi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/nsi-wg
------------------------------------------------------------------------
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg