[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
Calum Loudon
Director, Architecture
+44 (0)208 366 1177
METASWITCH NETWORKS
THE BRAINS OF THE NEW GLOBAL NETWORK
www.metaswitch.com
More information about the OpenStack-dev
mailing list