[Nsi-wg] time issue

[Inder Monga]

John, Thanks for giving me the opportunity to try and clarify

On Sep 27, 2010, at 5:41 PM, John Vollbrecht wrote:

> 
> On Sep 27, 2010, at 6:13 PM, Inder Monga wrote:
> 
>> John and Jerry and all,
>> 
>> We had a lot of discussion on this earlier this year before we took the connection services out of the architecture specification and when discussing the error recovery. This is what I remember being discussed then - just want to make sure it is aligned with the current conclusions and please point out where the differences are:
>> 
>> 1. The NSA-Requestor always asks for "Available Time"
> for automated request it asks for available time
> for user initiated it asks for resource time, or asks for available and gets resource time back so it can request at appropriate time

I think we should keep the user view consistent. The User ALWAYS asks for Available time. If it is user initiated, then the network does not need to add a "guard" time. The time user requested is then "available" for the user to provision based on their request. Provisioning time is automatically included.

>> 
>> 2. The NSA-Provider may choose to add their own configurable "guard" time to "Available time" make it the "Resource time". This will be different and specific to the network operator providing the services. The resource time helps them maintain a reservation calendar of when resources are available and deals with the resource overlaps, pre-emptions and all the good stuff.
> this is true for automated request.  it may be true for user initiated request depending on whether that is what is requested

I am suggesting we have it one way only for both. Maybe diagrams will help.

>> 
>> 3. The set of providers in the NSA service chain may have their own "guard" times - there is no need to align it, come up with a predictable value etc. It depends on the kind of the network that provider has built. There is no requirement to be close or far from the start time requested. 
> I am not sure what this means.  I assume there is some need to be at least close to requested available time.

Of course, as best practices, it should be close to requested available time. But we do not want to discuss about it in the NSI protocol specification other than state that each network needs to attach a network-specific guard time to the Available time in order to make sure that the resource is available for provisioning ahead of the user-requested time. This will prevent double-booking of resources.

>> 
>> 4. Each of those NSA providers may have an "Auto-provision" or "Signaled provision" configuration. "Auto-provision" means that the provisioning start signal to the statemachine is given by NSA-provider based on some timer. "signaled provision" means that the NSA-requestor may provision the start of connection setup (this allows for connections to be instantiated at time < total reservation time). 
> signaled provision is what I have been calling user initiated

Thanks.

>> 
>> 5. The original NSA-requestor waits for the signal from the NSA-provider telling it the connection is up. If the connection is not up before the "Available Start Time" requested - the SLA takes over. Either the NSA-requestor can then cancel the connection, or query the connection or Notify the NSA-provider that it is waiting for it. The NSA-provider can independently choose to Notify the NSA-requestor that provisioning is in progress even though the start time has elapsed.
> perhaps.  I don't think we agreed to anything like this, though the idea of SLA kicking in seems reasonable.  How this happens might be included in the service instance description.

Yes when we discuss SLA negotiation as part of the protocol. It may be part of the service agreement discussed out of band between the providers. Ensuring a consistent SLA across multiple networks is not going to be an easy problem to enforce or reason about within the scope of NSI v1.0. 

>> 
>> 6. If there is an error in the connection setup, that is notified up the service chain to the requestor.
> Up the service chain is something I am not clear about.

What I mean by "service chain" is a set of NSI-Requestors, NSI-Providers associated in setting up a single connection. This relates to sub-segmentation of the connection service among multiple NSAs/domains.


> 
> John
> 
>> 
>> 
>> Hope this helps - happy to answer any clarification questions.
>> 
>> Inder
>> 
>> On Sep 27, 2010, at 2:51 PM, John Vollbrecht wrote:
>> 
>>> Hello all -
>>> 
>>> Jerry and I had a discussion last week about the time issue.  I think we developed a useful approach.
>>> 
>>> The idea is to define two times, which I think we all agree exist.
>>> 
>>> 1) available time - time a connection is available to the application to communicate between devices
>>> 2) resource time - time a resource is reserved to support available time
>>> 
>>> To further define these -
>>> 
>>> Available time 
>>> - requested by the user for its application
>>> - provided by the network.  
>>> 
>>> resource time 
>>> - time a resource is allocated to a connection
>>> - includes setup and teardown time, if any
>>> - is time in reservation calendar for resource
>>> 
>>> Available time requested cannot be provided exactly by network because it cannot predict exactly length of setup and take down.  I believe we all agree with this.  
>>> Therefore provided available time can at best approximate requested available time.
>>> 
>>> We agreed that when a user requests automatic start connection it would request available time and the provider would schedule resource time to get as close as possible.
>>> When a request is for user initiated connection the time would be for reserved time, and the user initiation can start anytime after the reserved time.  Available time depends on setup and take down times of equipment.
>>> 
>>> -----------------
>>> I think we agreed on the above definitions.  The definition of time seem useful in discussing what goes in connection service messages.  We also talked about some possible implications of this.
>>> 
>>> The difference between available and resource time is setup and takedown time.  While it is impossible to be sure exactly how long they will be, it may be possible to define something statistical.  For example setup takes an average of 17 sec with std deviation of N.  If this is can be defined for the resource, then one can make a prediction about when a connection will be available with a degree of confidence.  
>>> 
>>> For example this would allow one to request an automatic connection, for example, at 5pm and have it available 99% of the time.  If the average setup time is 17 seconds and I add 10 seconds to be 99% sure, then the service would initiate the connection at 5:00:00 - 0:00:25, or 4:59:35.
>>> 
>>> We talked about including this "setup requirement" in the connection service definition of and NSA, and by implication including this in requests and replies.  I think this is worth talking about in the group.
>>> 
>>> John
>>> 
>>> _______________________________________________
>>> nsi-wg mailing list
>>> nsi-wg at ogf.org
>>> http://www.ogf.org/mailman/listinfo/nsi-wg
>> 
>> ---
>> Inder Monga	     ANI Testbed
>> imonga at es.net        ESnet Blog
>> (510) 499 8065 (c)   (510) 486 6531 (o)
>> "Whatever your mind can conceive and believe it can achieve."  - Napoleon Hill
>> 
>> 		
>> 
> 

---
Inder Monga	     ANI Testbed
imonga at es.net        ESnet Blog
(510) 499 8065 (c)   (510) 486 6531 (o)
"Whatever your mind can conceive and believe it can achieve."  - Napoleon Hill

		

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20100927/5822ba0a/attachment-0001.html