[Nsi-wg] NML topology

[Jerry Sobieski]

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 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/20100222/55380c2c/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Derived Graphs.pptx
Type: application/vnd.openxmlformats-officedocument.presentationml.presentation
Size: 85810 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/nsi-wg/attachments/20100222/55380c2c/attachment-0001.bin