|Thread Links||Date Links|
|Thread Prev||Thread Next||Thread Index||Date Prev||Date Next||Date Index|
I am sure that you are right that many people would agree that having both LAN and WAN PHY was a mistake. But I’ll bet that you’d get a pretty high percentage of them saying that WAN PHY, not LAN PHY, is the one that was the mistake J. In any case, we have LAN PHY and many service consumers have expressed the desire to transport it over transport networks. A number of service providers have responded by expressing the desire to buy equipment to provide such services with. A number of equipment vendors (perhaps most at this point) have in turn responded with equipment to do just that. And down the line to the component vendors who built the chips to enable the equipment vendors to enable the service providers to offer LAN PHY transport services. The market has spoken and there are now many transport networks in the world that can carry LAN PHY just as transparently as WAN PHY without doing unnatural acts to squeeze it into an STM-64/OC-192 payload. Unfortunately, because the ITU (and OIF) refused to listen to a number of their constituents (including carriers, equipment vendors and component vendors), we now have the situation where a lot of incompatible equipment is shipping that does almost the exact same thing but not quite the same thing. No disrespect is intended towards you or anyone else, but in my personal opinion the ITU has made a huge mistake on this one. I’m still waiting for the right opportunity to work with others to fix it and I’m hoping the IEEE is the place to do it.
Despite the above discourse, I know of a number of our customers who prefer WAN PHY to LAN PHY because despite the IEEE’s best attempt, LAN PHY doesn’t have the OAM features (dang, where did AIS go?) that carriers need to offer an economical service. WAN PHY inherited them from SONET/SDH so they use that instead.
Regarding your statement on differential delay (latency, skew, whatever), I honestly think this is another place that ITU hasn’t done it’s homework to converge what’s possible with what’s practical. (BTW, your discourse on the 125 microseconds requirement for VC is hard to read, I think you mis-phrased it a bit). While I think it is great that VC can support skews as high as 125 microseconds, I think it was a huge mistake to require conformant implementations to support a minimum of that much. Even at 10 Gb/s this requires more than a Mbit of memory and at 100 Gb/s would require more than a MByte. I believe most VC chips have had to go with off-chip buffer memory which drives up cost and complexity fairly substantially. On the other hand, most carriers I’ve spoken with always make sure to route all member circuits along the same path for availability reasons and therefore no one ever sees skews this high in reality. This was a bad tradeoff. The spec could have kept the capability for large skews while requiring conformant implementations to have much smaller amounts. Different hardware could have been built for the few applications that really needed skews this high. What am I missing?
Chief Technology Officer
1322 Bordeaux Drive
Sunnyvale, CA 94089
WWW : http://www.infinera.com
Stephen J (Steve) [mailto:sjtrowbridge@xxxxxxxxxx]
I think you are touching on some important points here where we need to be VERY careful.
I think that many will agree that a key mistake of 10G was to develop a LAN PHY and a WAN PHY that operated at a different payload bitrate. The WAN PHY was important because, as has been discussed, 10G was where we really got into having Ethernet as an Infrastructure interface, so it needed to work seamlessly into transport networks. But we should have selected a bitrate that works into all transport hierarchies.
As far as compatibility with transport technologies, a few thoughts:
- If we are considering multiple lane approaches and have the idea to carry the lanes individually across a transport network, it is essential to consider the technologies used in those transport networks. For example, if we are considering lanes on the order of 10G in size, we should surely select an exact rate that fits into an STM-64/OC-192 or G.709 OPU2 payload. If we also want to carry such a lane over a 10G LAN PHY, we should limit the data rate used over that iterface so that it still fits into the transport network.
- Regarding differential delay or skew, it depends on the underlying transport technology and the network span before reaggregating. With SONET/SDH, you are dealing with a basic frame rate of 125 microseconds, so virtual concatenation in this environment needs to consider several frames worth of differential delay. With G.709, however, the framing is essentially to give you OAM, a multiplex structure, and FEC rather than being tied to the payload rate. At 10G, the G.709 frame is just over 12 microseconds, and at 40G it is just over 3 microseconds. So the differential delay required to be compensated for virtual concatenation in G.709 is only 125 microseconds.
You mention the over-clocking of G.709 to carry LAN PHY. While this appears in some networks for point to point, it is not according to the standard, does not work with all equipment or components, and is not networkable (for example, you can't multiplex these over-clocked signals into a standard G.709 OTU3 (40G) signal). There has been a lot of angst in standards discussions about how to limit the proliferation of these kinds of solutions and get back to a coherent network architecture Since we are starting out in HSSG with a "clean slate" to define a new interface and have the freedom to select:
- Rates that match for the networks we want to interwork with
- Payloads that fit into the containers we want to carry them
I think we should NOT look to some of these special case implementations for how to build a new interface, but to the standards for the technologies where interworking or transport is important.
Finally, when (not if) we get to looking at 100G serial, I think we should remember the pain of 10G LAN PHY/WAN PHY and avoid repeating that experience. The ideal situation is if we could agree on a data rate, frame format, etc. that meets everybody's needs (not to mention generating extra volume with common technology to bring costs down). I think that it would be a good idea to work with the ITU-T to see if we could define a common, sensible evolution that works for data and transport environments (of course the lines between these are becoming increasingly blurred). It certainly wouldn't hurt to be working with the G.709 guys in ITU-T Q.11/15, and the optical physical interface guys in ITU-T Q.6/15.
You may recall that Glenn Parsons had
described the fact that IEEE is now a sector member of ITU-T, and that plans
were underway to hold a joint workshop in Late May in