Draft NSI Connection Service Protocol document
I have updated the NSI connection service protocol document to reflect the current discussions. This is intended to incorporate both the NSI connection service protocol details and sufficient contextual discussion to allow this protocol to be implemented. There will no longer be an NSI connection service architecture document. You can find a copy here: http://forge.gridforum.org/sf/go/doc16045?nav=1 All feedback is welcome. 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 _____________________________________________________________________
Peoples, Chin commented last week on the need for symmetry in naming for both operations and the state machine. I dropped of the WG call this week when my mobile battery died, but I will assume a detailed discussion did not take place. I did notice Guy changed the name of the cancel and release operation, so I thought I might bring up Chin's concerns again. These are simple changes so I do not think they have much of an impact. These are meant to line up the operations and state machine. Here are the current operations and a proposed change: Request a reservation: reserveRequest -> reservationRequest reserveConfirmed -> reservationConfirmed reserveFailed -> reservationFailed Terminate a reservation: cancelReservationRequest -> terminateReservationRequest cancelReservationConfirmed -> terminateReservationConfirmed cancelReservationFailed -> terminateReservationFailed Request provisioning: provisionRequest provisionConfirmed provisionFailed Release provisioning: releaseProvisionRequest releaseProvisionConfirmed releaseProvisionFailed Request a Query: queryRequest queryConfirmed queryFailed And the current stater machine values: Initial – nothing exist yet, the RA and PA are waiting the user initiation Reserving –a reserveRequest has been sent and the PA is attempting to make a reservation Reserved – the reserveRequest has succeeded and a reservation has been created Provisioning – a provisionRequest has been sent and provisioning is ongoing Provisioned (In-Service) – the Connection has been correctly provisioned Releasing – a releaseRequest has been sent and a release is ongoing Terminating (Canceling)– a terminateReservationRequest (cancelRequest) has been sent and a cancelation is ongoing Terminated– nothing exists any longer, a cancel request has been successful I think this might get us closer to what Chin is looking for... John. On 2011-05-06, at 1:08 PM, Guy Roberts wrote:
I have updated the NSI connection service protocol document to reflect the current discussions. This is intended to incorporate both the NSI connection service protocol details and sufficient contextual discussion to allow this protocol to be implemented. There will no longer be an NSI connection service architecture document.
You can find a copy here: http://forge.gridforum.org/sf/go/doc16045?nav=1
All feedback is welcome.
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 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
Hi John, I like your proposal for changes to the primitive and state names.... To me these seem more clear and consistent than previous versions. Guy From: nsi-wg-bounces@ogf.org [mailto:nsi-wg-bounces@ogf.org] On Behalf Of John MacAuley Sent: 08 May 2011 13:45 To: Guy Roberts Cc: nsi-wg@ogf.org Subject: Re: [Nsi-wg] Draft NSI Connection Service Protocol document Peoples, Chin commented last week on the need for symmetry in naming for both operations and the state machine. I dropped of the WG call this week when my mobile battery died, but I will assume a detailed discussion did not take place. I did notice Guy changed the name of the cancel and release operation, so I thought I might bring up Chin's concerns again. These are simple changes so I do not think they have much of an impact. These are meant to line up the operations and state machine. Here are the current operations and a proposed change: Request a reservation: reserveRequest -> reservationRequest reserveConfirmed -> reservationConfirmed reserveFailed -> reservationFailed Terminate a reservation: cancelReservationRequest -> terminateReservationRequest cancelReservationConfirmed -> terminateReservationConfirmed cancelReservationFailed -> terminateReservationFailed Request provisioning: provisionRequest provisionConfirmed provisionFailed Release provisioning: releaseProvisionRequest releaseProvisionConfirmed releaseProvisionFailed Request a Query: queryRequest queryConfirmed queryFailed And the current stater machine values: Initial - nothing exist yet, the RA and PA are waiting the user initiation Reserving -a reserveRequest has been sent and the PA is attempting to make a reservation Reserved - the reserveRequest has succeeded and a reservation has been created Provisioning - a provisionRequest has been sent and provisioning is ongoing Provisioned (In-Service) - the Connection has been correctly provisioned Releasing - a releaseRequest has been sent and a release is ongoing Terminating (Canceling)- a terminateReservationRequest (cancelRequest) has been sent and a cancelation is ongoing Terminated- nothing exists any longer, a cancel request has been successful I think this might get us closer to what Chin is looking for... John. On 2011-05-06, at 1:08 PM, Guy Roberts wrote: I have updated the NSI connection service protocol document to reflect the current discussions. This is intended to incorporate both the NSI connection service protocol details and sufficient contextual discussion to allow this protocol to be implemented. There will no longer be an NSI connection service architecture document. You can find a copy here: http://forge.gridforum.org/sf/go/doc16045?nav=1 All feedback is welcome. 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<mailto:nsi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/nsi-wg
Peoples, I think we have a small issue with the existing state machine when being observed externally across the protocol interface. At the moment, if I send a provisionRequest message to the PA we have a conditional transition based on startTime that is not being modeled. I remember the long discussions over this, but I think we need to revisit it quickly. As per section 3.3... Transition #1: Reserved state -> Provisioning state Precondition: reservation exists; state machine in reserved state, and current time is past startTime. provisionRequest: results in a transition from Reserved state into Provisioning state. Transition #2: Reserved state -> Reserved state - Precondition: reservation exists; state machine in reserved state, and current time is before startTime. - provisionRequest: results in a transition from Reserved state to Reserved state. With this state machine definition, and the current interface definition, there is no way to determine the difference between a Reserved state having already received a provisionRequest and a Reserved state having not received a provisionRequest. I think the distinction is important from an implementation perspective. In OpenDRAC we have an “Activated” state modeled between the “Reserved” and “Provisioning” which lets us transition into “Provisioning” once the startTime occurs. I am sorry to open this up again, but I was thinking of implementation and realized I could not get back this unmodeled state in a queryRequest. Comments? John. 3.3 Provisioning a Connection When the Connection is in the Reserved state the RA can send a provisionRequest message. This request will be treated in two possible ways depending on the arrival of the request in relation to the startTime nominated in the reserveRequest message: • Where the startTime has already passed (according to the PA local timer), receipt of the provisionRequest message results in the Connection state moving to Provisioning. • Were the startTime has not yet arrived (according to the PA local timer), the Connection remains in the Reserved state until the startTime is reached. The Connection state then moves to Provisioning. When the NRM indicates that the provisioning has been correctly completed, the Connection moves to the In-Service state. *** What happens if provisioning fails???
Guy, Going through the last of the requested WSDL changes I remembered this thread I had started off as a result of the ESnet comments from Chin. We have not yet adopted this change into any of the specifications. Should we do this today, or do you feel it is too late to make the cosmetic change? John. On 2011-05-09, at 4:47 AM, Guy Roberts wrote:
Hi John,
I like your proposal for changes to the primitive and state names…. To me these seem more clear and consistent than previous versions.
Guy
From: nsi-wg-bounces@ogf.org [mailto:nsi-wg-bounces@ogf.org] On Behalf Of John MacAuley Sent: 08 May 2011 13:45 To: Guy Roberts Cc: nsi-wg@ogf.org Subject: Re: [Nsi-wg] Draft NSI Connection Service Protocol document
Peoples,
Chin commented last week on the need for symmetry in naming for both operations and the state machine. I dropped of the WG call this week when my mobile battery died, but I will assume a detailed discussion did not take place. I did notice Guy changed the name of the cancel and release operation, so I thought I might bring up Chin's concerns again. These are simple changes so I do not think they have much of an impact. These are meant to line up the operations and state machine.
Here are the current operations and a proposed change:
Request a reservation: reserveRequest -> reservationRequest reserveConfirmed -> reservationConfirmed reserveFailed -> reservationFailed
Terminate a reservation: cancelReservationRequest -> terminateReservationRequest cancelReservationConfirmed -> terminateReservationConfirmed cancelReservationFailed -> terminateReservationFailed
Request provisioning: provisionRequest provisionConfirmed provisionFailed
Release provisioning: releaseProvisionRequest releaseProvisionConfirmed releaseProvisionFailed
Request a Query: queryRequest queryConfirmed queryFailed
And the current stater machine values:
Initial – nothing exist yet, the RA and PA are waiting the user initiation Reserving –a reserveRequest has been sent and the PA is attempting to make a reservation Reserved – the reserveRequest has succeeded and a reservation has been created Provisioning – a provisionRequest has been sent and provisioning is ongoing Provisioned (In-Service) – the Connection has been correctly provisioned Releasing – a releaseRequest has been sent and a release is ongoing Terminating (Canceling)– a terminateReservationRequest (cancelRequest) has been sent and a cancelation is ongoing Terminated– nothing exists any longer, a cancel request has been successful
I think this might get us closer to what Chin is looking for...
John.
On 2011-05-06, at 1:08 PM, Guy Roberts wrote:
I have updated the NSI connection service protocol document to reflect the current discussions. This is intended to incorporate both the NSI connection service protocol details and sufficient contextual discussion to allow this protocol to be implemented. There will no longer be an NSI connection service architecture document.
You can find a copy here: http://forge.gridforum.org/sf/go/doc16045?nav=1
All feedback is welcome.
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 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
participants (2)
-
Guy Roberts -
John MacAuley