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

NSI plugfest issues and resolution
by Tomohiro Kudoh 19 Sep '11

19 Sep '11

Hi all, Here is a link to the NSI plufest issues: https://docs.google.com/spreadsheet/ccc?key=0As4ZeyIu2P2YdFJJeTZfenNFb2RKM2… Tomohiro

1 0

OGF33 sessions and skype
by Tomohiro Kudoh 19 Sep '11

19 Sep '11

Hi all, NSI sessions at OGF33 is scheduled as follows: http://www.ogf.org/gf/event_schedule/index.php?event_id=20 (the first session will be started in 4 hours 10 minutes.) (If network is available at the venue, and has sufficient quality) I will host a skype (audio only) call. Please let me know your skype id if you would like to join. I will announce to the NSI chat just before the session too. Tomohiro

1 0

NSI Issues list – Rio de Janeiro Demo
by John MacAuley 18 Sep '11

18 Sep '11

Peoples, Here are some of the notes I captured. The reservation XML message contains two element tags both named “reservation”. The first is the reservation operation and the second is the reservation information contents. This will need to be fixed in the types XSD. The “providerNSA” and “requesterNSA” elements in the NSI protocol header caused some confusion. In the CS document we stated that this would be populated with the NSnetwork URN as defined in Salt Lake City. However, when the demo topology schema was created we introduced a new NSA object. Some people used the URN of the NSA object in the “providerNSA” and “requesterNSA” elements. We will need to make a definitive statement as we define the formal NSI topology. Do we rename the elements to “providerNSnetwork” and “requesterNSnetwork” and continue using the NSnetwork URNs, or do we switch over to NSA URN? Demo topology definition was an issue, but in the end we had something workable for the demo. Going forward we need to formalize NSI topology definition and how it relates to other schema such as DTOX and NML. I am going to start working on the topology discovery/exchange problem to get use moving forward. Security presented interoperability issues as some people enforced authentication and authorization while others did not. Some systems could not provide the needed credentials, and resulted in some incompatibility. I believe we are clear on what we want to implement for NSA-to-NSA security, but we need to formalize the session security requirements so we can begin to implement in the NSAs. Namespace issues – this is not an issue with the protocol specification but with a few of the less mature SOAP web services toolkits. They get confused between the interface and type namespaces for the protocol elements due to the use of “ref” to reference protocol operation elements from the types XSD in the interfaces WSDL. Now that we have had some demo experience with error handling, I think it is time to start formalizing values in the NsiExceptionType. I have already identified ten generic error conditions, and I am sure there are many more. As a follow up to this item, NSA implementations need to populate the NsiExceptionType.variables with additional information to help identify the problem that caused the rejection of the message. I had done this in OpenDRAC so any errors returned to other NSA would contain information formatted as follows: <messageId>SVC0001</messageId> <text>Invalid or missing parameter</text> <variables> <Attribute Name="replyTo" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"> <AttributeValue xsi:type="xs:string" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ><null></AttributeValue> </Attribute> </variables> Interface version discovery – I had discussed this with the group previously, but now that we are moving forward, up issuing NSI schema versions, and adding new interfaces we will need a mechanism for discovering the interfaces and versions supported by an NSA. I will propose something formal when I get a chance. John.

4 5

Thanks!
by Jerry Sobieski 16 Sep '11

16 Sep '11

Hi all- The First NSI Connection Service protocol public demonstration ov version 1.0 was a resounding success! Thanks tp you all for your patience and perseverance in driving so hard in such a short time. I received compliments from many folks that were impressed by the quality of the team that was present and sorting through the issues as well as very positive impressions by folks who now understand the NSI concept much better. Its real, finally! Thank you all again. Jerry

6 5

NSI plugfest status google doc
by Tomohiro Kudoh 13 Sep '11

13 Sep '11

Hi all, We have prepared a google doc page to share the status. Please update this page as you perform tests. https://docs.google.com/document/d/1McNO8NP2bXGjgJTk4hsPDARL-NehXEP_I4eNJZE… Tomohiro

1 1

YATU: Rio-Inter-Domain-Topo-Ring-v1.1h.owl
by Jerry Sobieski 12 Sep '11

12 Sep '11

Here is v1.12h (note: I skipped "g" for due to some testing I was doing that used g.) So "h" is the current version. Changes: - Included NSA contact info for DynamicKL (Sorry for losing that.) - Added NSA contact info for OSCARS (Dominica in the plugfest) Jerry

1 1

YATU: Rio-Inter-Domain-Topo-Ring-v1.1h.owl
by Jerry Sobieski 12 Sep '11

12 Sep '11

Here is v1.1h (note: I skipped "g" for due to some testing I was doing that used g.) So "h" is the current version. Changes: - Included NSA contact info for DynamicKL (Sorry for losing that.) - Added NSA contact info for OSCARS (Dominica in the plugfest) Jerry

1 0

YATU: Rio-Inter-Domain-Topo-Ring-v1.1f.owl
by Jerry Sobieski 12 Sep '11

12 Sep '11

Topo version 1.1f Changes: - updated NSA csProviderEndpoint fields for DRAC and GLAMBDA-KDDI - Added STPs Aruba:A5, and Grenada:G5 - Created connectedTo between A5 and G5 Jerry

4 3

Re: [Nsi-wg] Open dynamicKL NSA
by jeonghoon moon 12 Sep '11

12 Sep '11

To Henrik Thostrup Jensen****** ** ** I am very sorry for our inconvenient log file and ambiguous indication about name space problem.**** ** ** We developed our web services with JAX-WS2.0 based Metro engine, which supports WSDL to Java generation tool.**** To confirm the usage of name spaces in NSI messages, we also used AXIS2 and CFX engines to generate two more Java source codes from the WSDL document.** ** All three engines generated the same reservationRequest message which has two name spaces as attributes of the reservationRequest element and does not have prefixes for all children elements(e.g., requesterNSA, providerNSA, …): **** ** ** <ns5:reservationRequest xmlns:ns2="urn:oasis:names:tc:SAML:2.0:assertion"*** * xmlns:ns3="http://www.w3.org/2001/04/xmlenc#"**** xmlns:ns4="http://www.w3.org/2000/09/xmldsig#"**** xmlns:ns5=" http://schemas.ogf.org/nsi/2011/07/connection/interface"**** xmlns:ns6=" http://schemas.ogf.org/nsi/2011/07/connection/types">**** <ns5:correlationId>78729d97-8264-4a4b-ad53-8fec5ad529fb</ns5:correlationId>* *** <ns5:replyTo> http://220.69.240.218:2000/kreonet/ConnectionServiceRequester</ns5:replyTo>* *** <ns6:reservation>**** <requesterNSA>urn:ogf:network:NSnetwork:kreonet</requesterNSA>**** <providerNSA>urn:ogf:network:NSnetwork:dynamicKL</providerNSA>**** <reservation>**** ** ** Our implementation utilizes Metro engine to parse NSI messages.**** For your latest trail with ns2 name space for all children elements of reservation element,**** Metro engine returns null value when our implementation asks it to parse requesterNSA element of your reservationRequest message.**** Syntax error was marked in our log because of null value.**** We also have great difficulty to understand why Metro engine returns null value.**** ** ** When we use AXIS2(Jaxb) to parse your message, it returns an exception with unexpected element cause.**** ** ** To fix out this problem, we are studying unprefixed attribute ( http://www.rpbourret.com/xml/NamespaceMyths.htm#myth4) but we felt deeply our limitation about WSDL and name space knowledge.**** ** ** We sincerely ask someone to give us some comments about this problem.**** ** ** Best regards. **** On Tue, Sep 6, 2011 at 6:09 AM, Henrik Thostrup Jensen <htj(a)ndgf.org> wrote: > Hi > > (sorry for mixing my ndgf and nordunet mail addresses, use htj(a)nordu.netif in doubt, but they end up the same place :-) ). > > > On Mon, 5 Sep 2011, ???(YoungWook Cha) wrote: > > SyntaxError(Cause : ProviderNSA) was not generated by URN problem. >> >> This error was generated by the name space mismatch. >> > > Okay. Do you think it would be possible to add some information to the log. > It is very difficult to understand the errors currently loged. > > > I want to show you a query message from autoBahn that was recently dumped >> by our log system. >> >> You can find out that ns2 and ns6 name spaces are defined as attributes of >> the queryRequest element. >> > > [snip] > > > The following is a reservationRequest message generated by dynamicKL, >> which has two name spaces defined as attributes of the reservationRequest >> element. >> > > [snip] > > > In case of your message, ns1 is defined in the Envelope element. >> >> On the other hand, default name space("http://schemas.ogf.org/** >> nsi/2011/07/connection/types<http://schemas.ogf.org/nsi/2011/07/connection/types>") >> is defined in the reservation element. >> >> Will you check out the usage of name spaces? >> > > I fail to see the problem. This is a slightly odd, but semantically okay > for specifying the default xml namespace for an element and its children. > See http://www.w3.org/TR/xml-**names/#defaulting<http://www.w3.org/TR/xml-names/#defaulting> > > > <SOAP-ENV:Envelope >> xmlns:ns0="http://schemas.ogf.**org/nsi/2011/07/connection/**types<http://schemas.ogf.org/nsi/2011/07/connection/types> >> " >> xmlns:ns1="http://schemas.ogf.**org/nsi/2011/07/connection/**interface<http://schemas.ogf.org/nsi/2011/07/connection/interface> >> " >> xmlns:ns2="http://schemas.**xmlsoap.org/soap/envelope/<http://schemas.xmlsoap.org/soap/envelope/> >> " >> xmlns:xsi="http://www.w3.org/**2001/XMLSchema-instance<http://www.w3.org/2001/XMLSchema-instance> >> " >> xmlns:SOAP-ENV="http://**schemas.xmlsoap.org/soap/**envelope/<http://schemas.xmlsoap.org/soap/envelope/> >> "> >> <SOAP-ENV:Header/> >> <ns2:Body> >> <ns1:reservationRequest> >> <ns1:correlationId>**565619269916347590382575075391** >> 81676754</ns1:correlationId> >> <ns1:replyTo>http://orval.**grid.aau.dk:7080/NSI/services/** >> ConnectionService<http://orval.grid.aau.dk:7080/NSI/services/ConnectionService> >> </ns1:**replyTo> >> <reservation xmlns="http://schemas.ogf.org/** >> nsi/2011/07/connection/types<http://schemas.ogf.org/nsi/2011/07/connection/types> >> "> >> <requesterNSA>urn:ogf:network:**nsa:OpenNSA-testclient</** >> requesterNSA> >> <providerNSA>urn:ogf:network:**nsa:Martinique-DynamicKL</** >> providerNSA> >> <reservation> >> > > I ran the SOAP envelope through an XML parser, and dumped the tree. It > looks like this: > > <ns0:Envelope xmlns:ns0="http://schemas.**xmlsoap.org/soap/envelope/<http://schemas.xmlsoap.org/soap/envelope/>" > xmlns:ns1="http://schemas.ogf.**org/nsi/2011/07/connection/**interface<http://schemas.ogf.org/nsi/2011/07/connection/interface>" > xmlns:ns2="http://schemas.ogf.**org/nsi/2011/07/connection/**types<http://schemas.ogf.org/nsi/2011/07/connection/types> > "> > <ns0:Header /> > <ns0:Body> > <ns1:reservationRequest> > <ns1:correlationId>urn:uuid:**d41e5c6a-d7ff-11e0-ac34-** > 00144f20a8d2</ns1:**correlationId> > > <ns1:replyTo>http://orval.**grid.aau.dk:7080/NSI/services/** > ConnectionService<http://orval.grid.aau.dk:7080/NSI/services/ConnectionService> > </ns1:**replyTo> > <ns2:reservation> > <ns2:requesterNSA>urn:ogf:**network:nsa:OpenNSA-** > testclient</ns2:requesterNSA> > <ns2:providerNSA>urn:ogf:**network:nsa:Aruba-OpenNSA</** > ns2:providerNSA> > <ns2:reservation> > <ns2:globalReservationId>gid-** > 0962</ns2:globalReservationId> > <ns2:description>Test Connection</ns2:description> > <ns2:connectionId>conn-510</**ns2:connectionId> > <ns2:serviceParameters> > <ns2:schedule> > <ns2:startTime>2011-09-05T20:**46:19Z</ns2:startTime> > <ns2:endTime>2011-09-05T20:48:**19Z</ns2:endTime> > </ns2:schedule> > <ns2:bandwidth> > <ns2:desired>1000</ns2:**desired> > </ns2:bandwidth> > </ns2:serviceParameters> > <ns2:path> > <ns2:directionality>**unidirectional</ns2:** > directionality> > <ns2:sourceSTP> > <ns2:stpId>urn:ogf:network:**stp:Aruba:A1</ns2:stpId> > </ns2:sourceSTP> > <ns2:destSTP> > <ns2:stpId>urn:ogf:network:** > stp:Martinique:M3</ns2:stpId> > </ns2:destSTP> > </ns2:path> > </ns2:reservation> > </ns2:reservation> > </ns1:reservationRequest> > </ns0:Body> > </ns0:Envelope> > > This uses more common xmlns declarations, but is sementically identical. I > tried using the above payload instead, but it fails with the same message. > > If I'm doing something wrong, could you point it out clearly, and try to > show how it should look like instead. > > > > Best regards, Henrik > > Henrik Thostrup Jensen <htj at ndgf.org> > NORDUnet / Nordic Data Grid Facility. > -- Jeonghoon Moon Supercomputing Center Dept.of Infrastructure Technology Development KISTI(Korea Institute of Science and Technology Information) Tel : +82-42-869-0578 Fax : +82-42-869-0589 H.P : +82-10-2534-6754 Skype : otello90 MSN : otellomoon(a)hotmail.com "Expect Great Things from God Attempt Great Things for God"

4 11

G-LAMBDA/AIST
by Tomohiro Kudoh 09 Sep '11

09 Sep '11

Hi all, G-LAMBDA/AIST provider is now up and running endpoint http://163.220.30.174:8090/nsi_gl_proxy/services/ConnectionServiceProvider log http://163.220.30.174:8090/logs/nsi_gl_proxy.log

1 0