Hi all-

Here are some thoughts on why I think the notion of a "Point" does have merit in an NSI topology model:

"Nodes" and "Links" in our current discussions represent resource objects that exist in the physical transport topology.   Both objects have physical characteristics (e.g. latency, a transfer function, bit error rates, etc.), and both have "Ports" (I/O interfaces) that move data streams into or out of each respective object.   And, a resource could be a grouped and summarized object that hides a great deal of internal topology and/or performs a complex transfer function (more on this in a moment).

It makes sense (and reflects reality) to say that all Nodes and Links are in fact owned by one domain or another...no such thing really as a free Link.   We should be able to represent this in our model.  I think a "Point" construct - i.e. a Touch Point or Tangent Point does this rather nicely. (Admittedly, I had to be convinced myself that such a construct was useful and could work.)

So, given that two networks meet at such a point, how do we indicate that a Port from network A connects to a Link in network B?

A convenient way that has been explored in the literature is a derivative graph (sometimes called a Channel Graph): each physical component of the topology (i.e. the Nodes and Links) is reduced to a generalized "Resource" object with a corresponding set of Ports.  For instance a Link becomes a Resource with one input Port and one output Port and some physical characteristic(s) e.g. latency.    Ports are joined together through this notion of a "Point".  A Point is a topological object that ties one or more Ports together indicating that they represent the same location topologically speaking (physically speaking, this might indicate that a fiber Link is plugged into a switch Node/Port interface)

In a sense, a Point has no physical characteristics besides the Ports that make up the Point.  Resources ( physical Nodes and Links) have physical characteristics associated with them.  But our Point construct simply ties a number of Ports together - the characteristics of that Point are wholly derived from the characteristics of the constituent Ports.   A Point could in fact reference other Points as well as Ports - any/all such Points and their consituent Ports are all topologically equivalent.

In a practical sense, these Points could in fact be the Service Termination/Transit Points (STPs) we have alluded to in our discussions. (Even if we ultimately name them something else, the idea remains the same.)   Further, the recognition of a Point object allows us to locate all Ports that are joined together (think of a broadcast domain).    A Port construct would refer to a Point construct that would in turn refer to (list) all Ports that are joined at that Point.   A Path can then be found by searching from Start Point to Port to Resource to Port to Point to Port to Resource to Port to Point to ...  very clean...(IMO).

We can think of a Point as a topological construct that expresses purely connectivity (topological equivalence), where as a Link is a physical resource object or node in the physical network topology.  This subtle and seemingly minor distinction keeps all of our physical constraints in the Resources and/or their Ports, and puts the topological structure in the Points.  (It could be argued that this reduction actually means a Point should be called a link, but good grief...:-)  In the Inter-Domain topology papers and standards, a "point" where two networks meet makes a certain amount of sense...).

Finally, a set of contiguous Resources could be grouped together into a larger object.  This larger object could be another Resource object - thus creating a nesting of Resources to summarize and/or hide complexity.  There needs to be a method of mapping internal Ports to the external Ports of such nested Resource objects - Points do this nicely without requiring internal Port references to leak out to external agents... These larger scale Resource objects could be refered to as "Network" objects if we chose - it does not change their structure or function, but indicates a relationship of the larger scoped object to the internal components.  E.g. "A Network is a Resource object made up of other [sub-]Resources."

This modified NSI topology model may be implemented internally differently in various NSI implementations.   Its not absolutely necessary that NSI use the NML topo model in its pristine form to describe our architecture.  Nor is it necessarily the case that NML needs to make any changes to their model to accomodate NSI model.    In fact, it is not it required that NSI implementations use either the NSI or NML topology internally in an implementation.         NSI only needs to state the topology model it uses to describe the NSI architecture semantics and protocol - which does not place any requirements on implementers to build internal structures that must resemble this.  How an implementation represents its topology internally is not our concern- the implementers just need to understand how they map NSI semantics to their implementation so that they express the same semantic value.

I think if we describe the NSI topology as a reduction of physical Nodes and Links to the their Resource state, then a topology of Resources, Ports, and tangent Points is (IMO) easily understood.  I include a diagram of how all this can be diagramatically denoted...

Hope this helps...
Jerry

Jeroen van der Ham wrote: 
On 21/02/2010 18:20, John Vollbrecht wrote:
  
Attached is set of ppt slides to describe interdomain topology.  I
hope this helps - it is based on conversations in the NML group, and
is my understanding of what the Glossary of terms that Guy is
reviewing (and I think will review next Wed).
    

I just want to clarify my view of the conversation we have had in the 
NML group about this issue. This was mainly a discussion between myself 
and John wherein I tried to understand the NSI issue of describing 
inter-domain topologies.

The current NML topology model does not have "Points". Nor do we 
currently have plans to add them. *Unless* there is a use-case showing 
the need of Points, which clearly outlines why it is not possible to 
describe domain boundaries with the current NML Topology model. So far, 
I have not seen such a clear and valid use-case for "Points".

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