[vnrg] Towards a Virtual Network definition

Roland Bless <roland.bless@kit.edu> Wed, 16 February 2011 20:51 UTC

Return-Path: <roland.bless@kit.edu>
X-Original-To: vnrg@core3.amsl.com
Delivered-To: vnrg@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 2E59D3A6D2A for <vnrg@core3.amsl.com>; Wed, 16 Feb 2011 12:51:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id 91nE07yhUmP3 for <vnrg@core3.amsl.com>; Wed, 16 Feb 2011 12:51:30 -0800 (PST)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de []) by core3.amsl.com (Postfix) with ESMTP id B180A3A6A9D for <vnrg@irtf.org>; Wed, 16 Feb 2011 12:51:29 -0800 (PST)
Received: from irams1.ira.uni-karlsruhe.de ([]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1PpoLm-0007IJ-QQ for <vnrg@irtf.org>; Wed, 16 Feb 2011 21:51:57 +0100
Received: from i72ms.tm.uni-karlsruhe.de ([] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps port 25 for <vnrg@irtf.org> id 1PpoLm-0005X7-Lj; Wed, 16 Feb 2011 21:51:50 +0100
Received: from vorta.tm.kit.edu (i72vorta.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:21b:fcff:fe96:fe02]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 95E192FC023 for <vnrg@irtf.org>; Wed, 16 Feb 2011 21:51:50 +0100 (CET)
Received: from [IPv6:::1] (localhost []) by vorta.tm.kit.edu (Postfix) with ESMTPS id 51EE32DC for <vnrg@irtf.org>; Wed, 16 Feb 2011 21:51:50 +0100 (CET)
Message-ID: <4D5C38E5.1020304@kit.edu>
Date: Wed, 16 Feb 2011 21:51:49 +0100
From: Roland Bless <roland.bless@kit.edu>
Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20060111 Thunderbird/1.5 Mnenhy/
MIME-Version: 1.0
To: vnrg@irtf.org
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ATIS-AV: ClamAV (irams1.ira.uni-karlsruhe.de)
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de)
X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1297889517.114581000
Subject: [vnrg] Towards a Virtual Network definition
X-BeenThere: vnrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Virtual Networks Research Group \(VNRG\) discussion list" <vnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/listinfo/vnrg>, <mailto:vnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/vnrg>
List-Post: <mailto:vnrg@irtf.org>
List-Help: <mailto:vnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/vnrg>, <mailto:vnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Feb 2011 20:51:32 -0000


here is another attempt to define what a virtual network
in the sense of network virtualization is:

A virtual network (VNet) is a set of (virtual) nodes directly
connected by (virtual) links and realized on top of a
set of underlying physical resources, the "substrate".

This essentially represents the view of a VNet owner/user,
so he sees virtual nodes that are directly connected
to other virtual nodes, i.e., a bare link layer topology.
Protocols running _inside_ the virtual topology are
typically layer 3 protocols, therefore we speak of
Network Virtualization (virtualization at the network layer,
and virtual nodes are thus virtual routers)

Some features of VNets:

- A virtual network resource (node or link) appears to a user
  of that resource as if he is the (exclusive) owner of that
  resource. (=> isolation)

- There should be no assumptions about the particular
  network protocols or architectures running
  inside the VNet, i.e., it is not necessarily IP.

- One may use various substrate techniques (even at different
  layers) to create virtual links, e.g., WDM, IP Tunnels,
  MPLS, Ethernet VLANs, or even TCP tunnels.
  The substrate may be composed of heterogeneous
  technologies. The main interest of the VNRG
  is probably to consider IP(v4/v6) related technologies
  as common substrate technology.

- Partitioning or aggregation of substrate resources is possible
  to create virtual resources.

- A host that wants to connect to a VNet needs a
  running instance of the protocol(s) that are
  required to communicate with the VNet.
  It needs a substrate path (i.e., the virtual last mile link)
  in order to attach to a virtual (access) node.

Question: does the host "belong" to the VNet topology or
not? IMHO, it is the same situation as in the Internet today:
hosts are part of the network but don't belong to an
ISPs infrastructure, i.e., they are attached to the
access routers/switches etc.

Another interesting question is, however, how the end of
a virtual link is represented inside the virtual node, e.g.,
it could appear as an "ordinary Ethernet" device (i.e., virtual
device) or as any other L2 device.