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.


That's exactly what I was proposing in the unseen proposal, but it needed a
PHY change.

I thought the OAM transport would need a PHY change anyway, so if the PHY
was being changed for one we could change it for the other. Additional gate
count (cost) is minimal compared to TDM over packets, benefit is enormous.

Best regards


-----Original Message-----
From: Roy Bynum [mailto:rabynum@xxxxxxxxxxxxxx]
Sent: 28 January 2002 22:07
To: Bob Barrett; Ron Jeffries; carlosal@xxxxxxxxxxxxxxxxxx
Subject: RE: [EFM] RE: [EFM-OAM] Performance monitoring, installation,
trouble shoot ing.


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:

>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
>one without.
>It's an issue of back haul network architecture rather than tuning.
>Best regards
>-----Original Message-----
>[]On Behalf Of Ron
>Sent: 27 January 2002 19:16
>To: carlosal@xxxxxxxxxxxxxxxxxx
>Cc: Bob Barrett;
>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
> > few individuals is one thing; making it your main delivery mechanism for
> > every voice line is another. Currently available TDM-over-packet
> > 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