[Nsi-wg] Path Object information/function

[Jerry Sobieski]

John Vollbrecht wrote:
> The big issue with this in my mind is that adjacency as you define 
> depends on a particular topology.  If the topology is hierarchical or 
> perhaps different for different providers, then what is adjacent for 
> one may not be adjacent for another.    I don't think we want to 
> define topology in order to define what we mean by path terms, at 
> least if we can avoid it.  Does that make sense?
>
> John
>
Hey John-  
Two points: 
a)  The adjacency definition still works even for hierarchical topologies.
b) you cannot describe a "path" without some model of the topology (or 
graph) over which that path exists.

If two nodes are connected by a link, then they are adjacent.  By 
Definition.   This comes from our definition of a Link as being an edge 
in the topology graph and representing a "connection" between two 
nodes.   How you define the nodes or what topology they may 
hide/summarize is immaterial. And whether that link is predicated over 
some underlying infrastructure is also immateral.

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

Even in our multi-layer networks, adjacency is still defined by the 
existence of a link between two nodes.   The only precondition on this 
is that the link between those two nodes imposes no requirements on 
tours (pathfinding) through the topology.   In reality, the topology 
must often express more detail than simply physical hardware boxes - for 
instance, a Ciena CoreDirector would be expressed as several nodes in 
the topology - perhaps summarized into a single virtual node, but the 
pathfinding process must still consider, at some level, the functional 
elements/resources that exist inside the physical box (virtual node) 
that are necessary for establishing a connection through the node.  
Indeed, we may need to define totally virtual topological elements that 
represent  protocol conversions and adaptations if path finding is to 
work end to end...but this can still be done within a very simple graph 
oriented, possibly hierarchical, topology model.

So, for NSI's part, we *do* need to make some assertions about how the 
NSAs relate to topology.  This will require a topology model.  IMO this 
should be a very simple high evel model, but one that nevertheless is 
very generalized and can scale well.  Details of the topology database 
or the syntax or structure of a topology description or distribution 
processes are not our role...but the basic topology environment in which 
we expect the NSA to operate is within scope.

If PathFinding is a concern for NSI, then we must necessarilly have some 
topological model that we subscribe to.   Topology and PathFInding are 
intricately linked - you can not speak of one without some implications 
for the other.   For instance, we can not even begin to discuss Tree vs 
Chain models without some assumptions about topology.   What are those 
assumptions?  We must stipulate a knowledge of and/or responsibility for 
some portion of the topology if we expect the NSA to do anything of 
substance.   And if you have anything less that one global Master 
Control NSA, then you introduce issues about how two or more NSA would 
interact to effect a global service - which again implies something 
about topology.   So NSI Architecture is fundamentally dependent upon 
some basic topology model - we should define and describe that model and 
then describe how the NSI protocol(s) operate in the context of that model.

Not to put too fine a point on this, even just specifying End Points for 
a connection request stipulates some notion of topology.  What is an 
"End Point" or a "Service Termination Point"?   Even just deciding if an 
STP is in our domain or a foreign domain implies some concept of what 
the topology looks like and how it functions...  Making any intelligent 
decision about breaking a connection request into component segments 
requires some knowledge of topology.  So what topological properties are 
necessary to allow the NSA to function in this manner?   We really can't 
talk about Paths or PathFinding without some associated topology model.

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?

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20100129/d666b016/attachment.html