September 2011 - Nsi-wg - lists.ogf.org

Request for developer for NSI visualisation software
by Radek Krzywania 07 Oct '11

07 Oct '11

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(a)man.poznan.pl Networking Center +48 61 850 25 26 http://www.man.poznan.pl ________________________________________________________________________

7 11

Keep those
by Henrik Thostrup Jensen 07 Oct '11

07 Oct '11

Hi Please remember to keep your NSI agents running and well-taken care of so people can test their implementations against yours. Here is a short reservation test result: OpenNSA WS reservation test client Network: Aruba Reservation created. Connection ID: urn:uuid:bcfa9dda-ea7b-11e0-9905-00144f20a8d2 Network: Bonaire Callback for call urn:uuid:bd0924e0-ea7b-11e0-9905-00144f20a8d2/reservation from urn:ogf:network:nsa:Bonaire-OpenDRAC timed out. Network: Curacao Callback for call urn:uuid:c8f50fa8-ea7b-11e0-9905-00144f20a8d2/reservation from urn:ogf:network:nsa:Curacao-AutoBAHN timed out. Network: Dominica Callback for call urn:uuid:d4e0feee-ea7b-11e0-9905-00144f20a8d2/reservation from urn:ogf:network:nsa:Dominica-OSCARS timed out. Network: Grenada org.apache.cxf.binding.soap.SoapFault: Could not initialize class com.sun.xml.internal.ws.spi.ProviderImpl Network: Jamaica Reservation created. Connection ID: urn:uuid:e18453ee-ea7b-11e0-9905-00144f20a8d2 Network: Martinique Callback for call urn:uuid:e5561296-ea7b-11e0-9905-00144f20a8d2/reservation from urn:ogf:network:nsa:Martinique-DynamicKL timed out. Result: 2/7 succesfull registrations. Come on, we can do better :-). Best regards, Henrik Henrik Thostrup Jensen <htj at ndgf.org> NORDUnet / Nordic Data Grid Facility.

2 8

minutes from today's NSI conf call
by Guy Roberts 28 Sep '11

28 Sep '11

Hello all, The minutes from today's NSI call are available here: http://forge.gridforum.org/sf/go/doc16344?nav=1 Again, I strongly encourage everyone to review the features proposed for the upcoming versions of the NSI CS protocol and send any feature suggestions/requests you have to the mailing list. The roadmap can be found here: https://docs.google.com/spreadsheet/ccc?key=0ApTOJNVUoixhdF9UYWNBTGNWeWRkZG… Thanks, Guy _____________________________________________________________________ ** Guy Roberts, PhD Network Engineering & Planning * * Tel: +44 (0)1223 371300 * * City House Direct: +44 (0)1223 371316 * 126-130 Hills Road Fax: +44 (0)1223 371371 * Cambridge * CB2 1PQ E-mail: guy.roberts(a)dante.net<mailto:guy.roberts@dante.org.uk> D A N T E United Kingdom WWW: http://www.dante.net _____________________________________________________________________

1 0

Issue #36
by John MacAuley 28 Sep '11

28 Sep '11

Peoples, I have updated the text of issue #36 and would like to close the item. All the investigations I have done states that order is not guaranteed, although many of the toolkits do support the implicit ordering in their implementation, the XML specifications do not require it. Please see http://stackoverflow.com/questions/1336345/does-the-sequence-schema-element… John.

1 0

Wednesday's NSI conf call
by Guy Roberts 26 Sep '11

26 Sep '11

Hi All, The following is dial-in information for Wednesday's NSI call, time: 7:00 PDT 10:00 EDT, 15:00 GMT, 16:00 CET, 24:00 JST 1. Dial Toll-Free Number: 866-740-1260 (U.S. & Canada) 2. International participants dial: Toll Number: 303-248-0285 Or International Toll-Free Number: http://www.readytalk.com/intl 3. Enter 7-digit access code 8937606, followed by "#" Agenda: 1. NSI roadmap: agree on a roadmap for new NSI features, draft roadmap here: https://docs.google.com/spreadsheet/ccc?key=0ApTOJNVUoixhdF9UYWNBTGNWeWRkZG… 2. Review open issues, agree resolution and assign work: http://code.google.com/p/ogf-nsi-project/issues/list 3. Preparation for demo at SC11 Guy _____________________________________________________________________ ** Guy Roberts, PhD Network Engineering & Planning * * Tel: +44 (0)1223 371300 * * City House Direct: +44 (0)1223 371316 * 126-130 Hills Road Fax: +44 (0)1223 371371 * Cambridge * CB2 1PQ E-mail: guy.roberts(a)dante.net<mailto:guy.roberts@dante.org.uk> D A N T E United Kingdom WWW: http://www.dante.net _____________________________________________________________________

1 0

code.google project for NSI
by Guy Roberts 26 Sep '11

26 Sep '11

Hi All, As we are now entering a more mature phase of the NSI protocol standardization, I would like to introduce some more formalized processes into the group. First, I would like the group to agree on a roadmap for new features to be introduced in versions v1.0, v1.0 and v2.0, I will summarise the current thinking and send out for discussion on Wednesday's call. Second, based on our discussions at Lyon I have identified the need for an issue tracking system. I have created a code.google project for NSI which has a good issue tracker: http://code.google.com/p/ogf-nsi-project/ The issues identified in Rio, and the subsequent discussions have now been moved here from our Google spread-sheet. Once the group has agreed to make a change, this will be documented in the tracker and the issue will be accepted and assigned to someone to prepare a solution to submit to the group for approval. If you would like to submit new issues, or add comments to issues, you will need to send me your gmail address and I can add you to the project. Regards, Guy _____________________________________________________________________ ** Guy Roberts, PhD Network Engineering & Planning * * Tel: +44 (0)1223 371300 * * City House Direct: +44 (0)1223 371316 * 126-130 Hills Road Fax: +44 (0)1223 371371 * Cambridge * CB2 1PQ E-mail: guy.roberts(a)dante.net<mailto:guy.roberts@dante.org.uk> D A N T E United Kingdom WWW: http://www.dante.net _____________________________________________________________________

1 0

Request for demo participants at FIA in Poznan
by Radek Krzywania 22 Sep '11

22 Sep '11

Hi all, Between 24 and 28 Oct there will be an opportunity to perform a demonstration of collaborating NSI implementations at Future Internet Assembly event held in Poznan. The link to the conference is available here : http://www.week.fi-poznan.eu/online/. The demo will take place in about 4 weeks from now, and will be a good test before a SC event 2 weeks after. The main upgrade from the Rio plugfest is that dataplanes are planned to be involved in reservation process. I would like to kindly request any organisation that has an NSI ready network manager and already has or will have shortly support for dataplane, to volunteer to participate in this demonstration. That will help us to prepare and test a SC demo and also contribute to increase awareness of the NSI among really huge amount of people (there will be about 2000 people). Despite the event is organised mostly by European organisation, non-European partners are more than welcome to participate in the demo. Please let me know if you find it possible for you to join. A detailed demo plan and schedule will be defined next week. Best regards Radek ________________________________________________________________________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and radek.krzywania(a)man.poznan.pl Networking Center +48 61 850 25 26 http://www.man.poznan.pl ________________________________________________________________________

1 0

Post-Rio dessimination of all things NSI
by Henrik Thostrup Jensen 19 Sep '11

19 Sep '11

