Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [EFM] TDM circuit emulation




Providing "first class citizen" support for TDM over Ethernet 
is both technically sound and something I'd expect some service 
providers will demand. But TDM support over Ethernet doesn't 
require changes to the PHY, or the use of another lambda.

--ron jeffries
  rjeffries@xxxxxxxxxxxxxxxxx


Bob Barrett wrote:
> 
> Interesting.
> 
> Are there any CLECs, ELECs, CAPs etc. out there that would justify  a claim
> of 'broad market acceptance' for circuit support in the last / first mile
> over EFM?
> 
> Speak now or see a multitude of business plans evaporate into a .com style
> haze :-).
> 
> Not mine I hasten to add, but it would take a dent in the US context.
> 
> Bob
> 
> > -----Original Message-----
> > From: Charles Cook [mailto:cicook@xxxxxxxxx]
> > Sent: 12 December 2001 19:26
> > To: kmccammon@xxxxxxxxxxx
> > Cc: btolley@xxxxxxxxx; bob.barrett@xxxxxxxxxxxxxxxxxx;
> > stds-802-3-efm@xxxxxxxxxxxxxxxxxx
> > Subject: Re: [EFM] TDM circuit emulation
> >
> >
> > Qwest concurs with SBC.
> >
> > Charles
> >
> > kmccammon@xxxxxxxxxxx wrote:
> >
> > > Bruce and all,
> > > SBC does consider that next generation fiber access solutions
> > should support
> > > TDM such as T1 and voice services. If TDM services must be done on a
> > > separate wavelength and not with the PHY below 802.3 MAC, the EFM optics
> > > group should pick a wavelength plan that can support wavelength
> > evolution.
> > > -Kent
> > >
> > > Kent G. McCammon
> > > Access and Video Technologies
> > > SBC Technology Resources, Inc
> > > 4698 Willow Road
> > > Pleasanton, CA 94588
> > > 925-598-1246
> > > kmccammon@xxxxxxxxxxx
> > > This e-mail and any files transmitted with it are the property
> > of SBC, are
> > > confidential, and are intended solely for the use of the individual or
> > > entity to whom this e-mail is addressed.  If you are not one of
> > the named
> > > recipient(s) or otherwise have reason to believe that you have
> > received this
> > > message in error, please notify the sender at 925-598-1246 and
> > delete this
> > > message immediately from your computer.  Any other use, retention,
> > > dissemination, forwarding, printing, or copying of this e-mail
> > is strictly
> > > prohibited.
> > >
> > > > -----Original Message-----
> > > > From: Bruce Tolley [mailto:btolley@xxxxxxxxx]
> > > > Sent: Sunday, December 09, 2001 6:19 PM
> > > > To: bob.barrett@xxxxxxxxxxxxxxxxxx; stds-802-3-efm@xxxxxxxxxxxxxxxxxx
> > > > Subject: RE: [EFM] TDM circuit emulation
> > > >
> > > >
> > > >
> > > >
> > > > Bob:
> > > > I would welcome a presentation on this topic.
> > > >
> > > > If there is serious interest in supporting this application,
> > > > while I think
> > > > support for it is clearly outside the scope of the project,
> > > > one approach
> > > > would not be to define a PHY to support it but to leave wavelengths
> > > > available so we do not break the ability of other implementations to
> > > > support it.
> > > >
> > > > Bruce Tolley
> > > > Cisco Systems
> > > >
> > > > At 10:03 PM 12/9/2001 +0000, Bob Barrett wrote:
> > > >
> > > > >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
> > > >
> >

-- 
Occam Networks, Inc.
805-692-6225 direct
805-680-8086 mobile
507-242-2254 email fax
77 Robin Hill Road
Santa Barbara, CA 93117
http://www.occamnetworks.com