RE: [EFM] TDM circuit emulation
Jangrai
I am interested in TDM over EFM and over IP, however, so far EFM has ruled
TDM as out of scope or implementation specific.
It is one thing to run TDM in packets, it is actually easier to run TDM in
side bands, but that would mean changing the PHY. I was going to do a
presentation on this in Portland but I pulled it because there appeared to
be zero chance of changing the PHY at that point. If the group adopts OAM
other than in frames the PHY will need to be changed, and at that time
Pandora's Box will be open, so to speak, and I will come back in with my
presentations. May as well be hung for a sheep as a lamb. I.E. if we are
changing the PHY for OAM we may as well change it to add side band TDM.
In all packet networks circuit emulation as frames or IP is needed in the
metro / back-haul. Side band TDM won't cut it.
In traditional networks circuits can be done as they are today, or at worst
they need to be carried in the last mile / first mile along side the packet
traffic, to where the SONET / SDH metro handles them in the back-haul.
I have technology for both that I would be willing to contribute to EFM if
the group were to feel that that was a desirable enhancement to the EFM
specification.
There is certainly new silicon for EPON, probably for outside plant 1GE, and
probably for 10Base4 copper. However, I see the applicability being EPON and
1GE only, unless there is a benefit in changing the T1/E1 from its current
copper coding to something else to reduce cross-talk on the copper PHY.
Hugh / Howard - any comment on this from the copper track please?
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 ???
> Sent: 09 December 2001 15:39
> To: stds-802-3-efm@xxxxxxxxxxxxxxxxxx
> Subject: [EFM] TDM circuit emulation
>
>
>
> Hello,
>
> What do you think of T1/E1 and T3/E3 circuit emulation over EFM?
> Some vendors have announced TDM integration over IP.
> It might be some problematic in cost/performance due to cost of
> delay/jitter compensation. And how about supporting resiliency?
>
> Jangrai Roh