Hi All,

Jerry I like the way you have differentiated the concepts. We have multiple topology representations here - the physical transport topology and the  abstracted Service Topology constructs. 

"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.

The Physical topology model - model of theTransport Plane - consists of Nodes, Ports, Links, among other adaptation and topology constructs that are being defined by NML. EROs can be defined in terms of these objects and pathfinding over the transport topology can be done. IMHO, we do not need additional complexity, naming and addressing (the fallout of adding another concept) to appear in the transport plane topology. Can we all agree on this?

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.)

What you bring up here is the interesting merger of policy with topology (as Freek also mentioned in his response). The existence of the ownership policy is external to the physical transport topology and does not need to be modeled within the transport topology. My conjecture is that this policy resides within the Service Plane. So, if we do have to discuss how to represent a joint policy-topology representation, it needs to exist within the Service Plane and the NSI group should do on top of how and what NML uses to define the transport plane topology. This will help NML get unstuck and  move forward, AND come up with a comprehensive set of physical topology constructs that an NRM can use. 

Coming back to the point about "points" - it is clear that this concept has emerged due to the NEED to define an ownership attribute of a resource, since each resource is owned ONLY by a single NRM.
 One way to define an ownership attribute is to put this as an additional attribute of the resource object. This is consistent with current Service Plane where we use additional characteristics of the resource like latency, capacity, existing reservations schedule aka time etc. to implement the Path computation and scheduling function. 

The other way is to keep the concept of "points" in the service plane aka the  "Service Termination Point" (STP). Service Termination Point can represent both the ownership aspects and can be mapped onto a Node/Port on a Transport plane topology. In the service plane, a NSI request from the client would go from a source STP to a destination STP and over intermediate STPs, if so defined in the ERO. These STPs would define the inter-domain exchange points and would be mapped by the NRM onto a {Port-Link-Port} group that exists from a physical perspective to interconnect the two domains.

To summarize my point of view:  
A. Lets separate the physical topology representations (NML) from the service topology abstractions (aka STP). 
B. Let us use the NML representations of the physical topology as a common layer for resource provisioning, path-finding (and even multi-layer pathfinding) on the physical plane.
C. Let us look at the ownership policy aspects as an additional constraint along with capacity/time/scheduling set of constraints that apply to links and ports.  
D. Lets re-examine the need for Points, if necessary, within that Service Plane context. 

Inder (wearing non-chair hat)

On Feb 22, 2010, at 3:52 AM, Jerry Sobieski wrote:

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
<Derived Graphs.pptx>_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org
http://www.ogf.org/mailman/listinfo/nsi-wg