Hi Radek- As nice as I think the SNE graphical UI is, the topology it asserts does not correspond well to the NSI topology, nor does it separate that which is inter-domain and technology agnostic from that which is intra-domain and almost entirely a local NRM issue (i.e. implementation specific). The SNE model is imposing unnecessary requirements on the NSI demo. We are well outside of what the spec requires. This is why I recommended a very simple and direct NSI topology description for the Rio demos (and *only* for the demos - not permanently) that allowed each implementation to define their local NRM information independently. IMO, we do not want to impose more on the NSI interop demonstrations than has been vetted by the NSI group. However, since the group has decided to use the SNE topology in RDF format..., there are several issue we need to address. First is the mapping that Radak asks about: 1. I think within the SNE topology model, an NSI Network maps best to a SNE "node" object, and an NSI Endpoint maps best to a SNE "port" object. The SNE "GOLE" object is not too useful IMO - it only offers a name and a location. Since you'd still require the "node" object in order to define the NSI Endpoints (SNE ports), why do you need the GOLE object? Indeed, many of our GOLEs claim to be Distributed GOLEs which makes the location field of questionable usefulness. Including the GOLE object creates additional RDF output and causes additonal [unnecessary] processing if it is expected or present in the RDF description, and is not critical for NSI protocol interop. So I propose we ignore the GOLE object for Rio plugfest topologies. The Switchmatrix object is likewise not defined within the NSI topology model. While such an object may be of some use in the future for defining transfer functions of various topological objects, there is no defined rules for the switchmatrix object now, nor is it currently in the NSI context. So while it is probably harmless, it is still overhead, I propose we likewise ignore it for now. I suggest we use just the Node object and the Port object. This should suffice for Rio NSI topologies. 2. The editor requires the fields of the SNE Port object - the "capacity" and the "label" fields, to be filled. I tried this by putting the Label fields to "0" or "1" and the capacity field to "1000" and it accepted it. There is no semantic validation by SNE or the schema as to what these numbers mean (Gbps? Mbps? bps?). The capacity fields are floats (see the generated RDF), and the label fields are strings. These are not used by the NSI protocol. The parsers in each NSAs will have to validate the field contents as meaningful. 3. In the NRMs, it *is* necessary to associate physical characteristics with an NSI Endpoint. This is a local NRM issue (i.e. not NSI) and only of use to the local NRM that will perform the intra-domain path selection. The internal mapping NSI Endpoints to NRM nomenclature is domain specific. However, there does need to be coordination between adjacent (connected) NSI Networks so that the respective NRMs each have consistent view regarding the physical characteristics of a common interconnection Endpoint. Since we are manually defining the entire "global" NSI topology for each of the plugfest Challenges, we can do this easily. (In the real world, this will need be done differently...) For purposes of the NSI demos in Rio, since the specifics of physical characteristics are out of scope for NSI protocol, I propose that we explicitly define all NSI Endpoints (SNE "port"s) to be uniform: all Endpoints (SNE "port" objects) for the plugfest will be "untagged" (i.e. no subdividing Ports into virtual connections. I.e. "label" fields="0"), and all ports have the same max capacity of 1000. We will assert that the capacity is in units of "Mbps". This will allow us to focus on NSI protocol issues rather than NRM resource allocation issues. 3. It is important to note that the SNE editor does essentially no semantic validation. For example, the "name" field associated with each SNE object *must* be globally unique. If two objects in the SNE editor have the same name, it can not distinguish the two and only one object will be defined in the resulting RDF (OWL) code. It would be nicer if object names were only scoped within their parent object (i.e. "port" names only needed to be unique within their parent "node" object.) While this is inconvenient, its not a show stopper for now. However, it means that our SNE topologies must be globally coordinated so that the same name is never duplicated for any object, OR, we use a fully qualified name in the name field of each object. I.e., Each NSI network has a unique name, e.g., "Netherlight.edu" (the name in the SNE "node" object), and then the Endpoints (the SNE "port" objects) would be named explicitly "Netherlight.edu:endpoint1". If you specify the full path name in the port object, and the node name is unique, then you will have a unique port name and the connectsTo relations will generate the proper RDF. 4. You need to specify the connectsTo relation from each port to the corresponding port to indicate bidirectional connectivity. There used to be relation links to do this, but they seem to have been removed now in the SNE gui. 5. There is no relationship generated in the RDF that links a port to its parent node. The hasPort relationship only generates a link from the parent node object downward to the child port object. To find the parent node associated with a port, one must search for the port name in the list of hasPort relations of all the Node objects. However, since this is simply an artifact of the SNE RDF, an NSA reading the RDF information need not use the RDF directly internally - it can translate it into its internal topology and build whatever links it needs internally one time as it imports the RDF. However, since the RDF is generated by the SNE interpreter, the object names must still be globally unique in order to generate all the objects. 6. Note also: The SNE constructs/relations seem to be in flux. (the connectsTo relation has changed in the last week or so.) So the generated RDF/OWL code may change. And there may be implications to existing defined topologies being interpreted correctly. So just keep an eye open for this. The SNE editor is a nice UI. And generating RDF is ok as well (I am agnostic on RDF). But I am not happy with the imposed topology model - it needs more discussion to integrate well with the NSI framework or to enable more advanced topology constructs. And some of the cosmetic constraints seem unnecessary as well (e.g. global name scoping). This all being said, I will be defining the Challenge Topologies graphically first, then inputting them into the SNE graphical UI to generate RDF. I will circultate these diagrams and the associated RDF as soon as possible for review and comment. Hope this helps...Please offer comments, questions, or suggestions. I will have the Plugfest "Rules of Engagement" and initial Challenge doc out in a day or so for review and comment. Jerry On 7/25/11 6:51 AM, Radek Krzywania wrote:

Hi all,

A few questions on topology building (I am using SNE Editor for that):

-How do we indicate end points (e.g. servers)? Is it just a Port connected to Node, it’s additional Node, or a “connectedTo” label?:

Node (GEANT) – Port (Poznan /to srv/)

Or

Node (GEANT) – Port (Poznan) – Port (Poznan srv)

Or

Node (GEANT) – Port (Poznan; connectedTo=”srv URI”)

-According to documentation “The connectedTo statement uses the full URI of the connected port to show that it is connected to an outside Port, and uses the full identifier of that Port” – how do I know what is the URI of those ports? Should we agree between sites or is there a global register for those values?

-What is the max/available Capacity format? Is it bits per second or bytes or Mbps, Gbps?

Best regards

Radek

________________________________________________________________________

Radoslaw Krzywania Network Research and Development

Poznan Supercomputing and

radek.krzywania@man.poznan.pl <mailto:radek.krzywania@man.poznan.pl> Networking Center

+48 61 850 25 26 http://www.man.poznan.pl

________________________________________________________________________

*From:*nsi-wg-bounces@ogf.org [mailto:nsi-wg-bounces@ogf.org] *On Behalf Of *Inder Monga *Sent:* Friday, July 22, 2011 7:24 PM *To:* NSI WG *Subject:* [Nsi-wg] Fwd: Describing Topologies

Cross posting this on the NSI mailing list as well.

Inder

------------------------------------------------------------------------

*From:*Jeroen van der Ham <vdham@uva.nl> <mailto:vdham@uva.nl> *Date:* July 22, 2011 9:15 AM *To:* "automatedgole-pilot@internet2.edu" <mailto:automatedgole-pilot@internet2.edu> <automatedgole-pilot@internet2.edu> <mailto:automatedgole-pilot@internet2.edu> *Subject:* Describing Topologies

Hello,

Attached is a document describing how to create topology descriptions as Gerben presented last week.

The description shows how to create these in Notation3 format, which is a very user-friendly format for writing out RDF. Numerous validators and converters to RDF/XML exist, for example: http://www.rdfabout.com/demo/validator/

You can also use the graphical editor at http://auto-gole.appspot.com/

Unfortunately I'm going to miss all the fun, because I'll be away on holiday. Some of my colleagues will monitor this list should you have any questions about the descriptions. Please share the finished descriptions also on this list so that we can all see who finished them, and that I can later use them.

As a first incentive, I'm attaching the UvALight description, and I'm sure that Hans will forward the Netherlight description soon enough also.

Jeroen.

_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg