[Nsi-wg] NML topology
Inder Monga
imonga at es.net
Tue Feb 23 01:11:54 CST 2010
Hi All,
Jerry I like the way you have differentiated the concepts. We have
multiple topology representations here - the physical transport
topology and the abstracted Service Topology constructs.
> "Nodes" and "Links" in our current discussions represent resource
> objects that exist in the physical transport topology. Both
> objects have physical characteristics (e.g. latency, a transfer
> function, bit error rates, etc.), and both have "Ports" (I/O
> interfaces) that move data streams into or out of each respective
> object.
The Physical topology model - model of theTransport Plane - consists
of Nodes, Ports, Links, among other adaptation and topology constructs
that are being defined by NML. EROs can be defined in terms of these
objects and pathfinding over the transport topology can be done. IMHO,
we do not need additional complexity, naming and addressing (the
fallout of adding another concept) to appear in the transport plane
topology. Can we all agree on this?
> It makes sense (and reflects reality) to say that all Nodes and
> Links are in fact owned by one domain or another...no such thing
> really as a free Link. We should be able to represent this in our
> model. I think a "Point" construct - i.e. a Touch Point or Tangent
> Point does this rather nicely. (Admittedly, I had to be convinced
> myself that such a construct was useful and could work.)
What you bring up here is the interesting merger of policy with
topology (as Freek also mentioned in his response). The existence of
the ownership policy is external to the physical transport topology
and does not need to be modeled within the transport topology. My
conjecture is that this policy resides within the Service Plane. So,
if we do have to discuss how to represent a joint policy-topology
representation, it needs to exist within the Service Plane and the NSI
group should do on top of how and what NML uses to define the
transport plane topology. This will help NML get unstuck and move
forward, AND come up with a comprehensive set of physical topology
constructs that an NRM can use.
Coming back to the point about "points" - it is clear that this
concept has emerged due to the NEED to define an ownership attribute
of a resource, since each resource is owned ONLY by a single NRM.
One way to define an ownership attribute is to put this as an
additional attribute of the resource object. This is consistent with
current Service Plane where we use additional characteristics of the
resource like latency, capacity, existing reservations schedule aka
time etc. to implement the Path computation and scheduling function.
The other way is to keep the concept of "points" in the service plane
aka the "Service Termination Point" (STP). Service Termination Point
can represent both the ownership aspects and can be mapped onto a Node/
Port on a Transport plane topology. In the service plane, a NSI
request from the client would go from a source STP to a destination
STP and over intermediate STPs, if so defined in the ERO. These STPs
would define the inter-domain exchange points and would be mapped by
the NRM onto a {Port-Link-Port} group that exists from a physical
perspective to interconnect the two domains.
To summarize my point of view:
A. Lets separate the physical topology representations (NML) from the
service topology abstractions (aka STP).
B. Let us use the NML representations of the physical topology as a
common layer for resource provisioning, path-finding (and even multi-
layer pathfinding) on the physical plane.
C. Let us look at the ownership policy aspects as an additional
constraint along with capacity/time/scheduling set of constraints that
apply to links and ports.
D. Lets re-examine the need for Points, if necessary, within that
Service Plane context.
Inder (wearing non-chair hat)
On Feb 22, 2010, at 3:52 AM, Jerry Sobieski wrote:
> Hi all-
>
> Here are some thoughts on why I think the notion of a "Point" does
> have merit in an NSI topology model:
>
> "Nodes" and "Links" in our current discussions represent resource
> objects that exist in the physical transport topology. Both
> objects have physical characteristics (e.g. latency, a transfer
> function, bit error rates, etc.), and both have "Ports" (I/O
> interfaces) that move data streams into or out of each respective
> object. And, a resource could be a grouped and summarized object
> that hides a great deal of internal topology and/or performs a
> complex transfer function (more on this in a moment).
>
> It makes sense (and reflects reality) to say that all Nodes and
> Links are in fact owned by one domain or another...no such thing
> really as a free Link. We should be able to represent this in our
> model. I think a "Point" construct - i.e. a Touch Point or Tangent
> Point does this rather nicely. (Admittedly, I had to be convinced
> myself that such a construct was useful and could work.)
>
> So, given that two networks meet at such a point, how do we indicate
> that a Port from network A connects to a Link in network B?
>
> A convenient way that has been explored in the literature is a
> derivative graph (sometimes called a Channel Graph): each physical
> component of the topology (i.e. the Nodes and Links) is reduced to a
> generalized "Resource" object with a corresponding set of Ports.
> For instance a Link becomes a Resource with one input Port and one
> output Port and some physical characteristic(s) e.g. latency.
> Ports are joined together through this notion of a "Point". A Point
> is a topological object that ties one or more Ports together
> indicating that they represent the same location topologically
> speaking (physically speaking, this might indicate that a fiber Link
> is plugged into a switch Node/Port interface)
>
> In a sense, a Point has no physical characteristics besides the
> Ports that make up the Point. Resources ( physical Nodes and Links)
> have physical characteristics associated with them. But our Point
> construct simply ties a number of Ports together - the
> characteristics of that Point are wholly derived from the
> characteristics of the constituent Ports. A Point could in fact
> reference other Points as well as Ports - any/all such Points and
> their consituent Ports are all topologically equivalent.
>
> In a practical sense, these Points could in fact be the Service
> Termination/Transit Points (STPs) we have alluded to in our
> discussions. (Even if we ultimately name them something else, the
> idea remains the same.) Further, the recognition of a Point object
> allows us to locate all Ports that are joined together (think of a
> broadcast domain). A Port construct would refer to a Point
> construct that would in turn refer to (list) all Ports that are
> joined at that Point. A Path can then be found by searching from
> Start Point to Port to Resource to Port to Point to Port to Resource
> to Port to Point to ... very clean...(IMO).
>
> We can think of a Point as a topological construct that expresses
> purely connectivity (topological equivalence), where as a Link is a
> physical resource object or node in the physical network topology.
> This subtle and seemingly minor distinction keeps all of our
> physical constraints in the Resources and/or their Ports, and puts
> the topological structure in the Points. (It could be argued that
> this reduction actually means a Point should be called a link, but
> good grief...:-) In the Inter-Domain topology papers and standards,
> a "point" where two networks meet makes a certain amount of sense...).
>
> Finally, a set of contiguous Resources could be grouped together
> into a larger object. This larger object could be another Resource
> object - thus creating a nesting of Resources to summarize and/or
> hide complexity. There needs to be a method of mapping internal
> Ports to the external Ports of such nested Resource objects - Points
> do this nicely without requiring internal Port references to leak
> out to external agents... These larger scale Resource objects could
> be refered to as "Network" objects if we chose - it does not change
> their structure or function, but indicates a relationship of the
> larger scoped object to the internal components. E.g. "A Network is
> a Resource object made up of other [sub-]Resources."
>
> This modified NSI topology model may be implemented internally
> differently in various NSI implementations. Its not absolutely
> necessary that NSI use the NML topo model in its pristine form to
> describe our architecture. Nor is it necessarily the case that NML
> needs to make any changes to their model to accomodate NSI model.
> In fact, it is not it required that NSI implementations use either
> the NSI or NML topology internally in an implementation. NSI
> only needs to state the topology model it uses to describe the NSI
> architecture semantics and protocol - which does not place any
> requirements on implementers to build internal structures that must
> resemble this. How an implementation represents its topology
> internally is not our concern- the implementers just need to
> understand how they map NSI semantics to their implementation so
> that they express the same semantic value.
>
> I think if we describe the NSI topology as a reduction of physical
> Nodes and Links to the their Resource state, then a topology of
> Resources, Ports, and tangent Points is (IMO) easily understood. I
> include a diagram of how all this can be diagramatically denoted...
>
> Hope this helps...
> Jerry
>
> Jeroen van der Ham wrote:
>>
>> On 21/02/2010 18:20, John Vollbrecht wrote:
>>
>>> Attached is set of ppt slides to describe interdomain topology. I
>>> hope this helps - it is based on conversations in the NML group, and
>>> is my understanding of what the Glossary of terms that Guy is
>>> reviewing (and I think will review next Wed).
>>>
>>
>> I just want to clarify my view of the conversation we have had in the
>> NML group about this issue. This was mainly a discussion between
>> myself
>> and John wherein I tried to understand the NSI issue of describing
>> inter-domain topologies.
>>
>> The current NML topology model does not have "Points". Nor do we
>> currently have plans to add them. *Unless* there is a use-case
>> showing
>> the need of Points, which clearly outlines why it is not possible to
>> describe domain boundaries with the current NML Topology model. So
>> far,
>> I have not seen such a clear and valid use-case for "Points".
>>
>> Jeroen.
>> _______________________________________________
>> nsi-wg mailing list
>> nsi-wg at ogf.org
>> http://www.ogf.org/mailman/listinfo/nsi-wg
>>
> <Derived Graphs.pptx>_______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20100222/17496406/attachment-0001.html
More information about the nsi-wg
mailing list