Shikhar Bajaj bajaj at
Fri Mar 22 14:29:51 UTC 1996

> The thought is not to increase the efficiency of SONET, but rather the
> efficiency
> of the edge device that fills the SONET frames. The drive to doing this
> comes from
> the emergence of "integrated SONET multiplexers" that accept native
> traffic as
> input, and output to a OC-n network. There is NO talk of changing the
> STS payload
> size or the 125us transmit time. Those parameters are fixed and
> generally cannot
> be manipulated. But, the actual payload (2340 bytes) can be completely
> filled, thus
> optimizing the *utilization* of the SONET. 
> Like I mentioned, the project was focused on ATM and Frame relay. The
> idea was to
> provide the inetgrated SONET mux with information on the input traffic
> protocol. Based
> on the input protocol's cell/frame/packet size, the mux would attempt to
> completely fill
> a STS payload. There is a large amout of wasted bandwidth in today's
> systems where
> the STS is very much underutilized. This is because today's SONET
> systems tie one
> particular input to a specific STS. Optimization occurs by filling the
> payload with cells/
> frames/packets from multiple sources that use the same protocol. In
> essence, this
> begins to treat SONET as a shared transport system rather than the
> dedicated, virtual
> point-to-point system that it is today. Of course, the source and the
> destination of the
> multiple sources would have to be the same for this to work.

Gotcha.  This seems to be the next step in the evolution of SONET transport systems,
i.e. putting the muxing functionality in the same box as the switching/routing

> You guess right. In telephony, carriers want to use every bit that can
> possibly be used.
> Brings to mind a project where a certain carrier actually sold the
> protect channels on a
> ring to a customer.... but that's another e-mail altogether  ;-)

Actually, I hear that that practice is becoming more common.  Depending upon the 
discount, I may choose unprotected transport, especially if I knew that my edge
devices failed much more often than the carrier network.  :-)


More information about the NANOG mailing list