21 Jan
2010
21 Jan
'10
5:05 p.m.
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@ogf.org >>> http://www.ogf.org/mailman/listinfo/nsi-wg >> >> _______________________________________________ >> nsi-wg mailing list >> nsi-wg@ogf.org >> http://www.ogf.org/mailman/listinfo/nsi-wg >