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

Presentations from NSI meeting at HK
by Guy Roberts 17 Mar '11

17 Mar '11

Gridforge has been out of action for a few days, this is now fixed, so I have posted the presentations from the Hong Kong NSI meeting here: http://forge.gridforum.org/sf/docman/do/listDocuments/projects.nsi-wg/docma… 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

NSI endpoint references
by Jerry Sobieski 17 Mar '11

17 Mar '11

Hi folks- We need to still decide on an NSI endpoint reference scheme. This is essentially a means to uniquely identify end points within the *NSI* context. I think it is very important that we not confuse the "NSI endpoint reference" with the topology information that the NSAs may internally associate with an end point, or that other non-NSI functions may require. The NSI topology model only specifies "networks" and "edge/end points". And where an end endpoint in one network coincides with an end point in another network, NSI topology captures this peering connection relationship too. But this is /_all_/ NSI has regarding topology(!) This is the NSI "context". As far as I can see, all we really need within the NSI-CS specification is a "network identifier" : "endpoint identifier" tuple to uniquely identify an NSI-CS termination point. These NSI references are only relevant within the NSI context. I.e. Any mapping of NSI endpoint references to NRM resources is NRM specific and therefore (IMO) out of scope for the NSI standard (i.e. put another way: it is the NRM's responsibility to perform that mapping.) Further, I believe such mapping is only a local issue, so we should not promote other information beyond that local scope by allowing (or requiring) other information in the NSI endpoint reference itself. We should keep the NSI endpoint reference abstracted above any specific local or physical information. If physical topological information is important to the NSI, then we have a much bigger problem. And if an NSA requires such information, it should ask the owner/leaf NSA who presumably knows how to get that information from the NRM. The attached GLIF Global ID recommendation provides a good coverage of names in this respect. It defines a global identifier thusly: <GID> := <domain part> ":" <local part>. I think this is close to what JohnM was referring to on the call this week(?) Since this does provide the two basic components that NSI requires, (a "network" name and a "local part" for endpoint name) I think this will be a good and minimally sufficient way to specify NSI-CS termination points in version 1.0. The GLIF recommendation also allows for URN extensions. However, I would not include these as part of the NSI specification unless a) it maintains the network::endpoint tuple of NSI, and b) we can specify exactly what that URN should be and why it is necessary for NSI to function properly. At this time, I believe a simple name like "nordu.net:CPH-AMS-10GE" or "NetherLight:pSonar" is sufficient for v1.0. i.e. references without a urn: prefix. If someone thinks we need a URN specification for version 1.0, please pipe up and provide the reasoning - there may be such, I just am unaware of one in my mind at this moment. (But please don't tell me its needed for web services-WS is not why we created NSI:-). Adding a URN prefix qualifies the namespace - why does/should NSI need a qualified namespace for endpoint references? If you think we do, or even if you think it is just a good idea, please explain how this reconciles with the NSI architecture - i.e. how the URN version maps the <network><endpoint> tuple, and how it improves the basic GID mentioned above? Remember, we are only speaking to _/NSI/_ endpoint references,... I think as long as the basic <domain name><local part> tuple is maintained in an endpoint reference (in conformance with the NSI architecture), and the syntactic parsing is clear, then we do actually have a good bit of flexibility in the strings themselves. Thoughts? Jerry PS: With respect to how the NSI to NRM mapping takes place for each respective NRM, I think this should be described in the NRM implementation guide, not the NSI specification. NSI is NRM agnostic. While this does imply some translation function is required at the NSA, it keeps naming consistent across the entire NSI universe. (And I assert that the mapping is only meaningful locally anyway.)

8 38

NSI Connection Services WSDL
by John MacAuley 17 Mar '11

17 Mar '11

Peoples, I promised to get a draft of this out today so here it is. I checked to make sure it compiles, but not much beyond that. I have been adding documentation annotations to the files, but have not completed it yet. There is probably enough in there now for people to understand how it is laid out. I also auto-generated a PDF for the XSD types if you would rather look at that. I made many types up for lack of specification. We can discuss. John.

1 1

today's call
by Guy Roberts 16 Mar '11

16 Mar '11

Hi all, The following is dial-in information for today's NSI call, time: 7:00 PDT 10:00 EDT, 14:00 GMT, 15:00 CET, 23: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: Updating the Connection Service Architecture document for presentation at OGF31. 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 _____________________________________________________________________

3 2

NSI v1.0 Service Definitions (v1)
by Jerry Sobieski 16 Mar '11

16 Mar '11

Attached find the inital rough draft text for the service definitions...be forewarned the technical specifics of the XML details is still being worked out... Jerry

1 0

The NSA type and securityAttr elements.
by John MacAuley 14 Mar '11

14 Mar '11

Peoples, Based on the section "1.1 NSI message common attributes" of the Connection Services Architecture document I created the following common parameters structure in XML. I dropped the NSIversion since the WSDL name space will identify the version, and I also dropped the ServiceType since the WSDL service endpoint definition will cover this value. My question is with respect to the securityAttr element against each of the requesterNSA and providerNSA elements. What exactly will be contained in the securityAttr elements? Should this instead be against the entire message? I would like to understand the usefulness of these elements before committing them to the protocol specification.  <xsd:complexType name="CommonParametersType"> <xsd:sequence>  <xsd:element name="requesterNSA" type="tns:NsaType" />  <xsd:element name="providerNSA" type="tns:NsaType" />  <xsd:element name="transactionID" type="xsd:string" /> </xsd:sequence> </xsd:complexType> <xsd:complexType name="NsaType"> <xsd:sequence> <xsd:element name="nsaAddress" type="xsd:anyURI"/> <xsd:element name="securityAttr" type="tns:AttributeSequenceType"/> </xsd:sequence> </xsd:complexType> Thank you, John.

1 1

Minutes for today's NSI call
by Guy Roberts 10 Mar '11

10 Mar '11

... are available here: http://forge.gridforum.org/sf/go/doc16212?nav=1 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

Specification Completion - suggestions
by Inder Monga 09 Mar '11

09 Mar '11

Open Issues and plan for spec completion Deliverable for March 30th completed WSDL(s) for NSI-WG Web Services Framework What WS Standards are needed Prefer WS-Addressing for async bi-directional communication Security Message Primitives Attribute details completed connection services architecture doc 2. Completed WSDL(s) for NSI-WG Message Primitives Message attributes 3. Open Issues before spec complete Message Primitives Agreed upon behavior for Request, Provision, Release Finalize Cancel Confirm? Query (Management message) Notify (for Asynchronous PA -> RA notification) Modify (not in this spec, to be discussed after this version of spec is done?) STP definition and architecture - Should we do STP later? For demo specification Requestor will specify complete end-point The aggregator will know what to do Service Definition Basic List of attributes Questions * Is Service Definition a template or not? * Do we support optional network specific features? --- Inder Monga imonga(a)es.net

1 0

today's NSI call
by Guy Roberts 09 Mar '11

09 Mar '11

Hi all, The following is dial-in information for today'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: Updating the Connection Service Architecture document for presentation at OGF31. 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