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