[Nsi-wg] time issue

[John Vollbrecht]

I would suggest that there are at least several  issues that need to be resolved here.  I try to define the issues and what my solution to each of them would be - at least right now.

--


One is how to manage time across multiple NSAs - this is a problem when there are two NSAs, and more of a problem when there may be multiple NSAs involved in making a connection.

1) time syncrhonization 
Jeff has suggested that we require NSAs to run NTP to synchronize time between NSAs.  The only down side I see of this is that it requires each NSA to run NTP.  If we agree on this approach, then we might want to investigate if only provider NSAs need to run NTP, assuming a non provider will talk to a provider -  this might make it easier for applications to be NSAs.

The up side is that a request for starting and ending time is understood the same way by all NSAs.  This means that a request that goes to multiple lNSAs in an authorization sequence will all see the same time and understand it the same way.

*I vote for requiring NTP and working out the details - especially the potential difference in scheduling between segments because of possible skew in NTP time across NSAs.

2) Relationship between available and scheduled time
2a) available time definition
I think we agree that start and end time (or duration) in a request will be for available time.  Available time is time when the connection is actually available to carry traffic.  This is the time that is sync'd using NTP.  Note that available time is always an estimate because startup duration is variable.

2b) resource or scheduled time
This is the time a resource is scheduled for by its own NRM.  It calculates this time by inserting startup time for resources it controls before the requested start time, and inserts tear down time after the requested end time.  This time is different for every NRM and may be different for different equipment within an NRM - that is an NRM implementation.  In automated provisioning resource time is not shared with other NSAs.  The impact of this will be when trying to schedule connections close to each other, they connnection reservations must be separated by startup and teardown times in participating NSAs.

*I would like to see us accept these time concepts in talking about time issues.  There are probably issues I  haven't thought of yet that should be included in the descriptions.

3) Difference between automatic and manual provisioning
3a) Automatic provisioning is defined as having each NRM initiate connection so that it is estimated to be available at the requested start time. The time is estimated. It would be good to put some sort of bound on this, similar to what is done for NTP.  This requires that the provider be able to make a estimate of startup and teardown time such that it occurs in a predicable way.  Failure of a provider to do so would be an issue for SLA.

3b) Manual provisioning is defined as having a provision message sent to an NSA to initiate provisioning.  This capability requires that requestor know when a connection is available to be provisioned.  Presumably this time is the start time in the reservation minus startup time.    How the requestor know this time is not clear, though it is possible to build a protocol that would make it available.  In addition, the method of determining startime when a provision request is sent through a sequence of NSAs is also difficult, though not impossible.  

* I would vote to include automatic provisioning in V1 architecture and protocol, and include manual provisioning as a future in architecture and not in V1 protocol.  This gives us time to explore manual provisioning and its uses cases before trying to define how it is implemented.


John