NSI specific topology recommendation for plug fest.
Peoples, I think the existing detailed DTOX topology models we have been generating are excellent. I can definitely see how I will be able to incorporate this into future versions of OpenDRAC as a primary topology import mechanism, however, I do not think it is capturing the simplified concepts in NSI that are needed for the demo. I have been playing around with the example topologies trying to massage them into a form where I can learn not only the network and STP topologies, but the managing NSA topologies as well. I found that the existing DTOX topology is very good at the details of nodes, switch matrixes, and ports, but I had a hard time filtering down to the simple aspects. I also believe we will get into some trouble if we try to use the port class to model STP while also modeling physical ports. I am not sure if the DTOX schema can handle this aspect, as I could not find a describing schema. I spent time over the last couple of days discussing this with Jerry while we worked through the plug fest scenarios. He provided good feedback and pulled together the attached slide showing the concepts we are trying to capture. I also mocked up an example OWL file with an NSI topology specific name space, and introduced the NSI concepts of NSnetwork, STP, and NSA. These classes are used to model their simplified namesakes from the NSI CS protocol, and are not meant to replace the DTOX definitions, but augment them with our NSI specific concepts. We can consider the NSI topology elements an overlay on the existing DTOX elements, reusing data properties and including references to DTOX object instances. (I removed the DTOX object instances from the file to simplify the example). I think this will become much clearer when running NSI on out real networks and not this abstract topology for the demo. I have not yet validated the attached OWL so I apologize if it contains errors. The following classes and properties are introduced in the file… NSnetwork: We model a NSI network with the NSnetwork class. Example URN: urn:ogf:network:NSnetwork:Aruba Properties: · label - display name for the network. · canSwap - indicates VLAN Id interchange is supported in the network domain. · managedBy - the Network Services Agent managing this network. · hasSTP - a set of references to the inter-domain Service Termination Points that are within this network. · hasPart - a set of references to the DTOX Node NamedIndividual representing network elements within this network. NSA: We model a Network Services Agent with the NSA class. Example URN: urn:ogf:network:nsa:dracproxy01.surfnet.nl Properties: · label - display name for the NSA. · managing - indicates the network being managed by this NSA. · connectedTo - represents an NSA to which this NSA has a peering relationship. · dnsName - DNS name of the NSA. · csProviderEndpoint - the SOAP endpoint for this NSA's CS provider interface. · adminContact - administrative contact information for this NSA. STP: We model a logical Service Termination point with the STP class. Example URN: urn:ogf:network:stp:Aruba:Aiden Properties: · label - display name for this STP. · partOf - indicates the member network of this STP. · connectedTo - a topological link identifying the peer STP to which this STP is connected. · mapsTo - the logical STP represented by this object instance maps through to this physical entity (port, vlan, etx.) in DTOX. We will need to start up a discussion after the plug fest to address the issue of NSI topology needs. I believe these changes will do until then. Comments? Thank you, John.
Found a small issue in the example owl. On 2011-08-19, at 10:16 PM, John MacAuley wrote:
Peoples,
I think the existing detailed DTOX topology models we have been generating are excellent. I can definitely see how I will be able to incorporate this into future versions of OpenDRAC as a primary topology import mechanism, however, I do not think it is capturing the simplified concepts in NSI that are needed for the demo.
I have been playing around with the example topologies trying to massage them into a form where I can learn not only the network and STP topologies, but the managing NSA topologies as well. I found that the existing DTOX topology is very good at the details of nodes, switch matrixes, and ports, but I had a hard time filtering down to the simple aspects. I also believe we will get into some trouble if we try to use the port class to model STP while also modeling physical ports. I am not sure if the DTOX schema can handle this aspect, as I could not find a describing schema.
I spent time over the last couple of days discussing this with Jerry while we worked through the plug fest scenarios. He provided good feedback and pulled together the attached slide showing the concepts we are trying to capture. I also mocked up an example OWL file with an NSI topology specific name space, and introduced the NSI concepts of NSnetwork, STP, and NSA. These classes are used to model their simplified namesakes from the NSI CS protocol, and are not meant to replace the DTOX definitions, but augment them with our NSI specific concepts. We can consider the NSI topology elements an overlay on the existing DTOX elements, reusing data properties and including references to DTOX object instances. (I removed the DTOX object instances from the file to simplify the example). I think this will become much clearer when running NSI on out real networks and not this abstract topology for the demo.
I have not yet validated the attached OWL so I apologize if it contains errors. The following classes and properties are introduced in the file…
NSnetwork: We model a NSI network with the NSnetwork class.
Example URN: urn:ogf:network:NSnetwork:Aruba
Properties:
· label - display name for the network. · canSwap - indicates VLAN Id interchange is supported in the network domain. · managedBy - the Network Services Agent managing this network. · hasSTP - a set of references to the inter-domain Service Termination Points that are within this network. · hasPart - a set of references to the DTOX Node NamedIndividual representing network elements within this network.
NSA: We model a Network Services Agent with the NSA class.
Example URN: urn:ogf:network:nsa:dracproxy01.surfnet.nl
Properties:
· label - display name for the NSA. · managing - indicates the network being managed by this NSA. · connectedTo - represents an NSA to which this NSA has a peering relationship. · dnsName - DNS name of the NSA. · csProviderEndpoint - the SOAP endpoint for this NSA's CS provider interface. · adminContact - administrative contact information for this NSA.
STP: We model a logical Service Termination point with the STP class.
Example URN: urn:ogf:network:stp:Aruba:Aiden
Properties:
· label - display name for this STP. · partOf - indicates the member network of this STP. · connectedTo - a topological link identifying the peer STP to which this STP is connected. · mapsTo - the logical STP represented by this object instance maps through to this physical entity (port, vlan, etx.) in DTOX.
We will need to start up a discussion after the plug fest to address the issue of NSI topology needs. I believe these changes will do until then. Comments?
Thank you, John.
<nsi-interop-topology-example.owl> <NSI topology model.pptx> _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Hello, On 20 Aug 2011, at 04:16, John MacAuley wrote:
NSnetwork: We model a NSI network with the NSnetwork class.
Example URN: urn:ogf:network:NSnetwork:Aruba
Properties:
· label - display name for the network. · canSwap - indicates VLAN Id interchange is supported in the network domain. · managedBy - the Network Services Agent managing this network. · hasSTP - a set of references to the inter-domain Service Termination Points that are within this network. · hasPart - a set of references to the DTOX Node NamedIndividual representing network elements within this network.
NSA: We model a Network Services Agent with the NSA class.
Example URN: urn:ogf:network:nsa:dracproxy01.surfnet.nl
Properties:
· label - display name for the NSA. · managing - indicates the network being managed by this NSA. · connectedTo - represents an NSA to which this NSA has a peering relationship. · dnsName - DNS name of the NSA. · csProviderEndpoint - the SOAP endpoint for this NSA's CS provider interface. · adminContact - administrative contact information for this NSA.
STP: We model a logical Service Termination point with the STP class.
Example URN: urn:ogf:network:stp:Aruba:Aiden
Properties:
· label - display name for this STP. · partOf - indicates the member network of this STP. · connectedTo - a topological link identifying the peer STP to which this STP is connected. · mapsTo - the logical STP represented by this object instance maps through to this physical entity (port, vlan, etx.) in DTOX.
We will need to start up a discussion after the plug fest to address the issue of NSI topology needs. I believe these changes will do until then. Comments?
How do you envision labels to be added to the above topology? The ontology above maps almost directly to the DTOX schema we created before we started considering labels... The current test-topologies may not have labels in them, but as things look now, they will always be part of the network, and will always be something to consider when you are doing pathfinding. Jeroen.
Hi jeroen The issue is that currently NSI service termination points do not point to under-specified endpoints such as ports with labels. As it stands today an NSI STP would point to a particular label as the termination point for a circuit. To put something other than the terminating point of the circuit in the NSI reservation request implies a certain semantic about what specifically can be found in a request as an Endpoint and how to recognize and process it. We got into this briefly but decided it involved a lot of topology issues we were not able to address or answer at that time - so we shelved it until we had a chance to discuss a more sophisticated NSI topology model. For now, for the plugfest, we can treat Ports as the STP. We will define all interdomain peering points as untagged ports for the interop plugfest in Rio. In the Port object we either define a single label, (e.g. "0") or better, no label at all. This must be coordinated with the peer network so that their corresponding Port object is defined similarly. IMO, the NSI working group has not worked out a consensus approach to how we expect the protocol to treat "labels"...else it would already be in the standard. Strictly speaking, the NSI CS protocol works just fine as is - it just maps STPs to particular labels. (note: the SNE editor offered no Label object.) However, a number of folks are uncomfortable with this and want a different treatment. We need to have this discussion, but there are related issues we need to work through if we want all of these features to integrate in a cohesive and fashion. Sent from my iPad3g On Aug 22, 2011, at 5:10 AM, Jeroen van der Ham <vdham@uva.nl> wrote:
Hello,
On 20 Aug 2011, at 04:16, John MacAuley wrote:
forNSnetwork: We model a NSI network with the NSnetwork class.
Example URN: urn:ogf:network:NSnetwork:Aruba
Properties:
· label - display name for the network. · canSwap - indicates VLAN Id interchange is supported in the network domain. · managedBy - the Network Services Agent managing this network. · hasSTP - a set of references to the inter-domain Service Termination Points that are within this network. · hasPart - a set of references to the DTOX Node NamedIndividual representing network elements within this network.
NSA: We model a Network Services Agent with the NSA class.
Example URN: urn:ogf:network:nsa:dracproxy01.surfnet.nl
Properties:
· label - display name for the NSA. · managing - indicates the network being managed by this NSA. · connectedTo - represents an NSA to which this NSA has a peering relationship. · dnsName - DNS name of the NSA. · csProviderEndpoint - the SOAP endpoint for this NSA's CS provider interface. · adminContact - administrative contact information for this NSA.
STP: We model a logical Service Termination point with the STP class.
Example URN: urn:ogf:network:stp:Aruba:Aiden
Properties:
· label - display name for this STP. · partOf - indicates the member network of this STP. · connectedTo - a topological link identifying the peer STP to which this STP is connected. · mapsTo - the logical STP represented by this object instance maps through to this physical entity (port, vlan, etx.) in DTOX.
We will need to start up a discussion after the plug fest to address the issue of NSI topology needs. I believe these changes will do until then. Comments?
How do you envision labels to be added to the above topology?
The ontology above maps almost directly to the DTOX schema we created before we started considering labels...
The current test-topologies may not have labels in them, but as things look now, they will always be part of the network, and will always be something to consider when you are doing pathfinding.
Jeroen. _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Jeroen, What was the reasoning behind having "connectedTo" as a DatatypeProperty and not an ObjectProperty? I accidentally modelled them as ObjectProperty since they map directly to objects within the OWL. <!-- http://www.glif.is/working-groups/tech/dtox#connectedTo --> <owl:DatatypeProperty rdf:about="http://www.glif.is/working-groups/tech/dtox#connectedTo"/> Thanks, John. On 2011-08-22, at 5:10 AM, Jeroen van der Ham wrote:
Hello,
On 20 Aug 2011, at 04:16, John MacAuley wrote:
NSnetwork: We model a NSI network with the NSnetwork class.
Example URN: urn:ogf:network:NSnetwork:Aruba
Properties:
· label - display name for the network. · canSwap - indicates VLAN Id interchange is supported in the network domain. · managedBy - the Network Services Agent managing this network. · hasSTP - a set of references to the inter-domain Service Termination Points that are within this network. · hasPart - a set of references to the DTOX Node NamedIndividual representing network elements within this network.
NSA: We model a Network Services Agent with the NSA class.
Example URN: urn:ogf:network:nsa:dracproxy01.surfnet.nl
Properties:
· label - display name for the NSA. · managing - indicates the network being managed by this NSA. · connectedTo - represents an NSA to which this NSA has a peering relationship. · dnsName - DNS name of the NSA. · csProviderEndpoint - the SOAP endpoint for this NSA's CS provider interface. · adminContact - administrative contact information for this NSA.
STP: We model a logical Service Termination point with the STP class.
Example URN: urn:ogf:network:stp:Aruba:Aiden
Properties:
· label - display name for this STP. · partOf - indicates the member network of this STP. · connectedTo - a topological link identifying the peer STP to which this STP is connected. · mapsTo - the logical STP represented by this object instance maps through to this physical entity (port, vlan, etx.) in DTOX.
We will need to start up a discussion after the plug fest to address the issue of NSI topology needs. I believe these changes will do until then. Comments?
How do you envision labels to be added to the above topology?
The ontology above maps almost directly to the DTOX schema we created before we started considering labels...
The current test-topologies may not have labels in them, but as things look now, they will always be part of the network, and will always be something to consider when you are doing pathfinding.
Jeroen.
On 23 Aug 2011, at 00:02, John MacAuley wrote:
Jeroen,
What was the reasoning behind having "connectedTo" as a DatatypeProperty and not an ObjectProperty? I accidentally modelled them as ObjectProperty since they map directly to objects within the OWL.
<!-- http://www.glif.is/working-groups/tech/dtox#connectedTo -->
<owl:DatatypeProperty rdf:about="http://www.glif.is/working-groups/tech/dtox#connectedTo"/>
It was actually a bit of a dirty hack to allow it as a textfield in the editor... DataProperties are textfields and ObjectProperties are relations between objects, and are shown as connections and circles in the editor. In the end it should become an ObjectProperty indeed. Jeroen.
On 2011-08-22, at 5:10 AM, Jeroen van der Ham wrote:
How do you envision labels to be added to the above topology?
When you say labels do you mean the display names as I have used then here or VLAN tags?
The ontology above maps almost directly to the DTOX schema we created before we started considering labels...
The current test-topologies may not have labels in them, but as things look now, they will always be part of the network, and will always be something to consider when you are doing pathfinding.
Jeroen.
On 23 Aug 2011, at 00:04, John MacAuley wrote:
On 2011-08-22, at 5:10 AM, Jeroen van der Ham wrote:
How do you envision labels to be added to the above topology?
When you say labels do you mean the display names as I have used then here or VLAN tags?
I mean VLAN tags in the current topology, but wavelengths, timeslots, et cetera in future topologies. Jeroen.
That is a good question. I like the way you track vlans in the current port object. Very simple. However, it is not really modelling the concept of a vlan service topology. With the STP concept being a port abstraction, we need a way to point an STP to underlying network constructs. For example, in one version of STP I pointed it to an Ethernet port and had stored a vlan id in the STP to indicate the STP was modelling a specific vlan. Jerry pointed out that this would complicate the STP definition, and therefore, we should point it to a modelled vlan instead of directly to a port. Is NML planning on modelling Ethernet services as another topological layer with dedicated objects? On 2011-08-24, at 3:52 AM, Jeroen van der Ham wrote:
On 23 Aug 2011, at 00:04, John MacAuley wrote:
On 2011-08-22, at 5:10 AM, Jeroen van der Ham wrote:
How do you envision labels to be added to the above topology?
When you say labels do you mean the display names as I have used then here or VLAN tags?
I mean VLAN tags in the current topology, but wavelengths, timeslots, et cetera in future topologies.
Jeroen.
Hello, I've updated the SNE Editor with a new ontology which takes into account most of the suggestions that John and Jerry have made. If there is anything else that should be in there or should be removed from it, let me know. Attached is an N3 version of the same ontology for reference. Jeroen.
Hi Jeroen- - The NSnetwork resource needs a "hasSTP" relation that links to the STP objects. The NSnetwork object is the NSI Network, and STPs are the NSI Endpoints. There is not link between these. The interdomain topology should be complete (if not physically detailed) without any intra-domain topology. This allows remote STPs to be associated with a particular remote network/NSA without needing to define intra-domain topology to link them. - The NSA object needs a "contactInfo" field that contains the actual contact info. For now, this can be a simple string that the local MTL can use as a destination specification for the messages going to that NSA. Thanks Jerry On 8/24/11 5:52 AM, Jeroen van der Ham wrote:
Hello,
I've updated the SNE Editor with a new ontology which takes into account most of the suggestions that John and Jerry have made.
If there is anything else that should be in there or should be removed from it, let me know.
Attached is an N3 version of the same ontology for reference.
Jeroen.
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Hi, I've updated the editor again, adding: - connectedTo for NSAs (note that a top connectedTo blob only connects to a bottom connectedTo blob and vice versa) - contactInfo for NSAs - hasSTP to link NSNetworks and STPs (was added yesterday) Jeroen.
Hmm... Why the "connectedTo" for NSAs? This was something John mentioned and I don't understand. What does the connectedTo relation describe when between NSAs?? NSAs are control plane agents, and any NSA can contact any other NSA. This relation seems unnecessary for now, and until/unless we change the session model between NSAs. ?? Jerry On 8/26/11 11:16 AM, Jeroen van der Ham wrote:
Hi,
I've updated the editor again, adding:
- connectedTo for NSAs (note that a top connectedTo blob only connects to a bottom connectedTo blob and vice versa) - contactInfo for NSAs - hasSTP to link NSNetworks and STPs (was added yesterday)
Jeroen.
I put it in so we can start to try some intelligent routing of messages in a more complex NSA topology. I do not assume all NSAs are connected to all other NSAs since I do not think this will be true for anything other than our demo. Being able to build an NSA tree to determine message routing needs some investigation, and since this isn't covered by the NSI CS protocol, it is a good time to start investigating for the next version of the protocol. People can ignore it if they want but I am going to do some prototype code to use it. John. On 2011-08-26, at 11:23 AM, Jerry Sobieski wrote:
Hmm... Why the "connectedTo" for NSAs? This was something John mentioned and I don't understand. What does the connectedTo relation describe when between NSAs?? NSAs are control plane agents, and any NSA can contact any other NSA. This relation seems unnecessary for now, and until/unless we change the session model between NSAs.
??
Jerry
On 8/26/11 11:16 AM, Jeroen van der Ham wrote:
Hi,
I've updated the editor again, adding:
- connectedTo for NSAs (note that a top connectedTo blob only connects to a bottom connectedTo blob and vice versa) - contactInfo for NSAs - hasSTP to link NSNetworks and STPs (was added yesterday)
Jeroen.
No. This is a lousy time to unilaterally start adding new features! We only need topology for Rio. If we want to do a more complex topological process for the control plane, you should bring it to the working group. We don't want to confuse or add additional work for all the implementers now as we are headed to an interop. Please... Don't throw stuff into the Rio topology mods unless they are essential for Rio. If they are not essential for Rio, and not a part of the CS standard, take them offline as a personal project. I don't mean to be gruff here, but adding this stuff causes unnecessarily confusion and work. Thanks Jerry On 8/26/11 1:22 PM, John MacAuley wrote:
I put it in so we can start to try some intelligent routing of messages in a more complex NSA topology. I do not assume all NSAs are connected to all other NSAs since I do not think this will be true for anything other than our demo. Being able to build an NSA tree to determine message routing needs some investigation, and since this isn't covered by the NSI CS protocol, it is a good time to start investigating for the next version of the protocol. People can ignore it if they want but I am going to do some prototype code to use it.
John.
On 2011-08-26, at 11:23 AM, Jerry Sobieski wrote:
Hmm... Why the "connectedTo" for NSAs? This was something John mentioned and I don't understand. What does the connectedTo relation describe when between NSAs?? NSAs are control plane agents, and any NSA can contact any other NSA. This relation seems unnecessary for now, and until/unless we change the session model between NSAs.
??
Jerry
On 8/26/11 11:16 AM, Jeroen van der Ham wrote:
Hi,
I've updated the editor again, adding:
- connectedTo for NSAs (note that a top connectedTo blob only connects to a bottom connectedTo blob and vice versa) - contactInfo for NSAs - hasSTP to link NSNetworks and STPs (was added yesterday)
Jeroen.
Now to respond intelligently to the substance of the concept...:-) On 8/26/11 1:22 PM, John MacAuley wrote:
I put it in so we can start to try some intelligent routing of messages in a more complex NSA topology. I do not assume all NSAs are connected to all other NSAs since I do not think this will be true for anything other than our demo. Being able to build an NSA tree to determine message routing needs some investigation, and since this isn't covered by the NSI CS protocol, it is a good time to start investigating for the next version of the protocol. People can ignore it if they want but I am going to do some prototype code to use it.
All *NSAs* will be connected to all other NSAs...Just as any IP address can connect (in principle) to any other IP address. Whether an NSA /_accepts_ /a request is a different issue. This is policy, not message routing. Currently, NSI message routing follows the service tree...period. There are no intermediate NSAs. We have not stipulated any reqirement for how an NSA chooses the next NSA it contacts to progress a service request (Indeed, we have always stated that tree or chain was a local decision, and so likewise would be which NSA to use.) A particular segmentation does not dictate a particular service tree, but a service tree is *always* constructed, and it reflects the local hop by hop policy decisions of each NSA down the tree. So, if one wants to find the source of a *request*, one can still climb the service tree with proper credentials and discover the ultimate RA. However, if in practice we think that a given NSA will only be willing to accept and handle service requests from a finite subset of clients [NSAs] (which I think is entirely likely), then one can also expect many NSAs will not be able to forward requests directly to the NSAs along their desired [global] path - and these will need an intermediary. I.e. If every NSA in the world does not authorize on "jerry@nordu.net", then I need to know where to send requests that will result in the connection being made. I need a "default NSA" for my NSI service requests. Or a set of NSAs to use under different conditions. It sounds to me as if you want to indicate some sort of NSI message routing policy... I.e. Under these conditions, send requests to this NSA, under those conditions, send a request to that NSA. A sort of service request routing table. Is this what you mean above? I still believe this a local implementation issue and does not affect NSI, and so need not be part of the interdomain topology. Its an interesting discussion. Want to elaborate more on what you have in mind? Thanks Jerry
John.
On 2011-08-26, at 11:23 AM, Jerry Sobieski wrote:
Hmm... Why the "connectedTo" for NSAs? This was something John mentioned and I don't understand. What does the connectedTo relation describe when between NSAs?? NSAs are control plane agents, and any NSA can contact any other NSA. This relation seems unnecessary for now, and until/unless we change the session model between NSAs.
??
Jerry
On 8/26/11 11:16 AM, Jeroen van der Ham wrote:
Hi,
I've updated the editor again, adding:
- connectedTo for NSAs (note that a top connectedTo blob only connects to a bottom connectedTo blob and vice versa) - contactInfo for NSAs - hasSTP to link NSNetworks and STPs (was added yesterday)
Jeroen.
participants (3)
-
Jeroen van der Ham -
Jerry Sobieski -
John MacAuley