x
Routing

Redback Beefs Up Its Router

Ericsson AB (Nasdaq: ERIC) subsidiary Redback Networks Inc. is launching its most ambitious edge router yet, hoping a combination of increased density and subscriber-related features will give it an advantage over rivals Cisco Systems Inc. (Nasdaq: CSCO), Juniper Networks Inc. (NYSE: JNPR), and Alcatel-Lucent (NYSE: ALU).

The SmartEdge 1200, announced today and set for general availability in August, is Redback's highest-density box, with 480 Gbit/s of switching capacity (that is, 240 Gigabit Ethernet feeds supported) in one fourth of a telecom rack. On a full rack basis, that appears to outdo most edge platforms on the market, with Juniper's MX960 being the notable exception. (See Redback Adds SmartEdge 1200 and Juniper Antes Up on Ethernet (Finally).)

Table 1: Density Wars
Company Platform Capacity* Size
Alcatel-Lucent 7750 SR-12 400 Gbit/s 1/3 rack
Cisco 7613 720 Gbit/s 1/2 rack
Cisco 12810 800 Gbit/s 1/2 rack
Juniper M120 256 Gbit/s 1/4 rack
Juniper MX960 960 Gbit/s 1/3 rack
Redback SE 1200 480 Gbit/s 1/4 rack
Source: Company literature
* Full duplex. That is, divide by 2 to get the number of simultaneous Gigabit Ethernets supported.


Equally dramatic is the laundry list of functions integrated. The box includes: security features such as intrusion detection, IPSec, and a firewall; a session border controller; and deep packet inspection capabilities for detecting peer-to-peer traffic. The box also includes some mobility features -- along the lines of fixed/mobile convergence --- that Redback isn't fully disclosing yet.

This has all been added to a platform that already includes Ethernet aggregation and the functions of a broadband remote access server (B-RAS). The SE 1200 uses the same operating system as other SmartEdge boxes and can use the same blades as well.

The new release shows that Redback isn't stagnating after its acquisition by Ericsson, which was completed early this year. (See Ericsson Offers $2.1B for Redback , IPTV Drives Ericsson to Redback, and Ericsson Completes Offer.)

So far, Ericsson has made good on keeping Redback's name alive and has begun intertwining its engineering efforts with that of the IP equipment firm. Those unspecified mobility functions stem from Ericsson expertise, for instance.

"It's a great step for Redback and a big win for Ericsson -- proof that Ericsson hasn't slowed them down," says Eve Griliches, an analyst with IDC .

Redback says the SE 1200 is a reaction to the number of applications that now rely on IP. Routers are being tasked to handle more jobs at once -- security, VOIP, the throttling-down of P2P flows -- and in that complexity, Redback thinks it sees a chance to outdo the industry's giants.

"It opens up the largest IP services market we've ever seen," says Arpit Joshipura, Redback's vice president of product management.

The concept isn't lost on other companies. Session border controllers, for example, are finding their way into Cisco and Juniper routers, arguably siphoning some of the market from Acme Packet Inc. (Nasdaq: APKT) and Veraz Networks Inc. (Nasdaq: VRAZ). (See Cisco Integrates Session Control and Juniper Kills Its Session Controllers.)

Griliches points out that Redback's melting pot of features is reminiscent of CoSine Communications, which also touted feature integration with its IP-based subscription management box. But it didn't work out, and CoSine eventually became better known for its agonizingly slow shutdown. (See CoSine Terminates Merger Agreement, CoSine Seeks New Blood, and Fortinet Scoops Up CoSine IP.)

CoSine's main problem was that its box slowed down if all the features got turned on, Griliches says. By contrast, Redback is claiming that the SE 1200's functions, such as security and P2P detection, will run at 10 Gbit/s without degrading the performance of the router.

"All those features are processor and memory hogs, but Redback made sure there were separate ASICs, processors, and memory carved out for each of them," IDC's Griliches says. "It also made sure each of those features happen in a certain order in the router. It's making sure that where the stuff gets processed isn't a pull on the overall system processing."

One key point is that Redback doesn't use up router slots for most of these features -- its session border controller, for example, sits on the card that handles all control-plane functions. Security and P2P detection is housed on a separate blade, and once, for instance, a P2P flow is detected, the system can forward all other packets in that flow to the appropriate linecard.

Even bypassing the features, the raw density of the box is impressive and useful to carriers, analysts say. The new box gives Redback "a huge speed and feed argument," says Andy Buss of Canalys.com Ltd.

In addition to the increased capacity, the SE 1200 will handle eight times the subscribers of its predecessor, the SE 800 -- that is, more than 500,000 subscribers, compared with 48,000 for the older box, says Redback's Joshipura. "Subscriber" in this case refers to individual services, so that one busy household running video, VOIP, and P2P downloading all at once would count as several "subscribers" inside the router.

The SE 1200 is based on a new generation of Redback-designed ASICs. New I/O cards being built for the box include one with four ports of 10-Gbit/s Ethernet, and another for 20 lines of Gigabit Ethernet. The box has 12 slots for such cards and another two reserved for controller cards.

Redback says Taiwan's national carrier Chunghwa Telecom Co. Ltd. (NYSE: CHT), which has already deployed the SE 800, will be the first operator to use the new platform. (See Chunghwa Deploys Redback Gear .)

— Craig Matsumoto, West Coast Editor, Light Reading

Page 1 / 4   >   >>
ipLogic 12/5/2012 | 3:07:14 PM
re: Redback Beefs Up Its Router konafella,
also thanks for your opinon !
and I really donG«÷t mind; as said in that video G«£if you all agree, I have failedG«• :-)

but the gadgets you mentioned never really worked as promissed in the first couple of generations, and as you say they were terminal market;
people donG«÷t loose jobs if the integrated camera on the handy takes low-res pictures, but people do loose jobs if you drop 500.000 subscribers because there was bug when you updated the Signature database. (just the thought of it is creepy)

now with L3 and L4-7 in the same box ??
I don't want to blamed being against progress :-)
maybe in 3-5(7) years things change, but now there is lack of manpower to cover it. First you talk to Mr.MPLS who gives you deep dive in VPNs, but cannot spell DPI, then you have Mr.IDS who spells correctly DPI, but doesnG«÷t know the meaning of G«£iG«• and G«£eG«• in iBGP and eBGP.

And you need them both (necessary evil),
but When your (integrated) network burns who do you talk to ?


ItG«÷s just separate people (still) and if G«£integrated peopleG«• doesnG«÷t work, how will the G«£integrated solutionsG«• work ?

Once (if) production of integrated Mr.MPLS/IDS starts, then we can speak integrated solutions. Would you comfortably claim yourself being Mr.MPLS/IDS ? Would someone volunteer and take this burden on his back to claim it ? it's quite a bit of learning and expertise dispersed from L3 up to L7, is it achievable for one guy ? how many of those experts you can produce ? they keep complaining that IP is complex, what will happen when L4-7 gets into the game ?

How many people you know are really experts in Sonet header, and could simultaneously comfortably chat BGP policy expressions ? versus how many people you know that are recognised experts in Only One of the above ?

And I still keep that technically L4-7 is different Hw/ASIC architecture than L3; and fully separate blades sharing just power supplies is Ok (no interaction, separate Sw releases, and no performance compromise), but nothing more than that. You just have to clearly know which one failed, and whether you call Mr.MPLS or Mr.IDS. (and the rest of the box must keep working while one of those gentlemen plays in your life network with his part of the blades)

And finally there should be one Big red G«£Firewall On/OffG«• button that really momentarily works when things go wrong.


Do you have the swiss knife ? do you really use it for your steak ? And be honest :-) have you thrown out your (non-integrated) camera and (non-integrated) mp-3 ? I haven't... I do beleive we all will, some day ?soon?

Cheers
konafella 12/5/2012 | 3:07:15 PM
re: Redback Beefs Up Its Router ipLogic, you are right on the mark. Loosely couple everything and focus each team on making the best (loosely coupled) individual widgets and you will have dominance with the best collection of widgets the market has to offer. But unfortunately you will be stuck conquering a dying market in each individual category as the larger market moves toward integration.

Who makes the best pager? The best standalone-PDA? Best pure-mp3 audio player? You get the picture. It's not about being the best. It's about offering the most integration for the best price and doing it well (e.g. RIM, Apple, etc).

Sure, the terminal market and the network market have different market forces and different needs, but you can't oppose the trend for too long.

The features that defined the so-called "god box" in optical networking (such as ethernet, MPLS, ADM, cross-connect, etc) from the bubble era are becoming the table stakes features of today.

Ideally, I respect your opinion. Practically, the business and market forces defeat good engineering practice time and time again :(

kf
ipLogic 12/5/2012 | 3:07:17 PM
re: Redback Beefs Up Its Router metroman, you touched very good point of G«£Loose couplingG«• of people/intellect/cultures and innovationG«™

e.g. G«£Did NetscreenG«÷s development team got better (innovative, faster developing, profitable, motivated etc) G«£Tightly CoupledG«• under Juniper management (and interdepependent with M/T development team), or whould Netscreen guys have been better (innovative, faster developing, profitable, motivated etc) as G«£Loosely CoupledG«• (partnership, or similar)G«£.

and as I understand it, seems Chambers (probably experienced with his long years m&a) is trying to solve this problem with his G«£Command/Control->Collaboration/CommunicationG«• philosphy, i.e. builds organisational-culture where he G«£wants them AllG«• G«£the Best of eachG«• under one roof/logo/(collect all profits) but still G«£Loose CoupleG«• them so that they can each Innovate/Scale/Develop in the best way without the burden (and without the limits they impose between each other) if G«£Tightly CouplingG«• them together;

(G«PChambers on the CouchG«£ http://www.lightreading.com/do...
http://www.interop.com/lasvega...

and if we assume: developer-team-quality(motivation/innovation)=product-quality->

-> there you have the conclusion if you want to buy Security from Router vendor, or Routing from Security vendor; where ChamberG«÷s phylosophy seems to be looking for a model to bring together G«£Networking vendorG«• by (as) loosely-coupling them together (as possible).

based on (the correctness of) this philosophy L3-Router and L4-7-Firewall should be as Loosely coupled as possible i.e. different boxes is good, or even if you put them in the same box they should Not share anything more than the Power Supply. (and even if possible let each one of them be developed by separate G«£Loosely coupledG«• development teams, if you want to have the best of both of them)
all for the benefit to get the best of their innovation (profitablity if youG«÷re telco, or better service if youG«÷re subscriber)

so it comes to two issues:
- on one side we have the G«£Loose CouplingG«• of people/cultures/intellect/innovaton;
- on the other side we have the G«£Loose CouplingG«• of Technologies/Paradigms in this case L3 with L4-7 in the same box;


The technical part (L3 and L4-7) was touched by metroman, chook (and Mark should run this through his Interdependece model chook's N**2 problem of sub-systems in the same box)


L3 and L4-7 are fundamentally different and it is a challenge (will be dangerous) bringing them together in the same box, although it is G«£necessary evilG«• to bring them somehow together to get the G«£fullySecure-fullConnectivityG«• i.e. the ultimate goal,


1) Hw point of view: can you reuse L3 chips to do L4-7, or opposite ?
L3=IP/FIB-lookup is something else than L4-7=DPI/TCP-UDP-flow-analysis/signature/anomaly-detection, and as metroman said, reusing L3 lookup hardware for L4-7 will always bring compromise in performance to the platform that tries to combine them;
different FIB-vs-Signature match algorithms, different memory access requirements, different tree-search, different buffer requirements, (L3 does by packet where L4-7 buffers to get the full stream), L3 hierarchical addressing vs per-Flow, etc.
Router summarizes N-users->1-FIB-entry;
Firewall expands N-users*M-flows/user->M*N-Flow-table;

2) L3=IP-Router/BRAS operations is completely different than L4-7=Firewall operations
- you upgrade L3-Router sw once on 6-9(12) months, only after G«£heavyG«• trials and tests (for 500.000 subscriber BRAS even G«£heavierG«•);
- you G«£upgradeG«• L4-7-Firewall Sw(signature/protocolanomaly-database) (more or less) daily, and you donG«÷t really have the time to test or trial, but rather you are in a hurry to put that update to the box as soon as possible, before the bad-guys get you.
(Can you really ever enough test behaviour of L4-7 signatrure/protocol-anomaly under 500,000 subscribers each subscriber doing something else)

so what is the $$ price (and stress, and operations guys nerve) with the (almost daily) risk for 500,000 BRAS subscribers loosing-connectivity, if, while upgrading the Signature-database on the Firewall there might be a bug in only one of the signatures ?

3) L3=Router/BRAS run wide/global communication, (OSPF from the whole network, or BGP from other side of the world, AAA with the Radius server), where L4-7=Firewall should be G«£invisibleG«• to the world (bump-in-the-wire);
What happens if some OSPF, BGP, DHCP, PPP bug G«£opens the doorG«• to the Firewall/DPI in the same box ?
suddenly you are not just in connectivity problem, but you also lost your security that G«£shouldG«• protect your box, and prevent the problem from increasing.

So "same box" is Ok as long as they (L3, L4-7) share no more than the chassis itself, and would be good to be developed by different, Loosely-coupled teams.

Cheers
chook0 12/5/2012 | 3:07:19 PM
re: Redback Beefs Up Its Router Some very good discussion in this thread!

We don't seem to have touched on what is my single biggest problem with "God Boxes", which is that having all your functions in one piece of sheet metal synchonises all your version control operational issues.

If you have box A doing function A and box B doing function B, and you find a bug in A or need to upgrade A for some reason, then you only need to upgrade one set of functionality, only need to test and qualify the A functionality in the new code, and for most of the process at least, can forget about B functionality.

If you combine the two functions in a single box, software upgrades are more difficult from the point of view of finding the right release, qualifying and testing the release, etc. What's more it is much easier to get into a situation where no one release works for all functions. As you get more and more functionality into the box this can become an N**2 problem.

--chook
rodolg 12/5/2012 | 3:07:19 PM
re: Redback Beefs Up Its Router
in this table i only see Alcatel, Cisco , Juniper and Redback... but what about Huawei and Foundry?

In fact if we think of Smart Edge Routers we should consider the God Box of Huawei: ME60. Cisco does not have such a box like this neither Alcatel...
Have you heard about Cisco or Alcatel integrating DPI in the edge router?
StartupGrunt 12/5/2012 | 3:07:20 PM
re: Redback Beefs Up Its Router Does anyone have any comparison pricing on the set of products listed in the table?
ipLogic 12/5/2012 | 3:07:23 PM
re: Redback Beefs Up Its Router Ok, I see your point, but the decision how to transport long hold traffic might not be decided only on technological comparison, but rather which technology leads with the traffic (and gets most attention)

e.g.
(a) Broadband subscribers produce 40G backbone capacity over all-to-all automated, switched, short hold and no hold sessions aka IP.
(b) Business subscribers with value-add services (aka IP VPNs) produce 10G backbone traffic =>MPLS
(c) Business subscribers with long-hold sessions produce ?5?G backbone traffic over XXX (technology with least interdependencies)

Looking at 40G IP vs 10G MPLS vs 5G XXX, it looks most profitable to squeeze the 5G on top of the other 40+10 IP/MPLS...

Or you can say, our "well-behaved" business-day e-mails and attachments on our (monitored) company PCs and Notebooks are "peanuts" compared to the multimedia , downloads and other apps that we and our kids generate from our homes :-)

>>ItG«÷s interesting how the behaviour and generated-traffic of the subscribers will change with the new media, i.e. how often and how much we will generate information/data ? will the POTS user/traffic-statics be applicable to Internet user/traffic-statistics ?
And not just how much bps traffic but when and to/from where (dynamics, multicast, business vs residental, etc).

Cheers
Mark Seery 12/5/2012 | 3:07:24 PM
re: Redback Beefs Up Its Router Thanks ipLogic,

>> Only you're bit unfair
(a)- when considering Sonet/SDH transport: since this is One-to-One technology (point-to-point) withOut per-host-Granular Dynamic connectivity establishment capability <<

Perhaps with respect to voice services. But with respect to leased line services that do not go through SS7 controlled equipment, I would assert the comment is fair - but happy to get feedback.....

>> The keyword is "Distributed" (and bug-free of course).....<<

I would assert that the history of networking provides plenty of proof points that there are bugs / interdependencies that were not predicted acurately (and therefore avoided) by smart people; whether they be subtle timing relationships between SS7 switches or the behavior by having, or not, BGP dampening. Therefore interdependent systems are likely to always contain some inherent risk, even if it is the risk of unpredictable behavior under resource depletion conditions. The salient question then becomes when do you want to or need to accept this risk. For scaleable (millions of consumers), automated, switched, short hold and no hold sessions the risk appears to be unavoidable, today. For long hold sessions the risk is not unavoidable so then it simply becomes a question of preference - what are the cost/operations benefits/tradeoffs of additional protocol and/or equipment layers in the network. Different people answer that question differently due to opinion, organizational structure, business model, values, service mix, etc........in short, it is a market - and a market in transition at that.
paolo.franzoi 12/5/2012 | 3:07:25 PM
re: Redback Beefs Up Its Router
Integrating functions between what were previously separate products occurs all the time. It can be a good idea and is so generally when the 2 products are deployed together in a large application area 80% of the time (using the old 80/20 rule).

Why large? Because the R&D costs of doing the work has to be covered.

Why application area? Because there may be multiple applications for a product and in some cases the 80/20 rule may not apply.

Why 80/20? Because it is lower cost to make 1 box than 2 and the gained margin can be shared in a lower price. This makes sense if the gain lowers the price of the bulk of the deployment, because it would likely increase the cost of the 20%.

By the way, the complexity is still there in separate boxes. The complexity is managed in a different way and by a different group of people. That is why the more applications you pile on a network the less simple it gets.

seven


metroman 12/5/2012 | 3:07:25 PM
re: Redback Beefs Up Its Router slickmitzy

I have met many many ISPs and operators of all shapes, sizes and markets around the world and I would say that you are in the minority.

While representing router vendors I have asked the question about integrated Firewll and DPI and they historically have been generally against the idea. The reasons given are that other than the small enterprise market people are not comfortable buying managed firewall services from their SP. They prefer to manage their own security.

I think that the issue is deeper and has been touched upon in these discussions.

1. If you build all of these great features with NO COMPROMIZE on quality and performance you need several sets of Network Processors or ASICs, making the device expensive.

2. If you compromise (this almost always the truth) then the marketing spin does not meet the performance - ever turned on a new feature and seen performance drop in another area?? (Netflow is a good example - somewhere between 5% and 30% packet forwarding hit on some Cisco platforms.)

3. Buying these functions in separate devices is possible and you will get a best of breed solution (with some operational headaches). Buying in one device????...Will Redback be the best in each of these areas? Probably not any time soon.

4. R&D funding is not limitless - when push comes to shove, IP/MPLS requirements will get the first cut.

5. Support people will be retrained IP/MPLS people not specialists. They cannot afford to have a new set of support people.


What you must do is step though it - you don't get something for nothing, so you either pay more or take hit. No single company is the best at everything so what do you really want?

I would think that the DPI element is probably the most uesful of the features, especially for Ericsson who might want to start using it for billing in a wireless or FMC solution for event based billing, Targeted Ads and DRM....

Metroman
Page 1 / 4   >   >>
HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE