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

Wed Oct 5 13:18:41 CDT 2011

This sounds good to me.  I am collecting Lat/Lon information for the 
SC/FIA demo topology.  So this should be available in the FIA/SC 
topology via the hasLocation relations from the Network resource.

When the Automated Earth app does a detailed Query() it should discover 
the data path.  Then, for each network in the path, it can retrieve the 
hasLocation resource from the topology.  Thus it will have the 
hop-by-hop geolocation.

I suggest we try a test run. If you have some code, perhaps Henrik could 
jam it into the Open NSA to throw a state change event at the 
AutomatedEarth app.

I should have the initial topology diagram available by tomorrow for the 
automated GOLE call.

This will be *so* cool. (:-)
Thanks!
Jerry

On 10/5/11 10:45 AM, Tomohiro Kudoh wrote:
> Hi Jeroen, Jerry and all,
>
> I propose the attached architecture for visualization from the view
> point of the "NSI service plane" (not data plane like pinger).
>
> KDDI (Ikeda-san) may be able to configure their google earth based
> visualization tool to use this architecture, and AIST is able to
> prepare another more schematic visualization tool.
>
> 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?
>
> Tomohiro
>
> 2011/9/28 Jeroen van der Ham<vdham at uva.nl>:
>> Hello,
>>
>> My intention with the Dtox schema was to create something that help get the Automated GOLE demo started. The current topology mostly models control-plane aspects of a network topology, that is NSAs, NSNetworks and STPs (network edge ports).
>> At some point these objects have to be mapped to a data-plane, and it was my impression that at SC we will start with that. At that point NML should come into play.
>>
>> There are already some NML related concepts in the auto-gole.appspot.com editor, but these have not been used yet. They have been simplified a bit, for example we're using bi-directional ports at the moment still.
>>
>> I do hope to apply more of NML topology to this, and hopefully this is a good opportunity to do that some more.
>>
>> Jeroen.
>>
>>
>> On 27 Sep 2011, at 18:47, Jerry Sobieski wrote:
>>
>>> Hey Jeff-
>>>
>>> The NSA codes being developed by the various organizations are
>>> definitely intended for a real system.  But there is a lot of work yet
>>> for these groups to fully implement the NSI framework and the CS
>>> protocol.  And since there is so little time between now and SC we are
>>> trying to minimize changes the interop demo that would distract the
>>> teams from writing NSI code. ...primarily the main change will be to get
>>> the NSI agents covering real hardware present in the AutomatedGOLE
>>> fabric.  Hopefully, this will be fairly simple.
>>>
>>> The NML Topology is not adopted as the NSI Topology at this point.  This
>>> is an issue for the working group and won't be decided on the way to a
>>> demo.   Currently, we are using some extensions to the DToX ontology and
>>> an RDF/OWL data representation of the topology for common presentation.
>>> These seem to be performing well, but it is not clear to me how closely
>>> this parallels NML.   There are a lot of issues that need to be
>>> discussed and understood regarding the NSI framework and how it uses
>>> topology knowledge.   The NSI Topology is on the working group agenda
>>> for ongoing discussion (along with other topics) in parallel with the
>>> demo effort.
>>>
>>> The Observer tool we were discussing for the demo could be a long term
>>> tool.  It would need to be able to Query() an NSA for the service tree
>>> information down to the leaf nodes given a set of keys (e.g. Circuit
>>> ID).   This would essentially provide a monitoring agent with all the
>>> information it needs to trace the circuit and know its state.   The
>>> interface to the NSAs could currently be done using NSI Query requests
>>> in a polling fashion.  I know polling sucks, but it would work for the
>>> demo.   Later on, or as a quick and dirty hack for the demo, a
>>> notification system might be slipped in to replace the polling..  But
>>> the high level logic would remain the same: The purpose of the observer
>>> is to present the relevant information regarding a connection to the
>>> user (or the ops/eng personnel, etc.)  The details of the information
>>> and how such information might be organized and visually presented is
>>> the real value of the Observer.  The Observer would also be able to
>>> trigger other activities when conditions warrant.    So I do not think
>>> developing an Observer agent/application would be a simple throwaway
>>> demo-ware exercise.    Indeed, I think it would help us resolve formal
>>> issues regarding external access to the service tree.
>>>
>>> I hope this helps.   If you want to talk more details let me know and we
>>> can put a conf call together with Radek to put more meat on the bones.
>>> We have interest from some others as well.
>>>
>>> Thanks
>>> Jerry
>>>
>>>
>>> On 9/26/11 1:12 PM, Jeff W. Boote wrote:
>>>> Will the OGF NML topology format be used? Or is this a temporary situation again?
>>>>
>>>> If this is something being built towards an eventual real system, I may be interested in putting resources into it. If this is a one-off for a demonstration, then probably not.
>>>>
>>>> jeff
>>>>
>>>> On Sep 22, 2011, at 8:06 AM, Radek Krzywania wrote:
>>>>
>>>>> Hi all,
>>>>> For SC demonstration there is a need to have a centralised tool which will be able to show global reservation state and visualise the NSI demo topology. The first draft of such application will be required in about 4 weeks for Future Internet Week event held in Poznan between 24-28 Oct, where pre-SC NSI demo will be shown.
>>>>> During my discussion with Jerry Sobieski, we would like to propose the following specification for this visualisation tool:
>>>>> - A simple WebService needs to be implemented at network managers, which will allow to register event listeners (a WS addresses in fact), which will be the visualisation tool
>>>>> - NSI enabled network managers will notify listeners on all events regarding reservations (mostly reservation status change according to NSI reservation lifecycle model)
>>>>> - A visualisation tool will have a WS interface to receive the notifications from all domains involved in the demo
>>>>> - A visualisation tool will be able to show global status on the screen, possibly a topology map. It would be good if a reservation paths could be shown (either delivered by NSI implementations or "guessed" by a tool having knowledge on involved domains)
>>>>>
>>>>> The way of showing a view is a subject to discuss, it can be either a web page or an standalone application. The details should be clarified soon, at the beginning of the next week.
>>>>>
>>>>> As developers who are already involved in coding the NSI and their network managers, it will be best to find someone else dedicated especially for visualiser task. Jerry and I will appreciate any volunteering developers here, so please if you feel being able to write a simple tool to support with a little graphical interface for NSI demos, please rise your hand. In case of any questions, feel free to ask on mailing list or directly to me or Jerry.
>>>>>
>>>>> 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
>>>>> ________________________________________________________________________
>>>>>
>>>>>
>>>>>
>>> _______________________________________________
>>> nsi-wg mailing list
>>> nsi-wg at ogf.org
>>> http://www.ogf.org/mailman/listinfo/nsi-wg
>>>
>>>
>>> --
>>>
>> _______________________________________________
>> nsi-wg mailing list
>> nsi-wg at ogf.org
>> http://www.ogf.org/mailman/listinfo/nsi-wg
>>