-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tony Li wrote: > 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. There are a few aspects to this: - separate forwarding tables (some router vendors, Marco's "clonable stacks" for FreeBSD) - multiple, separate instances of routing protocol algorithms supported by some router vendors, and in some daemons > 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. See our work on the DynaBone (www.isi.edu/dynabone) ;-) We used a single overlay deployed on top of a 1,000 parallel alternate overlays, where the traffic was shifted below without interuppting the transport protocol. Just as the program in VM uses _its_ address, ignorant of the paging underneath, our system let the transport protocol operate on the addresses in the upper overlay, ignorant of the way in which it was encapsulated and mapped into any of the 1,000 underlying overlays. > 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. I'm not sure that's the case; it separates the ID/loc of the overlay from the ID/loc of base underlying network. There is still the need (or not) to separaet name from ID in each of the two layers, independent of virtualization. The issue of name vs. location is a networking concept, common to both real and virtual networks. > 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. DynaBone dealt with mobility and multihoming using the layering of virtualization, and didn't need to address the ID/loc split issue to achieve the benefits. > 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC+mwzE5f5cImnZrsRAsAmAKCydrtGrESVULgwm0AJ6g3JXUznOACg7AKs JwtDfIZtm7Blw9hJzsfXJ9w= =0KDZ -----END PGP SIGNATURE----- _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
