[Nsi-wg] new/modified NSI requirements

"Joan A. García-Espín" joan.antoni.garcia at i2cat.net
Thu Apr 8 06:04:51 CDT 2010


Hi all,

I agree with having the new requirements in general.

However, I've some concerns on whether we have to specify how the  
guard-time should be calculated. Some examples:
   - Chain deployment of the service plane: guard time for the  
provisioning should be at least the sum of local guard times. Could be  
computed at the reservation phase.
   - Tree deployment of the svc. plane: guard time should be at least  
the sum of NRM provisioning time + instantiation delay in the  
signaling (depends on the number of levels in the hierarchy in some  
cases).

Regards,
--
Joan A. García-Espín
CTX, i2CAT Foundation





El 07/04/2010, a las 21:09, John Vollbrecht escribió:

> 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
>
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg



More information about the nsi-wg mailing list