RE: [EFM] RE: [EFM-OAM] Performance monitoring, installation, trouble shoot ing.
Please start using the tdmoverefm@xxxxxxxxxxxxxxxx 'reflector' for emails on
this subject. (I'll test that email address with a cc of this message.)
TDM doesn't gel with statistical gain in current all packet networks; other
than that TDM over packets works very well. I don't think we will get away
from separate networks in the metro until the MEF, the ietf and the vendors
produce interoperable GMPLS systems that work. Meantime it is packet over
Sonet and TDM aggregation over Sonet in the metro, and separation of TDM
circuits at the POP site. This architecture (packet and TDM in the loop over
Ethernet) is transitional, and it works because the environment is
[mailto:email@example.com]On Behalf Of Carlos
Sent: 28 January 2002 03:23
To: Ron Jeffries; carlosal@xxxxxxxxxxxxxxxxxx
Cc: Bob Barrett; firstname.lastname@example.org
Subject: Re: [EFM] RE: [EFM-OAM] Performance monitoring, installation,
trouble shoot ing.
> 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
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
answer this question now; the L2 does not give enough guarantees, and it
be up to the L3 implementation to support it. There are so many
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
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