> Last year, I was involved with some vendor work that was being done to
> optimize the
> SONET payload for various protocols. In particular, the 'growth' bytes
> Z3, Z4, and/or Z5 in
> the SONET Path overhead would be used to optimize the payload size based
> on the
> protocol being used. The thought was that such an optimization would
> take place at the
> "edge" of the network, where local traffic is passed to a WAN, via
> SONET. ATM and
> Frame Realy were being focused on in particular, especially with the
> concatenated
> (OC-Nc) payload. I was told that IP has now been added to the list of
> protocols that
> SONET would optimize/support. If this work comes out as a SONET
> standard, it would
> be a great plus when using OC-3c interfaces on routers.
Why is SONET a problem? An STS-3c has 2430 byte frame of which 90
bytes are management overhead. This is a fixed efficiency of 96.3%.
Even if you increase the efficiency to 99+%, for bursty traffic like IP,
are people going to wait til they have 95% link utilization before they
increase their capacity? Of course not. Customers will be screaming
long before then. While more efficiency is always better, will anything
actually be gained by trying to squeeze an extra couple of percent out
of SONET? (Though I can easily see how this would benefit telephony :-) ).
I also don't understand how this technique would help anything in a WAN.
Even if you play games with the path overhead, the SONET regenerators
and cross connects in the carrier infrastructure are section and line
terminating equipment, respectively. They don't care what the path
overhead looks like and will still be expecting 2430 byte frames. Thus,
you would have to do some sort of "fragmentation" at the network edges.
It would also be interesting to see how they propose reconciling the
fact that their frame time is no longer strictly 125 usec.
Shikhar
