[Nsi-wg] Path Object information/function

[Jerry Sobieski]

Here are some thoughts on what a "Path Object" (PO) should contain 
and/or be able to do...please read thru and think about this and let me 
know your thoughts.

Jerry



- A Path Object is an ordered list of service transit points (STPs) 
through which a connection passes. 

- A Path Object must have at least two STPs: The ingress STP, and the 
egress STP.

- A Path Object should allow a path to be described using "sub-paths" 
(i.e. other Path Objects) or pointers/tags that reference other  Path 
Objects.  

- A Path Object is direction sensitive.  I.e. The path is always 
interpreted as beginning at the first STP (the head of the list), and 
proceeding towards the last STP (the tail) in the list.   There is no 
implication that a path object is reversable (or bidirectional).

-  A "fully specified" path identifies the complete set of STPs - in 
order - that a connection transits from ingress to egress. 

- A "partially specified" path identifies a subset of STPs - in order - 
that the connection transits - but not necessarily every STP the 
connection transits.  THis is a "loose hop" path

- A partially specified path may contain STPs that are, individually, 
only partially specified.  For example, a path may contain a STP 
indicating a specific switching element to be transitted, without 
specifying the specific port or VLAN id to be used.  This could also be 
generalized to indicate something as general as an particular network to 
be transitted.   Alternatively, the path element may specify a "label 
set", i.e. a set of labels or STPs that can are acceptable within the 
context of that STP.  THis may be useful for conveying valid VLAN IDs or 
Wavelengths that may be available to path selection functions downstream 
or for end-to-end tagging information.

Path objects can be used in several ways: First, would be to specify 
constraints on a *proposed* path - i.e. must transit this switch, but 
port selection has full freedom.  Or must transit this previously defned 
path.  The path objects need wild card masks to indicate these 
constraints.   Second use is to define a connect "as built", i.e. after 
the cnnection is full specified and/or in service, a fully specified 
detailed Path Object would capture the entire detailed path - end-to-end 
but perhaps not fully exposed.

BNF format:

<Path_Object>  :=  <Path_Object_Header> <Path_List>

<Path_List>  := <STP>  ( <Path_Object> | <STP> ) +   |   <Path_Object>+   

Path elements can be STPs or Path Objects.  STPs represent topology 
locations, these will likely be something such as:  
<domain_identifier><pointID> or <dom><node><port><label><...>.   These 
will likely be alphanumeric strings, possibly parsable, or they may be 
binary structures...  Likewise with Path Objects - these will likely be 
something like <domain><objectID>.   The key concept however is that the 
Path Object contains two types of elements: service termination points 
that refer to points in the topology, and a path object tag that refer 
to another strucutre outside the current path object.  So each elemnt of 
the path list must have a type code to say what type of path element it 
is, and then a string to uniquely dentify that object within a local 
context, and a length that says how long the object tag is.