- Nsi-wg - lists.ogf.org

call today?
by Jerry Sobieski 24 Aug '11

24 Aug '11

Are we on for today? J

2 1

08-20-topology-discussion-nsi-wg Digest, Vol 36, Issue 23
by ???(YoungWook Cha) 24 Aug '11

24 Aug '11

=================================== http://ngn.andong.ac.kr NGN Lab. Comp. Engineering Dept. Andong National University +82-10-2456-3237, +82-54-820-5714 =================================== ----- Original Message ----- From: <nsi-wg-request(a)ogf.org> To: <nsi-wg(a)ogf.org> Sent: Monday, August 22, 2011 9:15 PM Subject: nsi-wg Digest, Vol 36, Issue 23 > Send nsi-wg mailing list submissions to > nsi-wg(a)ogf.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.ogf.org/mailman/listinfo/nsi-wg > or, via email, send a message with subject or body 'help' to > nsi-wg-request(a)ogf.org > > You can reach the person managing the list at > nsi-wg-owner(a)ogf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of nsi-wg digest..." > > > Today's Topics: > > 1. Re: NSI specific topology recommendation for plug fest. > (John MacAuley) > 2. Re: NSI specific topology recommendation for plug fest. > (Jeroen van der Ham) > 3. Re: NSI specific topology recommendation for plug fest. > (Jerry Sobieski) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 22 Aug 2011 00:39:54 -0400 > From: John MacAuley <john.macauley(a)surfnet.nl> > Subject: Re: [Nsi-wg] NSI specific topology recommendation for plug > fest. > To: John MacAuley <john.macauley(a)surfnet.nl> > Cc: NSI WG <nsi-wg(a)ogf.org> > Message-ID: <7769F884-3DA9-412B-8599-1A3B64730CCA(a)surfnet.nl> > Content-Type: text/plain; charset="windows-1252" > > Found a small issue in the example owl. > > > On 2011-08-19, at 10:16 PM, John MacAuley wrote: > >> Peoples, >> >> I think the existing detailed DTOX topology models we have been generating are excellent. I can definitely see how I will be able to incorporate this into future versions of OpenDRAC as a primary topology import mechanism, however, I do not think it is capturing the simplified concepts in NSI that are needed for the demo. >> >> I have been playing around with the example topologies trying to massage them into a form where I can learn not only the network and STP topologies, but the managing NSA topologies as well. I found that the existing DTOX topology is very good at the details of nodes, switch matrixes, and ports, but I had a hard time filtering down to the simple aspects. I also believe we will get into some trouble if we try to use the port class to model STP while also modeling physical ports. I am not sure if the DTOX schema can handle this aspect, as I could not find a describing schema. >> >> I spent time over the last couple of days discussing this with Jerry while we worked through the plug fest scenarios. He provided good feedback and pulled together the attached slide showing the concepts we are trying to capture. I also mocked up an example OWL file with an NSI topology specific name space, and introduced the NSI concepts of NSnetwork, STP, and NSA. These classes are used to model their simplified namesakes from the NSI CS protocol, and are not meant to replace the DTOX definitions, but augment them with our NSI specific concepts. We can consider the NSI topology elements an overlay on the existing DTOX elements, reusing data properties and including references to DTOX object instances. (I removed the DTOX object instances from the file to simplify the example). I think this will become much clearer when running NSI on out real networks and not this abstract topology for the demo. >> >> I have not yet validated the attached OWL so I apologize if it contains errors. The following classes and properties are introduced in the file? >> >> NSnetwork: We model a NSI network with the NSnetwork class. >> >> Example URN: urn:ogf:network:NSnetwork:Aruba >> >> Properties: >> >> ? label - display name for the network. >> ? canSwap - indicates VLAN Id interchange is supported in the network domain. >> ? managedBy - the Network Services Agent managing this network. >> ? hasSTP - a set of references to the inter-domain Service Termination Points that are within this network. >> ? hasPart - a set of references to the DTOX Node NamedIndividual representing network elements within this network. >> >> >> NSA: We model a Network Services Agent with the NSA class. >> >> Example URN: urn:ogf:network:nsa:dracproxy01.surfnet.nl >> >> Properties: >> >> ? label - display name for the NSA. >> ? managing - indicates the network being managed by this NSA. >> ? connectedTo - represents an NSA to which this NSA has a peering relationship. >> ? dnsName - DNS name of the NSA. >> ? csProviderEndpoint - the SOAP endpoint for this NSA's CS provider interface. >> ? adminContact - administrative contact information for this NSA. >> >> STP: We model a logical Service Termination point with the STP class. >> >> Example URN: urn:ogf:network:stp:Aruba:Aiden >> >> Properties: >> >> ? label - display name for this STP. >> ? partOf - indicates the member network of this STP. >> ? connectedTo - a topological link identifying the peer STP to which this STP is connected. >> ? mapsTo - the logical STP represented by this object instance maps through to this physical entity (port, vlan, etx.) in DTOX. >> >> We will need to start up a discussion after the plug fest to address the issue of NSI topology needs. I believe these changes will do until then. Comments? >> >> Thank you, >> John. >> >> >> <nsi-interop-topology-example.owl> >> <NSI topology model.pptx> >> _______________________________________________ >> nsi-wg mailing list >> nsi-wg(a)ogf.org >> http://www.ogf.org/mailman/listinfo/nsi-wg > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20110822/675dbc7c/attachmen… > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: nsi-interop-topology-example.owl > Type: application/octet-stream > Size: 12053 bytes > Desc: not available > Url : http://www.ogf.org/pipermail/nsi-wg/attachments/20110822/675dbc7c/attachmen… > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20110822/675dbc7c/attachmen… > > ------------------------------ > > Message: 2 > Date: Mon, 22 Aug 2011 11:10:26 +0200 > From: Jeroen van der Ham <vdham(a)uva.nl> > Subject: Re: [Nsi-wg] NSI specific topology recommendation for plug > fest. > To: John MacAuley <john.macauley(a)surfnet.nl> > Cc: NSI WG <nsi-wg(a)ogf.org> > Message-ID: <2EDE9B14-3E07-4C19-9BCC-A2EE695B5484(a)uva.nl> > Content-Type: text/plain; charset=iso-8859-1 > > Hello, > > > On 20 Aug 2011, at 04:16, John MacAuley wrote: >> NSnetwork: We model a NSI network with the NSnetwork class. >>=20 >> Example URN: urn:ogf:network:NSnetwork:Aruba >>=20 >> Properties: >>=20 >> =B7 label - display name for the network. >> =B7 canSwap - indicates VLAN Id interchange is supported in the = > network domain. >> =B7 managedBy - the Network Services Agent managing this network. >> =B7 hasSTP - a set of references to the inter-domain Service = > Termination Points that are within this network. >> =B7 hasPart - a set of references to the DTOX Node = > NamedIndividual representing network elements within this network. >>=20 >>=20 >> NSA: We model a Network Services Agent with the NSA class. >>=20 >> Example URN: urn:ogf:network:nsa:dracproxy01.surfnet.nl >>=20 >> Properties: >>=20 >> =B7 label - display name for the NSA. >> =B7 managing - indicates the network being managed by this NSA. >> =B7 connectedTo - represents an NSA to which this NSA has a = > peering relationship. >> =B7 dnsName - DNS name of the NSA. >> =B7 csProviderEndpoint - the SOAP endpoint for this NSA's CS = > provider interface. >> =B7 adminContact - administrative contact information for this = > NSA. >>=20 >> STP: We model a logical Service Termination point with the STP class. >>=20 >> Example URN: urn:ogf:network:stp:Aruba:Aiden >>=20 >> Properties: >>=20 >> =B7 label - display name for this STP. >> =B7 partOf - indicates the member network of this STP. >> =B7 connectedTo - a topological link identifying the peer STP to = > which this STP is connected. >> =B7 mapsTo - the logical STP represented by this object instance = > maps through to this physical entity (port, vlan, etx.) in DTOX. >>=20 >> We will need to start up a discussion after the plug fest to address = > the issue of NSI topology needs. I believe these changes will do until = > then. Comments? >>=20 > > How do you envision labels to be added to the above topology? > > The ontology above maps almost directly to the DTOX schema we created = > before we started considering labels... > > The current test-topologies may not have labels in them, but as things = > look now, they will always be part of the network, and will always be = > something to consider when you are doing pathfinding. > > Jeroen.= > > > ------------------------------ > > Message: 3 > Date: Mon, 22 Aug 2011 08:15:09 -0400 > From: Jerry Sobieski <jerry(a)nordu.net> > Subject: Re: [Nsi-wg] NSI specific topology recommendation for plug > fest. > To: Jeroen van der Ham <vdham(a)uva.nl> > Cc: NSI WG <nsi-wg(a)ogf.org> > Message-ID: <7377BC40-AF8C-4FBD-B5D4-AF87DBDDED3D(a)nordu.net> > Content-Type: text/plain; charset=utf-8 > > Hi jeroen > > The issue is that currently NSI service termination points do not point to u= > nder-specified endpoints such as ports with labels. As it stands today an N= > SI STP would point to a particular label as the termination point for a circ= > uit. To put something other than the terminating point of the circuit in t= > he NSI reservation request implies a certain semantic about what specificall= > y can be found in a request as an Endpoint and how to recognize and process i= > t. We got into this briefly but decided it involved a lot of topology issu= > es we were not able to address or answer at that time - so we shelved it unt= > il we had a chance to discuss a more sophisticated NSI topology model. > > For now, for the plugfest, we can treat Ports as the STP. We will define a= > ll interdomain peering points as untagged ports for the interop plugfest in R= > io. In the Port object we either define a single label, (e.g. "0") or be= > tter, no label at all. This must be coordinated with the peer network so th= > at their corresponding Port object is defined similarly. > > IMO, the NSI working group has not worked out a consensus approach to how we= > expect the protocol to treat "labels"...else it would already be in the sta= > ndard. Strictly speaking, the NSI CS protocol works just fine as is - it j= > ust maps STPs to particular labels. (note: the SNE editor offered no Label= > object.) However, a number of folks are uncomfortable with this and want a= > different treatment. We need to have this discussion, but there are relate= > d issues we need to work through if we want all of these features to integra= > te in a cohesive and fashion. =20 > > Sent from my iPad3g > > On Aug 22, 2011, at 5:10 AM, Jeroen van der Ham <vdham(a)uva.nl> wrote: > >> Hello, >>=20 >>=20 >> On 20 Aug 2011, at 04:16, John MacAuley wrote: >>> forNSnetwork: We model a NSI network with the NSnetwork class. >>>=20 >>> Example URN: urn:ogf:network:NSnetwork:Aruba >>>=20 >>> Properties: >>>=20 >>> =C2=B7 label - display name for the network. >>> =C2=B7 canSwap - indicates VLAN Id interchange is supported in the n= > etwork domain. >>> =C2=B7 managedBy - the Network Services Agent managing this network.= > >>> =C2=B7 hasSTP - a set of references to the inter-domain Service Term= > ination Points that are within this network. >>> =C2=B7 hasPart - a set of references to the DTOX Node NamedIndividua= > l representing network elements within this network. >>>=20 >>>=20 >>> NSA: We model a Network Services Agent with the NSA class. >>>=20 >>> Example URN: urn:ogf:network:nsa:dracproxy01.surfnet.nl >>>=20 >>> Properties: >>>=20 >>> =C2=B7 label - display name for the NSA. >>> =C2=B7 managing - indicates the network being managed by this NSA. >>> =C2=B7 connectedTo - represents an NSA to which this NSA has a peeri= > ng relationship. >>> =C2=B7 dnsName - DNS name of the NSA. >>> =C2=B7 csProviderEndpoint - the SOAP endpoint for this NSA's CS prov= > ider interface. >>> =C2=B7 adminContact - administrative contact information for this NS= > A. >>>=20 >>> STP: We model a logical Service Termination point with the STP class. >>>=20 >>> Example URN: urn:ogf:network:stp:Aruba:Aiden >>>=20 >>> Properties: >>>=20 >>> =C2=B7 label - display name for this STP. >>> =C2=B7 partOf - indicates the member network of this STP. >>> =C2=B7 connectedTo - a topological link identifying the peer STP to w= > hich this STP is connected. >>> =C2=B7 mapsTo - the logical STP represented by this object instance m= > aps through to this physical entity (port, vlan, etx.) in DTOX. >>>=20 >>> We will need to start up a discussion after the plug fest to address the i= > ssue of NSI topology needs. I believe these changes will do until then. Co= > mments? >>>=20 >>=20 >> How do you envision labels to be added to the above topology? >>=20 >> The ontology above maps almost directly to the DTOX schema we created befo= > re we started considering labels... >>=20 >> The current test-topologies may not have labels in them, but as things loo= > k now, they will always be part of the network, and will always be something= > to consider when you are doing pathfinding. >>=20 >> Jeroen. >> _______________________________________________ >> nsi-wg mailing list >> nsi-wg(a)ogf.org >> http://www.ogf.org/mailman/listinfo/nsi-wg > > > > ------------------------------ > > _______________________________________________ > nsi-wg mailing list > nsi-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/nsi-wg > > > End of nsi-wg Digest, Vol 36, Issue 23 > ************************************** > > >

1 0

Testing NSI implementations
by Henrik Thostrup Jensen 23 Aug '11

23 Aug '11

Hi everyone, especially developers :-) If we want to have something working in Rio, we need to start testing. To facilitate this, I've a test instance of OpenNSA. The services can be reached at: http://orval.grid.aau.dk:9080/NSI/services/ConnectionService (Aruba) http://orval.grid.aau.dk:9081/NSI/services/ConnectionService (Bonaire) Where you can try to make reservation and so forth at. It only knows about the Aruba and Bonaire networks, but will invoke services at each other. There are still a lot of stuff missing, most notably error paths, so if you try something odd it might blow, but at least we will learn something :-) The log for the OpenNSA is available here if you want to see what is going on: http://orval.grid.aau.dk:9000/opennsa.log I also have a client that can exercise the whole reserve-provision-release-terminate lifecyles and query if you want me to try and interact with your service. You can send the URL to me directly if you don't want to have it public on the list. Again, we cannot wait to test in Rio if we want something that works there. So please give it a go :-). Best regards, Henrik Henrik Thostrup Jensen <htj at ndgf.org> NORDUnet / Nordic Data Grid Facility.

2 1

Plugfest participants contact information
by Jerry Sobieski 19 Aug '11

19 Aug '11

Hi all- Attached please find the current info I have received to date regarding Rio NSI Interop participants. We have 7 implementations that have asked to be part of this (!). I will keep this doc updated as additional info comes in, so please let me know if information changes. I will try to put this on a wiki next week. The recent addition of a couple new implementations means that we need to modify the previous Plugfest Guide in regard to test matrix. And there are several other tweeks as well to the Challenges in terms of how we run them - the basic functional tests are unchanged, but how we run them will change a bit to make it easier logistically. We want to clarify and simplify the complexity of the test scenarios - particularly in 3 and 4. These tweeks will also include an enhanced topology model/description that will work better for NSI testing (it is a superset of current set of topo resources. And still uses RDF and OWL.) I will have the updated guide available in a day or two. In the meantime, I encourage the teams to proceed with testing Challenge #1. And when you are confident that is working, move on to to Challenge #2 with *any* other teams that have completed #1 as well and are ready to do cross implementation tests. (In challenge #2, the pairing of teams was arbitrary, so feel free to test with any other implementation that is ready.) The contact info below should allow everyone to contact each other. Also, if you are ready to do Challenge #2 with another imlementation, please post that to the list so we can see and monitor progress. Thanks all! Jerry 1. AutoBAHN (GEANT) 1. Implementation Name: "AutoBAHN" 2. Project manager for the development effort: name: Radek Krztwania email:radek.krzywania@man.poznan.pl skype: Radoslaw.krzywania 3. Key software engineer: name: Michal Balcerkiewicz email:michalb@man.poznan.pl skype="michalb.psnc" 4. Indicate which individuals will be in Rio in person to participate in the Plugfest = Radek Krzywania 5. Status - We are almost ready for testing with other NSI implementations. We are finalising topology reading from OWL file, we are unsure how "Query" will behave at the end. For Challenges 1-3 we are mostly prepared. We still implement interfaces to see logs and event, but that mostly formal thing just to display logs with some filters. 2. DynamicKL (KISTI) 1. Implementation Name: dynamicKL 2. Project manager for the development effort. name: Jonguk Kong email: kju(a)kisti.re.kr <http://kju@kisti.re.kr/+82-10-3444-7418/jonguk> phone: +82-10-3444-7418 <http://kju@kisti.re.kr/+82-10-3444-7418/jonguk> skype: jonguk <http://kju@kisti.re.kr/+82-10-3444-7418/jonguk> 3. Key software engineer name/email/mobile/skype. name: Youngwook Cha email: ywcha(a)andong.ac.kr <mailto:ywcha@andong.ac.kr> phone: +82-10-2456-3237 skype: ngnlab414 name: Jeonghoon Moon email: otello90(a)gmail.com <mailto:otello90@gmail.com> phone: +82-10-2534-67564 skype: otello90 4. Indicate which individuals will be in Rio in person to participate in the Plugfest. Jeonghoon Moon 5. Status - Please provide a brief status of your implementation. Challenge 1 : almost provide (RA <--> PA in self) Challenge 2 : almost provide (inter-domain RA <--> PA) Challenge 3 : providing (alternative path) Challenge 4 : almost acceptable query request dynamicKL(NRM) is our own solution since 2008, now we developing of interface between dynamicKL and NSI CS protocol for interoperability according to NSI CS protocol document, there is no problem to adapt NSI protocol to dynamicKL. And our develop plan is announce version 1.0 at the end of 4th week Aug. (maybe 26th Aug) 3. DRAC (SURFnet) 1. Implementation name: OpenDRAC 2. Proj Manager: name: John MacAuley email: john.macauley(a)surfnet.nl phone: +1-613-220-6817 skype: john.macauley 3. Software Developer name: John MacAuley email: john.macauley(a)surfnet.nl phone: +1-613-220-6817 skype: john.macauley 4. Rio attendees: John MacAuley 5. Status: 4. G-Lambda/AIST (AIST) 1. Implementation Name: G-lambda/AIST 2. Project manager for the development effort. name/email/mobile/skype. name: Tomohiro kudoh email:t.kudoh@aist.go.jp mobile: +81-90-8741-3165 skype: t.kudoh 3. Key software engineer name/email/mobile/skype. name: Atsuko Takefusa email:nsi-gl@m.aist.go.jp mobile: +81-29-861-3091 skype: taketake320 4. Indicate which individuals will be in Rio in person to participate in the Plugfest. Tomohiro Kudoh& Hidemoto Nakada 5. Status Implementation has been started. Coding of dummy NSI provider/requester (which do not make actual reservation) is almost done. 5. G-Lambda/KDDILabs (KDDI Labs) 1. Implementation Name: G-lambda/KDDILabs 2. Project manager for the development effort. name/email/mobile/skype. name: Takahiro Miyamoto email: tk-miyamoto(a)kddilabs.jp mobile: +81-90-1966-5153 skype: takahiro.miyamoto 3. Key software engineer name/email/mobile/skype. name: Takahiro Miyamoto email: tk-miyamoto(a)kddilabs.jp mobile: +81-90-1966-5153 skype: takahiro.miyamoto 4. Indicate which individuals will be in Rio in person to participate in the Plugfest. Takahiro Miyamoto 5. Status Not started yet. 6. OpenNSA (NORDUnet) 1. Implementation name: OpenNSA 2. Project manager: name: Jerry Sobieski email: jerry(a)nordu.net mobile: +1-301-346-1849 skype: jerry.sobieski 3. Software developer: name: Henrik Thostrup-Jensen email: htj(a)nordu.net skype: henrik.thostrup.jensen 4. Rio attendees: Jerry Sobieski 5. Status: Basic message and lifecycle working, web service MTL in progress. 7. OSCARS (ESnet) 1. Implementation name: OSCARS 2. Project Manager/contact: name: Inder Monga email: imonga(a)es.net 3. Software development engineer: name: Evangelos Chaniotakis email: haniotak(a)es.net 4. Rio Attendees: 5. Status:

1 0

no NSI call today
by Guy Roberts 17 Aug '11

17 Aug '11

There will not be an NSI call today. 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

WSDL update
by John MacAuley 16 Aug '11

16 Aug '11

Peoples, Please find attached the latest revision of the WSDL and XSD files. There were a large number of changes incorporated based on the feedback from OGF 32, so please take some time to have a look through. The WSDL compiles, but I have not programatically verified the changes. Please let me know if I have missed or broken anything. John. Version 0.07 Changes to NSI WSDL specification Date: July 29, 2011 Author: John MacAuley Notes: These are changes requested at OGF 32 working group meeting. 1. Created a QueryFailedType to provide a specific type without revervation specific information. 2. Renamed transactionId to correlationId and added the correlationId to the SOAP output response (acknowledgement). 3. Changed globalReservationId to be xsd:anyURI and mandatory but permit it to be nillable. This will allow an OGF URN (reference artifact 6478 "Procedure for Registration of Sub-namespace Identifiers in the URN:OGF Hierarchy") to be used for compatibility with other external systems. 4. Restructured confirmed and failed parameters. 5. Renamed GenericResponseType to GenericAcknowledgmentType. 6. Renamed all WSDL output "Response" messages to "Acknowledgment". 7. Fixed type issue with ProvisionFailedRequestType. 8. Removed the versioning information from WSDL port type names and bindings. 9. Removed connectionState from generic confirmed and reservation confirmed message since the state should be implied. 10. NSA identifiers are now defined as xsd:anyURI to hold an OGF URN. 11. STP definition is now changed to be a xsd:anyURI to hold an OGF URN (urn:ogf:network:stp:<NSnetworkid>:<localid>). 12. Removed the query option in QueryFilterType for search based on connection state. 13. Renamed PathObjectType to PathType. 14. Removed NetworkIdType, LocalIdType, and ServiceTerminationPointGroup since no longer needed. 15. Renamed orderedStpList to stpList as requested since "List" implies "Ordered." 16. Modified the XSD definitions to do local imports and copied the needed external XSD locally to package with NSI definitions. 17. Lined up naming of operations in XSD with specification and associated types to help avoid type name conflicts (ReservationRequestType and QueryRequestType). 18. Simplified the interface portType definitions by defining a single acknowledgment message type for output. 19. Moved directionality of the service into the path object since this is an attribute of the path. 20. Moved path object out of service parameters to allow for different path definitions between the reservation request and the reservation response/query results. 21. Added DetailedReservationInfoType and DetailedPathType to allow for connection tree to be return in the reservation response and query response. This is the groundwork for implementation to provide more detailed connection information and recursive queries (future release). 22. Segmented service bindings into requestor and provider messages sets to help with code modularity and provided proper endpoint definition for RA and PA. This required restructuring of the interface file as well, and moving of the portType definitions into the service bindings. The NSI requestor SOAP endpoint "ConnectionServiceRequestor" contains definitions for: reservationConfirmed reservationFailed provisionConfirmed provisionFailed releaseConfirmed releaseFailed terminateConfirmed terminateFailed query queryConfirmed queryFailed forcedEnd The NSI provider SOAP endpoint "ConnectionServiceProvider" contains definitions for: reservation provision release terminate query queryConfirmed queryFailed Open Issues for after GLIF bake-off in Rio: 1. Need to add the security policies to the WSDL so we can sign the messages to validate authenticity. This will not impact the core schema but will impact the WSDL definitions. 2. Per conenction reservation user/security information in a query response. ---------------

3 4

Constructing STP from topology data.
by John MacAuley 16 Aug '11

16 Aug '11

Jeroen, Jerry, Can someone show me an example of how we will be mapping the abstracted topology provided for the interoperability tests. Sorry if this was already discussed, but I can seem to remember the thread. My guess would be that we are treating GOLE objects as networks and Port objects as the local part? I would therefore have the following STP address: urn:ogf:network:stp:Aruba.Loc:Aiden Do I have this correct? Thanks, John.

3 3

CFP: The Network-aware Data Management Workshop (NDM 2011) to be held in conjunction with SC 2011
by Inder Monga 12 Aug '11

12 Aug '11

Sharing an interesting CFP for a workshop to be held during SC2011, please feel free to share with your colleagues. Sorry if you receive duplicate requests. Inder ----------------------------------------------------------------------------------------------------- CFP: The Network-aware Data Management Workshop (NDM 2011) to be held in conjunction with SC 2011 Mon Nov 14th, 2011 - Seattle, WA (8:30am - 5:00pm) The Network-aware Data Management Workshop (NDM 2011) will be held in conjunction with the IEEE/ACM International Conference for High Performance Computing, Networking, Storage and Analysis (SC 2011), in Seattle, WA. The format will consist of 30 minute presentations of peer-reviewed papers. Accepted papers will be published in ACM or IEEE digital proceedings through SC'11. Scope: Accessing and managing large amounts of data is a great challenge in a collaborative environment where resources/scientists are geographically distributed. There is a need for efficient use of the network infrastructure in order to address the increasing data and compute requirements of large-scale applications. Since the amount of data is continuously growing, traditional techniques of leaving the burden on the user of moving/storing data is not a viable option in many cases. In order to deliver true exascale performance to the application layer, network-aware data management services for resource provisioning, intelligent data-flow and coordination between the host systems is highly desirable. This workshop will seek contribution from academia, government, and industry to discuss emerging trends in use of networking for data management, novel abstraction techniques for data representation, simplification of end-to-end data flow by providing transparent data services, end-to-end resource coordination, and network-aware tools for the scientific community. One "Best Paper" would be awarded for outstanding contributing to the field of large-scale data management across network. In addition to that, two "Best Paper Honorable Mention" would be awarded. Important Dates: Abstract Submission: Aug 22nd, 2011 Paper Submission due: Aug 29th, 2011 Notification of acceptance: Sept 26th, 2011 Camera-Ready version due: Oct 10th, 2011 Registration Deadline: Oct 14th, 2011 Workshop Date: Nov 14th, 2011 Workshop Web Site: http://sites.google.com/a/lbl.gov/ndm2011/ Workshop Organizers: Mehmet Balman, Lawrence Berkeley National Laboratory Surendra Byna, Lawrence Berkeley National Laboratory Topics of interest include but are not limited to: Challenges in data-intensive distributed computing End-to-end resource provisioning Optimization and development of data transfer protocols Scalable services for network-aware applications Re-configurable end-to-end data-access frameworks Network-aware scheduling and resource brokering Advanced services for managing data-flow On-demand bandwidth allocation and network reservation Application pipelines and workflow management Network-aware toolkits for data distribution Data replication and metadata management Data clouds, data scheduling, and data placement Heterogeneous resource management Performance evaluation of network-aware data management Invited Keynote Speaker: Ian Foster, University of Chicago & Argonne National Laboratory Title: TBA Submission Guidelines: Please submit full papers in PDF format via the submission site ( https://www.easychair.org/conferences/?conf=ndm20110 ). Reviewing of the full papers will be done by the program committee, assisted by external referees. Accepted papers would be given a total of 30 mins. for presentation and question time. If you have any further questions, please email Mehmet Balman and/or Suren Byna {mbalman,sbyna} at lbl.gov ------------------------------------------------------------------------------------

1 0

NSI CS WSDL and state machine v1.0 are available now for plugfest
by Guy Roberts 10 Aug '11

10 Aug '11

The WSDL and state machine for version 1.0 of the NSI Connection Service have now been frozen for the NSI plugfest. These can be found here: http://forge.gridforum.org/sf/docman/do/listDocuments/projects.nsi-wg/docma… Please be aware that this version is subject to errata if any show-stopper issues are found during development; these changes will be kept to a minimum to avoid disruption to prototype development. Happy coding and I look forward to a great plugfest in Rio! 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

GLIF Rio Plugfest Guide
by Jerry Sobieski 10 Aug '11

10 Aug '11

Hi all- Attached please find the GLIF 2011 Rio NSI Plugfest Guide v1.0. THis is fairly detailed, but it is meant to be very clear and even handed about NSI interoperability. This document includes four technical interop Challenges. Also attached please find the RDF (.OWL) files for the topologies that I use in the Challenges. You should be able to just upload these into the SNE editor to view them. These files describe a single self-contained inter-domain topology for the associated Challenge(s). The "Deuce" topology is for Challenge 1 and 2, the "Quad" topology is for Challenges 3 and 4. Please review and offer any comments or suggestions. These are drafts - I expect some [hopefully] minor adjustments to these over the next couple weeks. But I hope this is essentially on the right track to guide the implementations towards a successful interop in Rio. Thanks Jerry

2 2