Request for developer for NSI visualisation software
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@man.poznan.pl Networking Center +48 61 850 25 26 http://www.man.poznan.pl ________________________________________________________________________
Hello, I would be happy to help out with the implementation of a visualization tool. Jeroen. On 22 Sep 2011, at 16:06, 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@man.poznan.pl Networking Center +48 61 850 25 26 http://www.man.poznan.pl ________________________________________________________________________
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
-- BEGIN-ANTISPAM-VOTING-LINKS ------------------------------------------------------
Teach CanIt if this mail (ID 04FzO7atX) is spam: Spam: https://mailfilter.uva.nl/b.php?i=04FzO7atX&m=062229833e2d&c=s Not spam: https://mailfilter.uva.nl/b.php?i=04FzO7atX&m=062229833e2d&c=n Forget vote: https://mailfilter.uva.nl/b.php?i=04FzO7atX&m=062229833e2d&c=f ------------------------------------------------------ END-ANTISPAM-VOTING-LINKS
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@man.poznan.pl Networking Center +48 61 850 25 26 http://www.man.poznan.pl ________________________________________________________________________
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@man.poznan.pl Networking Center +48 61 850 25 26 http://www.man.poznan.pl ________________________________________________________________________
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@man.poznan.pl Networking Center +48 61 850 25 26 http://www.man.poznan.pl ________________________________________________________________________
nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
-- BEGIN-ANTISPAM-VOTING-LINKS ------------------------------------------------------
Teach CanIt if this mail (ID 02FBQMEsi) is spam: Spam: https://mailfilter.uva.nl/b.php?i=02FBQMEsi&m=6a7a924a831b&c=s Not spam: https://mailfilter.uva.nl/b.php?i=02FBQMEsi&m=6a7a924a831b&c=n Forget vote: https://mailfilter.uva.nl/b.php?i=02FBQMEsi&m=6a7a924a831b&c=f ------------------------------------------------------ END-ANTISPAM-VOTING-LINKS
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@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@man.poznan.pl Networking Center +48 61 850 25 26 http://www.man.poznan.pl ________________________________________________________________________
nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
-- BEGIN-ANTISPAM-VOTING-LINKS ------------------------------------------------------
Teach CanIt if this mail (ID 02FBQMEsi) is spam: Spam: https://mailfilter.uva.nl/b.php?i=02FBQMEsi&m=6a7a924a831b&c=s Not spam: https://mailfilter.uva.nl/b.php?i=02FBQMEsi&m=6a7a924a831b&c=n Forget vote: https://mailfilter.uva.nl/b.php?i=02FBQMEsi&m=6a7a924a831b&c=f ------------------------------------------------------ END-ANTISPAM-VOTING-LINKS
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
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@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@man.poznan.pl Networking Center +48 61 850 25 26 http://www.man.poznan.pl ________________________________________________________________________
nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
--
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Kudoh-san, Jerry-san and all. It's also good to me. I'm not familiar with NSI query() so I thought it might take much time to implement it to Automated Earth. However, the proposed architecture is easier for me. If the app on GoogleAppEngine provides all status with HTTP, SOAP or such a way, I can focus on the development of visualization part. Thanks, -Takatoshi Ikeda On Wed, 05 Oct 2011 14:18:41 -0400 Jerry Sobieski <jerry@nordu.net> wrote:
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@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@man.poznan.pl Networking Center +48 61 850 25 26 http://www.man.poznan.pl ________________________________________________________________________
nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
--
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
-- Takatoshi Ikeda <ikeda@ote.kddi.com> *** Changed E-mail address ***
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? Best regards, Henrik Henrik Thostrup Jensen <htj at ndgf.org> NORDUnet / Nordic Data Grid Facility.
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.
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@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@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
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@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@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
participants (7)
-
Henrik Thostrup Jensen -
Jeff W. Boote -
Jeroen van der Ham -
Jerry Sobieski -
Radek Krzywania -
Takatoshi Ikeda -
Tomohiro Kudoh