- Nsi-wg - lists.ogf.org

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

Minor corrections to the topofile. version 1.1e
by Jerry Sobieski 09 Sep '11

09 Sep '11

Hi all- Here is the Global Topo version 1.1e Changes in 1.1e: - Added URN prefix to the connectedTo relations in Grenada:G4 and Jamaica:J1 - Corrected spelling in admin contact info for Curacao (AutoBAHN) I still need csProviderEndpoint information from GLAMBDA-KDDI-L, and from OSCARS. Thanks all. Jerry

3 2

NSI plugfest conf call Friday
by Guy Roberts 08 Sep '11

08 Sep '11

Hi all, I would like to hold a last-minute NSI plugfest conf call to make sure that everyone is clear on where we are and what is the latest decisions and versions of documents. It is also an opportunity for coders to raise any questions/concerns you have. The following is dial-in information for Friday'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

Rio-Inter-Domain-Topo-v1.1d.owl
by Jerry Sobieski 08 Sep '11

08 Sep '11

Hi all- Here is topo version 1.1d Changes: - I reverted the naming to reflect the spec: urn:ogf:network:NSnetwork:<NSnetworkid> urn:ogf:network:stp:<NSnetworkid>:<localid> - I use urn:ogf:network:nsa:<NSA-name> to name the NSA objects. Note: I cannot find any notes that document a decision to separate NSnetwork and NSAid. So this object and its naming and use are AFAIK completely ad hoc. - I removed some relations that were specific to just on network (Bonaire). These were John's for DRAC, and were probably harmless, but I want to have a base topology that is the same for all implementations - no matter which network we may assign them to. - There is a "managing" relation now linking from NSA object to the NSnetwork object it manages. - I removed the mapsTo relations where they were specified - again to create a common base topology. Let me know if any mistakes or if we need any additional mods or enhancements. Jerry

3 3

NSI WG call Wed Sep 7, 2011
by Jerry Sobieski 08 Sep '11

08 Sep '11

Attendees- Jerry Sobieski (NORDUnet) Tomohiro Kudoh (AIST) Henrik Thostrup Jensen (NORDUnet) Jeroen van der Ham (UvA) Redek Krzywania (PSNC) Michal Balcerkiewicz (PSNC) John MacAuley (SURFnet) *_Demo presentation at Venue_* - We have 5 monitors and desks in the demo space at the art museum. We have a 90 minute formal demonstration presentation window Tuesday from 3:45pm to 5:15pm. The rest of the time we expect to have access to the demo room for continued testing. ***AI: Jerry: Confirm with RNP that the room will be available Wed and Thu after the window as well as leading up to the demonstration window. - The implementation teams are asked to continue interop testing and to capture log files as they run the Plugfest Challenge tests. These log files can be annotated to show the protocol messaging. And these annotated logs can be presented at the venue in the demo room in addition to the live runs, and/or as part of a short PPT from each implementation team. - We want to make sure we have as many live runs prepared for the demo window as is practical. But we do not expect all the Challenges to be ready or to be presented live. The anotated logs can be used to complement the live runs. We can allocate monitors as appropriate for the tests scenarios. _*NSA Implementation Status*_ I hope I summarized this close enough... - OpenNSA (NORDUnet - Henrik) - mostly all functional, self interoperable (Chal #1 works) - encountering many interoperability issues within the MTL (WS* related issues) - some testing with dynamicKL, but encountered some SOAP issues not sure how to resolve. - Need some input from JM. - AutoBAHN - FUnctional, have had some issue in an office move(?) - Expect to begin interop testing very soon - Need updated topology - No WS issues experienced with dynKL - G-LAMBDA (AIST) - Almost ready for interop test... - some testing with G-LAMBDA KDDI Labs - authentication is an outstanding issue - DRAC - John is coding like a mad man. *** Decided: For Rio, we will not require session authentication between NSAs. HTTP only. For SC we *will require* conformant authentication, HTTPS. *** For Rio, service authorization will be basic user based authorization. The user will be "jrv(a)internet2.edu". Case in-sensitive. This string my be authorized by the NSA however they wish, but all requests as part of the Plugfest will use this user credential. If the user is present, any/all service requests will be authorized. If not present, or any other user is present, service requests will be denied. *_Topology_* The current topology is the Rio Ring of 7 networks. Version 1.1c is latest. However, JM has proposed a modified topology to include "partOf" relations for STPs to indicate the NSnetwork object they belong to, and "managing" relation for NSA object to indicate which NSnetwork object they are responsible for. This version also uses full URN specification to name NSnetowork objects and STP objects. ***AI: Jerry: JS will review the topo file asap and if no other issue are obvious, it will be circulated as topo version 1.1d. On 9/7/11 10:38 AM, Tomohiro Kudoh wrote: > This is a resending of test message: > > Since the OGF NSI-WG mailing list is down, I made a temporary mailing > list. Addresses on the Jerry's contact list are registered as well as > Guy and Jeroen. > > Tomohiro >

4 8

demos in Rio
by Jerry Sobieski 08 Sep '11

08 Sep '11

Hi all- Looking closer at the schedule...it seems that we will have almost no time to present the NSI Plugfest effort in advance of the demo window on Tuesday. We will have time on Wednesday to present about the demo and related efforts in a session on the Automated GOLE project and the NSI deployment. So we can describe the demo here, and perhaps use this as an opportunity to touch on the major lessons learned from the demo. And of course we'll have monitors we can use to present some background in the demo space also. So keep a list of issues that we have had to deal with and forward that to me at your convenience. Thanks jerry

2 1

Tips on Topology
by Jerry Sobieski 08 Sep '11

08 Sep '11

A few notes on the topology distribution and importing process: First/****>>>*/You need to send me your csProviderEndpoint for your NSA and I will insert it into the NSA object for your network in the global topo file. This way everyone will get it. For Rio, I am being very constraining on topology. This is necessary to make sure every NSA sees the same topology, and so that where necessary we can easily assign any NSA to any of the test networks, and so we can minimize incidental changes that don't address Rio. So please bear with me on this for Rio. Each implementation will need to define their internal topology. I do not need to see that. And it need not be in rdf/owl...(It is possible to do so if you choose.) You need to define the "mapsTo" relations for STPs 1 and 4 in your respective network. I do not need to see this either as this is really intra-domain information. This mapsTo relation identifies the physical port in your internal topology that corresponds to the NSI STP. It should use a form that is recognized by your internal NRM and provides all the information the NRM will need to use that port in the provisioning process. You are welcome to modify or amend the topo file as you see fit. But you are not allowed change the fundamental model it describes. I will maintain a base global topology file. If there are features you think will be required or desired by all networks, please let me know. Thanks to all for your patience as we slog though these topology issues. Jerry

1 0

Final Extension - 15 Sept. - CFP: NetCloud2011 - Workshop Network Infrastructure Services as part of Cloud Computing, in conjunction with CloudCom2011 - November 20 - December 1, 2011, Athens, Greece
by Yuri Demchenko 08 Sep '11

08 Sep '11

FYI: The deadline is extended until September 15. You are welcome to submit a paper. This might be especially interesting for European researchers. This is a chance to attend the premier Cloud conference for Europe that features a number of invited speakers and presentations from European Commission on the current FP7 Call 8. Regards, Yuri ------------------------------------- CALL FOR PAPERS Network Infrastructure Services as part of Cloud Computing (NetCloud2011) In conjunction with the 3rd IEEE International Conference on Cloud Computing Technology and Science (CloudCom2011) November 20 - December 1, 2011, Athens, Greece Introduction The Cloud computing emerges as a new computing paradigm which aims to provide secure and reliable, on demand QoS guaranteed computing environments for the end-users. Cloud computing services usage in both academia and industry, changed the way of thinking on how users¡¦ needs can be satisfied by computational infrastructures. However, with the increase of data transferred among different places, it became critical how to support distributed computing resources with advanced network infrastructure services. It is envisioned that network infrastructure services provisioned on-demand could be managed and reconfigured dynamically by Cloud operators and user applications to achieve optimal usage criteria. Such dynamic infrastructures reveal new aspects in network virtualization, service delivery automation and general infrastructure resources management that should be supported by well-defined information models and related middleware. New components of the required network infrastructure for Cloud services and applications should create an integrated self-management environment that can react to changes in workloads and other events with minimal human interference. Security issues should addressed as a part of the general service delivery framework/workflow and support both infrastructure provisioning process and secure virtualised services/infrastructures operation. The workshop will discuss issues of optical network virtualisation to create internal distributed datacenter network infrastructure and provide dedicated inter-cloud network connectivity on-demand. Objective NetCloud, collocated with IEEE CloudCom 2011, attempts to address the problem of how the underlying network infrastructure is capable of supporting advanced cloud computing cases. The workshop is intended to bring together network research community, commercial network operators and industry with the major cloud computing players, including IT specialists, researchers and commercial providers. Topics of Interest The workshop includes, but is not limited to the following topics: * Dynamic infrastructure services for Clouds * Heterogeneous network architectures and frameworks for distributed and high performance computing * Information modeling for combined network and IT resources infrastructure services * New services provisioning/delivery models for multi-provider business environment * Network virtualization technologies * Virtual networking and network services in Clouds * Network infrastructure provisioning and management as a part of cloud computing workflows * Network interfaces for clouds * Performance and reliability issues * Service Level Agreement and QoS guarantees in the network layer * Dynamically provisioned security infrastructures (integration with provider and customer legacy services and service provisioning workflow, security policy definition, security context management) * End-to-end techniques for autonomic management of cloud resources * Policy based infrastructure services management * Experimental platforms that support network management in Cloud computing * Experimentation testbeds and measurements studies Call for papers: Papers describing original research on both theoretical and practical aspects of dynamic network services for cloud computing are solicited. Important Dates: EXTENDED: Paper Submissions: September 15, 2011 Authors' Notification: September 25, 2011 Camera-ready paper submission: October 1, 2011 Paper submission instructions: Submission website: https://www.easychair.org/account/signin.cgi?conf=netcloud2011 This workshop will only accept for review original papers that have not been previously published. Papers should be formatted based on the IEEE Transactions journals and conferences style; maximum allowed camera-ready paper length is six (6) pages. Submissions must be in Adobe PDF format, including text, figures and references. Accepted papers will be published in the CloudCom2011 proceedings, for further information see IEEE CloudCom2011 web page http://2011.cloudcom.org/. Review procedure All submitted paper will be reviewed by international Technical Program Committee. Workshop Organizers Mary Grammatikou, National Technical University of Athens, Greece (mary (at) netmode.ntua.gr) Bartosz Belter, Poznan Supercomputing and Networking Center, Poland (bartosz.belter (at) man.poznan.pl) Technical Program Committee 1. Ilias Baldine (RENCI, US) 2. John Baras (Maryland, US) 3. Thomas Michael Bohnert (SAP, Switzerland) 4. Graca Carvalho (Cisco, The Netherlands) 5. Nicola Ciulli (Nextworks, Italy) 6. Pasquale Donadio (Alcatel-Lucent Italy, Italy) 7. Yuri Demchenko (UvA, Netherlands) 8. Joan Antoni Garcia Espin (i2CAT, Spain) 9. Athanasios Liakopoulos (GRnet, Greece) 10. Diego R. Lopez (RedIRIS, Spain) 11. Norbert Meyer (PSNC, Poland) 12. David O'Callaghan (TCD, Ireland) 13. Max Ott (NICTA, Australia) 14. Symeon Papavassiliou (NTUA, Greece) 15. Anna Tzanakaki (AIT, Greece) 16. Pascale Vicat-Blanc (Lyatiss, France)

1 0