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