The advent of software-defined networking promises new test challenges. But it may also portend more flexible test instruments.
While we've already seen some carrier deployments of software-defined networking (SDN) and network functions virtualization (NFV), this year should mark the start of significant acceptance by Tier 1 service providers such as AT&T. The flexibility SDN and NFV promise can't come soon enough for many network operators - but there's a chance it may come too quickly for test equipment vendors still coming to grips with what software-programmable networks portend for their customers' test, measurement, and monitoring requirements.
A roundup of opinions from vendors of test instruments aimed at optical-network requirements reveals certainty that some things will remain the same within a general uncertainty about exactly how SDN will be enabled and what it means for them. At the same time, these test vendors have begun to ponder whether SDN and NFV concepts could apply to the instruments themselves.
Chasing a virtual entity
One challenge for test vendors as they ponder how SDN/NFV will affect performance measurement and assurance requirements is familiar. "The nice part is there's a lot of proof of concepts being done all over, so people are learning from that," notes Bruno Giguere, senior advisor in the Office of the CTO at EXFO Inc. "Unfortunately, testing is usually an afterthought. So they'll start putting stuff together and trying to make it work, and then they'll figure out, oops, we might need test functionalities for this or that."
Nevertheless, test vendors have begun to piece together some potential concepts. For example, separating the control plane from the data plane via SDN may require testing the performance of the two planes independently, suggests Hiroshi Goto, business development manager at Anritsu Co. He and Giguere agree that the dynamic nature of networks within an SDN environment also poses a challenge because it may be difficult for network managers to predict the demands an infrastructure may face. Therefore, managers and planners may have to stress fully the network and each element it contains to determine how far a dynamic application can push it safely. Measurements of latency and throughput will be particularly important, Goto believes.
Potential interoperability issues also may create a test requirement, Giguere adds. That could mean interoperability between the control and data planes or among platforms from different technology suppliers in a multilayer, multivendor SDN infrastructure.
Photo courtesy of EXFO Inc.
The addition of NFV concepts to the network complicates matters as well, points out Michael Bangert, a product-line manager specializing in SDN at JDSU. "Before, you might have had multiple discrete pieces of hardware that are connected together by fiber or a cable, and so you'd have opportunity for test access," he explains. "Now those functions may be operating in a server where you don't necessarily have that opportunity."
In other words, since functions that once resided in hardware can now be virtualized and located anywhere within a network provides significant advantages in flexibility and efficiency for network operators. But having to chase a virtual function or machine around the network to measure its performance or troubleshoot a problem poses a challenge for test vendors.
Some sort of network-wide monitoring capability will be necessary, the three sources agree. Theoretically, an operator could locate test capabilities at all network access points - but such a strategy would prove cumbersome, complex, and costly. "Maybe you can put it in between the networks or in the middle of the networks," theorizes Goto. "Maybe, if that is the case, then it's always at a gateway - you have to go through that test instrument to secure the performance."
Photo courtesy of JDSU
Fighting virtual fire with fire
One approach to testing virtual functions and machines that might come immediately to mind is the creation of a virtualized test function. Test-instrument vendors like Aeroflex (originally Schenick Network Systems), Ixia, and Spirent have introduced such virtual test implementations. JDSU has as well, from its xSIGHT Customer Assurance Application for wireless networks to its recently introduced TrueSpeed VNF offering for RFC 6349 applications.
Bangert sees virtual test functions as particularly applicable in three service-related areas: configuration, quality of experience, and assurance. Like the virtual-network functions (VNFs) whose performance they're measuring, virtualized test functions typically would reside in servers. "Anywhere that they have server resources in their network, they can now deploy a test, and that can be anywhere from central offices or exchanges potentially all the way out to customer edge routers that are at an enterprise or potentially the ENodeBs that are at the cell site," Bangert asserts.
Even where test hardware is required or desired, virtual test assets can play a role. For example, RFC 6349 is an IETF standard set of tests that measures the end-to-end throughput of TCP transmissions. It also enables troubleshooting of underperforming links. It's an end-to-end test, so it generally needs test assets on each end of the link. But with virtual test capabilities, one of those assets could be a virtual test housed in an existing server, which would halve the number of technicians (or truck rolls) the test would require. Theoretically, virtual assets could perform both ends of the measurement.
Bangert believes that other kinds of performance tests, such as RFC 2544 and Y.1564, would lend themselves well to virtual test approaches. However, physical layer tests for such fiber-related properties as chromatic and polarization mode dispersion or troubleshooting using optical time domain reflectometry currently appear resistant to virtualization, the sources agree.
Thus, while the use of test systems that leverage software may see an impact from SDN, handheld test instruments shouldn't see a steep drop in desirability or necessity in the near future. "Portables will still be around, especially if you're looking at, for example, 100-gig or 400-gig testing or PMD or CD," says Giguere. "These are things that cannot be virtualized.
"What I'm also hearing from service providers is that they still love to have those boxes around or dedicated boxes to do proof-of-concept [testing] because it's one less thing to worry about. They know their instruments," he adds.
New look for test instruments?
But that doesn't mean the portables will act the same since the influence of SDN/NFV on test could mean greater software programmability in such test sets.
In fact, Giguere asserts that EXFO has already begun to ship instruments that leverage SDN/NFV concepts. "For some applications, what we're shipping is basically hardware that has all the bells and whistles in it, and you can dynamically enable features, either time-bound or lease them or just try them," he reports. "It makes it more affordable for customers to get our solutions."
In particular, creating a pool of software-based test apps that can be shared across instruments makes economic and operational sense for operators, Giguere reasons. As well, so does having a test set that can initially be used for testing 10-Gbps links that can be easily upgraded to 100-Gbps capabilities when needed.
However, not everyone agrees that such capabilities represent the advent of SDN in test equipment. "When you start talking about virtual test functions, I don't necessarily know that I buy that," says Bangert. "I mean, we just call that options, and they're all field-deployable."
Putting too many potentially useful hardware features that could be enabled virtually could also be counterproductive, Goto adds. "If you need to reconfigure the test scenario by software, the hardware must be very super-capable from the beginning - kind of almighty," he says. "The concept of SDN is to reduce the initial cost and operating expense. But hardware-wise, if you need this kind of feature, it's going to be very expensive."
Service providers may not be quite ready to fully take advantage of such opportunities, either. "I think one of the other trends that's probably going to be very helpful for our customers is to have instruments be constantly connected to a management system so that they can be tracked, understand what options are on them, understand all of the tests that need to happen, and deploy options, test options flexibly to actually service the customers. That doesn't really happen today," offers Bangert. "I mean, we've got the tools to enable it. [Customers] really haven't taken advantage of it."
Test vendors themselves also may have to rethink their business models to fully embrace SDN/NFV, particularly the openness carriers will demand from network systems. Asked if EXFO is ready to have a third party write apps that would run on its SDN-enabled test equipment, Giguere responds, "Actually that's a nice trick question. I don't think we've talked about that one."
But after giving the idea some consideration, "Actually, it's a nice thought," Giguere adds. "We'd need to think about that one. If it makes business sense, I think it's something that we'd be willing to do."
Stephen Hardy | Editorial Director and Associate Publisher
Stephen Hardy has covered fiber optics for more than 15 years, and communications and technology for more than 30 years. He is responsible for establishing and executing Lightwave's editorial strategy across its digital magazine, website, newsletters, research and other information products. He has won multiple awards for his writing.
Contact Stephen to discuss:
- Contributing editorial material to the Web site or digital magazine
- The direction of a digital magazine issue, staff-written article, or event
- Lightwave editorial attendance at industry events
- Arranging a visit to Lightwave's offices
- Coverage of announcements
- General questions of an editorial nature