August 2011 - nml-wg - lists.ogf.org

Interface vs Port
by Jeroen van der Ham 01 Sep '11

01 Sep '11

Hello, A long time ago we have had a discussion on naming, where we finalized on Nodes and Ports. However, due to feedback that I'm getting in projects where semantic network descriptions are now actually being used, I have received requests to change Port to Interface. The problem is that in these projects the network descriptions become part of a larger infrastructure. Having an object named Port there to describe a network connection point is confusing to users who are not network-centric. They think that a Port object would describe something like a TCP/UDP port, instead of a whole network interface. Would it be possible that NML also changes the Port object to Interface, so as to sync up with the schemas that are already in use in GENI, Geysers and NOVI? Jeroen.

6 11

Multiple namespaces
by Freek Dijkstra 31 Aug '11

31 Aug '11

Last week's mail conversation drifted from XML syntax for NML relations to the use of namespaces in NML messages. An important difference in view was identified. Jason assumed that a single NML messages would only contain one namespace. I assumed that a single NML messages would only contain multiple namespaces. While a few example crossed the list, those were very probably not very relevant nor convincing. So I'll explain a bit better how I envision the different namespaces: - core topology concepts (link, node, port, adaptation, ...) - Ethernet-specific topology concepts (VLANs, segment size, ...) - IP-specific topology concepts (IPv4/IPv6 address, routing table, ...) - geography enhancement (geo location) and I potentially see a mix & match with other applications: - path finding, topology aggregation, domain control (NSI, provisioning) - monitoring, performance (NMC) I expected and still expect each of the above to go in a different namespace. The above leads to three scenario's in mind where it may be prudent to mix namespaces in a single message: - core topology with technology specific (Ethernet, IP, ..) namespaces. This is probably the weakest use case, as it is possible to add the core topology concepts to each technology specific namespace (e.g. using chameleon namespaces) - topology namespace with geo namespace - topology namespace with an application-specific namespaces (eg. topology + NSI for path finding, or topology + NMC for monitoring). Regards, Freek

4 19

Session notes for NML
by Freek Dijkstra 29 Aug '11

29 Aug '11

