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. - 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). - A "fully specified" path identifies the complete set of STPs - in order - that a connection transits from ingress to egress. - 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. 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.