[Nml-wg] About modelisation of the network description
Aaron Brown
aaron at internet2.edu
Wed Mar 5 15:18:30 CST 2008
Freek Dijkstra wrote:
> Evangelos Chaniotakis wrote:
>
>
>> I'm on the fence as to whether we need a separate "network" concept.
>> We might need to model administrative domains that run multiple
>> independent networks.
>>
>
> You totally convinced me. So:
>
> DOMAIN = administrative domain = an organisational entity that is
> responsible for the operational control of resources (including network
> resources)
>
> NETWORK = a collection of network elements that behaves as a single
> resource (it is possible to describe the functionality without exposing
> the internal implementation or detailed internal limitations)
>
So how would a network in this context be meaningfully different than a
node? A node is some entity with a set of interfaces to the outside
world. With this definition, a node could correspond to a domain, a
network element, some arbitrary group of network elements, etc.
Basically, as long as it's a thing or group of things with a set of
interfaces to the outside world, it can be reasonably described as a
node. The major benefit of the node model is that there's no real
difference between specifically described elements and summarized
elements. They look like nodes with interfaces and links in both cases
which on some level is true. No matter how specified you've gotten,
you're going to be summarizing something (e.g. in a router, you'd have a
number of logical node-entities interconnected with a bunch of logical
links, all of which is abstracted away behind a 'node'). It also
analogizes to how the links are summarized. A high-level link is made up
of a bunch of lower level elements underneath in the same way that a
high-level 'node' is made up of a bunch of lowel level elements.
In this view, you might have elements like so to describe the nodes in a
certain pop connecting esnet, geant and canarie:
<domain name="Internet2">
<!-- the definition of the physical elements -->
<node name="ciena1">
<port name="eth0">
<link name="link_to_ciena2" />
</port>
<port name="eth1">
<link name="link_to_ciena3" />
</port>
<port name="eth2">
<link name="link_to_esnet" />
</port>
</node>
<node name="ciena2">
<port name="eth0">
<link name="link_to_ciena1" />
</port>
<port name="eth1">
<link name="link_to_ciena3" />
</port>
<port name="eth2">
<link name="link_to_canarie" />
</port>
</node>
<node name="ciena3">
<port name="eth0">
<link name="link_to_ciena1" />
</port>
<port name="eth1">
<link name="link_to_ciena2" />
</port>
<port name="eth2">
<link name="link_to_geant" />
</port>
</node>
<!-- the definition of a pop -->
<node name="pop1">
<port name="virtual_eth0">
<link name="virtual_link_to_canarie" />
</port>
<port name="virtual_eth1">
<link name="virtual_link_to_canarie" />
</port>
<port name="virtual_eth2">
<link name="virtual_link_to_geant" />
</port>
</node>
</domain>
Then, you pass around pop1 to the interested parties as well as give it
attributes the same way you might give a node attributes (who is the
administrator for this pop, etc), and if they so desire, they can look
up the elements that actually make up the pop (those pointers would be
included in each of the elements, but they're left out of the example
for brevity). The virtual ports could also include as much information
as the physical ports that make them up so that they could easily be
used for path finding or whatever.
I think the view model is a great idea for getting a specified slice of
a set of elements(what are the elements I need to monitor? what does a
layer3 view of the network look like?). I'm just not sure it's the best
as a summarization technique. i.e. why should it be materially different
for me to do pathfinding if i have a full network topology information
(nodes + ports + links for everyone) vs. summarized network information
(my nodes + ports + links and views for everyone else's topologies).
What are people's thoughts on this?
Cheers,
Aaron
More information about the nml-wg
mailing list