Members of the NML working group joined for two sessions at OGF 32. About 15 participants attended the sessions. Here are some notes; note that they are not complete (Jerry created some additional notes during the 1st session). However, I'll post them here now before I forget... :) At the first session, Jeroen van der Ham went through the RNC schema, explaining and correcting minor issues. The main topic on the table was the XML syntax for describing ordered lists. After some heated discussions, the participants agreed on the following syntax for an example of a link "link_A-to-C" is described as the concatenation of two smaller segments, "link_A-to-B", followed by "link_B-to-C". <nml:link id="urn:ogf:network:example.net:link_A-to-C"> <nmlserialcompound:relation type="serialcompound"> <nml:link idRef="urn:ogf:network:example.net:link_A-to-B"> <nml:relation type="next"> <nml:link idRef="urn:ogf:network:example.net:link_B-to-C" /> </nml:relation> </nml:link> <nml:link idRef="urn:ogf:network:example.net:link_B-to-C"> </nml:link> </nmlserialcompound:relation> </nml:link> A few notes are in place here: * As agreed earlier, the syntax does not rely on the order of the XML elements in the syntax (while most parser retain the order, this is not required by the XML specification.) Indead, the "next" relation is used to explicitly specify the order. * No explicit "first" or "last" element is specified. A "last" element in a list can be found by finding the item without a "next" relation. A "first" item in a list can be found by finding the only item in the list which has no pointer to it. * There can be only one "first" and "last" element in a list; this means that branching (e.g. an item with two "next" items) is not allowed; this should be described with another construct. * This means that * while it was argued that the "next" relation is a syntax construct, while the relations as defined in the NML UML schema are topology constructs, and thus different, the same syntax would be used to describe both relations. * The name of the topological relation in the above example is called "serialcompound" after Figure 10 of G.805 (of Figure 16 of G.800). The name was not great, but the participants were too tired to come up with something better :) * The ordered list on itself is not enclosed in it's own XML tag (like <nml:list>), the elements are direct subelements of the parent <relation> tag. * At the end of the session, the participants had a discussion how to encode the relation type. In the above example, it is listed as '<nmlserialcompound:relation type="serialcompound">' and '<nml:relation type="next">'. While some arguments where laid forward, no definitive conclusion was reached. This topic remains open for discussion>. Finally, I like to thank all contributors to the discussion. It may have taken some time to talk some sense in me, that was due to my stubbornness, not due to the quality of the arguments. Those were in my opinion particularly good. A particular thanks to Jeff, Jason and Jeroen (the 3 J's) is certainly in place. Thanks, Freek

3 7

Conference Call August 25th
by Jeroen van der Ham 24 Aug '11

24 Aug '11

Hello all, After the OGF and holidays I'd like to get the NML calls going again. Let's setup a conference call on August 26th at the usual time and place: UTC 15:00 = 8:00 PDT = EDT 11:00 = 17:00 CEST. Call: +1-734-615-7474 (Please use if you do not pay for Long Distance) or +1-866-411-0013 (toll free US/Canada Only) Enter access code: 0186145 Agenda for the call: - discuss the outcome of the OGF32 - draw up a plan for finishing the NML schema document - plans for OGF33 - Discuss chameleon namespaces, XML syntax.

3 4

XML syntax for NML relations
by Freek Dijkstra 16 Aug '11

16 Aug '11

Hi all, Let me follow up on a technical part of yesterday's discussion. > At the end of the session, we had a discussion on how to encode the > relation name (here: "serialcompound") in XML. E.g. each relation as > a different element, a different attribute, or a different value of a > fixed attribute. So far, the relation type is encoded in the value of a type attribute (e.g. <nml:relation type="serialcompound">). Freek pointed out that this makes it harder to create a meaningfull schema for validation. For example, there is a difference syntax associated with next relations and serialcompound relations. <nml:relation type="serialcompound"> may contain 0 or more children, while <nml:relation type="next"> must contain exactly one child. The RNC schema does provide a means to specify this difference. Jeff confirmed this and pointed out that it is of course still possible to check the syntax using other logic, it is just not possible to create a detailed schema. (Freek pointed out that NMC has the same problem, which is the reason that no non-trivial WSDL was created for perfsonar, and no software used a SOAP library, despite that most NMC messages are embedded in a SOAP envelope). The encoding of the type of relation in a element (e.g. <nml:serialcompound>) allows more meaningful validation. However, this has another drawback: if a client does not know about a particular relation, it does not know if the unknown element is subclass of a relation and can or can not be ignored. In fact, it can not even do basic syntax checking (as if it was just a unknown NML relation), since it does not know it is a NML relation without parsing the schema definition (which will list the new element as a subclass of the base element). So there seem to conflicting requirements: * ability to do extended validation * know from just looking at XML (but not the schema) that something is a NML relation It may be possible to find a solution that caters to both requirements. For example, in NM, subclasses use the same name (a trick known as chameleon namespace in RNC). E.g. A subclass of e.g. http://schema.ogf.org/nm/base/port is also called "port", e.g. http://schema.ogf.org/nm/layer2/port. A similar trick is enforce that all relations must always be defined in the same namespace (which may only contain relations). E.g. everything that starts with http://schema.ogf.org/nml/relation/ is a relation. I think we should discuss this further. I know the above is a difficult technical discussion, so I appreciate that you read so far. Please provide feedback if this was clear, and if you have any opinion or thoughts on this topic. Regards, Freek

3 14

Chameleon namespaces (was: XML syntax for NML relations)
by Freek Dijkstra 16 Aug '11

16 Aug '11

Jason wrote: >> Even though its a special namespace, it can be reduced to the base >> which should make services happy. Freek wondered: > What do you mean with "special" namespace? Wait, you mean a Chameleon namespace? (you referred to http://books.xmlschemata.org/relaxng/relax-CHP-11-SECT-5.html earlier) I explicitly to NOT make that assumption. In fact, I'm very hesitant to use the concept of Chameleon namespaces, given the warning at the end of this page: > Chameleon schemas are very controversial. [...] Chameleon schemas > work contrary to most developers' namespace expectations, and in the > process remove most of the value of using namespaces. For this reason > I would recommend you be very cautious when using them! And this comes from the prime source on the topic... I do like the concept of subclassing, and I think we can (and should) include that (chameleon namespaces are a special case of subclassing). However, without proper consulting with a true XML expert, who thinks Chameleon namespaces is really the best solution to our problem, I am very hesitant to include that concept in NML. Freek

2 1

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

Network laydowns
by Connah Jessica J 04 Aug '11

04 Aug '11

Hi, I am currently working on a project looking at capturing networks in a tool agnostic way so that we can then easily migrate the networks onto different tools. I am interested in the outputs of your working group and what you decided was the best way to tackle this problem. I look forward to hearing from you. Kind regards, Jessica Connah Future Network Systems Information Management Department Tel: +44(0)1980 65 8238 Email: jjconnah(a)mail.dstl.gov.uk Rm 202, Building 5 Dstl Porton Down Salisbury, SP4 0JQ "This e-mail and any attachment(s) is intended for the recipient only. Its unauthorised use, disclosure, storage or copying is not permitted. Communications with Dstl are monitored and/or recorded for system efficiency and other lawful purposes, including business intelligence, business metrics and training. Any views or opinions expressed in this e-mail do not necessarily reflect Dstl policy." "If you are not the intended recipient, please remove it from your system and notify the author of the email and centralenq(a)dstl.gov.uk"

3 2