Freek, I need another clarification on terminology in the Adaptation/Deadaptation elements:
canProvidePort to one or more Ports or PortGroups (this describes a ability)
When you say "this describes an ability" do you mean that the Port or PortGroups listed are available for use but are not yet in use?
providesPort to one or more Ports or PortGroups (this describes a configuration)
I would then assume this represents the Ports or PortGroups currently in use by the function? If both of the above assumptions are true, then must a specific port being used in providesPort be removed from the canProvidePort list? Thank you, John Begin forwarded message:
From: John MacAuley <macauley@es.net> Subject: NML : Adaptation questions. Date: 1 December, 2016 6:40:03 PM EST To: Freek Dijkstra <Freek.Dijkstra@surfsara.nl> Cc: Network Markup Language Working Group <nml-wg@ogf.org>
Freek,
I hope this finds you well. I am attempting to model in NML the capabilities of an SDN switch we have in our lab. I am finding the NML specification lacks the detail I need to really understand how some of this would be done. I was not involved in the original discussions so thought I would ask some detailed questions on the examples that are present.
Here some XML from the NML specification defining two port pairs, adaptations, and switching service. I assumed the examples in the NML document were consistent between themselves.
<?xml version="1.0" encoding="utf-8"?> <rdf:RDF xmlns:nml="http://schemas.ogf.org/nml/2013/05/base#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:owl="http://www.w3.org/2002/07/owl#" xmlns:nmleth="http://schemas.ogf.org/nml/2013/05/ethernet#">
<nml:Topology rdf:about="urn:ogf:network:example.net:2013:org">
<nml:version>20130529T121112Z</nml:version>
<nml:Node rdf:about="urn:ogf:network:example.net:2013:nodeA"> <nml:name>Node_A</nml:name> <nml:hasInboundPort rdf:resource="urn:ogf:network:example.net:2013:nodeA:port_X:in"/> <nml:hasInboundPort rdf:resource="urn:ogf:network:example.net:2013:nodeA:port_Y:in"/> <nml:hasOutboundPort rdf:resource="urn:ogf:network:example.net:2013:nodeA:port_X:out"/> <nml:hasOutboundPort rdf:resource="urn:ogf:network:example.net:2013:nodeA:port_Y:out"/> <nml:hasService rdf:resource="urn:ogf:network:example.net:2013:nodeA:switchingService"/> </nml:Node>
<nml:SwitchingService rdf:about="urn:ogf:network:example.net:2013:nodeA:switchingService"> <nml:hasInboundPort rdf:resource="urn:ogf:network:example.net:2013:nodeA:port_X:in"/> <nml:hasInboundPort rdf:resource="urn:ogf:network:example.net:2013:nodeA:port_Y:in"/> <nml:hasOutboundPort rdf:resource="urn:ogf:network:example.net:2013:nodeA:port_X:out"/> <nml:hasOutboundPort rdf:resource="urn:ogf:network:example.net:2013:nodeA:port_Y:out"/> </nml:SwitchingService>
<nml:Port rdf:about="urn:ogf:network:example.net:2013:port_X:out"> <nml:hasService rdf:resource="urn:ogf:network:example.net:2013:port_X:out:adaptationService"/> </nml:Port>
<nml:AdaptationService rdf:about="urn:ogf:network:example.net:2013:port_X:out:adaptationService"> <nml:adaptationFunction rdf:resource="http://schemas.ogf.org/nml/2013/05/ethernet#802.1q"/> <nml:providesPort rdf:resource="urn:ogf:network:example.net:2013:port_X.1501:out"/> </nml:AdaptationService>
<nml:Port rdf:about="urn:ogf:network:example.net:2013:port_X.1501:out"> <nmleth:vlan>1501</nmleth:vlan> </nml:Port>
<nml:Port rdf:about="urn:ogf:network:example.net:2013:port_X:in"> <nml:hasService rdf:resource="urn:ogf:network:example.net:2013:port_X:in:deadaptationService" /> </nml:Port>
<nml:DeadaptationService rdf:resource="urn:ogf:network:example.net:2013:port_X:in:deadaptationService"> <nml:adaptationFunction rdf:resource="http://schemas.ogf.org/nml/2013/05/ethernet#802.1q"/> <nml:providesPort rdf:resource="urn:ogf:network:example.net:2013:port_X.1501:in"/> </nml:DeadaptationService>
<nml:Port rdf:about="urn:ogf:network:example.net:2013:port_X.1501:in"> <nmleth:vlan>1501</nmleth:vlan> </nml:Port>
<nml:Port rdf:about="urn:ogf:network:example.net:2013:port_Y:out"> <nml:hasService rdf:resource="urn:ogf:network:example.net:2013:port_Y:out:adaptationService"/> </nml:Port>
<nml:AdaptationService rdf:about="urn:ogf:network:example.net:2013:port_Y:out:adaptationService"> <nml:adaptationFunction rdf:resource="http://schemas.ogf.org/nml/2013/05/ethernet#802.1q"/> <nml:providesPort rdf:resource="urn:ogf:network:example.net:2013:port_Y.1700:out"/> </nml:AdaptationService>
<nml:Port rdf:about="urn:ogf:network:example.net:2013:port_Y.1700:out"> <nmleth:vlan>1700</nmleth:vlan> </nml:Port>
<nml:Port rdf:about="urn:ogf:network:example.net:2013:port_Y:in"> <nml:hasService rdf:resource="urn:ogf:network:example.net:2013:port_Y:in:deadaptationService" /> </nml:Port>
<nml:DeadaptationService rdf:resource="urn:ogf:network:example.net:2013:port_Y:in:deadaptationService"> <nml:adaptationFunction rdf:resource="http://schemas.ogf.org/nml/2013/05/ethernet#802.1q"/> <nml:providesPort rdf:resource="urn:ogf:network:example.net:2013:port_Y.1700:in"/> </nml:DeadaptationService>
<nml:Port rdf:about="urn:ogf:network:example.net:2013:port_Y.1700:in"> <nmleth:vlan>1700</nmleth:vlan> </nml:Port>
</nml:Topology>
</rdf:RDF>
Just so i am 100 percent clear I believe the relationship diagram for the port_X entity looks like this based on the XML provided.
In this example, I assume the deadaptation on port_X:in is stripping the 802.1q header containing vlan tag 1501 from the Ethernet frame, while the adaptation on on port_X:out is adding the 802.1q header with vlan 1501 to the Ethernet frame. Do I have this correct? This seems to be what the NML document is describing. The reason I ask is that I find the naming of the ports a bit confusing and counter intuitive to what I that was occurring.
Where does the physical port associated with urn:ogf:network:example.net:2013:port_X.1501:in(out) come into the picture and how do other vlans on the same port get multiplexed?
Up to this point I have been looking at this from the opposite perspective of what the example in the document describes. From my view the single physical port hasService to a DeadaptationService that providesPort to a set of labeled ports that had been imbedded as client layers within the physical port. If would look like this diagram:
This changes the semantics a bit. It implies that data entering logical port urn:ogf:network:example.net:2013:port_X:out?vlan=1501 will have the 802.1q header added with the vlan 1501 by the adaptation service before multiplexing on physical port urn:ogf:network:example.net:2013:port_X:out. Basically the logical ports continue to fanout upwards in this model and encapsulation/multiplexing is unwrapped.
So have I misinterpreted the NML document and my second diagram here is correct?
Thanks, John
