[vnrg] Some definitions and way forward

[Roland Bless <[e-mail]>]

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