Hi Radak - See comments inline... On 1/25/11 8:34 AM, Radek Krzywania wrote:
Hi all, As promised during recent call, in the attachment you will find first draft of what I meant. A simple reservation starting at particular time and ending at particular time, without failure conditions and "freezing" the reservation. Several comments to state diagram: - there is no such thing as Terminated state. Terminating IMHO is something similar, yet the name is ambiguous as it reflect something is being done with the reservation, while it's already finished. - Idle state is same as scheduled IMHO. Can't see practical difference. In both states resources are there, can't be used by anyone else. Yet they are not configured in the network. I assume idle implementation may differ for various providers (i.e. in some cases idle = provisioned, or idle = scheduled/auto start). In case idle=scheduled, then RA_Cancel does not need to go through Cancelling state (as there are no resources really committed in the network, just promised in the NSI agents). Idle state and Scheduled state are different. During the Scheduled state there are no resources allocated to the requester. It is just scheduled for some time in the future...i.e. a provision request will not produce a working circuit. Dring the Idle state, the resources *are* allocated to the requester, but may not be configured appropriately to make the resources "In Service". But the resources belong to the requester (and no one else can use them) during the Idle state, but not during the Scheduled state (other users may in fact be using the resources during the scehduled state.)
- in the tables describing actions in particular states, if message is sent I would indicate not only to whom, but also who is the sender. It is ambiguous for me in some cases, especially that I can't guess if one RA sends something to PA in the same or different domain. Also we are missing a communication between PA and RA for the same domain. Even if that's out of out protocol, there are some pre-defined actions which we expect to be done. I agree. But this will get resolved as we converge on a consensus State Machine model. It is my opinion that there are two essnetial SMs: One for the PA, and and one for the RA. And these should be driven by input events (messages, timer expiries, some other conditions we have not defined, etc.) The RA is very simple. The PA is more complex and there are a few issues that we need to clarify...in particular what these input events are.
Hoep this helps Jerry
Comments to attached scenario: - The states for first RA are ambiguous. As first RA does not have a domain below to control (it just request resources), it does not have simply defined reservation state, as this is global state. In AutoBAHN we have a global state as a sum of all states in particular domains (e.g. global state for 4 domains may be like Provisioning;Provisioning;In-Service;In-Service). I've placed them just single state just to show what is expected global state of reservation, but that require a discussion to decide how to deal with that. - There provisioning itself is not reflected in the diagram for two reasons - we did not defined steps to do so, and is unimportant from states point of view. - I am missing some kind of message to confirm reservation termination at the end. There is Cancel sent at the end, but to who and when? It seems it does not change any state anyway (missing state?). I did not put that on the diagram.
I made the diagram as readable as I could for now. I can't find a better form now, but I am open for suggestions. I am waiting for comments and discussion ;) Also I would be glad if I could get some help with NSI message names to be in compliance with other NSI documents. Since we clarify this diagram I can make some for failure scenarios or some more complex ones.
Best regards Radek
________________________________________________________________________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and radek.krzywania@man.poznan.pl Networking Center +48 61 850 25 26 http://www.man.poznan.pl ________________________________________________________________________
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg