Yes, Lightreading has proved to be informative. But despite how tempting it is to burst balloons, sometimes you need to refrain for a while.
"I'm really beginning to like Lightreading, they seem to have some good balloon prickers on staff."
The article was interesting because it begins to suggest the breadth of services that competitive carriers will look to support over GbE in the near future.
At 1 Gb, we may soon need to look now to 10 Gb, in order to overcome the "shortcomings" of 1 Gb. That should solve the delay issues for a while, no? When does it end? Of course, the answer to that is that it doesn't.
Extreme's use of 64 byte frame sizes for all ports reduces their flavor of Ethernet to the mode of ATM which uses 53 byte cells, IMO. Instead of supporting variable frame sizes, or larger frame sizes like Alteon's jumbo frames in order to support server farm and fibre channel applications at some point, their approach (Extreme's) seeks to "reduce" the potential frame size for "all" port flows and flywheel them as though they were in a TDM engine, if I'm reading it correctly.
I don't know about how wise this is, unless they stipulate the types of applications that would be supported on the specific network in question. Namely, that they would support only normal LAN-like applications and isochronous applications, such as voice and video. But not those types of applications that require larger frame sizes such as mainframe bulk data transfers, or very large SNA flows which are delay sensitive, or media converted fibre channel streams.
======
The authors note that the ILECs would not be inclined to adopt this model (or any GbE model, for that matter) at this time, and that greenfield carriers such as Yipes would be more inclined to do so. Apples and oranges, I think, if we're talking about voice -- which was mentioned early in the article.
Metro GbE is more likely to be adopted in the early stages by enterprises who contract their local dark fiber companies to dwdm-ize their virtual campuses, while supporting multiple traffic types over different wavelengths (lambdas).
Over one lambda, GbE will support flattened internetworking backbones, like collapsed building LAN backbones, only here it would be city wide or region wide. Another lambda will support IBM Escon or Fibre Channel, while yet another lambda will support channelized, or SONETized flows, including legacy voice and video services.
But I don't see any breed of carrier at this time that would be prepared to support PSTN voice over Ethernet as a standard POTS like, tariffed offering, complete with automated accounting and other OSS functions, such as 911, CLID, CLASS * features, etc.
Again, this "is" possible for enterprises where their own "on-net" provisions are concerned, especially if they are diving into VoIP between locations; but it's still a ways off for carriers of any type to be offering POTS over Ethernet at this time, IMO.
One problem that the authors don't speak about is one which is not uncommon with cutting edge technologies. And that is, the lag between getting the primary product out of the door (in this case GbE), and that of implementing standards and test equipment to monitor and measure them. Huge problem throughout the industry.
Any GbE architecture that would be put in place to support a Metro network at this time would lack the requisite test and measurement equipment needed to support carrier class operations. It has neither been standardized nor fully developed yet, and how could it? Metro Gigabit Ethernet calls for satisfying a set of parameters which are in some ways completely different than those which are found within the normal TIA/EIA framework of 100 meters for twisted pair, and 300 meters for multimode fiber, 2 km for singlemode possibly <?> [has that been finalized yet?], etc.
Actually, there are a number of different distance specifications for GbE for various grades of physical media, but they do not include MAN- and WAN-like reaches yet, that I am aware of.
As if to highlight the need for GbE-specific gear for test, measurement and monitoring, today I came across a question on NANOG that addresses this very point, as shown below:
-------
First ISPer:
Does anybody know a product to do Gigabit Ethernet traffic monitoring, like CoralReef does for OC3/OC12 [SONET]?
{singed}
----
Second ISPer:
am not aware of anyone currently shipping such a monitor, (i'd pay good money to be wrong tho) although several companies are planning to add gig-e to their existing monitoring products. caida does have funding from darpa to develop a gigabit ethernet monitor, & we will make that system work w coralreef, but unfortunately i can't nail down a ship date at this time
hopefully someone will point out a product i missed and i'll add it to the taxonomy
{signed} |
