[Nsi-wg] new/modified NSI requirements

[John Vollbrecht]

Some comments below --
On Apr 7, 2010, at 1:14 PM, Guy Roberts wrote:

> Hello all,
>
> Following on from today’s NSI discussions, the following new NSI  
> requirements are proposed.  Could you please take a look and let me  
> know if you are happy to accept these as agreed requirements?
>
> Guy
>
> ----------------
>
> Not UNI like:
> R1.1.10 The NSI architecture must not force services requests to  
> originate from any specific NSA. (i.e. this is different to MPLS UNI  
> which only allows connections requests that terminate on the node  
> associated with the UNI)
>
> Provisioning complete notification:
> D2.1.12a The Notify function must support a notification to indicate  
> that provisioning has been completed. (this is to allow local timer  
> based initiation of provisioning to be notified to the Requester NSA)
I don' t think the reason is just to allow local timer initiation.  I  
think the idea is to make notiification of provisioning completion  
orthogonal to initiating provisioning.

>
> Provisioning initiation methods:
> D2.2.6 Connection provisioning is initiated in two possible ways:   
> 1: When a Requestor NSA signals to the Provider NSA. 2: Once a  
> scheduled resource reaches the start time.  (I guess this implies  
> the need for some way of indicating which type of initiation of  
> provisioning should be used)
>
> Advanced reservation and near-immediate reservation method:
> D2.2.13 A requester NSA will create advanced reservation type  
> Connection requests by setting a start time and end time.
>
> D2.2.14 A requester NSA will be able to request near-immediate  
> Connections by setting a start time soon after the current time,  
> subject to guard time limits.
> Note that the guard time concept is added here to allow validation  
> of start times that are near-to-present-time.  This makes start  
> times more deterministic and reduces race conditions and other  
> problems during connection creation  -Guy Roberts 4/7/10 4:56 PM
>
> D2.2.15 A Provider NSA when scheduling a Connection request will  
> perform a guard time test on the start time as follows: If the start  
> time is less than current time + guard time then the connection  
> request will be rejected.
Is guardtime only a provisioning issue?  I thought there was  
discussion that a reservation might have a similar problem because of  
delays in reserving over a sequence of NSAs.  I am not sure this is a  
real issue because when I get a response the connection is reserved,  
and the only question is whether it is too late to be useful.
>
> D2.2.16 The guard time will be agreed based on local policy and  
> managed by the NSA.

I have a question about guard time in general.  Does one start  
provisioning at start-time minus guard time to guarantee that the  
connection is established at the start time, or does one start  
provisioning at start time and it is completed at start-time plus  
guard time?  I had always assumed the latter, but this seems to assume  
the former.

Seems to me issue with this for scheduling is that if one has a  
calendar and schedules a connection from t1 to t2 and another from t2  
to t3, to be precise one has to schedule t1 to (t2-guardtime)and  t2  
to (t3-guardtime), assuming that calls start down when provisioning  
starts.

I think this implies that guardtime needs to be included in response  
to a request for connection.


>
>
> ------------------------------------------------------------------------------------------------------------------
> Guy  Roberts,  Ph.D
>
> Network Engineering & Planning
> DANTE - 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 at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20100407/9ea2d3c3/attachment-0001.html