[Nsi-wg] time issue
Artur Barczyk
Artur.Barczyk at cern.ch
Thu Sep 30 09:46:51 CDT 2010
Hi,
On 09/29/2010 05:21 PM, John Vollbrecht wrote:
> I abstract from this discussion some things that need to be agreed.
>
> We are using the term available time and reserved time.
I would call it "requested time" (as it comes from the user request).
>
> Available time is requested time in a request and estimated time in a
> response. Perhaps estimated is best in both cases.
>
> There is a proposal that available time be used in all protocol
> messages. This certainly seems to work for automatic provisioning case.
IMO, this is the only thing that makes sense - reserved time will be a
local parameter of each NSA.
> For user provisioning it seems to me that some way of giving the user
> a estimate of startup time is needed. Also for user provisioning the
> assumption is that tear down is initiated by network to satisfy
> reserved end time (if not torn down by user before then). We need to
> decide how to deal with automated and user initiated in the same protocol.
If my understanding is right, the "user initiated" provisioning will be
done by the RA, so technically there should
be no difference to "automated" provisioning if the RA is provided with
the same info as any other NSA.
Which it should, unless we aim for a simplified UNI as described by
Jerry in an earlier mail (where I agree
we probably don't actually want that).
Btw, I never understood the need for user initiated provisioning in the
first place. The user has requested a resource, and it
has been confirmed to him. He can safely assume it's there (modulo error
conditions).
The provisioning should be initiated by the "owning" NSA, probably the
one that received the original user request, or
the RA itself.
Some other thoughts in this respect:
- The resources are reserved anyway.
- User is bound to initiate the provisioning at requested/available
time. He has no choice (otherwise we need to inform him about the
resulting reserved time - in which domain? So why asking him to do
so? What if he doesn't at all?
- User should not need to be network aware - it's the network that has
to provide the service to the specs.
So "automatic" provisioning is really the only reasonable option, I
think, be it from a PA or RA. Initiation by
a "dumb" user agent just opens a can of worms...
>
> Time synchronization is a major issue. I note that time
> synchronization in reservations is a question of setting start and end
> time equivalently in all NSAs. Jeff suggests that we use NTP or some
> equivalent to sync time between NSAs, which can provide a bound. I
> wonder if there is a way to do this, for reservations at least, in the
> protocol - each NSA sharing its time wirh its neighbor at in each
> request. I would like to see a list of specific issues and proposed
> resolutions to discuss. Is someone able to develop such a list?
I don't actually think this is an issue per se. All that is required is
to start ntpd, which any reasonably configured server does anyway.
This will give you (sub-)second synchronisation between NSAs, and if we
put it as a requirement, also the user.
Now, if we are talking about "guard times" and such of minutes, time
synchronisation to a second or so
will certainly be sufficient.
Not sure the NSAs need to synchronise between each other, at least in
v1, if each is required to synchronise to
a reasonably good time reference, which should be the thing mandated.
I agree the list of specific issues is needed here, I would again
recommend to think of state machines in this context.
With nested SMs, I believe the main issue is a timeout value to wait for
any NSA not in provisioned state at the user
requested/available time.
But then again one would need to look though the tree and chain models
in detail, so I'm sure there's more.
Cheers,
Artur
>
> Are there other issues that need to be resolved?
>
> John
>
>
>
>
>
>
>
> On Sep 29, 2010, at 10:00 AM, Jeff W.Boote wrote:
>
>>
>> On Sep 29, 2010, at 7:31 AM, Gigi Karmous-Edwards wrote:
>>
>>> Jerry,
>>>
>>> For your question : " While the guard times may be network specific,
>>> we do need to at least consider what we would like an NSA to do if
>>> for instance a provisioning guard time pushes a reservation forward
>>> into a previous reservation: Do we 1) reject the request since we
>>> can't prepend our guard time and still make the Requested Start
>>> Time? OR 2) Do we retard the Estimated Start Time to allow for
>>> the guard time? OR 3) do we reduce the guard time to fit the
>>> available lead time?"
>>>
>>> In my opinion, I think the answer here has to be # 1) each NSA must
>>> reject the request if their process to establish the connection
>>> requested can not meet the Start time. In my opinion an NSA should
>>> NOT be allowed to change the requested start time (this will cause
>>> all types of problems for other NSAs), so # 2) is not an option. The
>>> guard time for each NSA will most likely be vastly different and
>>> very dependent on the tools used by that network domain to configure
>>> the network elements for the requested path, so an individual guard
>>> time of an NSA is also nonnegotiable, so option # 3) is not an option.
>>
>> I agree #1 seems the most deterministic.
>>
>>>
>>> I agree with Radek, ONLY Start times and End times should be used in
>>> the protocol and that guard times are only private functions of each
>>> individual NSA.
>>
>> I agree with this. The guard times are not additive across each NSA.
>> The guard time from the perspective of the user will effectively be
>> the maximum of each NSAa guard time in the chain. But, the user
>> doesn't care as long as provisioning is accomplished by the users
>> requested start time. That time would be in the protocol and would
>> remain unchanged through each step of the chain. And, it shouldn't
>> matter how long it takes to tear down the circuit either as long as
>> the circuit is available until their requested end time.
>>
>> As to how to manage this time synchronization... I think it is
>> totally reasonable to depend upon existing protocols. There are other
>> protocols that already depend upon time synchronization, and many of
>> them use NTP. We are not talking about needing very tight
>> synchronization anyway. 1 second or even 10 seconds is plenty close
>> enough. It is more about bounding that error.
>>
>> jeff
>>
>>>
>>> Kind regards,
>>> Gigi
>>>
>>> On 9/29/10 8:45 AM, Jerry Sobieski wrote:
>>>> Hi Inder- I am not sure I agree with all of this...
>>>>
>>>> Inder Monga wrote:
>>>>> Radek
>>>>>
>>>>> I agree with your statements;
>>>>>> User is not interested in partial results, as he/she is not even
>>>>>> aware/interested in which NSAs/domains are involved. User doesn’t
>>>>>> care (if everything works fine ;) ).
>>>>>
>>>>> The protocol should be designed with the user in mind. The user
>>>>> does not care about guard time values, differences in setup times
>>>>> for MPLS vs optical lambdas, and concern itself with choices an
>>>>> NSA/NRM will make in path-finding.
>>>>>
>>>> The protocol designers can keep the user in mind, but /the protocol
>>>> is between the RA and the PA/ and and has a specific purpose: to
>>>> reserve and instantiate a connection across the globe. We need to
>>>> keep in mind that the RA is not always the end user - it is by
>>>> definition another NSA and could be an NSA in the tree/chain
>>>> somewhere. If we want to differentiate between the user and the
>>>> network, then we can create a simplified User to Network API, and a
>>>> different Network to Network API...but I don't think thats what we
>>>> want to do (:-) We need to IMO *not* think about the user, but to
>>>> think about the Requesting Agent - regardless of who it represents.
>>>>
>>>> Perhaps once the RA-PA protocol is tightly defined in all its
>>>> nuances, we can develop/recommend an end user API that simplifies
>>>> the the application's required interactions ?? This would allow
>>>> an application to embed an RA in a runtime library/module and the
>>>> application itself would only have to deal with the basic
>>>> connection requirements.... just a thought.
>>>>> In my opinion,
>>>>> a. the user should specify "Expected Start Time, Expected End
>>>>> Time". The NSAs/domains along the path determine resource
>>>>> availability and booking in their schedules based on their own
>>>>> configured guard time (guard times are not specified by NSI
>>>>> protocol. NSI connection service architecture should discuss them
>>>>> as a suggested concept).
>>>> While the guard times may be network specific, we do need to at
>>>> least consider what we would like an NSA to do if for instance a
>>>> provisioning guard time pushes a reservation forward into a
>>>> previous reservation: Do we 1) reject the request since we can't
>>>> prepend our guard time and still make the Requested Start Time?
>>>> OR 2) Do we retard the Estimated Start Time to allow for the
>>>> guard time? OR 3) do we reduce the guard time to fit the
>>>> available lead time?
>>>>
>>>> I think we now agree that the Start Time is just an estimate, due
>>>> primarily to the guard time itself being just an estimate. So none
>>>> of these times are etched in stone...So which option do we
>>>> recommend or require? The protocol is sensitive to these various
>>>> times - they cause timers to go off, messages to be sent, error
>>>> handling to kick in... If they are adjusted during scheduling or
>>>> provisioning, we MUST understand what impact they will have to the
>>>> protocol and how that will be carried through the service tree.
>>>>> b. Within reasonable limits, the connection should be up as close
>>>>> to the start time as possible. The user can set his own
>>>>> policy/configuration on how long to wait after the start time to
>>>>> accept a connection. Since the resources are guaranteed, this is a
>>>>> connection of setup/provisioning only. Hence, there is no protocol
>>>>> state transition when start time is passed other than the messages
>>>>> that indicate the circuit is established end to end or teardown
>>>>> message initiated by the client.
>>>> Ah, but the rub here is that the "user" is an RA...but not all RAs
>>>> are the end user. We are defining the actions of an RA, regardless
>>>> of whether it is a user NSA or an network NSA. So we must insure
>>>> that if the RA gets tired of waiting for provisioning to complete,
>>>> that whatever actions it is allowed to take will be consistent and
>>>> predictable through out the service tree for all the RA/PA
>>>> interactions. So the "user" actions are not irrelevant to the
>>>> protocol.
>>>>
>>>>> c. We should not design a protocol that depends on time
>>>>> synchronization to work. In my opinion, the start time, expected
>>>>> time to provision aka guard time is best handled/shared as a
>>>>> SLA/Service definition issue.
>>>> I agree: We cannot expect perfectly/exactly synchronized clocks
>>>> anywhere in the network. And therefore we cannot depend upon clock
>>>> synchronization for any part of the protocol to work. Which
>>>> implies that the protocol must work when the clocks are NOT
>>>> synchronized. How do we insure this? --> rigorous protocol
>>>> analysis.
>>>>
>>>> While the values of certain timers may be left to the Service
>>>> Definition/SLA, as I state before, we must make sure that the
>>>> protocol can function predictably and consistently in the face of
>>>> all possible timing permutations that are possible among NSAs.
>>>> This rapidly gets very complex if we allow too many variables for
>>>> the SD/SLA to define. Sometimes, its ok to identify constants that
>>>> the protocol must use so that we can validate the protocol and
>>>> simplify implementation and deployment. Indeed, often times when
>>>> clocks are only slightly skewed they introduce race conditions that
>>>> become more likely to occur requiring more careful consideration.
>>>>>
>>>>> d. Similar semantics apply to the end-time as well.
>>>> Pretty much. Across the board, things like clock events,
>>>> estimates, and service specific choices will create situations
>>>> where we need to insure the protocol and state machines will
>>>> function properly across the full range of possible permuted
>>>> values. This is in general why protocol designers say "make it
>>>> only as complex as it needs to be, and no more" - options breed
>>>> complexity.
>>>>
>>>> br
>>>> Jerry
>>>>
>>>>
>>>> _______________________________________________
>>>> nsi-wg mailing list
>>>> nsi-wg at ogf.org
>>>> http://www.ogf.org/mailman/listinfo/nsi-wg
>>>>
>>> _______________________________________________
>>> nsi-wg mailing list
>>> nsi-wg at ogf.org <mailto:nsi-wg at ogf.org>
>>> http://www.ogf.org/mailman/listinfo/nsi-wg
>>
>> _______________________________________________
>> nsi-wg mailing list
>> nsi-wg at ogf.org <mailto:nsi-wg at ogf.org>
>> http://www.ogf.org/mailman/listinfo/nsi-wg
>
>
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg
>
--
Dr Artur Barczyk
California Institute of Technology
c/o CERN, 1211 Geneve 23, Switzerland
Tel: +41 22 7675801
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20100930/614db76f/attachment-0001.html
More information about the nsi-wg
mailing list