& cplSiteName &
Comments
Newest First  |  Oldest First  |  Threaded View        ADD A COMMENT
<<   <   Page 3 / 4   >   >>
Kerry Davis
Kerry Davis
12/5/2012 | 1:44:26 AM
re: Make Way for Cisco's HFR
--------------
Meshes don't scale. And the cost and complexity
of a mesh (or a matrix) switching system gets
worse as the size of the system increases.
People who build them always talk about n-way
connections and then after probing "n" turns out
to be some tiny number forced by the complexity
involved in going beyond "n".
---------------

Meshes don't scale? Are you familiar with all possible hardware implementations of a mesh network? That sounds pretty absolute. I'd love to see that proof.

The Hypertorus Mesh designed at Brightlink does scale. Originally it scaled in 40G increments but with advances in interconnection optics it can scale in 2.5 G increments. It can scale from 1 to 5 dimensions. Each dimension providing 4 times the bidirectional switching bandwidth of the previous and each dimension requires exactly 3 fabric links. And yes, interconnecting shelves is more complex than a simple linear connection. However, complex connections can be made simple to implement. Unless if you consider a ring complex, because the logical mesh is overlayed over a physical ring and the connections from one shelf to the next can be very straight forward if implemented correctly. But I certainly agree that it can also be made very complex. That just isn't the case here. I disagree with your assumption that it has to be any harder than connecting east and west numbered or color coded fiber links between shelves.

As for cost, If I can remove the cost of an entire redundant switching rack by going directly from one I/O shelf to another and the complexity of having to program all those chips to make a single cross connect then I fail to see where there is additional cost and complexity.
Tony Li
Tony Li
12/5/2012 | 1:44:23 AM
re: Make Way for Cisco's HFR

Kerry,

Well, the constraint with the mesh model is that you lack the speedup in the fabric to provide topology independence. So a more 'difficult' fabric is giving you a certain benefit that some customers will value.

Tony
myoptic
myoptic
12/5/2012 | 1:44:22 AM
re: Make Way for Cisco's HFR
OK enough BS on the CLOS switch fabric already - no-one is going to use it anyway. How about answering the most important questions: which GSR linecards will be reuseable in the HFR?

Kerry Davis
Kerry Davis
12/5/2012 | 1:44:20 AM
re: Make Way for Cisco's HFR
Tony,

Not sure I followed that last statement. But our mesh physical topology, like a Clos physical topology, can be used to transport TDM data at wire speed or packet/cell data via a common crossconnect. Our ASIC is unique in that it is a combination of a packet switch and TDM switch. It packetizes the I/O stream and uses a speedup and buffering at each Mesh hop to transport to the egress node where it is reassembled in the order recieved at the ingress and sent out at wire speed. The HW does all the work to get it there with our recently patented routing algorithms. These algorithms not only work across a Hypertorus Mesh but also other physical matrix configurations. In fact, the first two dimensions (40G) can be configured as a full mesh.

Kerry
coreghost
coreghost
12/5/2012 | 1:44:15 AM
re: Make Way for Cisco's HFR
Meshes don't scale? Are you familiar with all possible hardware implementations of a mesh network? That sounds pretty absolute. I'd love to see that proof.


Ok. I'll narrow my comment to be that I've looked
at several people who have proposed routers
(not cross-connects) built around meshs.
None of the proposed hardware implementations
seemed to deliver the benefits suggested and
involved a complexity increase as the system
size increased.

Now maybe there are cross-connects were meshes
are fine or maybe there are mesh architectures
I dont know about or have not considered. but
every proposal or attempt I've seen to build
a router around a mesh has not been acceptable.
arch_1
arch_1
12/5/2012 | 1:44:13 AM
re: Make Way for Cisco's HFR
I don't know about the HFR, but I've seen several multi-stage packet fabrics mis-described in terms of topologically-related circuit fabrics.

For example, one vendor described thier multi-stage fabric as a "Benes," and in fact if you drew the nodes and links, the drawing was toplogically isomorphic to a TDM Benes network.

However, the fabric was not a Benes, because a Benes is a re-arrangably non-blocking circuit switch, while the fabric in question is a multi-stage packet-forwarding fabric.

As a wild guess, the HFR fabric is not a CLOS, for the same reason.

In all such cases, the characteristics of the TDM network to which the packet network is isomorphic are (almost) completely irrelevant to the characteristics of the packet fabric. You must analyze the packet fabric from scratch.

