[Nsi-wg] Immediate/Advance reservation (Re: NSI conf call minutes)

[Guy Roberts]

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 at aist.go.jp] 
Sent: 19 April 2010 09:19
To: nsi-wg at 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 at 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 at 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 at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg