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

Example section (nml-base)
by Roman Łapacz 24 Aug '12

24 Aug '12

Hi, attached a draft of Example section (for now it's MS Word document). I tried to make it as simple and clear as possible. Structures are not to heavy and names are very general. Waiting for comments thanks, Roman

4 10

CFP: NetCloud2012 (FINAL EXTENSION: Abstracts 24 August; Papers 30 August 2012) - The 2nd workshop on Network Infrastructure Services as part of Cloud Computing (3-6 December 2012, Taipei, Taiwan)
by Yuri Demchenko 24 Aug '12

24 Aug '12

Apologies for cross-posting. Dear Colleagues, The NetCloud2102 Organising Committee decided to extend paper submission deadline till 30 August 2012 but Abstracts submission deadline remain 24 August 2012. Please consider this opportunity to submit the paper to the workshop and have a chance to attend top Cloud conference CloudCom2012. The main conference CloudCom2012 has attracted a huge amount of submissions and is poised to be the main cloud related event in the region. Best Regards, Organisers Yuri Demchenko Bartosz Belter ----------- CFP NetCloud2012 -------------- The 2nd workshop on Network Infrastructure Services as part of Cloud Computing (NetCloud 2012) http://www.geysers.eu/index.php/newsandevents/49-events/139-netcloud2012-wo… In conjunction with the 4th IEEE International Conference on Cloud Computing Technology and Science (CloudCom2012) http://2012.cloudcom.org 3-6 December 2012, Taipei, Taiwan Paper submission website https://www.easychair.org/conferences/?conf=netcloud2012 Introduction The workshop is a follow-up of the first successful workshop in 2011, where a number of enthusiasts of cloud computing and future networking exchanged ideas and presented results of research projects dealing with clouds and network integration. 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 virtualisation, 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 address issues of network virtualisation to create an ecosystem for cloud computing applications. In particular, the workshop will discuss the progress of development of advanced tools and mechanisms for seamless and efficient integration of network and IT worlds, not well interconnected so far. The workshop will consist of a number of sessions, where recent results of on-going and just-finished research projects will be demonstrated. The workshop will present also some future research considerations on the future of cloud computing and networking and expose views from different perspectives: research projects and industry. The workshop will be followed by a panel discussion, to allow free exchange of thoughts and ideas between the workshop speakers and audience. Objectives NetCloud 2012, collocated with IEEE CloudCom 2012, 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 * Definition and architectures for the Network as a Service (NaaS) cloud service model and Cloud Carrier operational model * Heterogeneous network architectures and frameworks for distributed and high performance computing * Cloud and Intercloud architecture frameworks and required on-demand network infrastructure provisioning * Unified and converged IT and optical resources description languages and frameworks for cloud oriented infrastructures * General Infrastructure services provisioning in clouds, new architecture developments, service delivery and on-demand provisioning frameworks * Isolation and flexibility of the cloud oriented virtualised optical networks * Network infrastructure optimization for intra- and inter- datacenter communication and resources virtualisation * Standardization of optical network service provisioning interfaces for cloud based platforms and services * Co-advertisement, co-planning, composition and co-provisioning of any type of optical network resource and IT services (i.e. connectivity + IT resources at the end-points coordinated in a single, optimal procedure) * Performance and reliability issues, Service Level Agreement and QoS guarantees in the network layer * Dynamically provisioned security infrastructure and its 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 test-beds and measurement 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: Abstract Submissions: August 24, 2012 (Final EXTENSION) Paper Submissions: August 30, 2012 (Final EXTENSION) Notification: September 7, 2012 Camera-ready: September 28, 2012 NetCloud2012 workshop (during CloudCom2012): 3-6 December2012 Paper submission instructions 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 CloudCom2012 proceedings, for further information see IEEE CloudCom2012 web page http://2012.cloudcom.org/. Paper submission website https://www.easychair.org/conferences/?conf=netcloud2012 Review procedure All submitted paper will be reviewed by international program committee. Workshop Organizers The workshop is organized by the partners of the GEYSERS, the EC-funded FP7 project. Bartosz Belter, Poznan Supercomputing and Networking Center, Poland bartosz.belter (at) man.poznan.pl Yuri Demchenko, University of Amsterdam, The Netherlands, y.demchenko (at) uva.nl Technical Program Committee (tentative list) 1. Ilias Baldine (RENCI, US) 2. John Baras (Maryland, US) 3. Thomas Michael Bohnert (ZTH, Switzerland) 4. Luis Miguel Contreras (TID, Spain) 5. Graca Carvalho (Cisco, The Netherlands) 6. Nicola Ciulli (Nextworks, Italy) 7. Pasquale Donadio (Alcatel-Lucent Italy, Italy) 8. Joan Antoni Garcia Espin (i2CAT, Spain) 9. Jeroen van der Ham (UvA, Netherlands) 10. Max Ott (NICTA, Australia) 11. Anna Tzanakaki (AIT, Greece)

1 0

Dealing with unknown relations
by Freek Dijkstra 21 Aug '12

21 Aug '12

I like NML to be extensible. For example, if some NML publisher likes to add information that benefits monitoring or provisioning, that should be possible. A NML receiver should silently ignore this added information. However, we also don't want a receiver to just accept anything. If there is some obvious error in the NML, the receiver should still just reply with an error message. Imagine a receiver that receives some NML line containing a relation. 1. The relation is well-defined. e.g. Node N --hasService--> SwitchingService S 2. The relation is unknown e.g. Node N --hasDynamicService--> SwitchingService S 3. The relation is clearly invalid e.g. Node N --hasService--> Node Y 4. The relation is known, but the meaning is undefined e.g. Port P --hasService--> LabelService L Should we make a distinction between 3 and 4? For the purpose of extensibility, I would argue that it is useful to make this distinction. In fact, the current document makes this distinction. To quote the text on "hasService": > hasService relates a Network Object to a Service. This schema only > defines the meaning of: > • Port to AdaptationService, relating one server-layer Port to an > adaptation function > • Port to DeadaptationService, relating one server-layer Port to a > deadaptation function > • Node or Topology to SwitchingService, describing a switching > capability of that Node or Topology. So in this case "Port P --hasService--> LabelService L" would be syntactical VALID NML but with UNDEFINED meaning. "Node N --hasService--> Node Y" would simply be syntactically INVALID NML. Regardless if we think this distinction is useful, we should define how a NML receiver should handle the information. I can think of four situation what it should do with it: a) reject the line and reply with an error message b) accept the line and process it (for an known relation) c) silently drop the line d) store the line, even though it is unknown I'm not sure if (d) is ever a good idea. It means that a receiver will accept a Topology from T, and store all, including unknown statements, and if asked by someone else, it would faithfully replicate the original topology, including all unknown statements. My proposal is to: 1. The relation is well-defined. Requirement b: The receiver SHOULD accept and process the NML. 2. The relation is unknown Requirement c/d: The receiver MAY either silently drop or MAY accept the statement. 3. The relation is clearly invalid Requirement a: The receiver MUST NOT accept the NML, and SHOULD inform the sender of the error. 4. The relation is known, but the meaning is undefined Requirement c/d: The receiver MAY either silently drop or MAY accept the statement. (so I'd say that while we should distinguish between 3 and 4, in that situation 4 is processed the same as situation 2). Freek

3 3

hasPort/hasLink vs providesPort/providesLink
by Freek Dijkstra 21 Aug '12

21 Aug '12

Roman's mail reminded me on the following relation terms. hasTopology/hasNode/implementedBy related Topologies and Nodes: Topology X --hasTopology--> Topology Y Topology Y --hasNode--> Node Z Node Z --implementedBy--> Node W Question 1: implementedBy seems a bit off here, relating a subset to a larger part (while hasTopology and hasNode relate a larger part to a subset). Is that OK? (Personal opinion: I have never seem an example that used implementedBy, so I consider it somewhat experimental and thus don't really care) hasPort and hasLink relate Groups with its elements: PortGroup G --hasPort--> Port P1 PortGroup G --hasPort--> Port P2 PortGroup G --hasPort--> Port P3 LinkGroup L --hasLink--> Port L1 LinkGroup L --hasLink--> Port L2 LinkGroup L --hasLink--> Port L3 providesPort and providesLink relate Service to it's dynamic configuration: SwitchingService S --providesLink--> Link crossconnect1 SwitchingService S --providesLink--> Link crossconnect2 SwitchingService S --providesLink--> Link crossconnect3 AdaptationService A --providesPort--> Port vlan1 AdaptationService A --providesPort--> Port vlan2 AdaptationService A --providesPort--> Port vlan3 Question 2: are the names "hasPort" and "hasLink" well-chosen? (An alternative would be containsPort and containsLink). (Personal opinion: I think they're OK: they behave similar to hasToplogy and hasNode) Question 3: Are providesLink and providesPort well-chosen? Could we reduce the number of relations by just using hasLink and hasPort instead? (I have no personal opinion on this issue) Freek

2 1

Deviating from GFD.84
by Freek Dijkstra 20 Aug '12

20 Aug '12

Hello Richard, I'm writing to you as OGF Area Director, cc authors of GFD.84, The NML working group is defining a UML schema for network topology descriptions with a syntax in both XML and RDF/OWL. We like to use the same URI for both the XML and RDF namespaces, but found that XML and RDF use namespaces in a different way. To make the NML namespace valid for both RDF and XML, we like to deviate from GFD.84, which defines the syntax of OGF namespaces. In particular, we are thinking of ending the namespace with a hash (#) or slash (/), as required by RDF. Secondly, we are considering using "base" for the part name of the base schema, instead of repeating the project name. So instead of using http://schemas.ogf.org/nml/2012/10/nml http://schemas.ogf.org/nml/2012/10/ethernet We like to use either: http://schemas.ogf.org/nml/2012/10/base# http://schemas.ogf.org/nml/2012/10/ethernet# or http://schemas.ogf.org/nml/2012/10/base/ http://schemas.ogf.org/nml/2012/10/ethernet/ Do you have any objections to these namespaces, and do you have any advise on the choice for hash or slash variant? Note that it is not possible to publish both the XML and RDF/OWL schema at the specified URI, but we plan to put a HTML document at the specified URI with (RDDL and human readable) pointers to both schemata. FYI, these are the most important differences between XML and RDF namespaces: - Namespaces in XML are used for scoping, in XML the element name and namespace are separate parts in identifying a single thing. - Namespaces in RDF are used like prefixing, the element name and namespace are concatenated to form a single identifying URI. - It is *best practice* to not end XML namespaces in "/" or "#", but it is perfectly valid to do so, and many standards do. - It is *best practice* to end an RDF namespace in "#", but it is perfectly valid to use something else, some standards also use "/". Regards, Freek Dijkstra

