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 ------------------------------------------------------------------------------------------------------------------
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 http://www.ogf.org/mailman/listinfo/nsi-wg
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
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
Hey John - we touched on this in the call today, but I willr espond here as well... If the provisioning overuns the estimated GB and does not complete until after the requested In Service start time, then this should throw an error...but it does *NOT* automatically mean the request or the conenction should be rejected and torn down. IMO, if the user doesn't want it anymore, they should send a Cancel msg down the tree. IF its ok despite the overrun, they can ignore the Error. Its not clear to me if the conenction should remain in an errored state after notification. Or if the user must reply to the notification somehow. This is something maybe Inder can elaborate on in his error doc. Jerry John MacAuley wrote:
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 http://www.ogf.org/mailman/listinfo/nsi-wg
------------------------------------------------------------------------
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Hi Guy, So, to support that, what about the followings? We will have "reserve" operation only. (advance and immediate are not separate operations.) Reserve operation will include the following parameters. EXPLICIT_SIGNALING(boolean): a flag to indicate signaling message will be used. If this flag is "false", automatic provisioning will be used. STRICT_START_TIME(boolean): a flag to indicate whether start time later than specified is allowed. If "true", if provider NSAs can not provision resources at the specified START_TIME, they deny the request. If "false", provider NSAs will provision resources ASAP (after the START_TIME), if they cannot provision resources on time. START_TIME(value): Value zero can be used in combination with "false" STRICT_START_TIME. In this case, ASAP provisioning is requested. END_TIME(value) or DURATION(value): If END_TIME is used, the provisioning terminates at this time. If DURATION is used, the provisioning termination time is calculated by adding this time to the actual provisioning time. BTW, I think it is not "advanced reservation" but "advance reservation". Tomohiro On Wed, 21 Apr 2010 10:51:15 +0100 Guy Roberts <Guy.Roberts@dante.net> 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 ------------------------------------------------------------------------------------------------------------------
Hi all, Here is the timing diagrams. Tomohiro On Wed, 21 Apr 2010 10:51:15 +0100 Guy Roberts <Guy.Roberts@dante.net> 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 ------------------------------------------------------------------------------------------------------------------
participants (4)
-
Guy Roberts -
Jerry Sobieski -
John MacAuley -
Tomohiro Kudoh