Re: [vnrg] Some definitions and way forward

[Bhumip Khasnabish <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.irtf.org/mailman/listinfo/vnrg
>