x
Optical/IP Networks

Source: Cisco's HFR Tips the Scales

Networking equipment giant Cisco Systems Inc. (Nasdaq: CSCO) is building a router of colossal proportions, according to one source familiar with the product. The behemoth core routing platform supposedly links to up to 18 different chassis, weighs more than 1,300 pounds per chassis, and has a total system capacity of 11.5 Tbit/s.

Sound farfetched? It may well be. Light Reading couldn't independently verify our source's data, but those familiar with Cisco's plans -- analysts and other sources -- say the findings sound authentic based on their past meetings with carriers reviewing the product.

If true, these few details that have leaked out are significant, given that Cisco won't even publicly acknowledge that the product exists. Folks have speculated about Cisco's Huge Fast Router (HFR) for years. Most recently, some were expecting its debut at Supercomm 2003, then again at the International Telecommunication Union's ITU Telecom tradeshow in Geneva.

"We know it’s out there," says Stephen Kamman, an analyst with CIBC World Markets. "Everyone’s just waiting for Cisco to tell us what we already know."

Several analysts say the product is in trials with at least six carriers, two of which are believed to be AT&T Corp. (NYSE: T) and Sprint Corp. (NYSE: FON), and at least one major regional Bell operator.

The long-awaited router is interesting, in part, because Cisco has spent an exorbitant amount of time and money developing the beast, sources say. For example, the company has built an entirely new operating system to run the thing.

Kevin Mitchell, an analyst with Infonetics Research Inc., says that most carriers are still only testing the software. Consequently, he doesn’t expect the product to be commercially deployed for at least another 12 months.

Here are some other details one Light Reading source was able to uncover after reviewing documents that Cisco itself circulated about its product:
  • Architecture
    The HFR router can be configured in one of three architectures: single core; dual core, interconnected with 1.2 Tbit/s parallel-optical-link (Paroli cables); or multicore, with two core chassis that interconnect up to 18 chassis.
  • Software
    As mentioned, Cisco has developed an entirely new operating system for the HFR. The command line interface looks a lot like Cisco's Internetwork Operating System (IOS), the software that runs most routers today. The IOS and the new operating system likely share a lot of the same code, but they are very different architecturally. Unlike IOS, the new OS is modular and runs different software packages that enable various large feature sets, such as management, MPLS, routing protocols, multicast, and security.
  • Capacity
    In aggregate, the backplane of the system scales up to 11.5 Tbit/s. There has also been mention of supporting OC768 (40-Gbit/s) connections as part of a planning consideration for the product.
  • Processors
    Routing protocols are still handled by one or two dedicated route processors in each chassis. For scaleability, an additional distributed route processor can be installed in any line-card slot. This processor is similar to Cisco's Distributed Cisco Express Forwarding (dCEF), deployed on its lower-end routing platforms. The Express Forwarding processor provides each interface with an identical on-card copy of the FIB (forward information base) database, enabling them to autonomously perform express forwarding. The only difference with the distributed route processors on the HFR is that there is not a fixed 1:1 relationship between the line card and the forwarding table.
  • Virtual Routing
    Each slot in an HFR chassis can be assigned different virtual routers or logical routers. These logical routers can be separately rebooted, and each has its own configuration. But because each chassis is only given two route processors, virtualized scaleability is fairly limited.
  • Line-Card Flexibility
    In the line cards, the physical connection and optics have been separated from the routing functionality. As a result, the routing functionality can be mated with more than one type of physical optical connection -- so you could swap an OC12 for a Gigabit Ethernet card simply by changing the physical layer interface module.
  • Weight
    If you thought the TSR from Avici Systems Inc. (Nasdaq: AVCI; Frankfurt: BVC7) had a weight problem, get a load of the HFR (see Avici Battles Weight Problem ). One chassis is 1,350 lbs. -- about as much as a very large moose -- and gobbles 12 kilowatts of power.
Specifics about line-card densities on individual HFR chassis aren't known yet, but its scaleability recalls the Juniper Networks Inc. (Nasdaq: JNPR) T640 core chassis, which was introduced in 2002 (see Juniper Goes Terabit With the T640). At the time, Juniper outlined details of a new optical core it called the TX, which could be used to link together up to eight T640's. Cisco's scaleable router, deployed in a dual-core configuration, can supposedly link together up to 18 different chassis. Even though Juniper has introduced the concept of the TX, it hasn't formally launched the product, nor has it announced any customers that are using it.

"Considering that Juniper hasn’t released the TX core connection for the T640, it's really a matter of just comparing PowerPoint [presentations]," says Infonetics' Mitchell.

Avici is the only vendor that has a working multichassis implementation. The company announced in the second quarter of this year that AT&T had hooked two of its TSR routers together.

Cisco did not respond to requests for comment on this article. — Marguerite Reardon, Senior Editor, Light Reading

<<   <   Page 2 / 13   >   >>
jstuart_99 12/4/2012 | 11:17:47 PM
re: Source: Cisco's HFR Tips the Scales change_is_good wrote:
"csco thinks of procket like triumph the dog thinks of procket - "for me to poop on".

It's that type of thinking by cisco that allowed companies like procket to start up. Cisco has continually forced its customers to live with crappy code, line card upgrades for every new feature that comes out (anyone remember engine0,1,2,3,4 line cards?), and poor support.

If we look at history, IBM thought of Microsoft much in the same way... Look how that turned out.

routethus 12/4/2012 | 11:17:47 PM
re: Source: Cisco's HFR Tips the Scales >> csco could care less about procket. <<

of course, at one time Cisco couldn't care less about Juniper either, and let's not forget that Cisco wanted to buy Procket a few years ago.

cisco's internal hype about whether they do or do not care about someone is kind of irrelevant to the case, it is merely the usual bluster. that should not be taken as an endorsement of procket though, merely as an ambivilance towards the internal cheerleading at cisco.
change_is_good 12/4/2012 | 11:17:47 PM
re: Source: Cisco's HFR Tips the Scales >> Such an announcement has been made by CISCO to blunt Procket.

csco could care less about procket.

csco thinks of procket like triumph the dog thinks of procket - "for me to poop on".
AAL5 12/4/2012 | 11:17:44 PM
re: Source: Cisco's HFR Tips the Scales jstuart_99 said "Cisco has continually forced its customers to live with crappy code, line card upgrades for every new feature that comes out (anyone remember engine0,1,2,3,4 line cards?)"

"Interesting" argument but not exactly based on reality. E0/E1 are OC-12 based cards first released when the 12000 first was released, a customers decision to upgrade to E2 was not because it had 'features' E0 did not, the decision to upgrade was because this was a OC-48 based card, i.e. it gave increase switching capacity and density.

E4 was the first OC-192 card, an upgrade to this is also done for density/switching capacity reasons. The E3 engine which is a replacement for E2 OC-48 cards was possible because hardware technology had moved on since E2 was initially designed and it's now possible to add hardware to do more edge features at OC-48 line rate.

When designing switching hardware all core networking companies are bound by the hardware technology limits of the time i.e. clock speeds, FPGA capacity, Asic complexity, power budgets, board space budgets, memory capacity, memory access bandwidth etc.

Criticizing the ability to upgrade line cards to better/faster versions as time and hardware progress is similar to criticizing micro-processor companies for not sticking with 8-bit processors with a 1 Mhz clock.

AAL5
dwdm 12/4/2012 | 11:17:43 PM
re: Source: Cisco's HFR Tips the Scales AAL5,

Very good explanation and it does make sense for a hardware platform. However, does the market really need an HFR?
Tony Li 12/4/2012 | 11:17:43 PM
re: Source: Cisco's HFR Tips the Scales
According to the best available numbers (http://www.dtc.umn.edu/~odlyzk... the Internet is continuing to grow exponentially at 100%/year. If the market needs a terabit machine today, then it will need 2 terabits next year, four the year after that, then 8, then 16, 32, 64, etc.

Tony
jstuart_99 12/4/2012 | 11:17:42 PM
re: Source: Cisco's HFR Tips the Scales AAL5 wrote:
"Interesting argument but not exactly based on reality. E0/E1 are OC-12 based cards first released when the 12000 first was released, a customers decision to upgrade to E2 was not because it had 'features' E0 did not, the decision to upgrade was because this was a OC-48 based card, i.e. it gave increase switching capacity and density. "


Well that is one way to twist the truth - how about the real reality?

The upgrade process you described below provided cisco a continual revenue stream at the expense of the customer. You stated that "all core networking companies are bound by the hardware technology limits of the time ", but in reality it was only cisco that failed to keep up with the technologies. Cisco's first OC-192 card was in truth an OC-48 card with OC-192 optics, designed to keep customers from switching to juniper who had a line rate OC-192 card. The same goes for the original OC-48 card, which could only forward at OC-12 speeds. Your argument is the same one that cisco's salespeople use, but in reality it is just a poor excuse for inferior products.

The problem is that their "technology limits" seem to be about 2-3 years behind what others are capable of doing. As long as people continue to make excuses for why they continually produce inferior products, they will never change.

I suppose IOS is not really that bad, it's just a natural extension of the "technology limits" of cisco programmers....

Frankly, I am quite suprised people still believe cisco's crap.

andropat 12/4/2012 | 11:17:41 PM
re: Source: Cisco's HFR Tips the Scales AAL5,

Are you serious? Talk about drinking the cisco kool-aid. If you are a customer you are the reason most of the cisco sales people I know from the mid to late 90s no longer have to work.

You are correct in that new cards brought higher speeds and such. Sure a card has to change from oc48 to oc192. The key issue here is that they release enhanced cards within a h/w speed. Such as engine 4 then engine 4+. The 4+ finally caught up to filtering, qos, rate-limiting, etc., that the engine 4 did not. This can be spoken of in countless cases. I know one ISP that bought a bunch of 4+ cards to do something the 4 card could not and it still didn't work at scale. Now a few million dollars later they are stuck with 4+ cards that are providing no real additional value over the 4 cards.

Pat
edgecore 12/4/2012 | 11:17:41 PM
re: Source: Cisco's HFR Tips the Scales Tony,

HFR supports SMP, another reason for moving to the new OS...but I digress.

What is your opinion of the processing power on the control plane for the years to come. We seem to be seeing processors with multiple core (Broadcom and PMC Sierra come to mind, as does Intel's hyperthreading), we seem to be seeing more SMP architecture where we tightly souple single processors to have them work on the same set of thread with a coherent view of memeory (aka tightly coupled SMP).

Does the control plane of the future really need all this performance? Are routing protocols written in way to take advantage of concurrency/parallelism? Can they be re written to be that way?

WIll the control plane processors of the future have to be big endian chips, or does Intel have a shot on the control plane in a few years?

Lots of questions, but its cuz I care :-)

Thanks Tony,

EC

PS- Gea, UDAMAN, thanks for coming through

RouterOttawa 12/4/2012 | 11:17:40 PM
re: Source: Cisco's HFR Tips the Scales Isn't the HFR being done in Ottawa?
Isn't it based on QNX?

The execution nightmare is that this thing has so many technology rocket science elements that it is taking forever to build, and is slipping 6 months every six months. When and if it is finally announced (say Supercomm) carriers will need to test so much new stuff for at least a year. Mostly the HFR is way to keep customers busy and discourage them from buying competitive product...

Deja vu all over again? http://www.lightreading.com/bo...

Gea: all your base belong to booby. LOL.
<<   <   Page 2 / 13   >   >>
HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE