[Nsi-wg] Path Object information/function

[John Vollbrecht]

CTP is Connection Termination Point  -- as opposed to STP or Service  
Termination Point --   :)


On Jan 21, 2010, at 11:45 AM, Joan A. Garcia-Espin wrote:

> Thanks Jerry, it's a thorough description!
>
> Nevertheless, the definition of STPs is not 100% clear to me, and I  
> understand John's concerns regarding this.
> As you described, Jerry, STPs may be understood as "pointers" to the  
> service interface of the entities (NSA) that are in charge of the  
> path. In other words, the URL or Service ID of the NSAs, which in  
> any case belong to the service plane, rather to the transport plane.
> I'm not against this, on the contrary, I agree to have STPs in the  
> PO definition. In this case, the PO shows also a list of service  
> entities along the path.
>
> At this point I wonder if the PO is the service plane equivalent of  
> the ERO on the data/transport plane. Obviously, PO and ERO should  
> not have a 1:1 mapping, since PO (using the sub-pathing feature)  
> allows hiding parts of the service plane to unauthorised requesters.
>
> One more issue, I find the sub-pathing capability specially  
> interesting for security (authorisation) issue (who can/cannot  
> request info about a service along a given NSA, etc.).
>
> @John, what does CTP  (C* Transit Points) stand for? Most probably  
> it comes from the call I missed, sorry about that!
>
> regards,
> --
> Joan A. García-Espín
> CTX, i2CAT Foundation
>
>
>
>
>
> El 20/01/2010, a las 21:26, John Vollbrecht escribió:
>
>> 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
>>
>> _______________________________________________
>> nsi-wg mailing list
>> nsi-wg at ogf.org
>> http://www.ogf.org/mailman/listinfo/nsi-wg
>