Choices in Reservation operation

© 2006 Open Grid Forum

Choices in Reservation operation1PC/2PC, start_time/ASAP, explicit/automaticTomohiro Kudoh, AIST


Reservation options

• 1PC/2PC• 2PC has “held” state, and must be committed before

provisioning

• Reservation confirmation• Whether the root requester confirm success of all

reservations• 2PC inherently confirms success of reservations

• Start time parameter• Specify exact start time / ASAP request

• If the start time is ASAP, it is called immediate reservation

• Trigger of provisioning• Explicit: signaling message from the root requester• Automatic: Each leaf provider NSA provision at the

specified start time based on its own timer2


1PC without reserve confirmation

3Good case Bad case

• Very nondeterministic behavior

RequesterProvider a Provider b

reservereserve

provisionprovision

GB

GB


reservereserve

provisionprovisionGB

GB

Resource available

Resource not availableResource provisioned


Need for fail/rollback

4

• Protocol will need to support fail/rollback for cases where failure happens after reserve/commit


reservereserve

provisionprovision

GB

GB

Requester Provider b

Resource available

Resource not availableResource provisioned

failrollback


Summary for reserve confirmation

• 1PC without reserve confirmation is not appropriate for NSI, because of its non-deterministic behavior.

• I propose not to use this option for NSI.

5


Possible reservation operations

6

Codename

1PC/2PC

reserveconfirm

Exact start time(ST)/ASAP

Provisioning(explicit/automatic)

1SE

1PC

yesST

explicit

1SA automatic

1AE ASAP explicit

-

noST

explicit

- automatic

- ASAP explicit

2SE

2PCn/a

(inherently confirmed)

STexplicit

2SA automatic

2AE ASAP explicit


1SE and 2SE: comparison

7“all” case “none” case


reservereserve

provisionprovision

GB

GB


reservereserve

GB

GB


reservereserve

provisionprovision

GB

GB


reservereserve

GB

GB

1SE

2SE

ack

ack

held

heldcommitcommit

held

abortabort

ack

nackcancel

“commit” can be piggy backed to “provision”


Adding failure after commit



reservereserve

provisionprovision

GB

GB


reservereserve

GB

GB


reservereserve

provisionprovision

GB

GB


reservereserve

GB

GB

1SE

2SE

ack

ack

held

heldcommitcommit

held

abortabort

ack

nackcancel


failrollback


For exact start time/explicit

• 2PC does not introduce much complexity, compared to 1PC.

• 2PC is equivalent to 1PC (with confirm) if “commit” is piggy-backed to “provision”.

9


1SA and 2SA: comparison



reservereserve

GB

GB


reservereserve

GB

GB


reservereserveG

B

GB


reservereserve

GB

GB

1SA

2SA

ack

ack

held

heldcommitcommit

held

abortabort

ack

nackcancel

Start time


1SA and 2SA: comparison (2)

11


reservereserve

GB

GB


reservereserveG

B

GB

1SA

2SA

held

abortabort

ack

nackcancel

Start time

Provider b provisions resource when at start time, so partial provisioning occurs

Provider b does not provision resource since no commit message has been received

Start time


For exact start time/automatic

• 1PC will introduce non-deterministic behavior for automatic provisioning.

• 2PC is deterministic.

12


1AE and 2AE: comparison



reservereserve

provisionprovision

GB

GB


reservereserve

GB

GB


reservereserve

provisionprovision

GB

GB


reservereserve

GB

GB

1AE

2AE

ack

ack

held

heldcommitcommit

held

abortabort

ack

nackcancel



For ASAP/explicit

• 2PC does not introduce much complexity, compared to 1PC.

• 2PC is equivalent to 1PC (with confirm) if “commit” is piggy-backed to “provision”.

14


Summary

• I propose NSI to use 2PC, allowing piggy backed-commit.

15


Parameters of immediate reservation

• There was a discussion on whether to use (start time, end time) or (stat time, duration) for requesting parameters, and we decided to use (start time, end time) for NSI protocol

• They are the same for “exact start time operation”, duration = end time – start time

• But they are different for immediate reservation: (ASAP, end time), (ASAP, duration)• If the end time is specified, duration of provisioning

is not know, and vice versa.

16


Timing issues we should aware

• The following timing issues exist, and must be considered, regardless of whether we will use 1PC or 2PC• Time (duration) required to process request,

schedule and make resources ready for provision• Time (duration) between a trigger to provision

(signaling message or timer) and the time when connectivity for user become available

• Time (duration) between a trigger to cancel a provision (signaling message or timer) and the time connectivity disappears

• Time (duration) required to deliver a message

17


Provisioning timings(1)

• Provisioning sequence start time• The time a provider NSA starts action to provision a

connection (by timer or signaling)

• No preceding processing before this time is required.

• Provisioning sequence end time• After this time, provision sequence of another

reservation can be started

• Connectivity start/end time• The time the user can start/should finish to use the

connection

• Connectivity end time

18


Provisioning timings(2)

EPST Earliest Provisioning Sequence

Start time

Provisioning sequence must not start before this time to keep ECST (?)

LPST Latest Provisioning Sequence

Start time

Provisioning sequence must be started by this time to meet the service definition

EPET Earliest Provisioning Sequence

End time

No meaning?

LPET Latest Provisioning Sequence

End time

Provisioning sequence must be ended by this time to allow next reservation’s provisioning

ECST Earliest Connectivity Start time

Connectivity must not start before this time for security reasons.

LCST Latest Connectivity Start time

User requires connectivity by this time

ECET Earliest Connectivity End time

User requires connectivity until this time

LCET Latest Connectivity End time

Connectivity must not remain after this time for security reasons

19

Choices in Reservation operation

Documents

Transcript of Choices in Reservation operation