2 1

id and name in Location
by Freek Dijkstra 16 Aug '12

16 Aug '12

I'll take https://forge.ogf.org/sf/go/artf6573 to the list. In recent examples, it is common to add an "id" attribute and "name" to a Location object. These attributes are not formally defined: the "name" and "id" are defined in the schema as attributes of a Network Object, but Location is not (a subclass of) a Network Object. There are a few solutions: 1. Artifact artf6573 proposed to solve this by making Location a subclass of Network Object, but this proposal was opposed by a few group members. 2. Define "id" and "name" in two places in the schema: both as attributes of Network Object, and attributes of Location. 3. Allow "id" and "name" as attribute and subelement for any XML element and as predicates of any RDF Resource. 4. (non-solution) Don't allow "id" and "name" for Locations. I have a preference for #3. I'm sure this can be done in RDF. Can someone confirm this is possible in XML (RNC/XSD)? Also would this be allowed in a UML schema? (and if this can't be done in UML, do we care? -- I personally don't because I see no implementation issue.) Freek

4 5

NML conf call Thu Aug 9
by Freek Dijkstra 16 Aug '12

16 Aug '12

Hi all, We have a call today at the usual time and place: Thursday Aug 9 UTC 15:00 - CEST 17:00 - Eastern 11:00 - Pacific 8:00 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: - OGF36 sessions & attendance - Document status - List of open artifacts (my next mail will be an overview) Freek

1 2

Overview of artefacts & last call
by Freek Dijkstra 08 Aug '12

08 Aug '12

Hi all, Jeroen has made some passes on the document lately, and there have been some discussion on and off the mailing list. To keep track of issues, the list of NML artefacts has been updated: https://forge.ogf.org/sf/tracker/do/listArtifacts/projects.nml-wg/tracker.t… About 24 new artefacts have been added in the last month, and some closed. To make progress, I took the liberty to put some issues into "Last call". I will list them here. Note that I also put some into "last call" because I want them to close, and don't think there will be many comments. If you feel I was overzealous, please let me know off-list or on-list. With that, here is the list I hope you can have a look. Some of you may have already commented on-list: artf6562: Labelsgroup described as string artf6577: layer and label encoding terminology artf6573: Make Location a subclass of Network Object artf6535: Namespace of Relations artf6552: Ordered list artf6563: NML Relation formal definition artf6537: hasTopology implicitly defined? artf6584: Properties of a Location [NEW] artf6568: Properties of Ports and Links artf6567: Removal of Domain and Network artf6542: VLAN description Propose to reject: artf6554: Allowing inverse relations artf6490: Define physical Port/Interface Furthermore, the following artefacts are important, and have a clear proposal. It would certainly be useful if you can have a look: artf6495: Define Label syntax artf6569: PortGroup and LinkGroup artf6581: Experimental features artf6582: Unnamed NML objects artf6585: nml:parameter artf6580: Relate Node/Topology to a Link artf6578: existsDuring relation artf6536: Service Syntax in XML and RDF There are more artefacts, but this is the list I like to go through this (long) list in the coming conference calls and see if we can close them. For those with little time, I tried to put all important info in the description, so you don't have to read the whole discussion if you don't have the time. Thanks for your effort in reading them. It is appreciated. Regards, Freek (PS: and yes, artefacts is proper British spelling ;) )

1 0