[Nsi-wg] Constructing STP from topology data.

[Jerry Sobieski]

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 at 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 at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg