[openstack-dev] [NFV] VLAN trunking to VM - justification/use cases

Calum Loudon Calum.Loudon at metaswitch.com
Wed Oct 1 09:38:17 UTC 2014

Hello all

I took the action on last week's call to explain why the VLAN trunking to VM bp
is a relevant use case for NFV - here's my take.

The big picture is that this is about how service providers can use 
virtualisation to provide differentiated network services to their customers 
(and specifically enterprise customers rather than end users); it's not about 
VMs want to set up networking between themselves.

A typical service provider may be providing network services to thousands or 
more of enterprise customers.  The details of and configuration required for 
individual services will differ from customer to customer.  For example, 
consider a Session Border Control service (basically, policing VoIP 
interconnect): different customers will have different sets of SIP trunks that 
they can connect to, different traffic shaping requirements, different 
transcoding rules etc.

Those customers will normally connect in to the service provider in one of two 
ways: a dedicated physical link, or through a VPN over the public Internet.  
Once that traffic reaches the edge of the SP's network, then it makes sense for 
the SP to put all that traffic onto the same core network while keeping some 
form of separation to allow the network services to identify the source of the 
traffic and treat it independently.  There are various overlay techniques that 
can be used (e.g. VXLAN, GRE tunnelling) but one common and simple one is VLANs.
Carrying VLAN trunking into the VM allows this scheme to continue to be used in 
a virtual world.

In this set-up, then any VMs implementing those services have to be able to 
differentiate between customers.  About the only way of doing that today in 
OpenStack is to configure one provider network per customer then have one vNIC 
per provider network, but that approach clearly doesn't scale (both performance 
and configuration effort) if a VM has to see traffic from hundreds or thousands 
of customers.  Instead, carrying VLAN trunking into the VM allows them to do 
this scalably.

The net is that a VM providing a service that needs to have access to a 
customer's non-NATed source addresses needs an overlay technology to allow this,
and VLAN trunking into the VM is sufficiently scalable for this use case and 
leverages a common approach.


Calum Loudon 
Director, Architecture
+44 (0)208 366 1177

More information about the OpenStack-dev mailing list