Triggering a New Control Plane

4:00 AM -- The prospect of a multivendor control plane -- a single management system for a heterogeneous wireline network -- is getting closer in small steps.

The sticking point, obviously, is that no equipment vendor has an interest in doing such a thing. Avici tried giving it a go, relaunching as Soapstone Networks. Its control-plane software, first aimed at Carrier Ethernet, is now in the hands of Extreme Networks Inc. (Nasdaq: EXTR), where the multivendor potential isn't what's being emphasized. That's understandable. (See Extreme Puts Soapstone to Work.)

Tail-f Systems , though, is a software company that doesn't have a stake in any type of equipment. It sells configuration software, and its NCS software opens some interesting possibilities.

Tail-f describes NCS as a framework for developing configuration management software. A specific example is NCS for Carrier Ethernet, released last week. (See Tail-f Configures Carrier Ethernet.)

NCS uses the Netconf protocol -- which is relatively new but is used in some high-profile spots, such as Junos Space from Juniper Networks Inc. (NYSE: JNPR) -- to talk to network equipment. In this case, NCS handles configuration -- meaning, an equipment provider can use NCS to create a user interface that masks the nuts and bolts of service provisioning.

Now take that idea a step further. If enough equipment speaks Netconf, then something like NCS could be the basis for configuring multiple vendors' boxes -- an all-in-one software interface tapping an operator's entire network.

Carl Moberg, Tail-f's COO, agrees that this would be a logical direction. But getting there requires some leaps of thinking. Tail-f's customers for now are the equipment vendors, which won't be so keen on this idea. Tail-f also has the ear of some service providers -- but this would be new territory for them, too, an area that would call for more programmers rather than just script writers.

"I'm unclear on what the triggering factors are for a second step," Moberg says.

Even so, as Service Provider Information Technology (SPIT) rises in importance, the circumstances could start falling into place. Moberg likens NCS's situation to the rise of the SQL language in the 1970s; without it, every application had its own way to access a relational database. Likewise, today, every vendor's network equipment gets configured separately. It just makes sense that something more universal should emerge.

— Craig Matsumoto, West Coast Editor, Light Reading

spc_markl 12/5/2012 | 4:19:56 PM
re: Triggering a New Control Plane


I always found it ironic that at the trade shows over the years, the network management piece was always the last feature to be shown by exhibitors.  The management aspect was always the means to differentiate one's product as much as possible -- of course, it was also the least sexy in promoting a solution.  I would think that a universal control plane has as much chance as true SONET interoperability did in the past.  It is hard enough to sometimes get products from the same vendor to talk to one another, let alone from two different suppliers.

Mark Lutkowitz, Telecom Pragmatics

kshyam 12/5/2012 | 4:19:55 PM
re: Triggering a New Control Plane

i guess if openflow is a success thn we should have this capability ..yeah vendors are never going to do this..

cmoberg 12/5/2012 | 4:19:54 PM
re: Triggering a New Control Plane


In my opinion, this is changing with a number of drivers including increased complexity of the configuration changes required for service provisioning. Just look at the number of parameters required to provision a simple virtual point-to-point service regardless of technology used (carrier ethernet, MPLS, etc). With the expected change frequency this will not be something that will allow manual steps. It's a non-starter. Operators know this.

cmoberg 12/5/2012 | 4:19:54 PM
re: Triggering a New Control Plane


To elaborate a little further on the triggering factors for operator acceptance. My suggestion is that there are a couple of things that need to happen before it is feasible in any scale. First, the real differentiator here is the NETCONF protocol and the YANG modeling language. Without it, all solutions, regardless of whether provided by third-party or equipment providers just won't be viable long term. The cost of maintaing adapters to hide the shortcomings of CLI and/or SNMP for configuration management will be greater than their utility over time.

Provisioning of services requires support for NETCONF and YANG only in the elements/resources that participate in the service scenario. Operators with e.g. Juniper equipment can start working towards this right away for particular services. Now, many operators have non-NETCONF equipment for large parts of the installed base across service resources. My experience is that many operators are challenging the equipment providers to step up to the automation challenge by providing APIs instead of considering investing in third-party solutions. At this stage, vendors will arguably do a better job of providing northbound APIs on top of their products than third-party solutions reverse engineering SNMP and/or CLI for provisioning. This will eventually change.



paolo.franzoi 12/5/2012 | 4:19:53 PM
re: Triggering a New Control Plane


You know....people could like Generalize MPLS...and like make it support multiple kinds of equipment and technologies.  Man that would be real cool...then we would not need yet another new control plane.  Wait....




cmoberg 12/5/2012 | 4:19:53 PM
re: Triggering a New Control Plane


Well that would be awfully specific to MPLS wouldn't it? And perhaps run the risk of being overspecified yet underdefined, would it not?

How about a protocol and a data modeling language based on experience with specific features for well known shortcomings in existing protocols? That's be something worth considering, no?

Or do you suggest sticking to CLI scripts?

paolo.franzoi 12/5/2012 | 4:19:51 PM
re: Triggering a New Control Plane


Of course it would be - except that GMPLS actually exists and has been at least demonstrated on optical gear.

That is why I find this so funny - I mean hysterical.  What you guys are talking about here has been defined already and nobody wants to implement it.



cmoberg 12/5/2012 | 4:19:51 PM
re: Triggering a New Control Plane

We may be talking past each other somewhat (in the comment fields on LR!). GMPLS is not addressing the same part of the problem space that I believe is being discussed in the post above. The GMPLS RFC (3945) actually suggets using SNMP for service configuration purposes and points out the importance of complete MIB coverage "to allow the manager to manage the entire control plane" (section 12). That has not happened and my suggestion is that the simplistic nature of SNMP (peek or poke only) it is not well suited for structured configuration. The RFC is also pretty specific about why CLIs just won't cut it for any serious deployment (no interoperable standard).

This is the area where I see much room for improvement and on real problems. A robust way of configuring (yes, the writing part) the resources of the network.

neyo 12/5/2012 | 4:19:50 PM
re: Triggering a New Control Plane

A Control Plane will basically introduce automation in the network - automatic discovery of resources, route discovery and restoration from failure. Moving forward, the management plane will be basically relegated to management of the control plane rather than management of the network per se. 

GMPLS seems to be the only candidate for a unified control plane across all networking elements. The challenge is to write all the control plane software for all the network switching elements and test the interoperability across different vendors. All this just so that the guys in the network management center can sit back and enjoy their coffee.

paolo.franzoi 12/5/2012 | 4:19:50 PM
re: Triggering a New Control Plane


You are right.


The MANAGEMENT plane and the CONTROL plane are different.  Note, CONTROL plane in the title of the post.

Control planes are end to end connections (see phone calls).  Management planes configure things.  There are paradigms like SONET that actually do not have a Control plane but instead use the Management plane to configure connections manually.

The problem with Management planes are that they are single carrier which is nice for a sub-set of problems.  The problem with Control planes is that they are extraordinarily complicated to debug with lots of interoperability issues.  The problem with all of these ideas of multi-vendor, industry wide stuff is that no vendor wants to open themselves up to the competition by being able to plug in other vendor equipment.

As to a common management paradigm - see Telcordia OSMINE.  Yep, people really liked that.



Sign In