April 2010 - Nsi-wg - lists.ogf.org

Re: [Nsi-wg] Immediate/Advance reservation (Re: NSI conf call minutes)
by Gigi Karmous-Edwards 13 Apr '10

13 Apr '10

I completely agree with Radek's statements below. Compared to today's time to get a circuit... many users will be extremely happy with an "ASAP type" of response. Gigi Radek Krzywania wrote: > Hi, > I tried to catch up the discussion, hope I did not missed anything. > What is hard for me to understand is why are we trying to define measurable parameters (connection activation time) basing on non-deterministic, immeasurable parameters (guard time). Even if we measured how much time it takes to reserve and activate connection in a domain, we have only statistical view on how much time it MAY (SHOULD) take. Any change to the network, NSI architecture, HW, or even SF may extend this time unexpectedly, without prior notification. This is not something we can measure (or we need to do that constantly, changing guard time value every time, which in fact does not solve everything). IMHO we can't promise something we could not prove or be sure of. I am happy to measure guard time, add safe value (e.g. res + activation takes 4 minutes, + 2 minutes safe time = 6 minutes) and say to we SHOULD deliver a connection in less than 6 minutes. If we say we MUST provide it in less than 6 minutes, we have an issue. > I am rather more familiar with the option where connection is delivered as soon as possible, which means each domain performs reservation, then signalling is initialized immediately after resources are booked. Does user care if he gets it now = current time, or = current time + "gurad time or whatever"? I suppose not. If I want a circuit now, I expect to get it ASAP, which does not means it's deterministic. I am fine with knowledge I will get it around 6 minutes (statistically), but I must be immediately notified about activation. If we want to go into time details, we will get into very funny things like GPS synchronisation between users, NSA agents, networks, and domains. This is not a real-time system, not everything is deterministic, and not everything can be guaranteed. We can reconsider naming of the service, and change it from immediate to ASAP. > I am not sure if we should focus on this small issue, while facing resources guarantee in advance reservation mode. Try to guarantee there anything for 100% in 2 months time period:) Even if you assume no network/HW failures. > > Best regards > Radek > > ________________________________________________________________________ > Radoslaw Krzywania Network Research and Development > Poznan Supercomputing and > radek.krzywania(a)man.poznan.pl Networking Center > +48 61 858 20 28 http://www.man.poznan.pl > ________________________________________________________________________ > > > >> -----Original Message----- >> From: nsi-wg-bounces(a)ogf.org [mailto:nsi-wg-bounces@ogf.org] On Behalf Of >> Artur Barczyk >> Sent: Tuesday, April 13, 2010 10:11 AM >> To: Inder Monga >> Cc: nsi-wg(a)ogf.org; Guy Roberts >> Subject: Re: [Nsi-wg] Immediate/Advance reservation (Re: NSI conf call >> minutes) >> >> Hi Inder, >> >> I see, thanks for this clarification. >> >> I still think we are introducing an artificial decision step here, which >> will just be confusing to the end-user (and make the whole system >> more complex), and I still wonder about the necessity of it. >> Please see in-line: >> >> >> On 04/12/2010 11:15 PM, Inder Monga wrote: >> >>> Hi All, >>> >>> I feel there is a lot of confusion, so let me try to explain my >>> case/understanding. >>> >>> 1. Guard-time: >>> This concept was proposed for Advanced Scheduling only. This can be a >>> default value and it does not have to be an "exact" measurement of >>> provisioning times. It only handles path computation and reservation >>> times across domains. >>> >>> What does it mean to a user? >>> A user CANNOT ask for a advanced reservation connection with Tstart < >>> Tnow + Guard-time. If a user asks with a Tstart lower that Tnow + >>> Guard-time, the scheduled request is rejected outright. >>> >> Imagine I try to make a connection "NOW", and it gets refused after >> N minutes due to lack of resources. Then I try "2 minutes from now", and >> it gets rejected straight off. >> We shouldn't aim at having expert users who would understand this. >> I think the system should behave in the same (and deterministic) way, >> independent of what the user states in reservation time. >> (Btw - that the reservation and provisioning time might vary does not >> make it less deterministic.) >> >> >>> With an ADvanced Scheduling function, provisioning initiation can happen >>> from both the user or the provider. >>> >>> 2. On-Demand Service: In my opinion, Guard-time does not prevent an >>> On-Demand service as specified by Jerry. They co-exist. >>> An on-demand service, with Tstart = ASAP can be implemented very easily. >>> The service starts when the "provisioning complete" message is received >>> by the user. If the user does not receive that message, it continues to >>> wait. >>> >> Exactly what I was aiming at - but the same logic can apply to any time >> between "NOW" and the guard time, or doesn't it? >> All you need to do, if the start time is reached before the reservation >> is complete, to wait for the latter. >> >> >>> Does this make more sense? >>> >>> I will answer specifics below. >>> >>> >> [...] >> >> >>>> What I meant is that if that time has passed by the time the provider >>>> NSA gets notified of the reservation acceptance along the path, it >>>> should proceed directly to provisioning. >>>> >>> In advanced reservation, the open question is what should a domain do if >>> Tstart comes, and it has not got a reservation complete or provision >>> message? Should it delete the connection or provision its own set of >>> resources? Chin and I include this case in the error recovery document >>> to be published soon. >>> >> No, no - simply wait for the reservation to complete. Only then will >> you know if it succeeded in the first place. >> >> IMO, the provisioning and reservation systems cannot be completely >> decoupled. The provisioning stage should actually never be reached >> until a reservation is complete. It is dependent on the outcome of the >> path computation as well as resource reservation. Never go to provisioning >> before you know you can have the resources. >> >> >>>> You have to do this anyway, to protect against the guard time being >>>> set too short. In which case you can just as well set the guard time to 0. >>>> >>>> That's just common sense, IMO, what it means when I would ask for >>>> immediate >>>> circuit provisioning. "Please give it to me as soon as you're able to, >>>> I'm waiting." >>>> >>>> The thing not to forget is that someone can ask for a circuit not only >>>> "now", >>>> >>> I think the "now" case is actually, "as soon as possible" - which is the >>> on-demand case. Then it just waits for the right message from the >>> Provider Agent before it knows the connection is available to be used. >>> >> Yes, absolutely agree - that's a discussion terminology, which I'd be >> happy to change :-) >> However, we need to be precise on what we mean. An "ASAP" reservation, >> from a user's point of view, could mean really "any time possible, starting >> from now", i.e. also in 2 hours, if the resources will only then become >> available. >> I am not sure BoD does mean that. >> Will in such a case a BoD reservation be converted into a scheduled one? >> >> >>>> but "a minute from now", which would lead to the same problem if the >>>> time to >>>> >>> A minute from now actually becomes a "scheduled connection" and there is >>> where the problem really starts. >>> >> I am sorry I have missed large parts of this discussion, being kept off with >> other workload. Sorry if I am coming back to things which might be obvious >> to you by now. >> But I do not really understand where the problem really is. >> You mention the provisioning system to have to decide what to do >> if the reservation step is not complete - but I think the right design >> decision >> would be that the system should never actually be in such a state. >> (Sorry, I am falling into thinking in terms of state machines here, but >> well, >> that's what I start to believe would be good here.) >> >> Is there other reasons? >> >> Cheers, >> Artur >> >> >>> I feel we should support both Advanced Reservation with guard-time and >>> On-demand connection service. >>> >>> Inder >>> >>> >>>> process the reservation is longer than a minute (as it most probably >>>> will be >>>> in the next future). >>>> So the "now" string as in your option 2) would only work for a singular >>>> subset of the >>>> problem. >>>> >>>> Cheers, >>>> Artur >>>> >>>> >>>> >>>>> Guy >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Artur Barczyk [mailto:Artur.Barczyk@cern.ch] >>>>> Sent: 12 April 2010 17:28 >>>>> To: nsi-wg(a)ogf.org <mailto:nsi-wg@ogf.org> >>>>> Subject: Re: [Nsi-wg] Immediate/Advance reservation (Re: NSI conf >>>>> call minutes) >>>>> >>>>> Hi, >>>>> >>>>> I think guard time is a shaky concept, as who can tell how long it should >>>>> be - it can/will depend on the number of domains the circuit >>>>> contains, the >>>>> speed of each reservation/provisioning system as well as the load on the >>>>> system, and will be variable over time (hoping for faster >>>>> reservation/provisioning >>>>> systems in the future). >>>>> >>>>> But: if in step 5, the "wait for start time" means t_start <= t_current, >>>>> then the >>>>> provider will immediately pass on to provisioning. >>>>> What needs to be done however is to have the duration of the reservation >>>>> reflect the time difference between desired start time and the effective >>>>> one. >>>>> >>>>> I am sure I am missing something..? >>>>> >>>>> Cheers, >>>>> Artur >>>>> >>>>> >>>>> >>>>> On 04/12/2010 11:12 AM, Guy Roberts wrote: >>>>> >>>>>> Jeroen, >>>>>> >>>>>> Yes, that is correct. But the mechanism will be the same for >>>>>> advance reservations, just a later start time. >>>>>> >>>>>> Guy >>>>>> >>>>>> -----Original Message----- >>>>>> From: Jeroen van der Ham [mailto:vdham@uva.nl] >>>>>> Sent: 12 April 2010 08:19 >>>>>> To: Guy Roberts >>>>>> Cc: John Vollbrecht; nsi-wg(a)ogf.org <mailto:nsi-wg@ogf.org> >>>>>> Subject: Re: [Nsi-wg] Immediate/Advance reservation (Re: NSI conf >>>>>> call minutes) >>>>>> >>>>>> To sum this up, this describes a situation where there is no prior >>>>>> reservation and provisioning is started immediately because the >>>>>> startTime is meant as a "now"? >>>>>> >>>>>> Jeroen. >>>>>> >>>>>> >>>>>> On 09/04/2010 18:56, Guy Roberts wrote: >>>>>> >>>>>>> John, >>>>>>> >>>>>>> My thinking of how it could work is as follows (though the details >>>>>>> are really part of the protocol definition group's work): >>>>>>> >>>>>>> StartTime= time when the provisioning is begun. This is the only >>>>>>> possible meaning for StartTime since we have no way of knowing how >>>>>>> long the provisioning will take in advance of the provisioning >>>>>>> being performed. i.e provisioning completion time is >>>>>>> non-deterministic. For consistency as an asynchronous system, the >>>>>>> completion of provisioning (in-service) is pushed by the NRM to the >>>>>>> Provider which in turn sends this to the Requestor as a notification. >>>>>>> >>>>>>> >>>>>>> Locally initiated provisioning: >>>>>>> 1. The Requester NSA creates a request with a start time >>>>>>> (StartTime). StartTime= NSAs current time + Requester guard time. >>>>>>> Eg 12:00pm + 5 minutes = 12:05pm. >>>>>>> 2. Provider validates the start time as being at least the provider >>>>>>> guard time away from now. (note requester and provider guard times >>>>>>> could be a little different to allow for transmission delay of request) >>>>>>> 3. Provider begins the reservation process (12:01pm) >>>>>>> 4. Provider completes the reservation (12:02pm) >>>>>>> 5. Provider waits for the startTime (12:05pm) >>>>>>> 6. Provider starts provisioning locally (12:05pm) >>>>>>> 7. Provider waits for confirmation of provisioning from NRM (12:06pm) >>>>>>> 8. Provider sends a notification to the requestor NSA to notify >>>>>>> that the connection is in-service (12:06pm) >>>>>>> >>>>>>> Provisioning signalled by Requester: >>>>>>> 1. The Requester NSA creates a request with a start time >>>>>>> (StartTime). StartTime= NSAs current time + Requester guard time. >>>>>>> Eg 12:00pm + 5 minutes = 12:05pm. >>>>>>> 2. Provider validates the start time as being at least the provider >>>>>>> guard time away from now. (note requester and provider guard times >>>>>>> could be a little different to allow for transmission delay of request) >>>>>>> 3. Provider begins the reservation process (12:01pm) >>>>>>> 4. Provider completes the reservation (12:02pm) >>>>>>> 5. Provider waits for the startTime (12:05pm) >>>>>>> 6. Provider waits for the signal to provision (12:10pm) >>>>>>> 7. Provider initiates provisioning of the Connection (12:10pm) >>>>>>> 7. Provider waits for confirmation of provisioning from NRM (12:11pm) >>>>>>> 8. Provider sends a notification to the requestor NSA to notify >>>>>>> that the connection is in-service (12:11pm) >>>>>>> >>>>>>> >>>>>>> Guy >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: John Vollbrecht [mailto:jrv@internet2.edu] >>>>>>> Sent: 09 April 2010 17:28 >>>>>>> To: Guy Roberts >>>>>>> Cc: John Vollbrecht; Tomohiro Kudoh; Jeroen van der Ham; >>>>>>> nsi-wg(a)ogf.org <mailto:nsi-wg@ogf.org> >>>>>>> Subject: Re: [Nsi-wg] Immediate/Advance reservation (Re: NSI conf >>>>>>> call minutes) >>>>>>> >>>>>>> I am still a bit confused. Perhaps someone could do a timing diagram >>>>>>> like the one Tomohiro did a while ago when we were discussing 2 phase >>>>>>> commits. >>>>>>> >>>>>>> I will try to explain my confusion. My understanding has been that >>>>>>> we >>>>>>> agreed that provisioning would never be done without prior >>>>>>> reservation. So it would seem that the question being discussed is >>>>>>> "what is the time being requested in a reservation". If the >>>>>>> reservation succeeds then provisioning can happen. >>>>>>> >>>>>>> It seems to me one question is how to define the start time being >>>>>>> requested. The options seem to be that is is either 1) the time the >>>>>>> circuit is actually provisioned and ready to use or 2) the time that >>>>>>> provisioning of the circuit starts. In one case the previous >>>>>>> connection may terminate sooner by the guard time and in the latter >>>>>>> it >>>>>>> may start later by the guard time. If it is (1) then a connection >>>>>>> scheduled for now must have been started at [now - (start time)]. >>>>>>> >>>>>>> A second question is whether is is possible to request a connection >>>>>>> that starts "now". This implies reserving a connection and >>>>>>> initiating >>>>>>> it as soon as it is reserved. Assume that start time is when >>>>>>> provisioning a circuit starts (case 2 above). It seems that main >>>>>>> issue with this is whether the time to reserve a connection is longer >>>>>>> than the requestor is willing to wait. The time it takes depends on >>>>>>> how many NSAs are "chained" to satisfy the request and how long each >>>>>>> NSA takes to reserve the connection. This time is "authorization >>>>>>> time" not guard time as I understand it. >>>>>>> >>>>>>> There is another issue with defining authorization as "now" instead >>>>>>> of >>>>>>> a specific time. The problem is that each NSA in a chain will think >>>>>>> authorization happens at a slightly different time. I am not sure >>>>>>> how >>>>>>> important this is - it doesn't seem too important to me, but >>>>>>> perhaps I >>>>>>> am wrong. If provisioning starts after the reservation is complete, >>>>>>> then everything should be reserved, if at a slightly different time. >>>>>>> ---------------------------------- >>>>>>> >>>>>>> I think Guy is suggesting that start time is when provisioning starts >>>>>>> (case 2) above. That seems simplest to me. >>>>>>> I am not sure the provisioning time is important, and if not I would >>>>>>> think it good to include "immediate" reservation >>>>>>> >>>>>>> John >>>>>>> >>>>>>> >>>>>>> On Apr 9, 2010, at 11:15 AM, Guy Roberts wrote: >>>>>>> >>>>>>> >>>>>>>> Tomohiro, >>>>>>>> >>>>>>>> >>>>>>>>> In this case, only some parts of inter-network connection will be >>>>>>>>> provisioned. >>>>>>>>> >>>>>>>> Right, I forgot about this reason - it is a good point. Again, I >>>>>>>> think we are not complicating things too much if we have a rule that >>>>>>>> the Requester NSA cannot send a start time sooner than now+guardtime. >>>>>>>> >>>>>>>> I think we can solve the chain issue by not forcing any value for >>>>>>>> the guard time. This can be a policy decision to suit the service >>>>>>>> type, equipment and number of networks involved. >>>>>>>> >>>>>>>> Guy >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Tomohiro Kudoh [mailto:t.kudoh@aist.go.jp] >>>>>>>> Sent: 09 April 2010 09:04 >>>>>>>> To: Jeroen van der Ham >>>>>>>> Cc: nsi-wg(a)ogf.org <mailto:nsi-wg@ogf.org> >>>>>>>> Subject: Re: [Nsi-wg] Immediate/Advance reservation (Re: NSI conf >>>>>>>> call minutes) >>>>>>>> >>>>>>>> Hi Jeroen, >>>>>>>> >>>>>>>> There is a problem for inter-network connection. During the >>>>>>>> discussions >>>>>>>> in some calls, the problem of synchronizing networks (managed by >>>>>>>> different NSAs) was discussed. >>>>>>>> >>>>>>>> If you use the "now" type request for inter-network connection >>>>>>>> (without >>>>>>>> complicated coordination), the actual provisioning time of networks >>>>>>>> may >>>>>>>> be different. Moreover, some networks may provision resources before >>>>>>>> some other networks reply to the request, and such networks might deny >>>>>>>> the request. In this case, only some parts of inter-network connection >>>>>>>> will be provisioned. >>>>>>>> >>>>>>>> The guard time is one of the simple solutions to solve this problem. I >>>>>>>> understand there can be multiple ways to cope with this, but all of >>>>>>>> them >>>>>>>> will introduce some complication to some part (note that we decided >>>>>>>> not >>>>>>>> to use 2PC for the v1.0). This is a design choice matter. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Tomohiro >>>>>>>> >>>>>>>> >>>>>>>> On Thu, 08 Apr 2010 09:27:59 +0200 >>>>>>>> Jeroen van der Ham <vdham(a)uva.nl <mailto:vdham@uva.nl>> wrote: >>>>>>>> >>>>>>>> >>>>>>>>> On 07/04/2010 15:02, Tomohiro Kudoh wrote: >>>>>>>>> >>>>>>>>>> If a requester wants resources to be provisioned as soon as >>>>>>>>>> possible, it >>>>>>>>>> can set the start time parameter in a advance request to: >>>>>>>>>> (current time + guard time + a certain time required for message >>>>>>>>>> delivery). >>>>>>>>>> >>>>>>>>>> In this way, immediate provisioning can be requested by an advance >>>>>>>>>> reservation request. >>>>>>>>>> >>>>>>>>> The procedure above seems overly complicated and if I really am >>>>>>>>> pressed >>>>>>>>> for time, and I miscalculate the (current time + guard time + >>>>>>>>> delivery >>>>>>>>> time) by a few seconds. Denying the request means that I have to do >>>>>>>>> it >>>>>>>>> all over again, making me even more pressed for time. >>>>>>>>> >>>>>>>>> Why not keep things simple and always interpret a start time in the >>>>>>>>> past >>>>>>>>> as "now" ? (provided the end-time is in the future too) >>>>>>>>> Would there be any problems associated with that? >>>>>>>>> >>>>>>>>> Jeroen. >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> nsi-wg mailing list >>>>>>>> nsi-wg(a)ogf.org <mailto:nsi-wg@ogf.org> >>>>>>>> http://www.ogf.org/mailman/listinfo/nsi-wg >>>>>>>> _______________________________________________ >>>>>>>> nsi-wg mailing list >>>>>>>> nsi-wg(a)ogf.org <mailto:nsi-wg@ogf.org> >>>>>>>> http://www.ogf.org/mailman/listinfo/nsi-wg >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> nsi-wg mailing list >>>>>>> nsi-wg(a)ogf.org <mailto:nsi-wg@ogf.org> >>>>>>> http://www.ogf.org/mailman/listinfo/nsi-wg >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> nsi-wg mailing list >>>>>> nsi-wg(a)ogf.org <mailto:nsi-wg@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 >>>> _______________________________________________ >>>> nsi-wg mailing list >>>> nsi-wg(a)ogf.org <mailto:nsi-wg@ogf.org> >>>> http://www.ogf.org/mailman/listinfo/nsi-wg >>>> >>> --- >>> Inder Monga http://100gbs.lbl.gov >>> imonga(a)es.net <mailto:imonga@es.net> http://www.es.net >>> (510) 499 8065 (c) >>> (510) 486 6531 (o) >>> >>> >> -- >> Dr Artur Barczyk >> California Institute of Technology >> c/o CERN, 1211 Geneve 23, Switzerland >> Tel: +41 22 7675801 >> _______________________________________________ >> nsi-wg mailing list >> nsi-wg(a)ogf.org >> http://www.ogf.org/mailman/listinfo/nsi-wg >> > > _______________________________________________ > nsi-wg mailing list > nsi-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/nsi-wg >

1 0

NSI conf call tomorrow
by Guy Roberts 13 Apr '10

13 Apr '10

Hi All, The following is dial-in information for Wednesday's NSI call: Time: 7:30 PDT 10:30 EDT, 15:30 BST, 16:30 CEST, 23:30 JST Call: +1-734-615-7474 (Please use if you do not pay for Long Distance) or +1-866-411-0013 (toll free US/Canada Only) Enter access code: 0155180 Agenda: 1. Review action points from last meeting 2. Advance/immediate reservations 3. STPs 4. Other issues Guy ------------------------------------------------------------------------------------------------------------------ Guy Roberts, Ph.D Network Engineering & Planning DANTE - www.dante.net<http://www.dante.net/> Tel: +44 (0)1223 371 316 City House, 126-130 Hills Road Cambridge, CB2 1PQ, UK ------------------------------------------------------------------------------------------------------------------

1 0

Advanced vs. immediate reservation
by Guy Roberts 13 Apr '10

13 Apr '10

Hi All, I think I agree with Inder's analysis that we can support two types of connection request, immediate and advanced, as long as these two services have some constraints which I have summarized in this table: Service type startTime endTime State change State change Res->Sch Sch->Prov Immediate string: '0' >startTime asap Signalled only Advanced >Now + guardTime >startTime <startTime Signalled & local All other state changes are fixed: I -> Res: occurs as soon as the connection request is received Prov -> IS: occurs as soon as provisioning has been completed by NRM IS -> Rel: occurs after Cancel request has been processed. Note 1: '<' means before, '>' means after Note 2: A Connection has following states: Idle (I), Reserving (Res), Scheduled (Sch), Provisioning (Prov), In-service (IS), Released (Rel). The question for v1.0 is do we need to support the immediate mode or can we use near-immediate mode where we set the startTime close to 'now'? Guy ------------------------------------------------------------------------------------------------------------------ Guy Roberts, Ph.D Network Engineering & Planning DANTE - www.dante.net<http://www.dante.net/> Tel: +44 (0)1223 371 316 City House, 126-130 Hills Road Cambridge, CB2 1PQ, UK ------------------------------------------------------------------------------------------------------------------

1 0

immediate and advanced reservations in v1.0
by Guy Roberts 12 Apr '10

12 Apr '10

Hello All, Based on recent discussions I see two competing models for solving immediate type connection requests. Option 1: In the first solution (based on a proposal by Inder and described by Kudoh-san) a start-time of Now+GuardTime is used, where GuardTime is a hold-off time to prevent race conditions. We allow provisioning to be signalled either by the requester NSA and locally by the provider NSA. The guard-time is chosen by policy and is the (worst-case) time taken for reservation to complete. In this model, there is no distinction between near-immediate and advanced, the difference is only in the start time provided by the requester. The problem with option 1 is that it could be very slow - in large systems the guard-time could be several minutes. Option 2: An alternative solution to this problem (proposed by Jerry) would be to use the 'now' string in the start time. To prevent race conditions, instigation of provision must be signalled from the Requester. This would ensure that the provisioning phase is only begun once all reservations are completed. The down-side with this proposal is that it would preclude support for locally instigated provisioning based on the Providers timer. In this model the immediate reservation is distinguished by putting the 'now' string in the start time field. If you believe that we have a requirement to support local instigation of provisioning, then this will make option 2 unworkable. Too quickly gather feedback on these options, I have prepared the following web survey, please complete if you have an opinion on this topic: http://www.surveymonkey.com/s/R8KGD9F Guy ------------------------------------------------------------------------------------------------------------------ Guy Roberts, Ph.D Network Engineering & Planning DANTE - www.dante.net<http://www.dante.net/> Tel: +44 (0)1223 371 316 City House, 126-130 Hills Road Cambridge, CB2 1PQ, UK ------------------------------------------------------------------------------------------------------------------

2 1

new/modified NSI requirements
by Guy Roberts 09 Apr '10

09 Apr '10

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) 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. D2.2.16 The guard time will be agreed based on local policy and managed by the NSA. ------------------------------------------------------------------------------------------------------------------ Guy Roberts, Ph.D Network Engineering & Planning DANTE - www.dante.net<http://www.dante.net/> Tel: +44 (0)1223 371 316 City House, 126-130 Hills Road Cambridge, CB2 1PQ, UK ------------------------------------------------------------------------------------------------------------------

3 3

minutes for today's NSI conf call
by Guy Roberts 07 Apr '10

07 Apr '10

Minutes from today's call can be found here: http://forge.gridforum.org/sf/go/doc15954?nav=1 Guy ------------------------------------------------------------------------------------------------------------------ Guy Roberts, Ph.D Network Engineering & Planning DANTE - www.dante.net<http://www.dante.net/> Tel: +44 (0)1223 371 316 City House, 126-130 Hills Road Cambridge, CB2 1PQ, UK ------------------------------------------------------------------------------------------------------------------

1 0

tomorrow's NSI call
by Guy Roberts 06 Apr '10

06 Apr '10

Hi All, The following is dial-in information for Wednesday's NSI call: Time: 7:30 PDT 10:30 EDT, 15:30 BST, 16:30 CEST, 23:30 JST Call: +1-734-615-7474 (Please use if you do not pay for Long Distance) or +1-866-411-0013 (toll free US/Canada Only) Enter access code: 0155180 Agenda: 1. Review action points from last meeting 2. Review Architecture deliverable feedback 3. Is architecture deliverable v1.0 ready for submission? 4. NSI service instantiation or provisioning signalling 5. Other issues Guy ------------------------------------------------------------------------------------------------------------------ Guy Roberts, Ph.D Network Engineering & Planning DANTE - www.dante.net<http://www.dante.net/> Tel: +44 (0)1223 371 316 City House, 126-130 Hills Road Cambridge, CB2 1PQ, UK ------------------------------------------------------------------------------------------------------------------

1 0