[Nsi-wg] Request for developer for NSI visualisation software

[Jerry Sobieski]

Hi Tomohiro-

Yes, since this observer is a minimal piece of code for these demos, we 
decided that the ultimate RA client would request a circuit with a 
specific GLobal ID, and the Observer would be manually configured (or 
hard coded) to query on that Global Id.    We will use a Query() to 
discover the path of the connection, then periodic Query()s to poll for 
state change.   So...The observer will need to know which NSA to poll 
for each connection.  We decided that the network name could be embedded 
in the GlobalID (I think this is already a best practice with IDCP).  
Else, we have a single client uRA that both requests the connection, and 
then subsequently acts as the observer which would make the well-known 
global name unnecessary.

So the observer needs to map the network name to the NSA responsible and 
then to the soap endpoint...  So the observer can easily do this if it 
has the same topology file the NSAs use.  If we integrate the observer 
into the client uRA, then this netwrok-NS mapping is moot as we already 
know which NSA to query().

However, the location of the segment endpoints needs to be sent by 
observer to the Automated Earth.  For FIA/SC I am adding "location" 
object to the topology associated with each network.  The observer/uRA 
client will need the topology to obtain this location information 
associated with each network hop.

BR
Jerry

On 10/7/11 3:00 AM, Tomohiro Kudoh wrote:
> Hi Jerone, Henrik and all,
>
> The query behavior is specified as:
>
>   *                 Supports querying reservations based on connectionId or
>   *                 globalReservationId. Filter items specified are OR'ed to build
>   *                 the match criteria. If no criteria is specified then all
>   *                 reservations associated with the requesting NSA are returned.
>
> Therefore, for an external agent such as viewer to get information by
> query, the external agent should know connectionIDs or
> globalReservationIds of reservations somehow.
>
> Tomohiro
>
> On Thu, 6 Oct 2011 13:20:16 +0200
> Jeroen van der Ham<vdham at uva.nl>  wrote:
>
>> On 6 Oct 2011, at 13:06, Henrik Thostrup Jensen wrote:
>>
>>> Hi
>>>
>>> On Wed, 5 Oct 2011, Tomohiro Kudoh wrote:
>>>
>>>> To realize this, each ultimate provider should push state transition
>>>> information to the google app engine. If everybody agree, we will
>>>> prepare a sample code which should be incorporated to the
>>>> implementations.
>>>>
>>>> How do you think?
>>> Why not have the visualization tool use the NSI query interface? After all, it is what it is supposed to be used for. I dislike the idea of starting to build a parallel infrastructure for a task which is supposed to be solvable with the NSI protocol. Sure, the polling nature of query and the high entrance bar for SOAP+WSDL is probably not ideal, but I think we should at least try to build something using it, before we start on the parallel infrastructure. If it doesn't work or becomes to convulated or complex, perhaps we should reconsider parts of the protocol. If we cannot use NSI, who can?
>> If the NSI query interface is implemented and we can easily get the required information out of it, then I'm all for using that.
>>
>> In fact, I think that with your OpenNSA implementation I/we can jumpstart that implementation and should be able to query NSAs in no time at all.
>>
>> Jeroen.
>> _______________________________________________
>> nsi-wg mailing list
>> nsi-wg at ogf.org
>> http://www.ogf.org/mailman/listinfo/nsi-wg
>