Feb. 25, 2010

Attendees: Dantong, Dmitrios, Xin, Arie, Junmin, Alex

Technical discussion

Dimitrios sent the WSDL
discussed the API

Revised the StorNet API based on our F2F and last phone conference discussions.
Except for the structural differences, some renaming to better reflect the functionality. all is subject to further discussions.

The basic difference is the distinction between requests and reservations.%BR%A request may be associated with multiple reservations (1 to n relationship, 1 on 1 is the simplest case) %BR%A call may affect a whole request or a particular reservation which is part of a request.

The API support now 4 calls (reserveRequest, statusRequest, cancelRequest, modifyRequest)

All calls return a TResponse structure which is a revised version of TReserveRespone

statusRequest and cancelRequest accept a TRequestReference structure which can target a whole request, some, or only one reservation within a request

modify request can target a whole request, some, or only one reservation, and apply one or more modifications to each one

EStatusCode has 2 more values, CANCELLED, and NO_SOLUTION, to reflect the result of canceling a request and the response when no satisfactory solution was found a a list of counter offers is returned

TReserveRequest now includes TBAGInfo[] to pass the BAG segments.

added TFlowInfo[] to TResponse to return more details about individual reservations (e.g. ports, etc.)

advisory solution is only for alternative solutions
no_solution -> alternative_solution
no_solution -> "no" solution and searched time windows --> further discussion to be done
time in long integer
failure means that nothing can be done (TP could not find anything)

From Junmin's notes

each request solution has multiple reservation-windows.%BR%requestId 1--->N reservationID %BR%you can specify ports for each window.
no multiple soluntion with multiwindows
alternative solution will be provided with status code=NO_SOLUTION,%BR%add wsdl will add two functions, extendTimeout() & commitRequest(). %BR%If one cann't commit right away, call extendTimeout().
new attribute: advisory solutuions is (array of soluntions) and it is provided when NO_SOLUTION.
with status being RESERVED, then terapath is going to commit the reservation right away. Shall BeStMan find the solution is not needed, then it can call cancel().
name change: NO_SOLUTION above ==> ALTERNATIVE_SOLUTION
TBagInfo needs to add the bandwith attribute.
NO_SOLUTION will be added to indicate failure that is not due to incorrect request parameters, and new attributes will be added in the status structure in addition to current code/explanation pair, so the search restrictions from terapath can be specified when NO_SOLUTION is provided.

email will follow for the final structure.

Further email discussion from Arie on 02/25/2010

We have discussed how to make use of the additional information that TeraPaths can provide when NO_SOLUTION is determined. We came to the conclusion that advice from terapaths without knowing the bandwidth availability graph from BeStMan is useless, because terapaths need this bandwidth availability to make meaningful suggestions. Also, it is best if the max time for giving such advice will be determined by BeStMan (perhaps based on re-negotiation with the user).
Therefore, we propose to retract the attributes "AlternativeSolution" and "AdvisorySolutions" that we discussed in the conference call today. Instead, BeStMan will call with a larger time limit that it is comfortable with.
For example, if we want to have the solution with shortest duration somewhere between time t1 to t2, we call reserve([t1, ..] ...[.., t2], flag=shortest duration). Here [] indicates the multiple windows of the availability graph. If it returns a solution, we take it. Otherwise, we will call reserve([t1,..], ..[..t3], flag=earliest completion), where t3 > t2.
Similarly, if we want to have a solution that has earliest completion time from t1 to t2, but our deadline for completion is t3(>t2), we call reserve([t1,..], ..[..t3], flag=earliest completion) directly. Note that we give an extended availability window from t1-t3. So, if a solution is found only after t2, we’ll consider that the “alternate solution”. In other words, BeStMan will provide a larger window, t1-t3, that could include “alternate solutions” from TeraPaths in case that a solution in not found for the desired period of t1-t2.
This way TeraPath does not need to search beyond the given limit for a solution that BeStMan may not be able to use. Thus, all requests are uniform, and terapath needs to return only a single solution, or NO_SOLUTION for the provided window.
We can keep the extend()/commit() functions that were mentioned today for all regular reservation request, including for solutions that are within the desired t1-t2 time window.