[Nml-wg] Network and domain abstractions

[John Vollbrecht]

I would like to pursue the concept of view or model.  My primary  
interest is in terms of how the dynamic circuit path finding and path  
creation will use a topology description.

My thought on how this would work, which may be different than  
everyone else's, is something like the following.  This is very rough  
- I offer it for discussion.  The definitions need work, but I hope  
it gives the idea of what I think would be good in a "model or  
view".  I may also misunderstand this, so please correct if needed.

1. A "real" topology exists which describes real devices, interfaces,  
and links.  It includes parameters like bw, latency, geographic  
location, and capabilities like switchint  or adaptation (e.g.  
mapping VLANS or doing GFP conversion between ethernet and SDH).

2. The "real" topology includes information about control of  
capabilities - the administrative owner(s), the operational owner(s),  
and any device that can activate the capabilities.

3. The real topology has groups - which might be called networks, or  
domains or both.  It is not clear exactly how this will work.

4. On and from this real topology there are derived "views or models"  
which are useful to different applications.  In my mind this ability  
to have a common real topology from which different views are created  
is very powerful.

DCN views

An Interdomain Controller is the DCN entity that controls circuit  
establishment over multiple domains.  A domain is the set of  
capabilities that are controlled by an IDC.

An internal topological view of a domain will include all the  
capabilities that are in a domain and the devices that contain the  
capabilites.  In the simple case this is all the nodes and links in  
the domain.

An external topological view of a domain includes the links to  
external domains and the internal device to which the link is  
connected.  It also includes the capabilities of the domain to act on  
external links.

A DCN internal pathfinding view contains Nodes and links for a  
domain.  The nodes and links may correspond to the real topology or  
may be virtual links that are created by combining connections  
between locations into a single link (e.g. 4 GEs between sites are  
treated as a single link for pathfinding purposes) or by splitting  
connections into different links (e.g. STS-1-48= link1, STS-49-96 =  
link2).

A DCN external pathfinding view contains domains and links between  
domains.  There is some question as to whether a domain should be  
abstracted to look like a node.  My view is that from a DCN  
operational view they are different.  routes inside domain are  
calculated between nodes.  routes between domains are calculated  
between edges of domains.

A DCN path request view includes resources in the request.  It will  
have parameters for the request (e.g. bw) but will also include  
specific resources that are available.  I am not sure if the elements  
in a path request need to have a topological name.  I have called  
these route objects - there is probably a better name.

A DCN circuit is a path with specific resources at each link and node  
in the path.  Perhaps there is a better name for this - e.g. it is a  
link.  From a DCN perspective it is different than the links that are  
used to create the circuit, and needs a name in the DCN view.

-- I am not sure how different the monitoring view would be.  If the  
intent is to monitor DCN then I am guessing the view would be the  
same, perhaps with some information about monitoring devices.

-- I am wondering how this plays with the idea of showing links to  
applications - perhaps the network view can be limited to showing  
where applications connect to the net.




On Mar 18, 2008, at 4:22 PM, Freek Dijkstra wrote:
> Hi Aaron, Evangelos and Aurélien,
>
> I wrote:
>
>> So I, Aaron, and Evangelos (and perhaps Aurélien and John if they
>> have the coureage) now have a moral obligation to summarize our
>> network / domain  / view discussion on the wiki, in order to save
>> others the ordeal of reading our entire flood of mails from two weeks
>> ago.
>
> I very much hope you are willing to help with this.
>
> I just made a first attempt at the wiki:
> https://forge.gridforum.org/sf/wiki/do/viewPage/projects.nml-wg/wiki/
> https://forge.gridforum.org/sf/wiki/do/viewPage/projects.nml-wg/ 
> wiki/Grouping
> https://forge.gridforum.org/sf/wiki/do/viewPage/projects.nml-wg/ 
> wiki/Interfaces
>
> I will try to re-read the rest of the mails, and see if there are  
> things to add (or better: perhaps we can eliminate some of the  
> controversies by reaching a consensus!). Please have a look in the  
> mean time, and add whatever you feel is important feedback you want  
> to give to the NML WG. I'd say this is your chance to enforce your  
> superior model on other mortal souls :-)
>
> Regards,
> Freek
>

John Vollbrecht, Senior Network Engineer
Internet2
office +1-734-352-4960 | mobile +1-734-395-7890