Hi, Roland is really making an interesting point here. IMHO, we have to say which layer we are talking about. Examples I see: L1: DWDM; different lambdas are different virtual networks at L1 L2: 802.1q L2.5: the venerable ATM and MPLS nowadays Cheers,/PA On 29/07/10 10:20, Roland Bless wrote:
Hi, I thought a little bit more on that topic, e.g., whether IP on top of Ethernet itself is a virtualization technique and I think that it is not - longer rationale below. First, I want to second what Aaron said: we should consider network technologies other than IP in the substrate as well as in the virtual network. So sometimes it is easier to think of some abstract substrate technology instead of IP as substrate. However, I think one difference between "layering" and virtualization is as follows: when you put another protocol layer on top, you usually have to do it in the "end-system"/at the end points, i.e., IP nodes are sitting at L2 end points whereas L2 nodes (e.g., switches) are transparent for L2 end points. Same in L3 (letting the control plane aside for this moment): routers as L3 network nodes are largely transparent for the end-systems (except for first/last-hop routers), i.e., a transport connection at L4 is normally terminated in L3 end-systems. So in this way neither IP is a virtual network on top of Ethernet nor is a TCP connection on top of IP, but I would consider IP as an overlay and abstraction technique (it mainly abstracts from different L2 networks in its substrate). In contrast, a virtualization technique in/at L2 involves mechanisms within the L2 nodes, e.g., support of VLAN tagging. A real network virtualization technique at layer 3 would require, e.g., partitioning of a L3 node/a router; lets consider that you are running a different protocol than IP in a partition. The "hard part" now is getting/demultiplexing from the substrate to the virtual parts of the router. There are various ways to do it depending on the substrate's capabilities. So using a dedicated physical L2 port would be one possibility, using VLANs over a shared L2 cable would be another. If the substrate is on higher layers MPLS LSPs or L3 tunnels etc. can be used. Sometimes it also helps to think on addressing the virtual resources from the control plane inside the substrate. Basically you have to address a VNet (denoting a specific virtual network), a Virtual Node, and a specific Virtual Interface inside the Virtual Node, e.g., in order to connect a substrate link/tunnel to a specific interface of this particular virtual node. However, it is not required that VNet-IDs, Virtual Node IDs, or Virtual Link/Interface IDs are literally carried in substrate data packets since there could be link-specific mapping techniques using available multiplexing mechanisms, e.g., VLAN-tags. In analogy one can denote such link-specific identifiers for VNets as "VNet-Tags". A VNet-Tag identifies a virtual link in a link-specific context. In absence of multiplexing support in the substrate, it may be required to use an explicit shim header that carries the VNet-Tag in order to allow proper demultiplexing of virtual networks on a shared substrate link. To keep a long story short: when talking about virtualization we must be specific which layer is actually virtualized or do we consider layer 3 only? Regards, Roland _______________________________________________ vnrg mailing list vnrg at irtf.org https://www.irtf.org/mailman/listinfo/vnrg
-- Pedro A. Aranda Gutiérrez Telefónica I+D Technology Specialist New Network Technologies mailto: paag at tid.es C/Emilio Vargas,6 Tlf: +34-913 374 702 E-28043 Madrid "Fragen sind nicht da, um beantwortet zu werden. Fragen sind da, um gestellt zu werden" Georg Kreisler http://www.mendeley.com/profiles/pedro-a-aranda-gutierrez
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.