22 Jan
2010
22 Jan
'10
2:42 a.m.
See comments in line... John Vollbrecht wrote: > 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. > My reasoning is that the "service" terminates at certain points in the topology - whether or not a connection is active. The service can be delivered to those points. While these are point in the tranport plane, they represent those locations at the edge of a contiguous service domain. Once a service instance is established, i.e. a circuit or connection, then the end points of that connection could be called "connection Termination points". But I do not think CTP is adequate when refering to the set of points that are reachable by the overall service. BTW & FYI- GN3 is using the term Service Demarcation Point "SDP" in the inter-domain service architecture document. > > 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? This is a proposal - AFAIK it is new idea to support a means of describing a Path as containing one or more "path segments" which are implied to be concatenated (although the concept is found in many other areas of tree structures and linked lists) This notion requires that the Path Object have a handle that can be resolved to find a structure or database record(s) that describe the subpath in terms [ultimately] of STPs. If you look at the form of the Path Object I proposed, it should ultimately resolve into a list of STPs once all the sub-paths are expanded. And further, a PO must contain at a minimum two STPs - the ingress and egress STPs. >> >> - 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? Hmmm... a path object refers to a sequence of points in a topology. There is nothing in the path object itself that states the purpose or context within which the path object was built or can/should be used. Therefore, we can not assume that the notion of proceeding from point A to point Z is equivalent if posed as proceeding from Z to A. Indeed, the reverse path might be useful in some context, but we cannot assume that always (or ever) to be the case. Reversability is a function of the context in which the PO is used. > >> - 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 IN theory, a fuly specified Path Object would enumerate every valid service transit/termination point that the path traverses. In practice, this will likely never be attainable since much of the path detail is local within each domain and in some cases may not be relevant (take the case of the reseller connection being reallocated - is this resold connection a concatenated part of the user connection? or is it a tunnel thru which the user sees simply the two end STPs?) So it may not be terribly important to define a "fully" specified path object as it may not be something one can discern by looking at it, or will likely ever actually see in the wild. But the notion of "pinned" paths - i.e. loose hop paths or partially specified paths - is important. >> - 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. In terms of NSI, and in particular the NSI "Connection Service", I think we need to discuss and define what an NRM will expect and return. We interact with an NRM to reserve resources we know that NRM is responsible for - which means we have some topology information that tells us this. So if our path finding suggests we'd like to at least try to allocate those resources, we can only specify them to the extent they exist in our topology DB. If as we stipulated yesterday that the NRM uses an NSI protocol to communicate with a higher tier NSA, then we use the same NSI notions of STP and to describe the Path once it is confirmed. It is the NRMs responsibility to do any hardware specific munging necessary to return an NSI compliant Path confirmation. > > >> 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. > In the Chain Model, the path is nominated and explored forward, but confirmed backward. The Path Object is actually built backwards as the local [confirmed] portion of the path is prepended to the confirmed downstream portion of the path, and the resulting path object confirmed and returned upstream towards the originating requester. The Path Object structure itself may be manipulated in lots of ways - it may be built forward or backward or from the center as requests or confrmations are sent/received, it may be editted and/or expanded or reduced based on lots of different needs or processes. And I can see there would be intermediate or temporary path objects that might be necessary during path finding/reserving process, or for other related processes. How it is constructed will be a function of the process that constructs it, but thats perfectly fine. Ultimately, a valid Path Object should provide information describing a tour through a topology. I suggest this should be an ordered sequence of points that the tour must/does transit. And it must minimally have a starting point and and ending point. For NSI purposes, I suggest that the PO should consist of two basic path elements: 1) an actual transit point, and 2) an element that refers to another [sub] path object. Note: while the path object must provide path information, this does not mean that all path information in a path object must be exposed to all agents. We could say the path object should be able to provide the technical path information to a duly authorized agent. So the subpath object would be an implicit means of forcing an agent to obtain authorization in order to access the technical path data in that PO. Technically, I think the subpath may also be useful for things like protection and SRLG handling, etc. Further, We should differentiate a "Connection Object" from a "Path Object". The former will likely contain one or more of the latter. I.e. A Connection may be comprised of both a forward Path Object, and a backward Path Object. It is important to keep the characteristics of a circuit or a Connection separate from the object that specifies the path. Another complexity we may need to address n the future is point-to-multipoint Connections and how we describe those circuits and the paths that make them up. Hope all this sounds lucid:-) Jerry