If you are using a scheduled circuit fabric instead of a multi-stage packet fabric, you can analyze circuit fabric by traditional techniques, but it won't help much, becaues now you must analyze and build a scalable scheduling element. The blocking characteristics of the system as a whole will depend on the scheduler, not on the underlying circuit fabric. Good luck.

Incidentally the "Benes" packet fabric did in fact provide very good scalability and QoS characteristics, but it wasn't a Benes.

turing
turing
12/5/2012 | 1:44:12 AM
re: Make Way for Cisco's HFR
>Maybe not deploy, but they will buy. Sprint
>will buy whatever cisco tells them to. Same
>with SBC. They will go to trade shows and
>tell everyone how wonderful the HFR is and how
>happy they are with it even if never makes it
>into the real network.

That is so true it's scary. In fact, your whole message is incredibly dead on. Cisco doesn't need to make it a working product with working features - they just need to have the story. They have always understood that about selling, vs. their competitors who spent time on engineering. Engineers don't buy products, the guys who play golf do.
Kerry Davis
Kerry Davis
12/5/2012 | 1:44:11 AM
re: Make Way for Cisco's HFR
------------------
Ok. I'll narrow my comment to be that I've looked
at several people who have proposed routers
(not cross-connects) built around meshs.
None of the proposed hardware implementations
seemed to deliver the benefits suggested and
involved a complexity increase as the system
size increased.

Now maybe there are cross-connects were meshes
are fine or maybe there are mesh architectures
I dont know about or have not considered. but
every proposal or attempt I've seen to build
a router around a mesh has not been acceptable
-----------------------

Coreghost,

I think what you say here is a fair assessment. I don't know of any working mesh based crossconnects other than the Boss1000 by Brightlink. And I too have not seen a mesh based router that works well. But I don't think that the problem is because the physical interconnect is a mesh. I think the problem has to do with how traffic is transported across the Mesh. And the problem in my opinion applies to packet transport across Clos as well.

The typical mesh and Clos based multiservice (packet and circuit) fabrics have timing and QOS issues because, I believe, they try to do too much on the packet side and they try to emulate a circuit with an asynchronous packet stream (I have personal experience with two companies who have tried and failed). I believe if the Network Processors and the Traffic Management does its job properly at the ingress and egress I/O cards then our arbitrated circuit based mesh fabric that scales one to one right with the I/O card (could even be integrated with the TM chip)is a simple solution that is cost effective, scalable, and simpler than exists to date. The trick is in the ability to make and break crossconnect circuits fast enough to efficiently drain the packet buffers. And I think we have the solution to do just that and I have not seen anything similar out there.

Kerry
xbar
xbar
12/5/2012 | 1:44:08 AM
re: Make Way for Cisco's HFR
Myoptic,

Can you explain why is this an issue?

xbar
andreasb
andreasb
12/5/2012 | 1:44:04 AM
re: Make Way for Cisco's HFR
I apologize for interrupting the dialogue - but this seems to be relevant (given the interest in scalable fabrics).

A merchant silicon vendor (Dune) is currently shipping a switching fabric with integrated traffic management scaling from 20Gbps to 40Tbps (non-blocking) based on CLOS interconnect.

-The fabric and the TM devices interconnect via CLOS interconnect, however, as mentioned in previous messages, the routing strategy on top of the interconnect is the important aspect of the architecture.

-Up to 64 TM devices may be connected in a single stage configuration. 65-2048 TM devices may be connected in a 3-stage configuration. When using a 20Gbps TM device this translates into 1.28Tbps (single stage) or 40Tbps (3-stage).

-This means that 32 half-rack IO chassis of 640Gbps each (and maybe 1.2Tbps within a year or two) can be connected via several fabric chassis.

-This is not just a bit blaster solution, as it supports hundreds of thousands of flows with guaranteed rates/weight on top of it.

-Obviously, all of the above configurations are non-blocking.


Finally, ...this technology is available for anyone to use...


Andreas (DuneGÇÖs employee)

PS: Most people use it to build 20-640/1.28 product lines but it is nice to know you can scale...
<<   <   Page 3 / 4   >   >>


Featured Video
Upcoming Live Events
October 22, 2019, Los Angeles, CA
November 5, 2019, London, England
November 7, 2019, London, UK
November 14, 2019, Maritim Hotel, Berlin
December 3-5, 2019, Vienna, Austria
December 3, 2019, New York, New York
March 16-18, 2020, Embassy Suites, Denver, Colorado
May 18-20, 2020, Irving Convention Center, Dallas, TX
All Upcoming Live Events