Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: MCI

  • From: Bharat Ranjan
  • Date: Fri Mar 22 04:06:24 1996

>>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


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.

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  ;-)


	 mm mm   sssss  nnnnnn   * Bharat Ranjan              *
	m  m  m s       nnnnnnn  * Network Engineer           *
	m  m  m  sssss  nn   nn  * Microsoft On-Line Services *
	m     m       s nn   nn  * (206)-936-0471             *
	m     m  sssss  nn   nn  * bharatr@microsoft.com      *
	*******************************************************
	* The opinions/ideas in this memo are not necessarily *
	* those of Microsoft Corp.                            *
	*******************************************************
>




Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.