Hi Inder, good points, I'll try to answer them, but have only a few minutes before a meeting... On 01/19/2011 09:28 AM, Inder Monga wrote:

Artur,

Thanks for providing an update. I like the two states at the bottom that clarify what happens when the Cancel message is received. I have a few clarifications:

1. For the last state transitioning from ANY - Canceling - Terminating. - Ideally, the intermediate RA would send a Cancel message to the downstream PA and then release the resources and reservation without waiting for a release confirm? - Do we really need at the intermediate PA to wait to hear Rel_conf from all the downstream nodes before sending our own?

I think it can be done both ways. If we wait for an explicit confirmation, we'll need timeouts to guard against failures. A timeout has to be interpreted as "failed", but there's nothing else you can do than move to Terminating state anyway. If we have explicit confirmation, it would be useful for logging the fact that either the connection was released by the PAs, or not. Now, that's not a function of the protocol, so I could see also operation without waiting for confirmation - you send a cancel/release request, make sure your local resources are released, and move to terminating state. It ties in in the discussion what happens if a message is received from a PA relating to a connection which was already terminated. I am sure Jerry can tell you the details on the call.

2. I missed the discussion for the two new states (Auto-start and Idle) - and really did not see this discussion in last week's minutes? Can you provide more insight why these are necessary? I do understand that they may clarify how you would do each feature like auto start vs manual start, but does it really need a different state?

These states are not new. I removed them at some point for comparison, but on a previous call it was felt they are useful, so here they are back. I believe this makes for a better logical split of the state machine into a part where the connection is "only" scheduled in the future (red), and where resources are under the control of the RA (blue). Auto-start (taken the state name from Jerry) is what I considered a better name for what I was calling scheduled_wait previously.

3. From the state machine, the only way the circuit will come out of "In Service" state to "Idle" is when RA sends an explicit release message? There is no timer for the aforementioned state transition. Timer expiry is always the expiry of the reservation?

Yes, in this version. As I said, this SM does not handle things like data plane faults, etc., e.g. reported by PA. Looking back, I had an initial proposal where it would, but that was put off for later, if memory serves. Now, timer indicating end of reservation will bring us into the terminating state in the end - there's no need to go to idle. What other timer event would you think of?

4. Any communication timeout (for example after sending 3 messages or so without getting an ack back) should result in the PA communicating upstream and releasing the connection unless there is a catastrophic failure?

IMO, a communication timeout has to be treated as the PA not being able to comply with the request. There's no guarantee even that the remote NSA did receive the request. (I consider the NSA having received it when the handler dequeues the request, not when it's hanging in some RX buffer. So in my view the transport protocol does not guarantee delivery.) Gonna go, but I hope I could answer some of your points. Discussion would be much better, of course. Cheers, Artur

Thanks, Inder

On Jan 18, 2011, at 11:55 PM, Artur Barczyk wrote:

...

Hi Guy, All,

unfortunately I won't be able to attend today's call. For the discussion, I attach the latest state diagram V2, i.e. with the idle state back in.

To make the picture clearer, I separated out the transitions due to Cancel request and End of reservation - these can occur from any state, it would just make the picture less readable. Instead, they are shown in the lower part of the diagram as transitions from "Any" state.

Jerry, I did not after all include "Init" and "Terminated" states - I'd like to understand better (and discuss) the necessity of these. (Not a silent drop :-) )

I apologize I cannot participate in the discussion today, but will be happy to receive comments and read the minutes...

Best regards, Artur

On 01/18/2011 06:21 PM, Guy Roberts wrote:

...

Hi all,

The following is dial-in information for Wednesday's NSI call, time: 7:00 PDT 10:00 EDT, 15:00 GMT, 16:00 CET, 24:00 JST

1. Dial Toll-Free Number: 866-740-1260 (U.S. & Canada) 2. International participants dial: Toll Number: 303-248-0285 Or International Toll-Free Number: http://www.readytalk.com/intl 3. Enter 7-digit access code 8937606, followed by “#”

Agenda:

Ongoing NSI protocol and state machine discussion.

Guy

_____________________________________________________________________

** Guy Roberts, PhD Network Engineering & Planning

* * Tel: +44 (0)1223 371300

* * City House Direct: +44 (0)1223 371316

* 126-130 Hills Road Fax: +44 (0)1223 371371

* Cambridge

* CB2 1PQ E-mail: guy.roberts@dante.net <mailto:guy.roberts@dante.org.uk>

D A N T E United Kingdom WWW: http://www.dante.net

_____________________________________________________________________

_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg

-- Dr Artur Barczyk California Institute of Technology c/o CERN, 1211 Geneve 23, Switzerland Tel: +41 22 7675801 <CS_statemachine V2 20110116.jpg>_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg

--- Inder Monga imonga@es.net

-- Dr Artur Barczyk California Institute of Technology c/o CERN, 1211 Geneve 23, Switzerland Tel: +41 22 7675801