RE: [EFM] OAM (again)
Bob,
I had a conversation with Rich Taborek at the St Louis meeting. He
suggested using some of those reserved codes. Perhaps he could suggest
which ones he would recommend to use for the "sync" codes, etc.
Thank you,
Roy Bynum
At 10:26 PM 10/2/01 +0100, Bob Barrett wrote:
>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
> >