Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [EFM] RE: [EFM-OAM] Performance monitoring, installation, trouble shoot ing.




[Ron Jeffries]
> I'm familiar with one implementation where TDM over packet
> (IP over Ethernet) works reliably. It is feasible and
> "low complexity" to deliver tightly bounded timing
> synchronization for TDM streams without the need
> for "fine tuning" using standard PHYs.

Ron, I do have some practical experience with TDM-over-packet. And it really 
works, and better than many people think. However, it's not 'plug-and-play'. 
Sometimes it works out of the box, but sometimes you have to fine tune some 
parameters. Doing it for one customer is one thing - having hundreds of 
thousands of customers connected is another one.

I believe that TDM over packet may work - at least in theory. In fact, I hope 
it'll work someday, because then we'll be able to build an all-packet based 
network (I love packets :-). But let us be real, please. What concerns me 
most is the scalability of this solution. There are so many things that can 
happen in a real network, and simple assumptions do not work.

Picture yourself a real situation: an EFM access node, with some dozens of 
customers, each one using a different piece of equipment from different 
vendors. Everyone is happily talking on the phone. Now thrown in some 
congestion. Will the system be able to handle the load gracefully? Nobody can 
answer this question now; the L2 does not give enough guarantees, and it will 
be up to the L3 implementation to support it. There are so many combinations, 
making any prediction foolish. If the L2 supports sme type of TDM emulation 
natively, at least we can have a  reasonable expectation that the base voice 
service will hold under congestion.

Conclusion: we cannot escape from the fact that the requirement for TDM style 
service is a reality. In theory, it can be made to work using TDM over 
packet. Support for it in EFM has the potential to help a lot, and may make 
things a lot easier (and more reliable) for service providers.


p.s. making a single-vendor solution work, even in the field, does not count 
for me as a real solution. It has to work in a real environment, and that 
means multi-vendor. I'm sure most vendors would love to be sole suppliers, 
but as a customer, I would like to have choice. 

p.s. nothing against the *option* to buy from a single vendor. We do it 
sometimes; even then, we like to have alternative suppliers available, just 
in case.


Carlos Ribeiro
CTBC Telecom