W dniu 2012-02-22 10:52, Freek Dijkstra pisze:
Hi all,
I've tried to NML-ify the AutoGOLE topology. I did in RDF/XML because that is probably readable by both OWL and XML folks.
Below are the steps I took in detail, along with intermediate results (which may help in understanding the differences).
The main changes are: - made ports and link unidirectional, per NML specs. - use explicit link object to describe the SDP (NML has no connectedTo concept) - change the urn:ogf:network identifiers to a valid syntax, the ones currently in AutoGOLE use are not valid according to proposed standard nor previous use in either GLIF or perfSONAR community.
The file AutoGOLE-Topo-2012-02-22.rdf gives the result so far.
Notes:
1. The resulting topology file has three layers: - NML topology - dtox NSNetwork - dtox NSA I really like the clear distinction between the data plane (NML) and control plane (dtox/NSI). However, I wonder if we should move this to two layers, perhaps merging dtox:NSNetwork and nml:topology.
I'm not sure of this distinction if nml:bidirectionalport is STP (I have a problem with this: dtox:hasSTP in dtox:NSNetwork points at nml:bidirectionalport; moving from dtox to nml domain does not look right to me in this case). All elements in the example belong to NSI abstraction (links are SDPs, ports STPs; except VCard part). To me distinction is between NSI topology (represented by STP, SDP, NSNetwork, NSA) and internal domain topology which is hidden under mapTo relation. Yes. But first things first. This was/is a good exercise as we see
Hi Roman e al- In general, I think the NMLification of the NSI topology is quite good. I do not mind the unidirectional aspects myself as I believe these are necessary for NSI (ultimately) anyway. And as presented in Freek's example seem to be perfectly consistent with the current NSI model. (FYI- I have asked that unidirectional connections be a topic for NSI V2.0. The vcard issue is not on the critical path for NSI, so I am not too worried about that. Freek's suggestions seem fine to me. There is some concern about using the "port" term itself as it is just so overloaded that it creates confusion. But that said, I think the logical nature of the NML "port" construct as it represents STPs is consistent with NSI semantics. I think the bidirectional nature of NSI STPs will relax soon as well to be unidirectional STPs. STPs identify specific locations where a connection can be terminated (or originated). And really, a unidirectional flow of data is the atomic element of a "connection" and is in fact how actual switching fabrics are actually constructed, so this fits best (IMO). Binding arbitrary switch fabric input and output interfaces into a single "transmit/receive Port" on a box is purely an engineering practice (indeed - many optical equipment explicitly separate the transmit and receive paths to be configured independently by the transport engineers..) Bi-directional Connections are [should be IMO] a compositional service feature. (see comments further down.) There is no innate requirement that a "NSI Connection" be bi-directional. Nor is it required that the forward and reverse components be congruent or symmetric. Thus, I believe the basic coin of the realm should be a unidirectional topological construct as well. I understand why Freek translated STPs to be the bidirectional ports - this is how the current NSI topology uses them. But I would concur that what we really want is a unidirectional concept of a domain edge interface (STP or port) that identifies uniquely the termini for service instances with an "orientation" - in or out relative to the domain. some other comments below... On 2/22/12 9:19 AM, Roman Łapacz wrote: that the NSI topology can indeed be represented semantically in the NML format. This is a great first step. Now, as you suggest, there is this issue of "resolution" - the ability to define internal topology in finer resolution - still as NSI concepts or as NRM technology specific constructs. IMO, we should be able to recursively define more internal detailed NSI constructs until the domain is ready to map the NSI constructs to the tuple that the internal NRM will recognize. It is not strictly required that the "mapsTo" relation point to physical or technology specific information. The mapsTo could map to a more detailed NSI topology internal to a domain (think of a "federation" NSI domains). I do believe at some level the mapsTo should reference a topological object or tuple that is physical or a string that the local NRM can interpret to indicate where the NSI Connection should be terminated. Topo X1. Perhaps a next exercise would be to stipulate a simple exemplar network with a single physical switch. Lets take NetherLight domain as example. The expressed NSI/NML Topology should be such that we can ascribe a simple any-to-any switching function to NetherLight...from any ingress STP to any egress STP. Topo X2a & X2b. The next topology would be to enhance TopoX1 with the specification of an ethernet switch as Netherlight switching core. For X2a, assume the switch can do VLAN re-write and so the any-to-any switching capability is maintained. For X2b, assume the ethernet switch is a crufty old conventional switch that cannot swap VLAN IDs and so the any-to-any switching function is reduced to ingress port/STP(i) can switch to output port/STP(j) iff i=j. TopoX3. In this topo, provide an example we switch to NorthernLight. Show how NorthernLight could present a single NSI domain but has NSI "sub-domains" in NYC and CPH. (This is likely a real scenario...) Assume the switching functions are any-to-any for all ports/STPs. Consider the naming scope carefully.
btw. I'm still thinking that we don't need nml:bidirectionalport in NML :) We could use port with "bidirectional" relation.
I agree. What is a "bidirectional port"? It is really two ports bound together for purposes of ... what? Indeed - Freek bound NSI STPs together as bidirectional ports...you didn't have any information that said these ports were even on the same switch or of the same technology! (:-) Be careful about what your assumptions are. NSI STPs deliberately hide technology specifics - don't be fooled by the STP names:-) There were no MapsTo relations that pointed to physical descriptions, so you all made some assumptions that were not necessarily valid. A true "bidirectional port" would be a port on which data is sent in both directions simultaneously...which is in fact possible in the photonic realm. So perhaps the "bidirectional port" grouping needs some further consideration? Also... simply calling an in and out port a "bidirectional port" does not prevent those unidirectional components from linking to completely different far ends... Jerry
Roman
2. The dtox:hasSTP relation now points to a nml:bidirectionalport. NML defines a similar "hasPort" relation between a nml:Topology and nml:Port. (and there is some discussion to differentiate between hasOutboundPort and hasInboundPort). If dtox:NSNetwork and nml:topology are merged, I recommend to use these relations. 3. Yet unclear how exactly to tie Ethernet specifics to the examples, it seems prudent to use labels and the subnetwork concept as discussed in the NML-WG in Lyon (see subversion: https://forge.ogf.org/svn/repos/nml-examples/20110922/other_examples/configu...; you need a gridforge login. Drop me a line if you can't access it.)
Regards, Freek Dijkstra
List of steps I took:
Source: AutoGOLE-Topo-2012-01-25.owl
Removed owl:NamedIndividual Removed schema definitions (owl:Ontology, owl:AnnotationProperty, etc.) Removed Position comments (used by auto-gole.appspot.com) Removed unnecessary comments
Result: AutoGOLE-Topo-2012-01-25.rdf
Changed dtox:lat, dtox:long and dtox:Location to geo84:lat, geo84:long and geo84:SpatialThing Corrected label of Netherlight location from Copenhagen to Amsterdam (geo84 was OK)
Changed dtox:STP to nml:bidirectionalport Grouped ports of a single network in a nml:topology Commented dtox:connectedTo, since this is not valid NML Added rdfs:label to all NSA and all locations Changed admin contact from string to vCard
Result: AutoGOLE-Topo-2012-02-20.rdf
Change urn:ogf:network identifiers to valid syntax (urn:ogf:network:<FQDN>:<date>:<opaque>) Make all bidirectional ports unidirectional Explicitly defined NML links, with sources and sinks
Result: AutoGOLE-Topo-2012-02-22.rdf
Possible future direction:
Merge NML:topology with dtox:NSNetwork Remove the dtox:managedBy property, as there is already an inverse relation dtox:managing to find the correct dtox:NSA Added switch matrix to each NML topology Define switching capabilities for each topology. use nml:hasPort instead of dtox:hasSTP
Result: (the-AutoGOLE-future-is-yet-to-be-written.rdf)
_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg