Month: March 2013

We’ve not had much in the way of explicit vendor positioning for Network Functions Virtualization, despite the fact that my model says it will likely have more of an impact on the network equipment market over time than SDN will.  Server network middleware optimizer 6WIND had the first positioning of NFV I’ve seen, and Ericsson featured NFV prominently in their pre-MWC briefing.  Yesterday Overture joined the fray, and they might be onto something.

The overture concept is called Ensemble Open Service Architecture or Ensemble OSA for short.  What’s interesting about it is that it’s not a system/software strategy but a metro strategy, and that’s critical in my view because the focus of NFV in the future will clearly be the metro area.  What’s just a titch disappointing is that Overture is taking what in my view is too retrospective and conservative a view of the opportunity, and shooting short of the mark in today’s market can be fatal.

There are three layers to Ensemble OSA (three being the magic number, apparently, for most presentations including my own!).  The top layer is for applications, the middle for orchestration and control, and the bottom for resources.  One of the potentially valuable insights Overture adds to the picture is the placement of virtual functions and devices in the resource layer, which makes it possible to visualize that layer as an object model that’s organized by the middle layer and consumed by the top.  That’s the structure I think is most appropriate for any service-layer functionality for the network of the future, including both SDN and NFV.

The diagram Overture draws for the metro of the future is very much like my metro cloud diagram; functionality is pushed out to the very edge—the central offices—and hosted on servers that are thus highly distributed.  This creates a metro cloud network that’s drawn upon for the features that services need, and each feature can in theory be hosted near where it’s actually used or replicated as needed for performance reasons. Overture says that the architecture is edge-driven, meaning that edge devices couple functionality back to the network, and that also seems appropriate as a model.  The first problem in the details is that how this works isn’t explained; how are services coupled to the data plane.  Is the coupling an operations/management-level link or is it simply a connection?  How much substance is here is a determinant for the value.  The second problem is the lack of detail on how functionality is orchestrated,  That makes it impossible to tell whether Overture OSA is targeted only at carrier Ethernet customers (a difficult position to sustain given the dominance of consumer and mobile broadband) or at a larger base.

This leaves me in a bit of a quandary because absent detail it’s hard to know whether there’s anything here but slideware.  Since Overture said they started development of Ensemble OSA in 2012 it’s clearly not an enormous software project; there wasn’t time.  But I’ve said before that you could create something that would support SDN, NFV, and the service layer of NGN using open-source tools properly integrated, so the project timeline and lack of detail may be reflective of reuse of existing components and flexibility in their use, respectively.  If that’s the case they should have been specific.  The architecture seems good; it’s perhaps the only metro-NFV presentation yet made.  Is there anything behind it?  I can’t say.

What’s most disappointing is the press release focus on operations issues and not on service creation.  Even the NFV examples of new services are “new” in the sense that the implementation of the feature by a hosted component is “new” but the feature itself isn’t.  Overture could take a significant step forward with Ensemble OSA, a step that would connect the architecture with mobile and content in the near term, and with pretty much everything that’s new and at a higher level than the data plane in the long term.  But though CDNs and mobile infrastructure elements are NFV targets, they’re not cited in the Overture material, and nothing’s said about creating virtual functions that represent new things and not transplanted appliance features or operations tools.  To me, this diminishes the excitement of the announcement, and also the potential scope of benefits.  Finally, it makes me wonder whether there’s anything under the diagrams.  Without true metro cloud applications, this could be little more than carrier Ethernet with some PR hooks added.

I’ve said this before, but it bears repeating.  There is nothing in services that is truly valuable and is not going to end up distributed to the metro level.  Content is the clearest example of that; CDNs host everything someone cares enough about to pay for.  So what we’re going to see in the future is a transformation of “the Internet” into “Cloudnet”, which is a metro infrastructure that hosts valuable stuff locally so that its traffic travels no more than about 40 miles to the users.  Overture’s mission, and the mission of everyone who claims credentials in the SDN, NFV, or cloud computing space, is to build the metro infrastructure that makes this happen.  That’s what they have to go after, and in detail sufficient to validate their claim of support.  Maybe eventually they will but they didn’t do it with this announcement.

It’s good, maybe even great, that Overture seems to be embracing the metro-cloud architecture at the positioning level.  It would be better if they matched their details to their story, laid out what their specific capabilities were.  If you’re reading this, Overture, send me another deck with this detail included!  It would also have been better to have shouted the metro-cloud position to the rooftops as a means of indoctrinating the media and the market, but you don’t get mulligans in positioning so it’s too late for that.  Most of all I’d like to see them move away from the operations-defensive position.  If making networks cheaper year after year is the only goal, then operators should consider getting out of the network business.   You need top-line growth, ARPU growth, to sustain an industry.

Cisco’s announcement that it would host Arbor’s DDoS defense software on its Carrier Grade Service Engine is another indication that vendors are taking Network Functions Virtualization serious, though still perhaps not serious enough.  Yes, we’re hearing more about hosting functions, but we’re still not hearing about an architecture.

You can look at most forms of network security as being a kind of policy-controlled forwarding.  Normally you do packet forwarding by looking stuff up in a table and forwarding to the port you find during the lookup.  A firewall might block a port by simply forwarding to nowhere (not forwarding at all).  You might shut off a denial of service attack by not forwarding the packet streams from offending sources to a destination under attack.  The point is that there are two dimensions to the security process—changing forwarding policies and deciding when to change them.  It’s not unlike SDN in that respect.

Security in software is a virtual function too, right?  Not exactly.  It could be implemented something like SDN could be, which means that you could visualize this kind of forwarding-based security as a device cooperating with some hosted process that decides when to change the rules.  That’s NFV-like.  It could also be implemented as an in-line function, as firewalls are typically implemented today.  Putting service intelligence in a general-purpose line card like this may demonstrate the sort of function hosting that the NFV people have in mind, but not the independence from network appliances that drive NFV in the first place.

This raises a couple of questions.  First, is the goal of virtualizing functions to make them hostable in a general sense (meaning hosting on a line card is OK) or is it to host on a cheap general-purpose server the goal?  Second, are vendors jumping onto hosting stuff on line cards to preempt some of the benefits of NFV?  Juniper had already claimed service chaining of virtual functions was an SDN application.  Cisco doesn’t promote their Arbor thing as an NFV strategy, so might vendors be looking at their own NFV model, one that links “virtual functions” not with specialized appliances but with generalized line cards in switches and routers?

For the first question, while the NFV white paper makes it clear that the goal is hosting functions on industry-standard servers, it’s true that if vendors were to offer a line-card hosting option that wasn’t super-expensive, it might find acceptance with operators.  The line card would be specific to the vendors’ own equipment but it also might be more efficient.  If we presumed that security was implemented by actually passing a packet flow through the security software, having that software on the device would almost certainly make forwarding more effective.

For the second question, vendors like Cisco and Juniper might be tweaking the letter of NFV definition and (in Juniper’s case) wrapping the result in SDN to make the picture more palatable.  If that’s the case, then the success of NFV as an open concept would depend on it explicitly adopting an open model that, like SDN, separated virtual functions from vestigial device handling in an explicit way.  If we had line cards that provided the controlled-forwarding mechanism I described earlier, then those cards could be supported by centralized, hosted, software that controlled the forwarding using some open standard.  The problem of proprietary behavior comes from the integration of both control and data handling in the same security software tool, because if that’s done then you have a powerful incentive to host the security where the data is being handled, and you’re back to a proprietary device.

Architecture is the answer to this sort of thing.  You can’t express goals these days and not have vendors try to achieve them in a way that maximizes their own profits.  That is likely to have the effect of minimizing the cost reductions the goals included, of course.  NFV can secure its goals only by specification of enough architecture detail to nail down the implementation options.  Even then, as SDN evolution shows, vendors will try to secure the spirit of the change while violating the letter of the processes.  We have a lot of people talking about the definition of SDN when formally speaking SDN has been defined all along.  What they’re doing is modifying the definition of SDN to establish or protect commercial interests.  The same thing could well happen with NFV—even more easily given that NFV doesn’t have at this point any detailed standards or architectural models.  There are a lot of ways that you can say you meet a goal.

Mobile is not only the hottest spot in service provider infrastructure, it’s probably the only hot spot.  Mobile profits and revenues still show some glimmers of hope even though ARPU is expected to plateau late this year and start its slow decline next year.  My model says that operators are looking to make some smart changes in metro/mobile in the next couple of years, while the bloom is still at least in part on the rose.  But “smart changes” doesn’t mean spending like a sailor, and you can see some indicators of what it does mean already.

JDSU’s acquisition of Ariesto, a mobile infrastructure data collection and analytics play, is a kind of two-dimensional look at the future.  Obviously you don’t collect mobile data to plaster your walls with reports.  The goal of most of Ariesto’s users is to optimize delivery infrastructure to maximize customer satisfaction and lower costs (or at least control them).  For JDSU, who provides optical gear out of another division, to admit that you need to optimize mobile infrastructure says they recognize that future cost consolidation is a reality.  In addition, there’s the “upsell” argument for JDSU; they know that you can’t differentiate yourself at the bit-pushing level except by pushing cheaper bits, so they’re looking up to higher layers.

On the handset side there are also signs.  There was a time when a hot handset commanded almost any premium, and now Motorola’s handset unit (now part of Google) is cutting staff and operators are looking hard at Mozilla Firefox OS for featurephones to reduce their need to subsidize.  The demand that operators let users unlock phones when their contracts expire is also going to put pressure on operators to reduce or even eliminate subsidies, even if regulators don’t insist they do that.

All of this is happening as we start seeing ads for Google’s voice search (which of course they’ve had for some time), and ironically it’s this sort of service that holds the hope (at least that which remains) for the future in terms of mobile investing.  What voice search shows is that mobile users are different.  Most people would consider voice search for laptops or desktops to be a curiosity of so little value they’d not bother fiddling with it.  In the mobile space it’s a whole different picture.  Like mobile apps, voice search or voice commands in general offer a handset user a more convenient way to interact with a phone given that the phone isn’t likely their only distraction at a given moment.  Mobile fits technology to lives.  What operators and handset players need to be doing is taking that simple truth as a jumping-off point.

There have always been three operator monetization priorities, the big opportunity areas that if realized could make a profound difference in revenues and profits.  Content was number one, mobile/behavioral symbiosis the second, and cloud computing the third.  It has always been recognized mobile/behavioral was the biggest opportunity of all.  In fact, mobile/behavioral symbiosis could generate half of the total revenue attributable to cloud-based infrastructure, so it’s also symbiotic with the cloud.

The challenge with mobile/behavioral symbiosis has been that operators had no real clue how to go about it.  As a result, we’re seeing cost pressure on mobile infrastructure when we can see a path that could almost double total mobile capex if it were to be pursued.  This should generate some powerful incentives to make mobile/behavioral services work, but the first problem is that most don’t know what they are, and the second that they don’t know where to start.

Mobile/behavioral services are services that fuse information from multiple sources to generate insights and advice for mobile users.  If you take the question “Where can I find a good pizza?” as an example, the optimal answer would blend location-based services (where am “I”) with demographic analysis of businesses (where is “pizza”) and subjective assessments of quality (“good”) drawn from a combination of what the user might have liked in the past, pizza-wise, and how others might have reviewed the nearby pizzerias.  Look at this in even a cursory way and you see the structure of the app needed; a cloud process to dig out all that information on request and return it to the handset as a couple recommendations.  The operators have all the pieces needed to make this work, but there is no architecture to build this kind of application.

There is a platform to run it, which is the cloud.  The question is how the cloud as a platform would fuse with mobile backhaul and metro deployment to create a connection network to link all the users with all their application pieces, then how the software could be organized to make this work.  It’s long been my view that SDN could be applied to solve the first of these problems and NFV the second.  What I see as the industry’s challenge, and failing, is that we are not applying the obvious technologies to the critical problems at this point.  Maybe we never will.

If you fulfill mobile/behavioral opportunity with SDN/NFV fusion you get a major-league revenue increment to justify a significant amount of infrastructure investment.  Then we shift from reading consolidation stories to reading advancement stories.  I’d like that, and I’m sure most in the industry feel the same way.  If that’s true, then we have to start holding SDN/NFV players’ feet to the fire not on how they do some stupid, trivial little short-term thing but on how they compose those services of the future.

Every once in a while I get a break and have some time to review the comments people make on my semi-annual surveys.  The quantitative results can be tabulated pretty quickly but I have to grab a minute here and there to see what people have added as clarifying/expanding remarks, and it’s usually worth the effort.  This week I’ve been looking at the enterprise vision of cloud computing.

Enterprises tell me that the cloud is a still-a-bit-fuzzy evolution of the virtualization trend.  Virtualization, they say, was a way for them to apply multi-programming principles to applications that were designed to run not as tasks or threads but on dedicated hardware.  They were able to cut costs by consolidating servers.  IaaS is seen by most enterprises as essentially a hosted form of virtualization.  They found that there were some applications with utilization low enough and data volumes light enough that the pricing model for public cloud services made sense.  Add these situations to the combination of pilot/development use and you get the current cloud market.  You can see that these all represent “special circumstances”, and that this kind of cloud usage is not and won’t be a threat to internal IT or current practices.

The next step, says enterprises, is to apply public cloud services to another special circumstance, the workload portability applications.  There’s something to be gained in some businesses by sizing internal IT for something less than peak loads, then letting work flow out to a public provider.  It’s even better if you’re accommodating an internal failure by overflowing onto public resources.  Nearly all enterprises have looked at this, but in nearly 80% of cases they find that the data access costs are prohibitive.  Sure they can build a cloud configuration that has the attributes they need, but they end up buying servers in someone else’s data center and not using cloud computing.  This is why companies like IBM and Oracle have promoted packaged configurations; two-thirds of enterprises say that using one of these data-center-in-a-box configurations is cheaper than using public cloud services to support workload portability.  In all, this new cloud application source isn’t exploding the opportunity space either.

What companies are looking at most, or maybe I should say “looking for most”, is a new paradigm for cloud applications.  For the last decade, enterprises have looked at componentized applications to enhance productivity by tuning application data screens and functionality to classes of users rather than having one data presentation model for all.  With the advent of mobile broadband, these businesses now see “point-of-activity empowerment” as a source of productivity gains.  That means pushing information and even collaboration right to where the worker is, in the exact context that’s needed.  One of my survey enterprises likened it to having a worker’s second-tier support team virtually at hand when needed.  This, enterprises say, could be a major benefit.

What’s not clear is how critical “the cloud” is in realizing it.  PofA empowerment is an application integration issue, and you can solve it with SOA components or RESTful interfaces and something to scrape API data into a flexible presentation format.  In effect, every current application a business runs that presents results via an API is a SaaS private cloud service.  Private clouds in the sense most mean it, meaning implementations of IaaS or PaaS using the same software tools as a public provider would use, are proving harder to justify as a step up from virtualization.

If you look at how the cloud might change IT spending by enterprises, or drive massive service deployments on the provider side, you have to look beyond nickel-and-dime impacts from the applications we’re running in the cloud today.  Enterprises think it will have something to do with creating agile deployment platforms for point-of-activity apps, simply because if it doesn’t they don’t know where the benefits to drive massive cloud adoption would come from.

What this means, of course, is that we’re not doing a very good job of preparing cloud technology for a commercial future.  I think HP and IBM and Oracle are all trying to do that, but their attempts are contaminated by two factors—a drive for short-term results and the lack of media focus on relevant issues.  My model says that point-of-activity empowerment for businesses could drive cloud revenues up so sharply that the current market would be a pebble on the beach by comparison, but that’s modeling the opportunity based on the productivity benefits.  We still need to figure out how to reap those rewards.  Likely the solution will come from the convergence of various as-a-service trends, SOA, application integration, web apps and APIs…a host of things.  Users themselves will assemble the goods at some point—maybe 2016 or so.  Or we could present them with the package now and accelerate the industry’s profit deposits considerably.  Seems a logical choice to me.

I’ve been looking at the impact of the cloud, SDN, NFV and all of the rest of the growing list of acronyms.  My focus has been on the network equipment side, and the vendors who supply it, but there’s another piece of the puzzle, the IT side.  Whatever functionality leaves purpose-built network devices arrives somewhere else, unless we think networks will get less functional over time.

What’s happening to the IT guys?  One interesting data point is IBM’s decision to rebrand the “IBM Services Delivery Manager” as the “SmartCloud Orchestrator”, and it may be that Orchestrator is the ball-carrier for IBM’s vision of a cloud-driven network.

Orchestrator is a system package that is designed to create a total framework for cloud deployment and not just an overlay to support provisioning.  The unique perspective of Orchestrator is that it’s a cloud’s-eye view of applications, meaning that it’s designed to make application developers and IT professionals think of application deployments in the cloud as a holistic process, almost treating the cloud as a virtual computer.  That’s a very critical step because once you view the cloud as a virtual machine, you can start programming for it, which is exactly what IBM plans to do according to operators who have heard the pitch.

Everything we talk about in terms of modern application network evolution can be framed as the result of a DevOps or Quantum process.  We know that because it is already being done; Quantum’s evolution has been in no small part an expansion of the network models or templates that it recognizes.  But suppose that DevOps or Quantum (or, dare we say, Orchestrator) could also frame network functionality—help to host and connect virtual functions and centralized control planes?  I’ve pointed out for a couple of blogs that we need to be thinking about how you develop all this stuff we’re ceding magically to the cloud.  Why not develop it as a cloud application?

Probably the best place to test the efficacy of this notion is in the mobile space.  If you look at modern mobile/4G-LTE deployment you see that Systems Architecture Evolution (SAE) broadly defines a mobile world that exists at three levels.  There’s a service plane that’s made up of IMS elements, there’s a signaling plane (eNodeB and MME), and there’s the Evolved Packet Core with the SGW and PGW.  All of IMS is arguably a hosted process, and so is all of the signaling handling.  What’s left is the EPC and the notion of mobility management of the data plane.  I don’t think there are many who believe that SDN or NFV processes would divert the data plane into servers (it doesn’t scale in performance or cost), but if you were to combine SDN central control with the hosted elements of IMS and MME, add in the control pieces of the SGW and PGW, and link the result via OpenFlow to simple switches, you could create a mobile-metro model that was totally revolutionary.

Forget protests that you can’t virtualize all of mobile infrastructure; you can virtualize everything but the data plane and that’s all anyone could expect.  Given that the data-plane pieces of this puzzle are those simple switches that could reasonably be stamped out by pretty much any competent manufacturer if somebody like IBM offered a spec, we can see that a player like IBM could come to own this process.

The challenge for IBM is the partnership challenge.  IBM has been trying to be the foundation player, relying on partners to offer the service- or application-specific parts of the puzzle.  That’s fine for applications intended for enterprises, but it has a fatal flaw when targeting the evolution of operator networks.  The players with assets in the service layer (Alcatel-Lucent, Ericsson) aren’t likely to cede the market to IBM.

HP and Oracle probably hold the key here and not IBM, despite the fact that IBM is taking a giant step with Orchestrator.  HP has specific network assets, and so does Oracle (different ones, to be sure).  HP has as good a cloud incumbency as IBM and Oracle has a better network-software incumbency.  Could HP or Oracle define a virtual-machine cloud model like Orchestrator but make it immediately relevant to the service provider space by including mobile service features?  Sure they could; we just don’t know if they will.

And we should care a lot, particularly if we want to predict the future of SDN.  I’ve gotten most of the way through my model of SDN impact, and the inescapable conclusion even at this early point is that no vendor can succeed in the SDN space without selling mostly to network operators in the next three years.  Also, nobody can win with network operators without winning in metro-cloud.  For all the IT vendors, the mission I’ve described here is the formula for relevance.  For network equipment vendors, the mission I’ve described is potentially their Achilles’ Heel; if they lose this then they lose control of both SDN and NFV, and likely forever.

We’re living in a period when every day someone proposes a new networking revolution, and I find it interesting that the networking revolutions that we’ve really tried to bring about are still in the smoky-room-unshaven-anarchist phase.  Five years ago, network operators had three priorities for monetization, the top one being content.  As of last fall, they were telling me that they had made little progress there.  Sixteen percent of content projects approved had even gotten as far as the trial stage.  Why?

In the course of these project developments I got about two-dozen detailed project plans to review, and I was struck by the similarity of the plans—not so much in the specific details but in the fact that the centerpiece of the whole thing was the functional block diagram.  On the average these diagrams had about 20 blocks, and they made great reading in the executive washroom I’m sure, but they don’t do much beyond organizing what you have to do.  In particular they don’t deal with the “how” part.  In eighteen of the plans I reviewed, the operators were unable to find components to match the blocks, and that simple truth is what stalled the project.

So what do we see today when we look at “revolutions” like the cloud, or SDN, or NFV?  The dreaded functional block diagram.  OK, we all know that the cloud has to provide for resource hosting (a block), management (another block), assignment (third block).  Does drawing this picture move the ball on designing a cloud stack or implementing a cloud?  Not unless you’re doing “Dick and Jane do Cloud”-level work.  With both SDN and NFV we have proposals for functional architectures, but if you wanted to write an SDN or NFV application today, how far do you think you’d get?  Not far enough.

In the early days of service-layer standards work, after months of frustrating conference calls on a particular standard, I got an email from a big European telco, and it said “Tom, you have to understand we’re 100% behind implementable standards.  We’re just not sure this is one of them.”  Which is my big gripe about all of this stuff.

Everything about the cloud, or SDN, or NFV has to be about APIs—application program interfaces that let software call functionality and drive changes in resources or applications.  In modern development, APIs are normally defined as part of an object model, which is a set of software abstractions that represent the pieces of the thing being done.  We use, indirectly, object models every day that we use smartphones or browsers or .NET because the stuff is built on that principle.  So where is the object model for the cloud, or SDN, or NFV?

Well, we are not there yet, with any of the standards activities built around our revolutions.  We’re not even moving convincingly in that direction.  I’ve been reading a thread online where a group is looking to define SDN.  Well, SDN is already defined.  Here’s a presentation that provides as good a foundation for the notion as you’ll find anywhere:  http://www.slideshare.net/martin_casado/sdn-abstractions.  The presentation not only defines SDN, it introduces a key point about implementing SDN or anything else; software-building is about the creation of abstractions.  That’s what object models define.  If we had an abstract object representing a network and mapped it to both direct devices and virtual subsets, we could write apps to that object’s APIs and the same code works in all cases!  Isn’t this something we’d want?  Is it something we’re talking about?  No, because we’re not talking about the right stuff.

My suggestion has been that every “standard” activity that’s aimed at software-driven processes be accompanied by an open source project that builds the object model, prototypes the logic, runs lab tests and demonstrations, and insures that the issues of functionality, performance efficiency, security, and availability are addressed from the first.  This would also insure that “standards” don’t end up available only through proprietary implementations.  I still think that’s the best approach, but I’m not seeing much support for the notion in the vendor community (Surprise!) or even among operators.  Yet if you look at those agonizing standards processes that never seemed to get anywhere, those operator projects like content monetization that are still pasted to walls in conference rooms and not running in networks, they’ve all fallen prey to problems that collateral development could have resolved from the first.  If we want software to take a key role in the future of networking, we need to start thinking like software people.

 

 

You’re familiar by now with my rants on how we’ve decomposed ecosystemic shifts like the cloud, SDN, and (eventually perhaps but hopefully not) NFV.  What has to be considered as a whole new cooperative model for IT and networking is instead being looked at as a bunch of disconnected product changes that might lead to a future but quite likely won’t lead to the optimum one.

There’s probably no better example of this need/risk profile than the security of the future “fusion” infrastructure; network and IT as one layer and not two.  Today we have security issues that arise largely from two sources; contamination of content (malware on websites) and contamination of access (hacking).  With the cloud we have a set of new issues as well as an exacerbation of many of the old ones.

Generally, the cloud introduces a new risk of resource contamination, and a new source of risk in signaling hacking.  The IT/networking fusion that’s coming is a distributed and cooperative community, and cooperation in a distributed anything doesn’t come easy.  When we talk about resource pools we assume that we know where everything in the pool is and what its status is, for example.  Could somebody enroll themselves in a pool and become in effect a part of our applications?  Why not, if we presume that cloud resources are dynamically allocated?  The dynamism means there’s a process for resource enrollment.  But even easier, why couldn’t you attack a resource pool by spoofing status messages that made the resource appear to be down, or make a single resource look “available” to everyone no matter what its state?

And it gets worse.  If we have centralized network processes, we can hack them and attack them with denial of service.  We can spoof them too.  One little change in a forwarding table can send packets down a totally different path.  One fork in the table can monitor everything we do.  A virtualized network process can be the firewall logic we just offloaded from our gadget, or it could be the firewall logic planted by a hacker.

It’s not that the cloud, or SDN, or NFV creates a problem as much as the combination of those things exposes problems we’ve had all along.  There are some fundamental truths about the network of the future that we should be able to see today, and truth number one is you cannot have user traffic sharing a network with service signaling.  “The Internet” is a user network so the Internet can’t be how we control services, intra-service (between components) or inter-service (between services, or between services and users).

Truth number two if the new fused IT/network world is that telemetry from resource/network monitoring has to be managed in volume and also separated from user networks.  Operators are already saying that they face applications where monitoring traffic exceeds service traffic.  You can’t have that if you want to control costs, but you also can’t have that if you want to have available and secure networks.  Any monitoring problem in a pooled-resource, central-controlled, environment has the effect of telling a lie to the controller, and your cloud can’t be built on a web of resource lies.

Truth number three is that you can’t add security to an insecure environment.  We are focused too much today on “making the network secure” by adding components that are designed to identify and block bad things.  We need to focus on networks that can be driven to do good things as their standard behavior.  One thing that means for things like the cloud or SDN or NFV is that there is no such thing as inherited trust.  Any contributor to anything has to be validated by the federating process that joins them to the community.

You can draw a picture of where this has to go, which is the notion of a network at two layers, the structure I’ve called “Cloudnet”.  With Cloudnet every user accesses the cloud through agent processes that the user can explicitly trust.  These agent processes in turn trust resources and make the connection.  There is no access without a trust transfer, and the process of mediating resources happens inside the inner cloud layer where it’s never accessible to user traffic.  SDN central control happens inside here, and so does cloud resource commissioning and network functions hosting.

There’s still more, I think.  All the furor over how the cloud or SDN is going to demand all these network probes collecting intelligence for delivery to a central point creates a commercial problem with profitability even if we can solve the security issues of spoofing monitoring points to lead to bad control decisions.  With SDN, for example, we could create domains of manageable size controlled by a central element and presenting themselves as virtual devices to a higher-level collecting domain in much the way that internal routing areas/domains can be aggregated into ASs with border gateways.  We need to be looking, in our review of SDNi (SDN interconnect), on how we communicate state/status between the domains and how we make global routing decisions by aggregating local ones.  There’s been some work done on this in the past in protocols as old as SNA and ATM, and since we’re now looking at a future where we re-create some of the problems of the past, we should look at how they were solved and adapt the strategies.

We are never going to realize the cloud’s potential, or SDN’s potential, or NFV’s potential, if we create a future infrastructure that can’t be commercially viable, available, and secure.  We can’t assure that with bottom-up design, and so we need to be looking to vendors and standards bodies to address these high-level concerns, to be sure that our steps to the future don’t take us over a cliff along the way.

There are always a few announcements or news items in a week that by themselves don’t make the grade in justifying extensive comment, but that might demonstrate something as a collection.  This week we have just that, with announcements from Arista Networks, Mellanox and 6WIND, and BTI Systems.

All of these announcements are cast in an SDN mold, and by now I’m sure you realize that I’m skeptical of the exploding hype cloud surrounding SDN.  All are also, under the covers, grounded in technology evolution and not SDN revolution.  That’s not necessarily a bad thing because we do have to evolve to SDN, but it demonstrates the balance being fought today in the network market.  It’s a war between the need to achieve press visibility by latching on to the concept de jure while at the same time selling your heart out to get revenue to make your venture backers or stockholders happy.

Arista is in my view a good example of a company who’s working to solve the special problems of the cloud, and in particular the problems of the cloud data center.  They offer a line of switches that are based on custom network software, and that software handles a host of issues that have plagued cloud data center designers.  Think spanning tree, monitoring, visibility of VMs and associated network segments, and the old bugaboo of adaptive network behavior.  There is no question that the concept is valuable, no question that cloud networking is important, but there is a question of whether this fits the real model of SDN or whether it’s an argument (and potentially a quite successful one) whether we need central control to resolve the issues of today’s distributed networks.

Mellanox is another interesting contrast.  On the one hand they are, with their long-standing support of InfiniBand switching, arguably the dominant player in fabric switches.  On the other hand, most enterprises in our survey never heard of the company.  Their alliance with 6WIND, a company I’ve noted as the first to make a credible positioning in the Network Functions Virtualization space, is aimed at creating a fabric-based, server-optimized architecture for the hosting of network functions in the cloud or the creation of componentized service-layer technology for network operators.  This is again a very good idea, and the alliance is actually more than sufficient to validate their position, but their launch got next to no notice despite the fact that Light Reading has now committed itself to covering NFV.

With BTI we have yet another slant.  The company talks about “cloud interconnect” and “data center interconnect” and “SDN” in their positioning, and certainly there is a need for 1) intra-cloud connectivity, 2) data center linkages inside a cloud, and 3) software control of connectivity in the cloud.  BTI demonstrably provides at least credible support for all three of these things, but they just can’t pull them together into a compelling story.  Why is “data center connect” not more an application for the fabric or switching solutions inside the data center?  Most connected-data-center applications I’ve seen have hundreds of ports in the data center and perhaps two or three to connect data centers.  What are the applications that generate intra-cloud or data-center-connect needs?  Horizontal traffic among applications would seem a logical reason to connect two data centers; is it the only one and why is it likely to be increasing now when presumably we’ve not had a major problem up to this point?

The common theme here is that “the cloud” is a new relationship between IT and networking, one where networks are a resource to applications as much as memory or CPU power or storage.  It defines a harmony of resources and not the connection of things, and because of that it puts new demands on the networks and the IT processes.  Both must evolve; both are evolving.  What we need to do is to address the goals of the evolution, frame an architecture that represents the model of the future cooperative network/IT relationship, and evolve both networks and IT into conformance with that new model.  Simple, right?

What we are doing is trying to force that balance I talked about.  We want to make the goal not the harmony of the cloud but the individual baby steps we’re taking.  SDN is not the wrapper for every vendor claim that involves software, networking, or definition, it’s a specific notion to replace distributed adaptive network behavior with centralized control.  We have three SDN camps today.  One (the centralists or OpenFlow purists) is actually pursuing the original goal, but they’re way behind the curve in defining all the pieces.  Another (the distributionists or “evolutionaries”) is sustaining most or all of the current distributed network behavior and adding centralized technology to bound or override it.  A third is simply erecting an SDN billboard and calling a press conference.  NFV, which is becoming the latest media hot button, is a bit behind SDN in terms of cynical evolution toward a Roman spectacle, but clearly heading for the same fate.

Arista, in my view, is representing a valuable and maybe even vital discussion, which is whether we need to consider centralization of network connectivity and forwarding control to meet the goals of cloud networking.  Mellanox and 6WIND are asking whether the data center has to be better coupled to the network than traditional network-layer server middleware could achieve.  They’re also asking what would host virtualized functions for NFV.  BTI is asking whether the metro network of the future is going to look totally different based on the explosion of hosting that will emerge from the combination of profit-driven cloud adoption by operators and the hosting of newly virtualized functions extracted from devices.  But none of them are asking the questions the right way, and so none are moving us closer to an answer.