RE: [EFM] RE: [EFM-OAM] Performance monitoring, installation, trouble shoot ing.
Bob,
As long as you are using two separate pipe, why not make one of them a
fixed bandwidth at the physical layer? Then you would not need the
additional complexity of the TDM over whatever.
Thank you,
Roy Bynum
At 09:45 PM 1/28/2002 +0000, Bob Barrett wrote:
>Ron
>
>Like you, I am familiar with one implementation of TDM over layer two. I
>guess now I know of another one.
>
>The fine tuning is required in the back haul not the last / first mile. One
>has to keep the time critical traffic away from the internet traffic on
>pipes with statistical gain. The easiest way is two pipes, one with gain and
>one without.
>
>It's an issue of back haul network architecture rather than tuning.
>
>Best regards
>
>Bob
>
>-----Original Message-----
>From: owner-stds-802-3-efm@majordomo.ieee.org
>[mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf Of Ron
>Jeffries
>Sent: 27 January 2002 19:16
>To: carlosal@xxxxxxxxxxxxxxxxxx
>Cc: Bob Barrett; stds-802-3-efm@ieee.org
>Subject: Re: [EFM] RE: [EFM-OAM] Performance monitoring, installation,
>trouble shoot ing.
>
>
>
>Hi Carlos,
>
>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 jeffries
> Occam Networks, Inc.
>
>
>carlosal@xxxxxxxxxxxxxxxxxx wrote:
> >
> > Bob Barret said:
> > > Servicing 32 customers with time critical data e.g. T1 or POTS (leave
> > > aside video for now), requires a scalable TDM like mechanism.
> > ^^^^^^^^
> > I think you nailed the problem. Making TDM-over-packet emulation work for
>a
> > few individuals is one thing; making it your main delivery mechanism for
> > every voice line is another. Currently available TDM-over-packet solutions
> > require fine tuning and care to work well (don't look hard or it will
> > break). To make it scalable, it has to be (a) easy to provision and (b)
> > bulletproof under load. Current solutions fail to meet both criteria.
> >
> > Carlos Ribeiro
> > CTBC Telecom