How to Save Nokia Siemens's Optical Business

Pleasantly sirpised to see thatLarry is still speaking as a Capella's CEO.

Anybody knows if Capella is still alive and funded? I thought they were done.

Gross margins in the optical business lines are below 40% and falling.  Adding software on custom-built hardware won't get the overall margins back, either. 

Let me quote 'obaut'

Tuesday December 4, 2012 9:03:58 PM

“On how futuristic/strategic *software* defined networking is: Isn't it true that, when there's the alternative of clever architectural solution, best software is no software. Shouldn't we thus be looking toward +++*user/application/traffic*+++ defined networking?”

Most people assume that network traffic is a near continuous stream. That was true in the days of 9600 bps, but the scale of the traffic packets size to the speeds (time) on the network have drastically changed. Watching outgoing traffic (See how below) from a PC in 2k packets at 45/100Mb shows that the transmission of each packet lasts for a very miniscule part of a second and becomes a stream of impulses with gaps. (Calculation left to reader for their favorite speed)

So as traffic leaves contributors as impulses & gaps they are usually merged on higher speed lines as shorter time impulse transmissions. Managing this traffic merger requires very fast scheduling of individual packet impulses, not allocating/fixing bandwidth. This dynamic traffic requires the speed only available from very fast hardware/switching fabrics. High level network guidance/policy decisions can be passed to the hardware/switching fabric using table/state driven methods.

But the question is: how fast this high level guidance/policy can be provided to make decisions on allocation/scheduling of BW to dynamic impulse traffic in a timely or correct manner. The traffic mix varies completely second by second with the current short transmission times and mixes. My observations of both tier 1 and enterprise networks traffics. But can this be managed from software on network processors deciding sub-groups based on constant parameters or else using traffic reports of what has already happened????

OP

PS  For visual confirmation of impulse traffic use PC with W7;

http://addgadgets.com/network_meter/

And BW was once considered almost free!

In the last few years much more granular allocation management is becoming required as the BW cost increases and the demand and mixes increase exponentially.

To clarify: where I said adaptive networking (down to layer 1) is needed is _within_ the individual service contract networks, eg within a WAN contract for an ASP or large enterprise, the external parameters (SLA) of which can remain static for several months or years and can be centrally controlled. This is consistent with present commercial models; it just makes their implementation more efficient.

That argument is one that I think would have to be made to the buyers themselves; the approach is not consistent with the positions that they've taken, at least in my conversations.

Operator views on services is that you don't discover them or have them adapt to your needs, you purchase them, thus they are imposed by policy on infrastructure.  That's what's at the core of the central control process.  Central control lets you engineer network behavior to the services you've committed to provide.

The other side of the coin here is that any wide-area network strategy that aims for multiple service levels or grades, however they are defined and whatever their relationship to applications might be, has to contend with the current best-efforts model of the Internet and the limitations of the current peering process on QoS-delineated services.

So one way to look at it is that regular IP-routing under-controls the network from the operators' point of view by letting the user traffic patterns direct the network behavior even in a way that is not accordant with the network operator's intents. SDN would bring (operator/user/application-owner) controllability to IP-routed networks.

I find that too reactive, and that SDN over-controls matters that should be handled automatically at data plane, enabled by clever system architecture and intelligent data plane.

Much of the problems with traffic defined (IP routed) 'adaptive networking' actually arise from the technical limitations of the presently used equipment: for instance, the traffic load adaptivity does not extend beyond the lowest packet-switching layer. With the present hardware gear, the physical network layers are non-adaptive to the packet traffic load variations, causing (technically avoidable) bottlenecks and/or poor overall utilization, and often both - even at the same time.

This point is highly essential: the practice of mixing unrelated traffic streams in same physical layer capacity pools (rather than keeping them isolated at their own physical layer sub-pools) is a reaction to the lack of adaptivity of physical layer bandwidth allocation. With present HW gear, it would be too inefficient to dedicate physical layer capacity resources to each service contract such as an enterprise WAN or CDN. Instead, in an effort to improve network capacity utilization efficiency, unrelated (eg different enterprise/ASP customers') traffic streams are made to share the same physical resources. This practice (a reaction to that the present HW is limited to non-adaptive physical layer connections) leads to the everything affects everything problems of the present Internet, and the consequent (reactionary) need for control, eg via SDN.

A more proactive solution is a data plane that makes it economical to keep unrelated network applications (e.g. traffic from different network service contracts*) on their own physical layer sub-pools. A way to make this economical is to extend the packet traffic load adaptive bandwidth allocation down to the physical layer: same way as L3 IP packet load drives the creation of L2 forwarding layer frames, the L2 data loads should drive L1 bandwidth allocation (within each contract-specific L1-sup-pool) at the actual packet/byte load granularity. 

This will simplify the upper layers of the networks and the OAM (security policing, contract administration etc) a whole lot.

*Besides single customer/user organization contract networks, dedicated physical layer sup-pools can be organized for inter-exchange applications, to provide inter-connectivity, as explicitly desired/authorized, among different user groups. This model enables flexible, cost-efficient and high-performance Internet connectivity in a manner that is scalable and secure.

I would argue that most IP architects would say that IP networks were "traffic-defined" in that they adapt to traffic and topology in an adaptive way.  The difference between what I perceive the goals of SDN to be and the notion of traffic-defined or adaptive networks lies in the question of permission.  An SDN maps connections and resources based on software control, which means that the network does what it's explicitly set to do.  Adaptive networks do what they're presented, which some will say isn't what they're supposed to do.

But I don't want you to believe I think SDN will displace everything.  The central-control concept of SDNs likely wouldn't scale to the Internet level.  SDN technology is really about "intranets", networks inside resource pools, networks inside enterprises, etc.

With respect to application-defined networks, it's my view that individual application control of network services isn't practical.  The Cloud-SDN marriage would mean that provisioning a cloud application would collaterally provision the network service, which is not applications defining networks but applications and networks being defined by a common (DevOps) process.

Yes, technologically the point is to minimize, and if possible, eliminate the need for middleware type software, via clever architectural solutions. And business-wise, the success of X-as-a-Service business models is largely due to that they are "no software, no hardware" from the customers point, just the results/functionality needed.

But regarding what is strategic in networking technologies and services: my point is that ***SDN actually is reactive***. Operationally, SDN is a reaction to the way the network control software was embedded in the dominating IP router vendors' boxes, locking the service providers to vendor-specific network technologies. And there are response time etc. performance reasons why SDN is not even a very good technology approach for solving that operational/commercial problem.

However, the much more important goal is to find a way to minimize/eliminate the need for the network control plane software. That is the goal of what could be called the application defined networking: in this architecture, the user application traffic patterns (within their longer term contract/policy defined boundaries*) directly drive the realtime network behavior at the 'bare metal' hardware level, eliminating the need for middleware, which causes non-value-adding complexity, and prevents timely response to network data plane events, thereby leading poor network efficiency and/or QoS.

*Naturally these matters shall remain in the domain of management plane and non-realtime control plane software.

Btw, can you give examples of "current adaptive networks (that) are traffic-defined"?

I think that any of those concepts would have to be defined to be assessed.  In any event you could argue that current adaptive networks are traffic-defined.  Operators seem to believe that they want less adaptive behavior; that's one of the principles of SDN.

I don't think the best software is no software; minimalism?

On how futuristic/strategic *software* defined networking is: Isn't it true that, when there's the alternative of clever architectural solution, best software is no software. Shouldn't we thus be looking toward *user/application/traffic* defined networking?