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, 3 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
>