[Nsi-wg] Path Object information/function

[John Vollbrecht]

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.


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?
>
> - 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?

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


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

John


>
>
>
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg