x
NFV Tests & Trials

EXCLUSIVE! NFV Interop Evaluation Results

The Participants
The invitation to participate in the NIA's Phase 1 test was issued in August. Once we had published the invitation, NFV infrastructure (NFVi) and virtual network function (VNF) vendors responded very quickly and in a very positive manner. In total, four NFVis participated in the first test campaign:

  • Alcatel-Lucent CloudBand
  • Cisco NFVi
  • Huawei FusionSphere
  • Juniper Contrail

All NFVis were configured as data center solutions, ready for deployment at centralized service provider infrastructure locations. In addition, 17 VNFs from 12 vendors lined up to be tested with these NFVis. They were:

  • Alcatel-Lucent VSR (virtualized service router)
  • Alcatel-Lucent VMG (virtualized mobile gateway, part of the mobile Evolved Packet Core [EPC])
  • Alcatel-Lucent VMM (virtualized mobility manager, part of the mobile EPC)
  • Cisco ASAv (virtual firewall)
  • Cisco CSR1000v (virtual router)
  • Cobham Wireless TeraVM (Virtual Application Emulation and Security Validation)
  • Hitachi vMC (virtual mobile core -- consisting of EPC components MME, SGSN, SCGW, uEPC)
  • Huawei VNE (virtual router)
  • Ineoquest IQDialogue ASM (virtual video test probe)
  • Ineoquest DVA (virtual video quality probe)
  • Juniper vMX (virtual router)
  • Juniper vSRX (virtual firewall)
  • Metaswitch Perimeta vSBC (virtual session border controller [SBC])
  • NetNumber TITAN (virtual centralized signaling and routing control [CSRC])
  • Netrounds Test Agent (virtual IP application probe)
  • Procera PacketLogic/V (virtual deep-packet inspection [DPI] filter)
  • Sonus SBC SWe (virtual SBC)

The wide variety of participating VNFs shows that the industry is progressing well in terms of virtualizing all sorts of network functions. Some VNF types, such as virtual routers, are typically quite straightforward regarding their internal structure and the migration from physical to virtual. Initially we had expected that most of the VNFs put forward for this evaluation would be of this "low-hanging fruit" type. As it turned out, quite a few of the more complex virtual mobile core implementations (EPC, IMS, SBC) were submitted for testing, indicating that these types of applications are more ready for NFV than we had thought.

This initial round of testing, being focused on basic lifecycle management, did not do justice to complex VNFs: As one of the vendors rightfully pointed out, the "cloudification" of network functions involves substantial modification of the physical network function code base. An interesting future test area will focus on how VNF vendors enable elastic, interoperable cloud-based services.

Next page: Test Setup and Coverage

Previous Page
2 of 6
Next Page
muzza2011 12/10/2015 | 2:39:46 PM
Network now needs a permanent Proof of Concept lab We're at the 'art of the possible' stage, rather than the 'start of the probable' regarding live deployment... which if taken at face value, should wholly sidestep the heinous blunder of productionising a nine 5's infrastructure in for a five 9's expectation.

As much as the IT proposition to a user involves all layers of the ISO stack, if you screw the network you've lost the farm, which then negates any major investment in state of the art delivery systems up the stack.

Any tech worth their weight will crash and burn this stuff on Proof of Concept lab... and weld all the fork doors closed... as it'll be their 'nads on the line should if fail in production, not any IT upper heirarchy who decided to make an (unwise) executive decision.

Fail means *anything* regardless whether its a SNAFU or an hack-attack vector that no-one tested. 

In short, test to destruction, armour-plate the resultant design, and always have a PoC lab bubbling away in the background for the next iteration, because the genie is now out of the bottle and won't go back in.
mhhf1ve 12/8/2015 | 8:56:52 PM
Open source doesn't necessarily mean any support available... It's always interesting to see how open source platforms still have gaping holes with major unsupported functions. Every fork/flavor of an open source project means more than a few potential gaps for interoperability with other forks.

 
HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE