RE: [EFM] OAM (again)
All
The 8B/10B code runs at 1.25G on the PHY, loads of room for a standard side
band there, using spare legal codes or illegal code values, but it does need
both ends to implement the same kludge (yes, I would call it that if it is
not standardised).
This would create a backward compatibility issue. Is 10Base-T physically
compatible with 10Base-5, I think not, so we would not be creating any new
precedents by doing this. The 1GE EFM PHY does not have to equal the 1GE
PHY. Different application, different interface. The backward compatibility
issue could be overcome by front ending the existing systems at the POP /
CO, re-programming their logic (if it is re-programmable), or changing the
line cards (all of which are vendor revenue opportunities). The installed
base is not vast at the moment, hopefully no more than five percent of the
market for 1GE in the access space has been addressed, if that.
So what's the problem for the system vendors with respect to side band OAM,
if the SPs are willing to accept that they will have to upgrade any existing
1GE hardware to take advantage of the EFM standard?
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 Roy Bynum
> Sent: 02 October 2001 15:25
> To: 'mattsquire@xxxxxxx'; Moshe Oron
> Cc: 'mattsquire@acm.org'; stds-802-3-efm@ieee.org
> Subject: Re: [EFM] Network timing, ATM, ADSL/VDSL and EFM
>
>
>
> Fletcher,
>
> I and my customers would prefer "smart pipes" to either "fat pipes" or
> "smart switches". One of the problems that the transmission service
> providers have created is a level of support transparentcy that
> most people
> are unaware of. On of the reasons that ATM is so complex is that trys to
> emulate the functionality that is inherent in the service provider Tx
> framing. Like 802.3, most people take it for granted that transmission
> "circuits" are "plug and play" at the physical connectivity
> level. They do
> not know that the vast majority of that plug and play functionality is
> because of the physical coding and signal standards. T1/E1 etc, have a
> coding similar to what was done for 64/66 in 10GbE. Every x
> number of bits
> "revenue traffic", an additional bit is added. Unlike 10GbE, the
> additional bits in T1/E1 coding are also used to carry
> information. Network "timing" synchronization, customer service
> labels, remote problem resolution, and a low bandwidth comm function are
> embedded in the T1/E1 "out-of-band" overhead created by those bits. This
> works so well and so transparently, that even the shared service people
> such as the ISPs are unaware of how the physical connectivity is
> maintained
> and supported.
>
> It is also inexpensive. A T!/E1 CSU today costs less that what
> a GbE SMF
> PCI card does. If it had the commodity market that 10/100Mb
> Ethernet does,
> it would probably have much the same pricing, or lower.
>
> Thank you,
> Roy Bynum
>
> At 08:53 PM 9/30/01 -0400, Fletcher E Kittredge wrote:
> >On Fri, 28 Sep 2001 15:58:14 -0700 Moshe Oron wrote:
> > > I agree to what Matt wrote about QoS mechanisms being crucial
> mostly when
> > > resources get congested. This is why the argument that ATM is
> > inefficient as
> > > it involves the cell tax is not a good one. Over-engineering the link
> > to the
> > > extent that prevents congestion and thus eliminates the need
> for QoS might
> > > involve a much higher tax.
> >
> >Correct! The key question is which is cheaper: fat pipes or smart
> >switches and CPEs? This would be a question for the market-place.
> >
> >regards,
> >fletcher
>