Carrier Ethernet

Quite simply that bridges and the spanning tree protocol won't work on really large networks. For example, most bridges (switches) can only learn a few tens of thousands of MAC addresses - and if there are more devices than the bridges can learn, frames get broadcast to all attached LANs. Further the way that addresses are propagated around the network, and how the network organizes itself, also fairs poorly in large networks.

Routing, OTOH, is much more hierarchical, and network interconnections are managed much more explicitly, so it scales far better. Basically the Internet is all routed (as opposed to bridged), with the obvious exception of relatively local and small bridged networks (usually smaller than a few thousand nodes).

Anyone remember back in the 80's when the telecoms thought that they could build nationwide networks as a single (or maybe a few large) ATM cloud?

From reading that article, it seems that Carrier Ethernet is just some extensions to ethernet, not a fundamental change to how any of it works. However, Light Peak and Firewire being described as competitors to ethernet in the context of carrier networks seems somewhat suspect to me, and throws the editing of the entire article into doubt in my opinion.

Sure, although I've always thought that the telecoms get a bit too much grief for not realizing that packet switching was the wave of the future.

In the early eighties, the (effectively) virtual circuit switched phone network was orders of magnitude larger than the Internet. Even IBM's *internal* SNA network (also effectively VC) was bigger than the entire Internet until about 1985/86. Also, in that era, well before the WWW, connections/sessions tended to have absurdly (by current standards) long lifetimes, even on the Interne,. Think TELNET and FTP type sessions dominating traffic. And on the local side, connections between things like workstations and servers could also easily be considered very long term. Even some of the interactive precursors to the WWW, like NAPLPS/videotex/teletext, were oriented around long term connections. In such an environment, a (virtual) circuit switched approach, with the associated high circuit setup costs, is at least reasonable.

Even today, large parts of the Internet run over telco provided circuits, many of which are actually running ATM under the hood (SONET/SDH links, and most DSL lines), although that is declining, particularly at the higher end.

But having vast numbers of very short-lived connections makes the circuit switched approach much less attractive. Although there are ongoing and repeated efforts to bring some of the advantages of circuit switching back to IP routing (IP Flows, for example).

And there's a bit of a terminology problem. A "switch" was the traditional name of the device handling circuit switched connections, and was really nothing like what we'd have called a "bridge" on packet/frame oriented LANs. And as I mentioned some of the switching systems had demonstrated far greater scalability than any packet switching network at the time. The adoption of the term "switch" for marketing Ethernet bridges just adds to the confusion.

Hi, Mark

Bridges are indeed used in network providers.

Spanning tree is generally not used. If the provider is adding a bridge, STP would disrupt its network too long time, to converge.

In Ethernet WAN, we consider connectionless paths (CL) and oriented connection paths (CO). With CO paths, address learning process is useless.

Best regards, Michelot

Bridging has some tables and overheads that grow faster than linear with the number of connections and devices across the entire set of indirectly connected switches.

Every end point connected to a bridged system has at least 1 MAC address, and any traffic to that device implies that MAC has entries in some or all the devices that make up the network.

This means linear scaled up table space is needed, but the maintenance overheads that occur grow more quickly as well.

The other practical problem is that a network needs to be stable to operate well, and in practice that means that you need ways to limit changes to parts of the system so their effect stay local.

in bridging a topology change can propagate across the system.

Think of the hierarchy in routing as being selective information hiding.

Instead of 1 entry per MAC address for 100,000 devices in table for a big corporate network, you may need just 1 or a few routing entries saying "xxx corp is that way".

This means any topology change in xxx corp stays within their system - the rest of the system doesnt need to see it

Hi Stephen,

In the user plane, a bridge is not a MAC end point.

Best regards, Michelot

Wording quibble. Given the loaded nature of the word "broadcast" it might be better to put that as "frames get transmitted out all connected ports" or "frames get flooded out all connected ports" lest some new folks think the frames get transformed into actaul broadcast frames.

rick jones

The meaning of "scale" is in the sense of how one quantity must change when you change another.

One can, for example, discuss the change in the size of the legs of an animal with its weight. That is:

"How does an animal's leg scale with its weight?"

In many interesting and useful cases, the answer is an exponent.

How does a tree trunk diameter scale with tree height?

How does the speed of a transistor scale with its size?

How does the cost of a transistor scale with it speed or size?

Doesn't scale means that something else happens, such that the scaling laws aren't useful anymore.

Transistors (and animals) don't scale well down to atomic size. They also don't scale well up to planetary size.

-- glen