[Nsi-wg] Fwd: Describing Topologies
Jerry Sobieski
jerry at nordu.net
Mon Jul 25 23:19:59 CDT 2011
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 at man.poznan.pl
> <mailto:radek.krzywania at man.poznan.pl> Networking Center
>
> +48 61 850 25 26 http://www.man.poznan.pl
>
> ________________________________________________________________________
>
> *From:*nsi-wg-bounces at ogf.org [mailto:nsi-wg-bounces at 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 at uva.nl> <mailto:vdham at uva.nl>
> *Date:* July 22, 2011 9:15 AM
> *To:* "automatedgole-pilot at internet2.edu"
> <mailto:automatedgole-pilot at internet2.edu>
> <automatedgole-pilot at internet2.edu>
> <mailto:automatedgole-pilot at 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 at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20110726/88538d45/attachment-0001.html
More information about the nsi-wg
mailing list