Pekka, > 2. Virtual machine is more than virtual memory > ============================================== > > The majority of today's hardware does not support full virtual machine > functionality, i.e., virtualising also the protected mode. In the > mainstream architectures it has been appearing only recently.
I'd like to refer you to http://en.wikipedia.org/wiki/VM/CMS. This is to point out that we have been delivering true virtual machine functionality in "mainstream" architectures since 1966. Only recently have we chosen to reimplement it for the average user's desktop system. You are correct, a virtual machine is much more than just virtual memory. In includes virtualizing everything within the computer system, not just main memory. If we extend the analogy to our domain, what you are asking for is a first class virtual network, NOT just a virtual address space. What would a virtual network look like? Well, the current jargon is Virtual Private Network, but if we take the risk of opening a VPN, you can easily imagine a virtual Internet. This includes virtualizing routers, links, control plane, etc. I submit to you then, that tunneling today is simply the creation of a virtual link, or as I said originally, tunnels create a virtual topology. Virtual routing is being delivered already today in a crude form known as 2457 and in a more general form by at least two router vendors. Therefore, I believe that we largely already have everything that you seek. Subsequent refinements and improvements are of course inevitable, but conceptually and architecturally, I would claim that we are pretty much already there. The last, and perhaps most difficult architectural step necessary to complete this vision is the ability to virtualize the transport connection away from the network instantiation. Just as in a virtual memory system, where the application program does not care which physical page a particular piece of virtual address space resides in, we need to provide an API to the network layer that the transport layer can operate on, even while the network layer is shifting beneath it. In a virtual memory system, demand paging can cause an application page to change physical addresses. In a virtual network, we should be able to shift the network layer completely, without interruption to the transport layer. Pekka, you touched on the solution and those who have been in the fray for awhile know where this leads: the separation of the network address into locator and identifier. More generally, not only into a host identifier, but into a transport connection identifier. This would deal with many of the issues and complexity that we see today with mobility, multihoming, and would even provide such interesting possibilities as migration of transport connections across hosts. This is a battle that has been fought long and hard and has been settled and I do not bring it up again to re-open it. In fact, I implore all those that have read this far to resist the urge to renew hostilities. I only mention this topic out of completeness, not to re-ignite the debate. > My claim is that if we did the split, there would be much less need for > "managing" the IP address space, leading to a situation where most (if > not all) long term needs for IP virtualisation would disappear. Does it? As Joe Touch pointed out, even with a large amount of physical memory, there are distinct advantages to having virtual memory. True, you may give up demand paging, but you may still with to have an independent uniform, and predictable address space for programming simplicity. These same needs drive us to create VPNs regardless of the size of the address space. Regards, Tony _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
