[Nsi-wg] suggested diagrams
Jerry Sobieski
jerry at nordu.net
Wed Sep 15 07:34:05 CDT 2010
Hi Radek / all-
I agree with Radek that a modify() primitive is not something we should
include in V1.0 There are too many complexities and fundamentally it
does not provide the protocol a capability that is not able to be
perfromed though other mechanisms.
As for provisioning, we had quite a long discussion - several as I
recall - regarding how a connection reservation should go from
"scheduled" state thru "provisioning" state to "active" state. I agree
with Radek that ultimately a Provision() request issued from a RA will
be ignored (should be ignored!) if it is not within the reserved time of
the reservation...and if the resources are reserved for a certain time
but not provisioned, they are still allocated to the Connection and so
the connection owner should still be charged accordingly. ..And if the
user is being charged, why should the PA not provision the connection
when the reservation begins regardless of whether the RA requests it
explicitly? I do not recall from our discussions why we thought the RA
needed to do this? There is a certain elegance that I like by having
the prime mover NSA initiate the provisioning that goes down the service
tree and bubbles back up the service tree with confirmations... But
there are timing complexities here that cause problems, and there are
other ways to have the notifications bubble up the service tree.
Seperately, there was an issue of provisioning time. I.e. Does the
reserved "Start Time" represent when the "Provisioning" state is
entered, or does it represent when the "In-Service" state is entered?
The implication is that in the latter case some [estimated] guard time
must be added to the start time in the reservation to allow for
provisioning time. As I recall, we were converging on a consensus view
that for the RA initiatied "Manual Start" connection the Start Time was
the start of provisioning, and for a PA initiatied "Auto-Start"
connection that the Start Time was the In-Service time. --> The
simplest way to resolve this for v1.0 would be to simply assert that
Provisioning begins at the Start Time, and that Release begins at the
End Time, and both are PA initiated. This makes the user accountable
for setup time, and the network accountable for tear down time. It
could be a policy decision to only charge the user for the In-Service
time, but we simplify the service protocol by simply mapping Start Time
to one specific event, and simply mapping End Time to another specific
event. (Note: a reservation could still be released early by RA
request, but the PA release would be standard.)
A lot of the discussion of Manual/Auto start had to do with
synchronicity of calendars: If I issue a manual start down tree, but
the down tree calendar is not quite sych'd with my calendar, I might get
a reject just because I issue the manual start too early... So this
introduces all kinds of protocol complexities in order to recover and/or
retry it later... Again, a RA initiated manual start may actually
introduce a lot of unwanted complexities. The simplest approach is IMO
to require each NSA to autostart their provisioning and, seperately,
require a up-tree notify() whenever the connection state changes. The
state change notify will allow each PA to know deterministically that
all subtree components are completed, and then it can push a notify up
to the RA.
I do not recall what the use case justification was for an RA initiated
Manual Start. However, as stated above, I can envision the need for
a PA->RA notification ( or alert of some sort) that the Connection has
transitioned into an "In Service" lifecycle state (or more generally a
notification whenever the Connection changes state.)
Ultimately, IMO we need to be able to assure that the state of a
connection is deterministic within every NSA and that the protocol
converges to a single state for all NSAs. This means that even though
each NSA up and down the tree may have a different state for their
portion of the connection at certain times as it ttransitions, that
given time, the protocol will converge to a single state for the
connection end to end and up/down the service tree. This implies that
certain states are stable and will only change if there is an external
triggering event (such as a timer expiry or a new protocol message is
received).
There is also the issue of "immediate" connection requests. I.e. a
connection whose start time has already passed (or was specified as
null). These connections are to be placed into service as soon as
possible. I suggest for simplicity sake, that these requests follow
the same lifecycle as a book-ahead reservation. I.e. they are initiated
with a Reserve() primitive like any other connection, Response go back
like any other primitive, and the provisioning is auto-started, and the
connection goes into service as quickly as these states can be managed
down the service tree. I don't see a need to do things differnently
for immediate vs scheduled reservations.
Finally, I think it is fundamental that the Connection service provide
first and foremost a simple ability to deliver a connection with the
specific and guarranteed characteristics requested by the user. I
think the simplest approach to this is to fill in unspecified
characteristics with defaults from a Service Definition, and then
provide a Yea or Nay confirmation. No negotiation, no PA adjusted
parameters, no guesses as to what the user might accept, no 20
questions, ....The user requests exactly what they want, and the network
either says yes or no. This would be the best way to get started (IMHO:-)
Sorry for the length...ugh
Jerry
Radek Krzywania wrote:
> Hi all,
> Maybe I am in minority, but for the sake of simplicity, and speed up the process of NSI protocol v1 release, I would really skip anything related to modification of the reservation. First - users usually knows what they want, so I don’t expect this option to be extensively used. Second - in most cases this introduce complexity to reservation processing, which requires use cases and analyses. In some cases modification of reservation cause to create completely new one, with new path, new attributes, etc. This IMHO is v2.
>
> I've missed last call, so maybe I am not in the subject right now (I will miss today call also due to travelling), but sending ResvConn from Requestor NSA is either pointless or should be the only option. Provider will not set up the connection before scheduled time, so Provider NSA will ignore Requestor NSA ResvConn message in such case. If Provider NSA will not setup a connection as scheduled by himself, what is the reason to book it (operator can't use those resources anyway)? The following options are possible:
> - Provider NSA books resources (not configure). Requestor NSA can ignite the connection creation anytime between scheduled time and also terminate it within that time. Provider NSA anyway needs to close the connection at the end of scheduled time, if Requestor NSA did not so. So Requestor NSA needs to keep track of connection state anyway (but that obvious).
> - Provider NSA creates connection in the scheduled time frame (connection start/end time), thus Requestor NSA does not need to send anything. The circuit will be just there as requested. Here an information from Provider NSA to Requestor NSA about circuit creation/cancellation is required (therefore the dashed lines on figures 2 and 3 in your pdf for ConfProv and CancelConf should be solid, thus obligatory). Requestor NSA may cancel the connection any time as well, by sending a message to Provider NSA (but this is not obligatory, also I would not care for v1; this is kind of reservation modification as it changes reservation end time in fact).
>
> Mixing those two scenarios introduces mixed use cases, while we should think if such situations will happen in reality. The issue will arise while we get accounting system and what policy will be used to charge users - time based or connection based. If user is charged per connection, he will not care to release resources before connection expiration time, as this will not save "money" for him (in contrary to operator, but not necessary). If policy is on time basis, user may pay far more attention to when start and close connections. On the other hand, from operator point of view, resources are booked anyway, so it does not matter if the connection is created and active, or not (except some green IT stuff, power and cooling, etc., while connection is active, but this is not the case here, especially for v1). Due to this, I am closer to the first scenario, where ProviderNSA takes care of setting up and tearing down the circuits, while Requestor NSA is just requesting a connection in specific time frame (booking/scheduling).
> Huh - this email is getting long :) If you wish, I could write a short document on that, providing issues any thoughts.
>
> And small comment on primitives - the message names should be unified ConfResv, ConfProv, but CancelConf. So the last message should be ConfCancel.
>
> Best regards
> Radek
> ________________________________________________________________________
> Radoslaw Krzywania Network Research and Development
> Poznan Supercomputing and
> radek.krzywania at man.poznan.pl Networking Center
> +48 61 850 25 26 http://www.man.poznan.pl
> ________________________________________________________________________
>
>
>
>> -----Original Message-----
>> From: nsi-wg-bounces at ogf.org [mailto:nsi-wg-bounces at ogf.org] On Behalf
>> Of John Vollbrecht
>> Sent: Tuesday, September 14, 2010 11:52 PM
>> To: NSI WG
>> Subject: [Nsi-wg] suggested diagrams
>>
>> Attached are two pics - the first is a possible replacement for figure 3 in
>> section 5 of the current doc. The second shows some additional primitives
>> that can be added in similar way.
>>
>> Separating the timelines is meant to indicate that the initiating requestor
>> might not be the same in each case. The dotted lines indicate that some
>> messages are optional in the getting the work done in a connection lifecycle.
>>
>> We might talk about this tomorrow.
>>
>> I haven't had a chance to show the notify, but I will try to add this tomorrow
>> before the call.
>>
>> John
>>
>>
>>
>
>
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20100915/eba082e7/attachment-0001.html
More information about the nsi-wg
mailing list