Hi All, Having reviewed our discussions on advanced reservation, I have the following observations: 1. we agreed in Munich to go with 1PC 2. in the process of writing up 1PC in the architecture document, we discovered some of the subtleties around timing and multi-domain provisioning could result in non-deterministic behaviour. 3. this was tackled with a proposal to incorporate confirmation messages and guard-bands. 4. these modification have enhanced the 1PC behaviour to be close to the original 2PC proposal. In light of this, I am in favour of moving directly to a 2 phase commit solution for v1.0. This will future-proof the NSI protocol. In my view this is important since any enhancement from 1PC to 2PC will require backward compatibility - and this is likely to be difficult process. Can I request that you please read through Tomohiro's proposal as I would like to get agreement on this topic on this Wednesday's call. Thanks, Guy -----Original Message----- From: Tomohiro Kudoh [mailto:t.kudoh@aist.go.jp] Sent: 19 April 2010 09:19 To: nsi-wg@ogf.org Subject: Re: [Nsi-wg] Immediate/Advance reservation (Re: NSI conf call minutes) Hi all, I proposed the guard time scheme since I understood there has been a consensus of not to use 2PC or reservation confirmation in the WG. Following such constraints, the guard-time is a simple way to mimic immediate reservation. However, according to the discussion of the list and the last call, most of people do not think it is acceptable, and I think we can re-consider adoption of 2PC. So, let me propose another choice of reservation operation as attached. Tomohiro On Wed, 07 Apr 2010 22:02:08 +0900 Tomohiro Kudoh <t.kudoh@aist.go.jp> wrote:
Hi all,
To keep the v1.0 architecture simple, I propose to not to use the immediate reservation in v1.0. Instead, I propose to define guard time, and use it as follows:
- The "guard time" is: possible maximum time required to process a request and make resources ready for provisioning.
- Each provider NSA must define its guard time and provide it to requester NSAs.
- A requester NSA should not request a reservation which start time is smaller (earlier) than (current time + guard time). Time required for message delivery should be taken into account too.
- If a provider NSA receives a reservation request which start time is before (current time + guard time), it simply denies the request.
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.
Tomohiro
On Thu, 1 Apr 2010 14:54:15 +0100 Guy Roberts <Guy.Roberts@dante.net> wrote:
The minutes for yesterday's conference call are available here:
http://forge.gridforum.org/sf/go/doc15952?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 -------------------------------------------------------------------- ----------------------------------------------
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg