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

OpenDRAC topology example
by John MacAuley 06 Sep '11

06 Sep '11

Peoples, I modified the example topology to show the urn:ogf names for elements to help clarify. These are the formats that should be in the messaging. John.

1 0

test message to nsi-wg mailing list
by replogle＠www.ogf.org 06 Sep '11

06 Sep '11

This is a test to see if the nsi-wg mailing list is working again. Thanks, Joel

1 0

minutes from Wednesday's NSI call
by Guy Roberts 06 Sep '11

06 Sep '11

Now that Gridforge is back up, I have posted the minutes from this week's NSI conf call here: http://forge.gridforum.org/sf/go/doc16321?nav=1 _____________________________________________________________________ ** 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 _____________________________________________________________________

2 1

Tomorrow's NSI conf call
by Guy Roberts 06 Sep '11

06 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: NSI Plugfest preparation 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

Test email - please ignore
by Jerry Sobieski 06 Sep '11

06 Sep '11

Foo.

1 0

Rio Inter-Domain Topo Ring v1.1a
by Jerry Sobieski 06 Sep '11

06 Sep '11

Here is an update on the inter-domain topology OWL file (the Rio Ring). ---> I deleted the intra-domain Ports. ---> Corrected a mispelled object name. ---> Added the csProviderContact URL to the NSA object for Aruba (OpenNSA), Bonaire (OpenDRAC), and Curacao (AutoBAHN.) Others- please forward me a contact place for your NSA. ---> Added Admin contact info to the NSA adminContact field. Note- the SNE graphical display only shows a single link between objects for connectTo, and mapsTo relations...The RDF is actually correct in showing relations both directions, but the editor somehow combines them to a single line. This topology now contains only NSnetwork objects, STP objects, and NSA objects. Each implementation will need to edit this topology file to map their STPs to the corresponding internal ports. The mapping is done by inserting the string representing the internal port into the "mapsTo" field of the corresponding STP. A reverse relation should be provided mapping the internal port to the STP. Each NSA/network must do this for every STP in their assigned network. Each network is free to define an internal topology as is most convenient for them. The only requirement on internal topology is that the STPs defined in the inter-domain topology must map to internal ports with the following characteristics: a) 1000 megabits/second max capacity, and b) untagged. If your internal topology is static, you can send me your updated OWL file and I will integrate the mapsTo fields into my global topology file and then subsequent topology updates will have your mappings already included... Tip: The DToX ontology used for the Rio NSI Topology still supports the Node, Port, and several other topology objects. These can be used by the respective networks to define internal topology that is compatible with the inter-domain topology if they so choose. If you need *ANY* help with this at all, explainations, advice, questions, etc... PLEASE!!! Let me know! We are up against the wall now...simple is better...If I can simplify things for you I am glad to do so. Best regards! Jerry

4 7

Topology version 1.1c
by Jerry Sobieski 06 Sep '11

06 Sep '11

Hi all- Last week someone noticed that the names of the networks and STPs in the RDF/OWL files did not conform to the URNs described in the NSI CS spec. So in exploring this issue, I believe we have a conflict in the URNs. And since I do not want to distract any further from the development, I am specifying a Rio topology database that avoids the issue completely. We can discuss it in Rio after the demo:-) So to avoid a long discussion prior to Rio, I am circulating a new topology file. This file describes the Rio Ring as before but with the following changes: 1. The "http://glif.is/.../detox#" prefix has been removed from the all Resource names and references. 2. The names are NOT the URN form; they are just the simple strings that identify the object. The issues I found confusing are: - First, the NSI spec defines an STP to have a network identifier and an endpoint identifier of the form: urn:ogf:network:STP:<networkname>:<endpointname> ...an attempt to capture the NSI tuple notion we've been using for NSI. A similar URN exists to specify network names: urn:ogf:network:NSnetwork:<networkname> If we substitute the network URN as the <networkname> in the STP URN we get a rather unusual URN result: Example: urn:ogf:network:STP:urn:ogf:network;NSnetwork:Aruba:Aiden This funky URN is at least one interpretation of the spec. I don't think this is what was intended. The confusion comes from the <networkname> portion of the STP URN - is this *really* a "network" name? ...Or just another namespace qualifier that insures the unique scoping for the <endpointname> component? If it really is a network name, then you get the funky URN. If it is just meant to add additonal namespace scoping, then *any* tag could be used in the <networkname> component - i.e. it does not have to be a network name at all. Which is fine...except that the STP URN would no longer uniquely identify an STP, it would just be a unique endpointname that could belong to *any* network. I believe there is the assumption that the STP URN contains a valid network name that can be used to locate the NSA associated with that STP. IMO, this is a problem in the spec and is pretty fundamental to the protocol. - Second, the NSI CS spec governs what should be in the CS protocol messages, not what should be in a topology database. So we don't strictly need to have the URNs in the topologyDB as there is no topology model or standardized database structure that requires it. Therefore, as long as we know how to map a NSI-CS URN to the name of the desired object in the topoDB, or vice versa- construct a URL from the object name in the topoDB, we should be fine - at least for Rio. - Third, what is "best" for the topologyDB depends a lot on how the various NSAs intend to use or represent that topology. And its not clear to me how the various NSAs are using the STP and NSobject URNs. Example: the endpoint "A1" in network "Aruba". The namedindividual object for the STP A1 is now called just "A1"...not "http://glif.is/working-groups/tech/detox#A1", nor is it called "urn:ogf:network:STP:Aruba:A1" Likewise, the NSnetwork topo object is called "Aruba", not "http://glif.is/working-groups/tech/detox#Aruba", nor is it called "urn:ogf:network:NSnetwork:Aruba" Note: the resource /types/ were not modified. These still use the glif.is/...dtox prefix. (I wasn't sure if changing these would break the RDF) For Rio, I have insured that all objects will have unique short names ala A1, B2, M3, etc. across the global topology. Therefore, you can locate the STPs associated with a Network by: "Aruba hasSTP ?" and vice versa find the NSnetwork associated with an STP by "? hasSTP A1" Again, this is an expediency for Rio and will be an issue we need to discuss for future topo database. I know some will object to this (someone *always* objects)...but this is sufficient for Rio and will allow us to put the focus back on NSI - not the cobbled together hacked up topology database. As always, what we do in the name of Rio should not be considered anything but a temporary/interim approach to be reviewed afterward and done better. Questions? Let me know. Thanks Jerry

1 0

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

06 Sep '11

To Henrik Thostrup Jensen SyntaxError(Cause : ProviderNSA) was not generated by URN problem. This error was generated by the name space mismatch. 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. <?xml version = "1.0" ?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <ns2:queryRequest xmlns:ns2=" http://schemas.ogf.org/nsi/2011/07/connection/interface" xmlns:ns3="http://www.w3.org/2001/04/xmlenc#" xmlns:ns4="http://www.w3.org/2000/09/xmldsig#" xmlns:ns5="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns6=" http://schemas.ogf.org/nsi/2011/07/connection/types"> <ns2:correlationId>9fa0a8ce-7d20-482a-8088-349d73c29d24</ns2:correlationId> <ns2:replyTo>http://hemp.man.poznan.pl:9080/nsi/ConnectionRequesterPort </ns2:replyTo> <ns6:query> <requesterNSA>urn:ogf:network:NSnetwork:Curacao</requesterNSA> <providerNSA>urn:ogf:network:NSnetwork:Bonaire</providerNSA> <operation>Summary</operation> <queryFilter /> </ns6:query> </ns2:queryRequest> </soap:Body> </soap:Envelope> The following is a reservationRequest message generated by dynamicKL, which has two name spaces defined as attributes of the reservationRequest element. <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> 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") is defined in the reservation element. Will you check out the usage of name spaces? <SOAP-ENV:Envelope xmlns:ns0="http://schemas.ogf.org/nsi/2011/07/connection/types" xmlns:ns1="http://schemas.ogf.org/nsi/2011/07/connection/interface" xmlns:ns2="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Header/> <ns2:Body> <ns1:reservationRequest> <ns1:correlationId>56561926991634759038257507539181676754</ns1:correlationId> <ns1:replyTo> http://orval.grid.aau.dk:7080/NSI/services/ConnectionService</ns1:replyTo> <reservation xmlns=" 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> Best regards, YoungWook Cha =================================== http://ngn.andong.ac.kr NGN Lab. Comp. Engineering Dept. Andong National University +82-10-2456-3237, +82-54-820-5714 =================================== ----- Original Message ----- From: "Henrik Thostrup Jensen" <htj(a)ndgf.org> To: "jeonghoon moon" <otello90(a)gmail.com> Cc: "Jerry Sobieski" <jerry(a)nordu.net>; "NSI Working Group" <nsi-wg(a)ogf.org>; "JongUk Kong" <jonguk.kong(a)gmail.com>; "???(YoungWook Cha)" < ywcha(a)andong.ac.kr>; "John MacAuley" <john.macauley(a)surfnet.nl> Sent: Monday, September 05, 2011 9:29 PM Subject: Re: [Nsi-wg] Open dynamicKL NSA > Hi again, sorry for the spamming :-) > > (cc'ing John, as he is the expert and the nsi-wg mailing list appears not > to be working currently). > > On Mon, 5 Sep 2011, Henrik Thostrup Jensen wrote: > >> This changes the error in the dynamicKL log to concern the providerNSA, most >> likely because I don't use the URN scheme (next on the todays todo list). > > I've updated my implementation to use the urn scheme, but I still get a > ProviderNSA syntax error from the log (unfortunately there isn't any more > information available). > > Here is the SOAP envelope: > > <SOAP-ENV:Envelope > xmlns:ns0="http://schemas.ogf.org/nsi/2011/07/connection/types" > xmlns:ns1="http://schemas.ogf.org/nsi/2011/07/connection/interface" > xmlns:ns2="http://schemas.xmlsoap.org/soap/envelope/" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> > <SOAP-ENV:Header/> > <ns2:Body> > <ns1:reservationRequest> > <ns1:correlationId>56561926991634759038257507539181676754</ns1:correlationId> > <ns1:replyTo> http://orval.grid.aau.dk:7080/NSI/services/ConnectionService</ns1:replyTo> > <reservation xmlns=" 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> > <globalReservationId>gid-7087</globalReservationId> > <description>Test Connection</description> > <connectionId>conn-199</connectionId> > <serviceParameters> > <schedule> > <startTime>2011-09-05T12:13:20Z</startTime> > <endTime>2011-09-05T12:15:20Z</endTime> > </schedule> > [snip] > (I still need to fix the correlationId) > > According to the schema, the type for NSAs is xsd:anyURI. I think > "urn:ogf:network:nsa:Martinique-DynamicKL" should be a valid URI, but > perhaps I am overlooking something. > > > 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"

1 0

Open dynamicKL NSA
by jeonghoon moon 05 Sep '11

05 Sep '11

HI PlugFest Developers,**** We have just finished the first version of NSI web services. (dynamicKL in KISTI)** Our implementation supports reservation, provision, release, termination, and query messages.**** It can be reached at:**** http://220.69.219.228:8010/nsi/ConnectionServiceProvider**** ** ** We adopted the following URNs for NSA and STPs:**** - NSA: urn:ogf:network:NSnetwork:Martinique**** - STP1: urn:ogf:network:NSnetwork:Martinique:M1**** - STP4: urn:ogf:network:NSnetwork:Martinique:M4**** The log for our web services is available here:**** http://220.69.219.228:8080/dynamicKLInfo/dynamicKL.log**** ** ** Could you try to connect to our web services? **** ** ** Best regards. -- 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 8

Rio Inter-Domain Topo Ring 1.1b
by Jerry Sobieski 01 Sep '11

01 Sep '11

Hi all- John found a bug in the topofile. Attached is the corrected topology v1.1b. - Corrected STP A3 to be: Aruba hasSTP A3 (instead of the reverse.) The other STPs look ok. - added contact URL for G-LAMBDA AIST. Jerry

1 0