Hi Henrik and all, I don't think the RSM Henrik has proposed is clearer. It is semantically same as the original RSM, and message sequences between revisions (i.e. new reservation request can be only received when the previous state machine is in committed or aborted state) is not clear. Just adding some explanation words to the original RSM would be better. But I might be biased since I was involved in the design of the original state machine. Peoples, please give you comments. Tomohiro On Thu, 25 Apr 2013 13:09:30 +0200 (CEST) Henrik Thostrup Jensen <htj@nordu.net> wrote:

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