[Nsi-wg] Reserved State Machine

[Henrik Thostrup Jensen]

Hi

I think some of the confusion around the Reservation State Machine (RSM) 
comes from that a connection can have multiple revisions and that each 
revision can actually go through the states. This makes it very tricky to 
have a state machine that works across multiple revisions.

A better approach might be to have an RSM per revision. I have attached a 
PDF of how I think such a state machine could look. Reserve_Aborted is now 
a stable state, indicating that the revision has failed. A new revision 
can be started from all stable states.

This makes it very clear where each revision is in its lifecycle.

There could be a state after Reserve_Committed to indicate that the 
reservation has been superseeded by a new revision, but since we probably 
wouldn't expose that, I don't think it is strictly needed.

The Provision State Machine (PSM) and Lifecycle State Machine (LSM) should 
be per connection.


On a side note: I think having 2PC will create more problems than it 
solves, as getting that to work in a multi-domain environment is going to 
be very tricky.


     Best regards, Henrik

  Henrik Thostrup Jensen <htj at nordu.net>
  Software Developer, NORDUnet
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nsi_reserve.pdf
Type: application/pdf
Size: 8392 bytes
Desc: 
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20130425/2e4e5cc6/attachment.pdf>