the Gole object is subordinate to a Node objevt which i find puzzling.
In the OWL file the GOLE class seems to encompass location/site information. I assumed this was a GOLE peering point site similar to what we have today in the automated GOLE demo. Nodes are located in GOLE sites as specified with the locatedAt property. From what I can see the GOLE class is not a subordinate of the Node class, but a object that the Node is related to through the locatedAt relationship. If we changed GOLE (or created a new class) called "(NSI)Network" then we could use a partOf or similar relationship to model a Node as part of a network. In addition we can related your service description type attributes in this object.
The sne Gole resource and the sne Switchmtrix resource are not used by NSI, but I included them in plugfest topologies for completeness sake. The NSAs can ignore them for now.
We need the SwitchMatrix class since these objects are containers for the hasPort relationship which allows us to determine ports associated with a Node.
1. Drop the Gole object as its use is confusing. I suggest changing it to be a "Network" object. And we define a "hasPort" relationship for Network objects. e.g. Network(Aruba) hasPort Port(Aiden).
I have no issue keeping the GOLE class as it is just additional modelling information that some people may desire, however, I agree we need a network class as well. I assume the reason we would model a port directly off the network instead of a Node is to hide the network details and provide additional abstraction?
2. We define a "hasComponent" relation from Networks to Nodes. e.g. Network(Aruba) hasComponent Node(force10a).
There are other existing relationships we can use such as "partOf" that would save us creating a new one.
3. Define a NSIcontactInfo attribute for Network objects. This info would be a string or URI that indicates how to contact the NSA associated with this Network object.
Today I defined a "managedBy" relationship based on a suggestion from Jeroen. It contains the URN of the NSA which can be mapped externally to a physical address. I have no issue adding additional details on physical addresses if needed. <managedBy rdf:datatype="http://www.w3.org/2001/XMLSchema#anyURI">urn:ogf:network:ethernet.netherlight.net:nsa:dracproxy01.surfnet.nl</managedBy>
4. Define a "mapsTo" relation for Ports. Think of this as a logical equivalence of two ports. e.g. Port(Aiden) mapsTo Port(f10a-0-1). And Port(f10a-0-1) mapsTo Port(Aiden). This will be used to as described below.
I was doing something similar so that I could map the abstract STP ports defined here through to the physical ports within the SURFnet network. I really want to drive my NSI implementation exclusively off of this topology description and not require the internal OpenDRAC topology database except for NRM intra-domain path finding. To do this I need to get in the additional data discussed. I have no issue doing this locally, but once we are running on the automated GOLE it would be nice if I didn't have to manually edit the owl file every time a new version is issued. Thanks, John. On 2011-08-15, at 9:20 PM, Jerry Sobieski wrote:
hi John
The current SNE generated topology files for the plugfest map NSI Network==SNE Node. And NSI Endpoints== SNE Port.
While we can make this work as a purely interdomain topology for the plugfest,, it does not play well with the NRMs and inter vs intra domain topology. I would like to see a few minor but important modifications implemented.
The sne Gole resource and the sne Switchmtrix resource are not used by NSI, but I included them in plugfest topologies for completeness sake. The NSAs can ignore them for now.
Imo, a GOLE is actually just a very special case network...one with particular policies. It would be inappropriate to use this for networks that do not conform to those policies. But NSI requires no such policies. Also, this SNE Gole object assumes a single point object rather than a distributed entity typical of most networks - and many GOLEs. Finally, the Gole object is subordinate to a Node objevt which i find puzzling. I would think the Devices that comprise the Gole would be subordinate to the Gole.....? So for several reasons it would not be an applicable topology object for most networks and is not directly relevant to the NSI world, or to the plugfest.
FYI, I've posed the following mods to Jeroen to modify the current SNE topology so that it maps more conveniently to NSI:
1. Drop the Gole object as its use is confusing. I suggest changing it to be a "Network" object. And we define a "hasPort" relationship for Network objects. e.g. Network(Aruba) hasPort Port(Aiden).
2. We define a "hasComponent" relation from Networks to Nodes. e.g. Network(Aruba) hasComponent Node(force10a).
3. Define a NSIcontactInfo attribute for Network objects. This info would be a string or URI that indicates how to contact the NSA associated with this Network object.
4. Define a "mapsTo" relation for Ports. Think of this as a logical equivalence of two ports. e.g. Port(Aiden) mapsTo Port(f10a-0-1). And Port(f10a-0-1) mapsTo Port(Aiden). This will be used to as described below.
(note: scoping of things like Port names as used above in rdf is based on their source file not their topological relationship. Thus there are some nuances to object naming to avoid scoping problems. But this is an rdf issue, not the topo model. Note also, the "mapsTo" relation does not replace the "connectsTo" relation...connectsTo is still present for Ports to indicate physical connections to other similar Port objects.)
These mods allow the SNE topology to define Networks as inter-domain objects and Nodes as intra-Domain components of those Networks. i.e. the Nodes and all of their relations constitute intra-domain topo info.
The "hasPort" relation for Networks allows us to specify Port objects that are inter-domain edges of the Network entity. Node objects already have Port relations defined for them...these are intra-domain Ports. The mapsTo relation maps inter-domain Ports to the corresponding Intra-domain Port, and vice versa. Thus no intraDomain toplogy info need be available to remote NSAs in order for them to select the local Network as a transit neywork, or which edge ports to use, or how to contact that NSA.
Thus in the SNE topology description, interdomain Ports "connectTo" other interdomain Ports. interDomain ports "mapTo" intraDomain ports. intradomain ports connectTo other intraDomain ports. and finally, intraDomain Ports also mapTo corresponding InterDomain Ports. Thus path finding works, and NSAs know which Endpoints exist in each Network without needing to know internal topology details of those remote Networks, and NRMs can relate those Endpoints to internal STPs and other intra domain details.
The above topology relations map very nicely to NSI. SNE Networks are equivalent to NSI Networks, and the SNE Ports directly under an sne Network equate to NSI Endpoints. And all of the physical port information is found in the intradomain port objects under Nodes or Switchmatrices - where the NRM has access to it. This keeps the inter-domain and intra-domain info in seperate layers of the topology description, yet both can coexist within a single topo file if present. Each domain can easily pass just the interDomain Network and Port info into a global topology file for all to use, and can include as much or as little intraDomain info as it deems appropriate. And NSAs have all the information they need to function according to spec.
I believe these are fairly minor tweeks to the SNE topo model, but would be extremely helpful to the NSI effort. I hope to discuss this with Jeroen soon to get these mods integrated asap.
What do you think John?
Jerry
Sent from my iPad3g
On Aug 15, 2011, at 11:55 AM, John MacAuley <john.macauley@surfnet.nl> wrote:
Jeroen, Jerry,
Can someone show me an example of how we will be mapping the abstracted topology provided for the interoperability tests. Sorry if this was already discussed, but I can seem to remember the thread.
My guess would be that we are treating GOLE objects as networks and Port objects as the local part? I would therefore have the following STP address:
urn:ogf:network:stp:Aruba.Loc:Aiden
Do I have this correct?
Thanks, John. _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg