21 Jan
2010
21 Jan
'10
5:26 a.m.
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