“Time” in the NSI Protocol Two notions of “Time” are important to NSI Connection Service – Absolute time Globally Coordinated Time and Date, “UTC” time. Necessary foremost for coordinated scheduling of distributed resources or processes. Accuracy of the UTC time among independent agents should be such that the variance in clocks is small compared to average duration of the tasks or allocation windows. This will allow distributed state to converge without significant adverse impact to resource availability. NTP, commonly accurate to +/- 5ms, is adequate for providing a coordinated Time of Day. 1 second (+/- 5ms) is suitable for these purposes. Even a 1 minute +/- 15 seconds would probably suffice… Small variances in clocks across agents, and other non-deterministic timing skew must be handled by the protocol such that distributed state machines converge to a common state quickly and correctly. – Relative time The order, “timing”, of events relative to one another (and internal state) within the NSI Protocol finite state machine. This is important for protocol state convergence and correct termination, particularly among asynchronous autonomous agents such as NSAs. A correctly specified Finite state machines does not require time synchronization among autonomous agents for the protocol to converge.

“Time” in the NSI Protocol The NSI protocol SM itself is not sensitive to absolute time, it is only sensitive to the relative timing of events – The event scheduler may use a time and date to identify when to trigger a protocol event, and the protocol may compute various time/dates trigger other various events, but the protocol itself is not driven by any specific absolute time or date, nor does it require synchronization of UTC among NSAs. The NSI protocol state machine operates on a FIFO Event Queue (EQ) – separate and distinct from the schedule queue (SQ)… – Time-based events are removed from the schedule queue and placed on the protocol event queue when their “scheduled time” = “the current time”. – Events are processed off the event queue by the state machine in First In First Out order. – Other events such as inbound message events are also place on the protocol event queue for processing The “scheduler” process is implementation specific. The protocol requires only an interface to the scheduling functionality that: – Must have a granularity of 1ms. – Must be able to queue timer events with a time of day. (a calendar) – Must be able to queue timer events with a specific delay (a timer) i.e. current time+delay. – Must be able to delete events from the schedule prior to expiry – Must be able to invoke a callback routine upon expiry of the event.

Relative Timing Example – Auto Provisioning NSA Orig NSA PA RA Reserving Scheduled ReserverReq ReserveResp ProvComplete Requested DayClock InService TIme Provisioning Reserving In Service Est Prov Time In Service Scheduled Provisioning? Propagation Delay – variable and unknown, range <1ms to ~250ms Processing Delay – variable and unknown, range <1ms to 60s+ NTP Variance – variable and unknown, range +/- 5ms assumption. Issues: 1.What is “acceptable” InService delay? How do we formalize it? 2.Est Prov Duration is dependent upon both NRM and/or children NSAs 3.For the RA, when does Provisioning phase begin? 4.For PA, does Provisioning begin at bell, or ProvCompl from below? Both?

Timing – Auto Provisioning NSA RA PA RA PA Reserving Scheduled ReserverReq ReserveResp ProvComplete Requested DayClock InService TIme Provisioning? Scheduled Reserving NTP variance ??? Provisioning Provisioning? a1 b1 a3 b2b3 a4 a5 b5 b4

Recommendation A common UTC time, accurate to +/- 1 second (?), is required of all NSAs. – NTP is suitable to facilitate this (though NTP is not specifically required.) – This UTC is used for coordinated booking of resources. The NSI coordinated Resource Scheduler books resources using date & time to a resolution of 1 second. – The resource scheduler reserves the resource in the resourceDB on the RS 1second granularity, and places a “start time” event on the Protocol Event Schedule and an “End Time” event on the Protocol Event Schedule on 1s intervals. NSI Protocol Scheduler (SQ) schedules events on 1 ms granularity, and uses the local system time with resolution of 1 ms, to clock them. – NTP keeps local system time [fairly] accurate to a common global time – The protocol state machine uses the SQ to schedule [microtimed]events (time-outs, grace periods, etc) with 1ms resolution. The Protocol Scheduler should provide the following pseudo API: – eventID= setEvent(datetime.ms, expiryCallback()) or – eventID= setEvent(elapsedtime.ms, expiryCallback()) – status= delEvent(eventID)