Re: [vnrg] Some definitions and way forward

["Papadimitriou, Dimitri (Dimitri)" <[e-mail]>]

Hi,

These definitions stems from the view that physical resource owner provides virtual resources of the same kind (delimits the type of virtual resources it can deliver). My understanding from the scope given in the Maastricht meeting was:

- virtual resources can be hosted on physical resources of different type i.e. virtual nodes/links don't have to be instantiated from physical nodes/links; for instance, a virtual network can comprise virtual nodes that are bringing together/aggregating resources from multiple physical nodes AND a set of virtual nodes that are emulated on a single physical machine.  

- virtual resources composing a virtual network can be of different type and thus virtually operate at different layers (thus beyond nodes and links operating at a given layer) including wireless/wireline virtual links with different properties (with or without emulated delay), hosts and intermediate nodes of different kind, e.g., switches, routers, base stations, etc.). This is basically what makes the difference between an "overlay network" and "virtual network".  

The role definitions here below tend to reproduce (and thus somehow limit) the roles we actually know from "physical networks". Taking the above definitions, if the virtual network would be running on physical hosts, "providers" would not maintain any physical resource of the type indicated here below (routers, links, wireless infrastructure, etc.) but only computing resources on terminals/servers. 

The role definitions provided here below tend to enforce too a client-server strict demarcation between resource owner and non-owner merging thus a functional and operational role whereas demarcation would be needed between an external entity to the VN (as delimited by the functionality that the VN delivers) and a Virtual NAP (whether one owns the underlying resources or not).

Thanks,
-dimitri.

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Roland Bless
> Sent: Wednesday, August 03, 2011 1:55 PM
> To: [e-mail]
> Subject: [vnrg] Some definitions and way forward
> 
> 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
>