[Nsi-wg] Path Object information/function

[Jerry Sobieski]

See comments in line...

John Vollbrecht wrote:
> This is very good - thank you very much.  Some comments in line -- 
> except one here -- I like the name CTP rather than STP.  A major 
> reason is that this is on the transport plane, not the service plane, 
> and calling it service termination seems to me to imply service 
> plane.  I leave this discussion to later as it doesn't affect the meat 
> of the discussion.
>
My reasoning is that the "service" terminates at certain points in the 
topology - whether or not a connection is active.    The service can be 
delivered to those points.  While these are point in the tranport plane, 
they represent those locations at the edge of a contiguous service 
domain.     Once a service instance is established, i.e. a circuit or 
connection, then the end points of that connection could be called 
"connection Termination points".   But I do not think CTP is adequate 
when refering to the set of points that are reachable by the overall 
service.  

BTW & FYI-   GN3 is using the term Service Demarcation Point "SDP" in 
the inter-domain service architecture document.
>
> On Jan 20, 2010, at 2:24 PM, Jerry Sobieski wrote:
>
>> 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.
> - are there existing examples of this or is it a proposal?
This is a proposal - AFAIK it is new idea to support a means of 
describing a Path as containing one or more "path segments" which are 
implied to be concatenated (although the concept is found in many other 
areas of tree structures and linked lists)  This notion requires that 
the Path Object have a handle that can be resolved to find a structure 
or database record(s) that describe the subpath in terms [ultimately] of 
STPs.   If you look at the form of the Path Object I proposed, it should 
ultimately resolve into a list of STPs once all the sub-paths are 
expanded.   And further, a PO must contain at a minimum two STPs - the 
ingress and egress STPs.
>>
>> - 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).
>>
> does this have to do with pathfinding or is there something more to it?
Hmmm...  a path object refers to a sequence of points in a topology.  
There is nothing in the path object itself that states the purpose or 
context within which the path object was built or can/should be used.   
Therefore, we can not assume that the notion of proceeding from point A 
to point Z is equivalent if posed as proceeding from Z to A.  Indeed, 
the reverse path might be useful in some context, but we cannot assume 
that always (or ever) to be the case.   Reversability is  a function of 
the context  in which the PO is used.

>
>> -  A "fully specified" path identifies the complete set of STPs - in
>> order - that a connection transits from ingress to egress.
>>
> are these STPs for all resources in the path  that are controlled by 
> different NRMs
IN theory, a fuly specified Path Object would enumerate every valid 
service transit/termination point that the path traverses.   In 
practice, this will likely never be attainable since much of the path 
detail is local within each domain and in some cases may not be relevant 
(take the case of the reseller connection being reallocated - is this 
resold connection a concatenated part of the user connection? or is it a 
tunnel thru which the user sees simply the two end STPs?)   So it may 
not be terribly important to define a "fully" specified path object as 
it may not be something one can discern by looking at it, or will likely 
ever actually see in the wild.  But the notion of "pinned" paths - i.e. 
loose hop paths or partially specified paths - is important.
>> - 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.
>>
> I agree with this, but perhaps defining what is "required" and what is 
> "allowed" , especially in situations where a connection is made from 
> multiple RMAs in different provider agents.
In terms of NSI, and in particular the NSI "Connection Service", I think 
we need to discuss and define what an NRM will expect and return.   We 
interact with an NRM to reserve resources we know that NRM is 
responsible for - which means we have some topology information that 
tells us this.    So if our path finding suggests we'd like to at least 
try to allocate those resources, we can only specify them to the extent 
they exist in our topology DB.    If as we stipulated yesterday that the 
NRM uses an NSI protocol to communicate with a higher tier NSA, then we 
use the same NSI notions of STP and to describe the Path once it is 
confirmed.   It is the NRMs responsibility to do any hardware specific 
munging necessary to return an NSI compliant Path confirmation.

>
>
>> 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.
>>
>
> So, for something like the chain model where segments A-B-C are 
> included.  Typically provider A gets request, inludes ingress and 
> egress of A in the path and forwards the path in a request to B.  I 
> think the ingress and egress of A need to be either dropped or marked 
> as "not part of the request to B".  I think this might be done 
> explicitly or by implication, but would be good to define.
>
In the Chain Model, the path is nominated and explored forward, but 
confirmed backward.  The Path Object is actually built backwards as the 
local [confirmed] portion of the path is prepended to the confirmed 
downstream portion of the path, and the resulting path object confirmed 
and returned upstream towards the originating requester.    The Path 
Object structure itself may be manipulated in lots of ways - it may be 
built forward or backward or from the center as requests or confrmations 
are sent/received, it may be editted and/or expanded or reduced based on 
lots of different needs or processes.   And I can see there would be 
intermediate or temporary path objects that might be necessary during  
path finding/reserving process, or for other related processes.   How it 
is constructed will be a function of the process that constructs it, but 
thats perfectly fine.  

Ultimately, a valid Path Object should provide information describing a 
tour through a topology.  I suggest this should be an ordered sequence 
of points that the tour must/does transit.  And it must minimally have a 
starting point and and ending point.   For NSI purposes, I suggest that 
the PO should consist of two basic path elements: 1)  an actual transit 
point,  and 2) an element that refers to another [sub] path object.     
  Note: while the path object must provide path information, this does 
not mean that all path information in a path object must be exposed to 
all agents.   We could say the path object should be able to provide the 
technical path information to a duly authorized agent.   So the subpath 
object would be an implicit means of forcing an agent to obtain 
authorization in order to access the technical path data in that PO.  
Technically, I think the subpath may also be useful for things like 
protection and SRLG handling, etc.

Further, We should differentiate a "Connection Object" from a "Path 
Object".   The former will likely contain one or more of the latter.  
I.e. A Connection may be comprised of both a forward Path Object, and a 
backward Path Object.   It is important to keep the characteristics of a 
circuit or a Connection separate from the object that specifies the 
path.   Another complexity we may need to address n the future is 
point-to-multipoint Connections and how we describe those circuits and 
the paths that make them up.

Hope all this sounds lucid:-)

Jerry