Next-generation Architecture archives - Uncommon Wisdom

Uncommon Wisdom:

next-generation architecture

Oct 29 2009   12:31PM GMT

Juniper’s radical service-layer software and semiconductor architecture speaks to carriers and enterprises



Posted by: Tom Nolle
service-loayer architecture, next-generation architecture, Juniper, Junos operating system, cloud architecture, semiconductors, platform as a service

We can’t apologize for the characterization here; Juniper announced a radical combination of an extensive service-layer software system and a new semiconductor architecture, taking the most profound step the company has taken since it was founded.

The new chip is a family, the first member of which is Trio. It is based on a “Network Instruction Set Processor” model that builds software on the device using instructions customized for network behavior control rather than general-purpose instructions, as NPs do. In this respect, the chip is almost like an ASIC, but unlike an ASIC it’s programmable at the primitive NISP-instruction level, so new features can be added right down to the instruction level. It’s this architecture that accounts for the considerable improvements in performance, scalability, power efficiency, etc. that Juniper has demonstrated (through independent lab tests).

The software (Junos Space) is centered on a complete restructuring of the Juniper Junos operating system, and it extends Junos to cover not only Juniper devices but also independent software development, and even a new device client (Junos Pulse) that will provide security and identity management, VPN control, and connection control.

The software side of the announcement is the most critical because it is based on middleware to create what is, in effect, a platform-as-a-service cloud on which operators can build service features and service management components.The software there can then leverage software running on the routers through the old Juniper PSDP program, and through that could even, in theory, be linked to special “primitives” programmed into the new Trio NISP chip.

From a selfish vendor perspective, the most important thing is that Juniper ties the service layer development downward into its devices (through its router development programs like the old PSDP) and even potentially down into the chips themselves. That creates a value circle for them and it also lets operators build differentiation by linking their service solutions tightly into the network, giving better integration, operations, and performance than OTT players could achieve.

Juniper released applications for Ethernet activation, surveillance and monitoring, and problem management in the network. These are built on the Junos Space architecture. This new model is so radical that frankly it’s hard to believe it came out of Juniper, never known either for software or for making game-changing moves. This is clearly one such move, though, because it will at the minimum catalyze the whole service-layer marketplace.

Juniper also announced an expansion of its IBM OEM deal to include the SRX, which offers security control and falls under the Junos Space software umbrella at least in a development sense.

Finally, BLADE Network Technology announced it would license Junos for blade server switches, possibly the first porting of a network OS to another platform. Just assimilating all of this will no doubt create some headaches, but early indications from operators suggest they’re very interested, and there is also surprising early interest among large enterprises, particularly in the cloud computing potential.

Feb 24 2009   3:24PM GMT

Juniper orchestration initiative to address services platform



Posted by: Tom Nolle
next-generation architecture, next-generation services architecture, Juniper, Alcatel-Lucent Cisco

Juniper, at its industry analyst event scheduled before its primary analyst meeting, hinted of a major initiative later this year in what the company calls “orchestration.” The new activity, coming out of its emerging network management team, appears to be creating a model for NGN services that is not radically different from the NGNSA model we propose in our TMT Advisor Planners’ Briefing.

Just what Juniper will release was not discussed, but the timing was early second-half of 2009. The lack of an effective architecture for NGN services is in our view the major issue in the industry, and Juniper’s lack of progress toward one is one of our most significant concerns about the company’s strategy.

If Juniper were to move aggressively here we believe that it could steal the march on Alcatel-Lucent and Cisco, or at least force them to step up their respective plans. The way the idea was explained makes it sound far more like a fundamental architecture than like “network management”, though, and we hope Juniper won’t bury the idea in the wrong organization.


Feb 13 2009   7:03PM GMT

Service layer platform vendors: Not game-changing yet



Posted by: Tom Nolle
service delivery platforms, next-generation architecture, Nortel, Juniper, Cisco, HP

Nortel may be preparing its own application platform, something that would compete with HP ProCurve, Cisco’s new blade server, and Juniper’s JCS1200. All of these products reflect the reality that the “network” is dividing formally into a service layer and a transport layer, and that value-add in the service layer is critical to operators monetizing network investment.

The challenge for Nortel here will be the same as for other players: It’s not enough to have service-layer platforms; you also need an NGN Services Architecture, a framework for application/feature creation that empowers the platforms you’ve deployed.

Truth be told, none of the applications presented on these platforms so far has been compelling or game-changing, and operators want the game to change. Our view remains the same: The standards bodies tasked with work in the service layer are moving too slowly—as telco standards bodies tend to do. The vendors have been happy to blow kisses at standards instead of taking risks to get in front of the issues, and the operators have little chance to progress toward their goals without vendor support. This accounts for the uniformly low scores equipment vendors earn from operators in their support of operator monetization goals.