Hi everyone (long email, get coffee) With the demo in Rio done, it is time to reflect a bit over the current protocol and state before moving. I've collected a list of issues over the last month or so, but have intentionally not communicated them as it was more important to have things ready for Rio. Protocol: The schedule has a start time, end time and duration. - AFAICT we do not need duration. Can anyone explain what we need it for? Is there a rationale for the minimum and maximum bandwidth? (I entered the NSI community a bit late, so humor me). The callback model makes it very non obvious to handle failures. - In general, dealing with network problems has not been thought through. - This becames fairly clear when we had problems establishing connection. There is nothing specified on how to continue from there (i.e., who carries the responsibility for propagating state updates). The TechnologySpecificAttributes does not seem to have any usage, except "future compatability", but are there no examples or use cases for them. - I suggest removal, and then adding specific fields if we need them later. The reservationConfirmed message includes all the reservation details. Is this really necessary? Couldn't it just be a simple acknowledgement. I would consider adding a state to indicate that the connection failed for some reason. The terminated state is a bit broad in what it describes. Having two ways of querying seems like one too many. Remember that both have to implemented. Is there a reason we cannot just have one? The term "NsiExceptionType" seem to have gotten into the spec. It should be called serviceException. The messageId in the serviceException should either have a number of options or not be there. - It should probably be called errorId as well (it doesn't identify a message). - A possiblity could be to adopt the HTTP error codes. The text and variables solution in serviceException seems like overkill. Why not just have the text there? Quite often it is not clear what fields are required in a message and which are not. WSDL: XML Schema has a value "Terminateing" for ConnectionState. xsd:dateTime allows value without a timezone, which is problematic. - I suggest that the protocol dictates that all protocol timestamps should be in zulu time (which is really the only sensible thing to send over a wire IMHO) WSDL specifies a reservation.reservation, which is somewhat unfortunate. I suggestion reservation.reservationInfo connectionId is enforced as a UUID, which is not tune with the protocol spec. which specifies that the connectionId only has to be unique within the requester NSA scope. ServiceException should probably be called "serviceException" to follow the naming convention. I've also compiled a list of issues which have been confusing people. The purpose of this list is simply have a spec which is easy(er) to implement, which IMHO is very important quality of standard (and one we are far from). - The URN prefixes - Requester / provider role fields - replyTo / addressing in general - Distributed development - Reordering of messages from "logical order" - Bad error messages from SOAP/WSDL stacks (and probably other things as well) - XML/WSDL namespaces - Security I have some comments/suggestions as well: The URN prefixes are just prefixes. They do not add any value, and have been a source of confusion. I suggest we remove them. I'm not sure the requester/provider role fields are really necessary. It should be clear from the security context (I'll get back to that), who it is one is communicating with. The replyTo fields seems to me like being a surrogate for dealing with lack of addressing for not having topology done. On the other hand they also make it a lot easier to make clients as a client does not have to exist in the topology to be able to comminicate with an NSA. I suggest we think a bit over how we want this to work, and how we want to support potentially short-lived clients creating connections (because something needs to initiate connection creation). The distributed collaboration with developing NSI agents was initally a bit fuzzy and hindered by some barriers. The skype room improved this a lot by bringing down the latency in developer communication. Reordering of messages from "logical order". I still think the protocol design is a bit clumsy, especially when combined with the lack of how to handle network errors (unavailable hosts, etc.) and short-lived clients. I've been thinking a bit about it, but haven't really come up with any substantial. Some people (me included, if not especially) have struggled quite a bit with their SOAP/WSDL stacks, and the lack of checks and bugs in there. However several people have also been puzzled with the error messages from them .e.g., getting an integer parsing error when an element was simply missing. Somewhat similar, I had an issue where my SOAP stack used the wrong namespace on an element. The issue here was no so much the bug in the SOAP stack (it happens), but that I could not figure out what was right and wrong by looking at the WSDLs. Security. Let me be very clear here. HTTP basic and some SAML attributes have nothing to with security. It did not provide integrity, confidentiality, or assurance. I am also puzzled by the choice of SAML, as SAML is intended for communication between identity providers and services, but there are no identity providers in NSI. Also, I don't think that anyone in this group actually understands SAML (I don't). My suggestion for security is to use TLS with certificates (from a recognized CA) in each end, and nothing more. It is not the most trivial thing in the world (but isn't really difficult either), but it fairly well understood and has widespread support. Lastly, I think the group is suffering heavily from having thought too much and having constructued to little. This has of somewhat changed after Rio, but I fear that we are now so far into the process with writing the standard, that it is difficult to have any big changes done, as people do not want to change what has already been made. The project group also still operates in very ad-hoc fashion. This can work great to a certain extent, but I think that limit has been crossed some time ago. We need to get better organized, but this is not really my area of expertise, so I won't suggest something. I'm on vacation until monday, so take your time replying :-) Best regards, Henrik Henrik Thostrup Jensen <htj at ndgf.org> NORDUnet / Nordic Data Grid Facility.

2 2

Internet2 ION at SC11
by Jason Zurawski 19 Sep '11

19 Sep '11

Greetings; In preparation for SC11 (http://sc11.supercomputing.org/) this year, we would like to gauge expected use of the Internet2 ION Service for demonstrations during the conference. As in years past, we are working to be sure that every institution wishing to use the service has an equal chance to do so. We will be working with users and engineers this year to develop a "schedule" that will allow: - Equal use of the bandwidth on the network between the conference center and end sites - Scheduled times for testing before the show starts, and demonstrations during exhibit hours. - A way to contact someone at Internet2, and SCinet, to help steer any technical problems to the right locations If you end site is planning on using Internet2 ION, please contact Jason Zurawski (zurawski(a)internet2.edu) and provide: - Contact information for demo participants - Expected use of ION, e.g. how much bandwidth will be consumed and where will the demo originate/terminate - How often you would like to run your demo during exhibit hours Please feel free to pass along this note to colleagues who may not be subscribed to these mailing lists. Thanks; -jason

1 0

common types
by Michał Balcerkiewicz 19 Sep '11

19 Sep '11

Hello, Here is what I mean regarding having some common types (Provider interface): For example, let's see how Reservation message looks like (it applies to reservation, provision, release, terminate and query messages): reservation reservationRequestType correlationId replyTo reservation and compare it to provision message: provision provisionRequestType correlationId replyTo provision So my question is, do we need these reservationRequestType and provisionRequestType? Couldn't it look like the following: reservation correlationId replyTo reservation provision correlationId replyTo provision or we could have some common header for correlationId and replyTo fields: reservation commonRequestType (contains correlationId, replyTo) reservation provision commonRequestType (contains correlationId, replyTo) provision Regarding the Requester interface: All confirmation/failed messages (except queryConfirmed, queryFailed and reservationConfirmed) contain correlationId and GenericConfirmedType/GenericFailedType. For example, terminateConfirmedType looks like: terminateConfirmedType correlationId terminateConfirmed (contains GenericConfirmedType) Question is do we need to have terminateConfirmed type here (or in case of terminateFailedType do we need terminateFailed)? Couldn't it look like: terminateConfirmedType correlationId GenericConfirmedType Br michal

1 0