[Nsi-wg] Path Object information/function

[Inder Monga]

> 
> 
> 
> So in closing, we should perhaps have a section in the NSI Architecture doc that clearly and succinctly describes the contextual topology model over which the NSI is defined and operates.   This needn't be a long section, and should be fairly high level, but I think explicitly describing the topo model allows us to describe how NSAs and NRM and STPs relate to the transport plane we purport to manage.  Thoughts?
> 

My assumption had been that these are well understood concepts that need not have a separate section, but now I feel a high-level description is warranted. It would be good to supplement it with external references. 

> In practice, a "hierarchical" node simply hides its internal topology and only expresses itself as a single virtual node (or a set of virtual nodes nodes with some abstracted topology.)    From a topological perspective, those virtual nodes are still "nodes" and still have "links" to other nodes.  And so, that virtual node is still adjacent to the other nodes at the ends of those links.  That single virtual node must still be consulted in order to reserve a path though it.   (Of course the NSA (or NRM) responsible for that virtual node must still consult the internal nodes that comprise the opaque internal topology - but that is invisible to the external agents.)  

This is how the implementation was in the DRAC project I was involved with. Multi-layer path-finding is implemented in this context as well -  intermediate topology of a lower layer can be abstracted as a virtual node or link at a higher layer. Usually in today's networks, since the layers are fixed/provisioned, narrowing down to an optimal path, within a particular contextual topology is easier. When these multi-layers have agility i.e. topology can be changed on demand at each layer, that is when the optimal path decision process becomes quite complex. In this situation full-understanding and representation of the capabilities and constraints of the virtual nodes within the topological model becomes required. This is a research topic in itself and I would not want to go in such detail in the architecture spec.

Inder



> Jerry
>> On Jan 27, 2010, at 8:36 PM, Jerry Sobieski wrote:
>> 
>>> Hi John-
>>> 
>>> I am deleting some of the text to make the email a bit more readable...
>>> 
>>> John Vollbrecht wrote:
>>>> 
>>>>> Jerry wrote:
>>>>> Not sure what you mean here...  From Jeroen's comments, we might have two indicator bits: one that says "This hop is strict", and a second that says "This hop is required".   The former means that this hop should be and is expected to be adjacent to the previous hop within the service transport layer.  
>>>> 
>>>> So adjacent needs to be defined.  Do you mean ordered, in the sense that other hops might be inserted but the order must be correct?  This might be the case where a high level set of POs might be requested and these might later include lower (hierarchically) paths.  Or is there a definition of adjacent that requires lowest level POs (and what is lowest)?
>>>> 
>>> "Adjacent" means "directly next to each other."   I will get pedantic now(:-):  Two vertices in a graph are adjacent if they are connected by an edge.   Within our network topology model, two Nodes, A and B, are adjacent if there exists a Link in the toplogy that has one endpoint on A and the other endpoint on B.   A Link, which represents an immutable transparent transport conduit between two Nodes in the topology,  by definition, establishes adjacency between those two nodes.
>>> 
>>> In the PO, a "strict" hop means simply that the path from hop(k) to hop(k+1) transits no (zero) intervening nodes. i.e. hop(k) and hop(k+1) should be or are expected to be adjacent in the topology.    The latter hop, the k+1 hop in this example, would be flagged as "strict" in this case.     In the PO, the order of the hops is important, but the strict/loose tagging only implies something about the possible presence or absence of intervening nodes. 
>>> 
>>> To be clear about adjacency, if a Link in the topology is realized over lower layer infrastructure - even if that infrastructure itself is part of the topologyDB - the Link still constitutes adjacency since the underlying supporting infrastructure is transparent to the layer at which the Link is defined in the topology (i.e. the nodes it connects).  This allows us, for example, to allocate a GFP/SDH circuit over an SDH cloud and define the resulting ethernet connection in the topology as an Ethernet Link forming an adjacency between two Ethernet Nodes. 
>>> 
>>> Jerry
>> 
> _______________________________________________
> 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/20100129/61d101b6/attachment-0001.html