& cplSiteName &

Make Way for Cisco's HFR

Light Reading
News Analysis
Light Reading
5/21/2004

Tuesday is the big day.

That's when analysts expect Cisco Systems Inc. (Nasdaq: CSCO) to announce the oft-delayed Heavy Fast Router* (HFR), the next-generation core router and successor to the Gigabit Switch Router (GSR) 12000 series.

It's been two years since Juniper Networks Inc. (Nasdaq: JNPR) announced its T640 next-generation router, and in the interim, Cisco has preached the 12000 series as a sufficient choice for new core networks, refusing to acknowledge rumors of HFR being developed in the background.

Meanwhile, competing core routers have emerged from companies including Avici Systems Inc. (Nasdaq: AVCI; Frankfurt: BVC7), Chiaro Networks Inc., Hyperchip Inc., and Procket Networks Inc.

Quite a few HFR details have leaked out in recent months. From what our sources say, the system is a 16-slot, full-rack chassis with 640 Gbit/s of capacity. Installations of up to 18 chassis are possible, for a maximum capacity of 11.5 Tbit/s. Cisco is expected to take the leap of running a new operating system on HFR, replacing the company's Internetwork Operating System (IOS), which, despite its success in carrier networks, is often criticized as insufficiently robust (see Source: Cisco's HFR Tips the Scales and Cisco's HFR Gets Mod).

But what else is under the hood? On the eve of the HFR's unveiling, here's what analysts and competitors are saying about the system.

It's built for speed

Sources say the HFR will be the first Cisco platform to support 40 Gbit/s per slot, and it almost certainly will support OC768c interfaces, possibly in its first release. The "c," for "concatenated" indicates one flow of 40-Gbit/s data, as opposed to, say, four OC192 feeds.

Cisco is slinging the big guns first, trotting out OC768c, quad OC192, and quad 10-Gbit/s Ethernet interfaces. Sources expect the slower interfaces, such as single 10-Gbit/s Ethernet, to come in later releases.

Physically, the HFR will be slimming down. The first release is expected to fit a 23-inch-wide rack, but sources say later versions -- including the half-sized HFR -- will fit the more common 19-inch rack (see Sources: Cisco Building 'Son of HFR').

It's a family affair

The half-sized "son of HFR" isn't the only follow-up announcement planned. Some of HFR's software features will be latecomers as well, meaning the new software will lag IOS for more than a year, according to some sources.

The family of follow-up features appear to fall into two groups, and one source pegs their arrivals at 10 and 16 months after the initial HFR launch. The 10-month group includes GMPLS, IPv6 multicast, and VLAN support. The 16-month group includes both Layer 2 and Layer 3 VPN support.

It's debatable whether a core router needs full VPN functionality, considering most of the work happens at the edge. Still, a lack of VPN support is eye-catching, with VPNs being such a hot topic in routing, and competitors count it as a strike against the HFR. "Certainly in the core, you're looking the router to transport VPN. It has to be able to recognize the MPLS protocol," says Hema Ganapathy, senior solutions marketing manager for Juniper Networks.

It's got a new look

Cisco wouldn't dare ditch the command-line interface (CLI) associated with IOS, because it's become so pervasive. But it does seem time to upgrade. Sources say the HFR is outfitted with the new Craft Web Interface (CWI), a browser-based, graphical interface, which should come in handy for managing large, complex HFR installations. For those who prefer it, CLI will still be available.

The switch fabric story

It's a complex topic, but the switch fabric is the heart of a router's design, and in this case it demonstrates the differences in philosophy between the HFR and other core-routing platforms.

The HFR's switch fabric uses what's called a Clos architecture, a classic model developed by Bell Labs researcher Charles Clos in 1953. The idea is to arrange switching elements in multiple stages -- three, in the HFR's case -- which saves on the number of links required to connect every input to every output.

The single- and dual-chassis HFRs will implement stages 1, 2, and 3 on one switch-fabric card. That means the switch card looks normal, ignoring the chips on board, and the operator wouldn't even have to know about this Clos thing. Where things get tricky is when multiple chassis are involved.

In that case, the HFRs are all connected to one or two switching hubs, a setup that sounds analogous to the TX router that's going to interconnect Juniper's T640s (see Juniper Goes Terabit With the T640). These hubs contain almost nothing but Stage 2 switch-fabric cards, sources say. The satellite HFRs are then populated with a different switch-fabric card containing the Stage 1 and 3 switching elements. Thus, all traffic goes from one HFR (Stage 1) to one of the hub routers (Stage 2), then to the destination HFR (Stage 3).

This requires some planning. "You have to invest in enough '2' cards up front because the '1' and '3' cards must connect to this component. Basically, you can't 'pay as you grow' like you can with a modular fabric," says Esmeralda Swartz, Avici vice president of marketing.

By contrast, Avici's TSR system distributes the switch fabric among all the linecards. As more cards are added, the switch fabric grows accordingly.

But wait, there's more

Plenty of questions about the HFR remain. Among the most closely watched aspects of Cisco's announcement will be the reliability features, which could determine the HFR's suitability for carrier networks. The HFR's power consumption will be scrutinized, too, as competitors say the system is more power-hungry than any other core-router chassis.

Some of the HFR's best aspects might not be in the numbers, though. At least one analyst says the system includes usability features that reflect a real concern for telecom operators' needs. "They've done a lot of things that carriers will just love," says Debra Mielke, principal with Treillage Network Strategies Inc.

We'll have more on that Tuesday.

— Craig Matsumoto, Senior Editor, Light Reading

* Yes, we know the initials stand for something else.

(32)  | 
Comment  | 
Print  | 
Related Stories
Newest First  |  Oldest First  |  Threaded View        ADD A COMMENT
Page 1 / 4   >   >>
Truelight1
Truelight1
12/5/2012 | 1:44:55 AM
re: Make Way for Cisco's HFR
Does this mean the ROUTER guys finally get the idea on how to build non-blocking switches - KISS or should I say KISC - really.


justapeon
justapeon
12/5/2012 | 1:44:55 AM
re: Make Way for Cisco's HFR
It will be interesting to see how successful Cisco will be with a Clos based design. Achieving modular design that doesn't require buying the interconnects up front will be an interesting thing to watch. I'm sure this beast will be hell to get integrated into the product configurator.
reoptic
reoptic
12/5/2012 | 1:44:52 AM
re: Make Way for Cisco's HFR
Seems like the basic routing software is still far from done, chassis still in the works for smaller and narrower model, still doesn't scale up. Rushing the product out beacause they lost market share 2 quarters in a row? Marketing hype or not, folks won't deploy an unfinished product.
null0
null0
12/5/2012 | 1:44:49 AM
re: Make Way for Cisco's HFR
Depends how many queues and how many differentiated services you want to run. Other CLOS architectures are blocking even if you run as few as two diff services!

Null
Tony Li
Tony Li
12/5/2012 | 1:44:49 AM
re: Make Way for Cisco's HFR
Software is never done. There's always another chassis in a slightly different form factor. And scalability is hard if you have a non-uniform fabric, so I'd be surprised if is scaled with the first announcement.

In short, your complaints would apply to every single router that has ever been shipped. Obviously, some of those have been installed.

Tony
andropat
andropat
12/5/2012 | 1:44:48 AM
re: Make Way for Cisco's HFR
This is interesting... so now you have 2 major clos architectures that both scale to multi-chassis (or claim will)...both support 40G per slot bandwidth.

In my opinion, Juniper will have the edege for a number of reasons. First to market so have had a lot of time to work out th e kinks... still full-featured single binary image... 19" rack... already has the half-sized router (t320).....

I think this product is going to hurt cisco longer-term. They are the best marketing company in the world so the hype will probably be incredible but all the true engineers will see the risk factor and time factor involved for deploying this beast.

Procket... this is your chance!

Pat
reoptic
reoptic
12/5/2012 | 1:44:48 AM
re: Make Way for Cisco's HFR
>>Software is never done

Right, its not done, and usually version 1.0 is kind of buggy (or 3.0 in case of Microsoft).

>>scalability is hard if you have a non-uniform fabric, so I'd be surprised if is scaled with the first announcement

Agree, probably not done either. Nasty part may be having to replace the hardware to make it work down the road.

>> your complaints would apply to every single router that has ever been shipped

