Network and domain abstractions
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/Groupin... https://forge.gridforum.org/sf/wiki/do/viewPage/projects.nml-wg/wiki/Interfa... 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
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
John Vollbrecht wrote:
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.
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).
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.
I agree with your statement that it is useful to talk about an actual network, knowing that it really is that network and not some abstract view. Could you define "real topology" for me? Is that a single network (controlled by a single domain), or is that all networks together? If it is all together -- I like to emphasize that I prefer that there is a concept of a common real topology, but no-one has full knowledge of this real topology (likely they have a full knowledge on the local domain, and abstracted views of other domains).
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.
Yes, and I would distinguish between the physical "network" class and the organisational "domain" class (which is the administrator of a network) A few notes on terminology: after discussions a couple of years ago, I now distinguish between - juridical owner - economic owner - administrator = operator Where the administrator is the same as the operator: the entity that enforces policies, and the economic owner is the entity that decides on policies.
3. The real topology has groups - which might be called networks, or domains or both. It is not clear exactly how this will work.
You previously said that you want to have a "common" real topology. Does the grouping of this real topology in domains should also be common? Thus is it the same for everyone, or could device A be in domain 8 for me, while it is in domain 11 for you? I hope there is such a common grouping of all network elements into networks, and everyone sees the same networks. However, I'm fine to have an additional "view" concept where other entities may see different views.
DCN views
[...]
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.
I do not see why it is necessary to know about the terminating device for links in the external view. It seems to me that all I need to know is the encoding of the link, the the capabilities of the domain ('network' in my terminology) to act on this link.
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).
Good. We need a discussion about links. But you seem to suggest that according to you a "link" is equal to a ITU-T G.805 "link connection" (that is, logical links). "Splitting" is not a word I would use though. Your example is pretty complex. Do you also want to be able to (a) say that the STS-1-48 link is composed of 48 distinct STS channels? (b) do you want to be able to say that link1 and link2 are in fact transported over the same OC-192? If so, you need rather detailed multiplexing and adaptation classes to describe this.
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.
So do you propose that we have a distinct "domain" and a "node" class? Could you define them for me, so I know the difference between the two?
routes inside domain are calculated between nodes. routes between domains are calculated between edges of domains.
I may do path finding in a completely different way (I may look at interfaces and the grouping in nodes/devices/domains altogether). I think such implementation details are firmly out of scope of the NML. What is in scope is that there is enough information for you to do the path finding.
I am not sure if the elements in a path request need to have a topological name.
How do you want to refer to an element? How other then it's name? (This is not a rethoric question! A valid answer may be "by it's properties".) Finally, you wrote in your first sentence that you "like to pursue the concept of view or model". Good. However, you only defined "internal topological view" and "external topological view". I think that this distinction can already be handled by the "network" concept. A network has capabilities, external links, and a bunch of internal network elements. For the internal view, I list it all. For the external view, I only announce the capabilities and external links. I do not see the need to define another "view" class or "model" class to accomplish this. I do like the "view" concept, but I have not really seen a convincing argument for it. The one that came close was Evangelos mail of March 4 [1], where he had different views for monitoring and other services. In the end, we always give a limited set of information to our neighbours. That is a view on our full topology knowledge of our own network. That is always possible. However, if we later want to *refer* to this specific set of information, then we want to name this "view". Regards, Freek
Freek Dijkstra wrote:
I do not see why it is necessary to know about the terminating device for links in the external view. It seems to me that all I need to know is the encoding of the link, the the capabilities of the domain ('network' in my terminology) to act on this link.
You need to know about the terminating device, otherwise you cannot find a path to it. We could of course go into hierchical addressing, but that opens up the whole naming-and-addressing can of worms. Jeroen. -- My email address has changed to <vdham@uva.nl> (The science has disappeared from my address, but I'm still doing it)
Jeroen van der Ham wrote:
I do not see why it is necessary to know about the terminating device for links in the external view. It seems to me that all I need to know is the encoding of the link, the the capabilities of the domain ('network' in my terminology) to act on this link.
You need to know about the terminating device, otherwise you cannot find a path to it.
So you are saying that you want to find a path *to a terminating device in a domain*? I would rather find a path *to a certain domain*, and don't care exactly which device it terminates at. To clarify: With "terminating device" I mean the first device that I encounter when crossing the domain boundary. I do not want to know about that. (Perhaps I want to be able to find a path to a certain device in the middle of a domain, if that is my final destination, but that is a different discussion.) Allow me to give a short example. If I connect to the Amsterdam Internet Exchange, I know I connect to a 10 GE port on a switch, with certain properties. That's all I need to know. I don't care about the name of that switch. In fact, 4 years ago or so, the AMS-IX stopped terminating customer links at the switch, but put a optical cross connect (OXC) in between the customer and the switch. Like so: : CUSTOMER ----------- OXC ---------- Core switch : \ : \ domain boundary ---------- Backup switch Now if the core switch crashes, the OXC flips mirrors and withing milliseconds, the data is forwarded to the backup switch. So what is the terminating device in this case? The OXC, the core switch or the backup switch? I don't want the name to change if the OXC flips its switch, since that it an event I don't (want to) know about. Honestly, I don't care. All I care about is the service. As a customer, I call this interface "A", and don't care if this interface "A" is an interface in the OXC, the core switch or the backup switch. Regards, Freek Dijkstra
I just phoned Jeroen. We had a misunderstanding on terminology. I meant to say that: It is not necessary (and often undesirable) to describe edge devices to describe an abstracted view of a domain. Jeroen was saying: It must be possible to describe end nodes (terminating devices of a path) within an abstracted domain view. Freek
On Mar 19, 2008, at 1:51 PM, Freek Dijkstra wrote:
John Vollbrecht wrote:
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. 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). 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.
I agree with your statement that it is useful to talk about an actual network, knowing that it really is that network and not some abstract view.
Could you define "real topology" for me? Is that a single network (controlled by a single domain), or is that all networks together? If it is all together -- I like to emphasize that I prefer that there is a concept of a common real topology, but no-one has full knowledge of this real topology (likely they have a full knowledge on the local domain, and abstracted views of other domains).
for me a "real topology" is one that matches physical devices as understood by operational engineers - stuff that has to be installed somewhere. real topology can be a single domain, a partial domain, all the devices in the world - the real part is kind of "not virtual"
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.
Yes, and I would distinguish between the physical "network" class and the organisational "domain" class (which is the administrator of a network)
A few notes on terminology: after discussions a couple of years ago, I now distinguish between - juridical owner - economic owner - administrator = operator
Where the administrator is the same as the operator: the entity that enforces policies, and the economic owner is the entity that decides on policies.
These all seem good to me
3. The real topology has groups - which might be called networks, or domains or both. It is not clear exactly how this will work.
You previously said that you want to have a "common" real topology. Does the grouping of this real topology in domains should also be common? Thus is it the same for everyone, or could device A be in domain 8 for me, while it is in domain 11 for you?
Here is where "real" topology and views may be different. In a DCN view domains are the same for everyone. If it is domain 8 for me, it is domain 8 for you. but that is just the view
I hope there is such a common grouping of all network elements into networks, and everyone sees the same networks. However, I'm fine to have an additional "view" concept where other entities may see different views.
DCN views [...] 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.
I do not see why it is necessary to know about the terminating device for links in the external view. It seems to me that all I need to know is the encoding of the link, the the capabilities of the domain ('network' in my terminology) to act on this link.
I think it is necessary because capabilities of the network may be different at different edges. Also as Jeroen points out it is necessary to be able to make connections.
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).
Good. We need a discussion about links. But you seem to suggest that according to you a "link" is equal to a ITU-T G.805 "link connection" (that is, logical links). "Splitting" is not a word I would use though.
could be - I am not familiar with G.805, but this sounds right.
Your example is pretty complex. Do you also want to be able to (a) say that the STS-1-48 link is composed of 48 distinct STS channels? (b) do you want to be able to say that link1 and link2 are in fact transported over the same OC-192? If so, you need rather detailed multiplexing and adaptation classes to describe this.
yes - but from a DCN pathfinding view I don't care how this is done.
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.
So do you propose that we have a distinct "domain" and a "node" class? Could you define them for me, so I know the difference between the two?
A domain is a network of nodes. The main difference from a DCN point of view is that nodes are internal and routing within a domain uses nodes, routing outside the domain uses domains (or perhaps networks would be better name). This is basically hierarchical routing, and has to do with the DCN view
routes inside domain are calculated between nodes. routes between domains are calculated between edges of domains.
I may do path finding in a completely different way (I may look at interfaces and the grouping in nodes/devices/domains altogether). I think such implementation details are firmly out of scope of the NML. What is in scope is that there is enough information for you to do the path finding.
well I think DCN uses a specific grouping and this needs to be included in its "view"
I am not sure if the elements in a path request need to have a topological name.
How do you want to refer to an element? How other then it's name? (This is not a rethoric question! A valid answer may be "by it's properties".)
good question. right now we have domains, nodes, ports and links. these are all potential elements
Finally, you wrote in your first sentence that you "like to pursue the concept of view or model". Good. However, you only defined "internal topological view" and "external topological view". I think that this distinction can already be handled by the "network" concept. A network has capabilities, external links, and a bunch of internal network elements. For the internal view, I list it all. For the external view, I only announce the capabilities and external links. I do not see the need to define another "view" class or "model" class to accomplish this.
but the real topology may not for example reflect the view of certain physical connections being multiple links. and it may include a lot more information that is not needed by DCN like physical location or administrative owner.
I do like the "view" concept, but I have not really seen a convincing argument for it. The one that came close was Evangelos mail of March 4 [1], where he had different views for monitoring and other services. In the end, we always give a limited set of information to our neighbours. That is a view on our full topology knowledge of our own network. That is always possible. However, if we later want to *refer* to this specific set of information, then we want to name this "view".
I think this is a good starting place. be sure that all the info of the "real" network is in the topology but give views of it to different applications. Then applications can define what they need and be sure it is there. And the topology is maintained in a single place. John
Regards, Freek
John Vollbrecht, Senior Network Engineer Internet2 office +1-734-352-4960 | mobile +1-734-395-7890
participants (3)
-
Freek Dijkstra -
Jeroen van der Ham -
John Vollbrecht