Re: [vnrg] Some definitions and way forward
Bhumip Khasnabish <vumip1@gmail.com> Wed, 03 August 2011 14:32 UTC
Return-Path: <vumip1@gmail.com>
X-Original-To: vnrg@ietfa.amsl.com
Delivered-To: vnrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC9F21F86B6 for <vnrg@ietfa.amsl.com>; Wed, 3 Aug 2011 07:32:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.998
X-Spam-Level:
X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_BAYES_5x7=0.6, SARE_BAYES_6x7=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ReuXiAhlLeD2 for <vnrg@ietfa.amsl.com>; Wed, 3 Aug 2011 07:32:24 -0700 (PDT)
Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by ietfa.amsl.com (Postfix) with ESMTP id 1C8B421F86AC for <vnrg@irtf.org>; Wed, 3 Aug 2011 07:32:24 -0700 (PDT)
Received: by gyf3 with SMTP id 3so611558gyf.13 for <vnrg@irtf.org>; Wed, 03 Aug 2011 07:32:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=voVKSgsuux3JVAmCq8cQUSLW6N+neMY0b4Q9jTqfFDo=; b=HQ1FBW+t4nW2RGK50M+O8tsfLORteSiB86DraKZCLZeY9+CdwHkEuQeNu+YY4Alcy3 HNwnwudeipcc3z76jJzZ2MCvJ//1R7C5HvpPfawd5lVDZgjsA7rs9gltqPiUzCf/znw6 Ox5jeynyRF7xFfB2ZJ+0JbJrlLkGIaPyo5Cs4=
MIME-Version: 1.0
Received: by 10.236.176.36 with SMTP id a24mr6096759yhm.284.1312381954798; Wed, 03 Aug 2011 07:32:34 -0700 (PDT)
Received: by 10.236.103.164 with HTTP; Wed, 3 Aug 2011 07:32:34 -0700 (PDT)
In-Reply-To: <4E3936FF.1090006@kit.edu>
References: <4E3936FF.1090006@kit.edu>
Date: Wed, 03 Aug 2011 10:32:34 -0400
Message-ID: <CANtnpwiY8qiCFgZowmfRRN9aG_WyATzE0jn12DZiuAYFcbF0FA@mail.gmail.com>
From: Bhumip Khasnabish <vumip1@gmail.com>
To: Roland Bless <roland.bless@kit.edu>
Content-Type: multipart/alternative; boundary="20cf303b3cc139b2dc04a99abc7f"
Cc: "vnrg@irtf.org" <vnrg@irtf.org>
Subject: Re: [vnrg] Some definitions and way forward
X-BeenThere: vnrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Virtual Networks Research Group \(VNRG\) discussion list" <vnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/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, 03 Aug 2011 14:32:25 -0000
Hi Roland, Thanks. Do we need to define "Virtual Node" and "Virtual Service" as well? VNode may contain a variety of virtual resources, and we may need to define them. Best. Bhumip On Wed, Aug 3, 2011 at 7:54 AM, Roland Bless <roland.bless@kit.edu> wrote: > Hi, > > as already mentioned in the IETF-81 meeting, I committed to > write up some definitions (mostly results from the 4WARD EU project) > that may be useful for further discussion of terminology and problem > statements. I'll leave recursion aspects aside at first since it usually > complicates the discussion - but it's often rather straight-forward to > apply recursion (i.e., consider virtual resources as (virtual) > substrate) etc. > Some illustrations of roles and interfaces can be found in > http://www.ietf.org/proceedings/77/slides/VNRG-3.pdf > > Virtual Resource: > A virtual resource appears to a user of that resource > as if he is the (exclusive) owner of that resource. > > Substrate: > This denotes the physical resources that host the virtual > resources, i.e., each virtual resource is instantiated > inside one or more physical resources. Substrate resources can > either be partitioned or aggregated in order to provide a > virtual resource. From the above definition of a virtual > resource follows that virtual resources must be > isolated from each other in the data plane as well as > in the control plane. > > Virtual Network: > 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. > There should be no assumptions about the particular > network protocols or architectures running > inside the VNet, i.e., it is not necessarily IP. > Virtual nodes can be further distinguished into > virtual routers and virtual hosts. Virtual routers > forward packets whereas virtual hosts are sinks > or sources of packets. > > Infrastructure Provider: > The Infrastructure Provider (InP) is responsible for maintaining > physical networking resources, such as routers, links, wireless > infrastructure, etc., and enabling the virtualization of these > resources. The InP also offers a resource control interface for the > virtualized resources. Through this interface, InPs can make virtual > resources and partial virtual topologies available to virtual network > provider, which are the customers of the InP. The InP can usually > migrate virtual resource between substrate resources so that the > users of virtual resources are not aware of any change. The actual > mapping from virtual to substrate resources inside the InPs domains > is usually only known by the InP. InPs may have to use a common > interface for setting up virtual links across different InPs. > > Virtual Network Provider: > The Virtual Network Provider (VNP) constructs virtual networks using > virtual resources and partial topologies provided by one or more InPs. > The VNP needs a resource control interface to request and configure > these virtual resources offered by the InP who actually owns the > resource. A newly constructed VNet can be made available to a virtual > network operator (or to another VNP, who can recursively use > it to construct an even larger VNet). The VNP performs mainly a broker > role, providing easier access for VNOs to virtual resources spanning > multiple InPs. > > Virtual Network Operator: > The Virtual Network Operator (VNO) operates, controls, and manages the > VNet in order to offer services inside the VNet. > Once the VNet has been constructed by a VNP, the VNO is given > "Out-of-VNet access" to control the virtual resources, allowing him > to configure and manage them just like a traditional network operator > manages physical network resources. This Out-of-VNet access control > interface is required in order to install, reboot, start, stop, shutdown > virtual node etc. from outside the VNet (e.g., if your virtual > node crashed, you must have some knob to restart/revive it). > This also requires to get transparent access to the virtual resources > irrespective of where the resources is currently hosted in the > substrate as the InP may not expose the current location and migrate > the virtual resource "freely". The VNO also controls and manages the > virtual resources from inside the VNet (In-VNet Management). > > Service Provider: > A service provider may provide services to end-users by using the > protocols running inside the virtual network. Consider an IP-TV > provider who delivers IP-TV inside the VNet to his customers. > In order to accomplish this, the Service Provider may want to employ > IP multicast for efficient distribution of the streams inside the VNet. > So the VNO may run PIM-DM/SM protocols inside the VNet as required by > the service provider. > > We note that some of the roles can actually overlap, e.g., > VNP and VNO, InP/VNP/VNO and service provider etc. > > End-users: > End-users attach to the virtual network and use the communication > services provided by/within the virtual network, i.e., they run a > virtual node that implements the suitable protocol stack. > End-users have usually access to some substrate network and need to > get to a virtual access node via a viable substrate path. This process > of transitioning the real world into the virtual world/net is called > "end-user attachment" and the substrate path can be considered as being > a so-called "virtual last mile link". A typical method to accomplish > this is to create a tunnel across the substrate between the end-user's > device and the VNet access node. Problems that need to be solved here > are for example: how can an end-user find the right virtual access node > for a particular VNet across the substrate? How can mobility and > multi-homing in the substrate be considered, e.g., the virtual link stays > connected. How to consider multi-homing and mobility in the VNet, i.e., > being attached to multiple VNet access nodes simultaneously or moving > between them? > > More detailed text on the scenario and control interfaces > can be found here (open access): > http://journal.ub.tu-berlin.de/eceasst/article/download/225/216 > > I would propose that we try to create an RG draft that defines > some basic terminology, captures the content of some recent > RG discussions on some related aspects as virtual vs. logical, > layering vs. virtualization, important properties, "acid tests", > and so on and then describes some of the > problems that the RG feels need to be solved. In a next step > we may pick some of the problems and work on them (probably in > parallel). > > Regards, > Roland > > _______________________________________________ > vnrg mailing list > vnrg@irtf.org > https://www.irtf.org/mailman/listinfo/vnrg >
- [vnrg] Some definitions and way forward Roland Bless
- Re: [vnrg] Some definitions and way forward Bhumip Khasnabish
- Re: [vnrg] Some definitions and way forward Papadimitriou, Dimitri (Dimitri)
- Re: [vnrg] Some definitions and way forward Joe Touch
- Re: [vnrg] Some definitions and way forward Roland Bless
- Re: [vnrg] Some definitions and way forward Roland Bless
- Re: [vnrg] Some definitions and way forward Roland Bless
- Re: [vnrg] Some definitions and way forward Papadimitriou, Dimitri (Dimitri)
- Re: [vnrg] Some definitions and way forward Roland Bless
- Re: [vnrg] Some definitions and way forward Andreas Fischer
- Re: [vnrg] Some definitions and way forward SCHARF, Michael
- Re: [vnrg] Some definitions and way forward Roland Bless
- Re: [vnrg] Some definitions and way forward Papadimitriou, Dimitri (Dimitri)
- Re: [vnrg] Some definitions and way forward Andreas Fischer
- Re: [vnrg] Some definitions and way forward Joe Touch
- Re: [vnrg] Some definitions and way forward Roland Bless
- Re: [vnrg] Some definitions and way forward Flinck, Hannu (NSN - FI/Espoo)
- Re: [vnrg] Some definitions and way forward Roland Bless
- Re: [vnrg] Some definitions and way forward Flinck, Hannu (NSN - FI/Espoo)
- Re: [vnrg] Some definitions and way forward Roland Bless
- Re: [vnrg] Some definitions and way forward Papadimitriou, Dimitri (Dimitri)
- Re: [vnrg] Some definitions and way forward Flinck, Hannu (NSN - FI/Espoo)
- Re: [vnrg] Some definitions and way forward Papadimitriou, Dimitri (Dimitri)
- Re: [vnrg] Some definitions and way forward Roland Bless
- Re: [vnrg] Some definitions and way forward JFC Morfin