This is a stretch. Certainly true when people ship things for some trials or to research institutions they are often half-finished, but half-finished products aren't in too many large production networks. When it comes to IP core routers, cycle from trial to production deployment is even longer.

We'll see how many HFRs are deployed this year. What is your guess?
dwdmguy
dwdmguy
12/5/2012 | 1:44:45 AM
re: Make Way for Cisco's HFR
Cisco knows how to design clos architectures that are non-blocking. Their 15600 is fully non-blocking today and supports 320G on a single shelf. According to cisco.com, the 600 also supports 40G per slot (4xOC-192, 16xOC-48). Granted the 600 is TDM, bu if cisco let the 600 team and the HFR team collaborate, the HFR should be in good shape if it uses a clos.
Kerry Davis
Kerry Davis
12/5/2012 | 1:44:44 AM
re: Make Way for Cisco's HFR
=======
This requires some planning. "You have to invest in enough '2' cards up front because the '1' and '3' cards must connect to this component. Basically, you can't 'pay as you grow' like you can with a modular fabric," says Esmeralda Swartz, Avici vice president of marketing.
==========

Esmeralda,

I totally agree with your comment. However, I would contend that scalability is also important. And to have a truely "Pay as you Grow" and Scalable switching fabric it can not be a centralized architecture as is the case with Clos or single stage shared memory. It must be distributed to the resolution of the I/O line card and it must be some form of mesh or matrix (which is simply a structured mesh).

Kerry Davis
Aztech Partners
www.AztechPartners.com
Kerry Davis
Kerry Davis
12/5/2012 | 1:44:44 AM
re: Make Way for Cisco's HFR
Null,

A CLOS architecture is inherently non-blocking (either strictly or rearrangably depending on how you do it) at the TDM level (if configured as Chuck designed it in 1953). Non-blocking, which is the ability to connect one point to any other point at any one time to the full capacity of the I/O. What you describe seems to refer to non-blocking at the PDU level which, from a TDM perspective, requires the ability to connect one point to every other point at the same time. Which is clearly impossible, but we can emulate such a functionality using an arbitrated TDM circuit along with network processing, traffic management and external buffers.

I believe the real issue with a clos architecture used to switch packet/cell data is the inability to change circuit pathways so that the buffers don't overflow due to the inability to construct pathways fast enough to drain them. So the Clos architecture itself is not really the problem. It is the SW or the HW supporting the architecture in combination with the diversity of the traffic that creates the difficulty. And understandably so, because this is a very difficult thing to do, especially as you scale very large like the HFR.

However, I must take this moment to shamelessly plug an alternative that I personally have a stake in. And that is the HyperTorus Mesh that was developed at Brightlink. The HTMESH architecture enjoys a one to one relationship with the Packet/Cell or TDM PHY. Therefore, the centralized switching hub referred to in this article is not necessary at all. Like Clos, it too is nonblocking at the TDM circuit level. And it is far easier (as in much faster) to make and break unidirectional or bidirectional connections from one point to another across the fabric. That speed allows for the draining of the packet/cell data buffers before they overflow. This is largely due to a much simpler provisioning method for the HTMESH than a multistage Clos (most of the work is done in real time in the HW). Anyone who has programmed a multistage stage Clos and/or had to write rearrangement algorithms for the beast can testify to the complexities, especially as the fabric approaches maximum capacity.

Of course one could always simply increase the size of the buffers at the expense of propogation delay or add buffers to the central stages of the switching fabric as is depicted in the lightreading article on buffered and shared memory switching fabrics. So Cisco has many options to make it work. But I would agree that just making it work is not good enough. You wouldn't take a semi truck to the Daytona 500 but it would make it around the track.

Kerry Davis
Aztech Partners
www.AztechPartners.com
http://www.lightreading.com/do...

--------
Depends how many queues and how many differentiated services you want to run. Other CLOS architectures are blocking even if you run as few as two diff services!

Null
-------
Page 1 / 4   >   >>
Featured Video
Upcoming Live Events
March 16-18, 2020, Embassy Suites, Denver, Colorado
May 18-20, 2020, Irving Convention Center, Dallas, TX
All Upcoming Live Events