[Nml-wg] NML : Adaptation questions.

John MacAuley macauley at es.net
Thu Dec 1 18:40:03 EST 2016


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20161201/8a2ebde8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2016-12-01 at 4.15.31 PM.png
Type: image/png
Size: 139314 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20161201/8a2ebde8/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2016-12-01 at 6.04.10 PM.png
Type: image/png
Size: 121230 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20161201/8a2ebde8/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1626 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20161201/8a2ebde8/attachment-0001.bin>


More information about the nml-wg mailing list