Re: [vnrg] Some definitions and way forward

[Joe Touch <[e-mail]>]

Hi, Roland,

Some of the issues below go well beyond architecture - e.g., operators, 
ISPs, etc.

It might be useful to focus on the arch aspects first.

Also, it'd be useful to understand your view of the relationship of 
these definitions to PPVPNs, VPNs, etc.

Joe (as an individual contributor)

On 8/3/2011 4:54 AM, Roland Bless 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