Telco heavyweights pass packets in NFV demo

NFV gets more open

Multivendor NFV service chaining demo

NTT, NEC, Hitachi, Alcatel-Lucent, Cisco, and ALAXALA have put together a key test of interoperability in the network function virtualisation (NFV) world.

They've shown that the NFV concept of “service chaining” – putting together virtualised services by directing traffic through the addresses of services rather than (say) hardware – not only works, but can work on a cross-vendor basis.

The release itself is pretty dry, so The Reg's networks desk is going to take a shot at explaining why it matters.

Service Chaining

The first step in NFV is to take a function – the firewall is a handy example – and abstract it from particular hardware. Instead it becomes a software running on a virtual machine (VM) that can be spun up and down on-demand.

Service chaining describes the next step in the operation: creating more complex services by “chaining” different virtual network functions (VNFs) together – with different service chains able to be built for different customers.

While vendors would love to keep their customers closeted in a single environment, that's not really feasible – which is why standards organisations like ETSI and the IETF have been working on interoperability.

In the current six-vendor demo, which will be shown off in public later this week at the NTT Musashino R&D Center at that company's 2015 R&D forum, the collaborators demonstrated packet delivery to the appropriate virtual network service, in the correct order.

This involved the six vendors preparing various components of service chaining (Classifier, Service Function Forwarder, Service Function Chaining Proxy, and Controller) and getting them to interoperate.

The NEC canned statement describes the roles of each of these as follows:

  • Classifier – Determines what service is to be applied to a flow, and attaches the appropriate tag. In the interop test, a network service header (currently being standardised in the ITEF) was used as the tag.
  • Service Function Forwarder (SFF) – reads the tag to decide which service function is the destination for a particular packet.
  • SFC Proxy – this provides legacy integration for “pre-NFV” network services. Since (for example) a legacy firewall won't know what to do with the SFC header, it strips it off if a packet is being sent to a legacy service.
  • Controller – manages the Classifier and SFF, and updates the relevant tables.
Multivendor NFV service chaining demo

What multi-vendor NFV service chaining looks like, apparently. Image: NEC

In the service chain shown in the image above, video destined for a mobile device needs to be a bit thinner than a laptop browser.

In the service chaining model, all that's needed to add video optimisation to the chain is the appropriate tag. So if it all works as described on the box, NFV plus service chaining provides both flexibility and automation.

Since telcos won't rip out today's non-virtual equipment while it's still got economic life in front of it, the ability to use NFV proxies to integrate existing kit is also important. Demonstrating multi-vendor interop in a way that also offers a phased introduction of virtualised kit is a big step towards getting telcos to implement the emerging NFV technologies. ®




Biting the hand that feeds IT © 1998–2019