Re: [EFM] Re: [EFM-Copper] Long Reach Copper Presentations in Vancouver
John,
You have hit upon a real dilemma here. Is "Ethernet" a "service" from a
marketing aspect or is "Ethernet" the Physical/Data Link layer technology
from a standards aspect? Which aspect of "Ethernet" should EFM concentrate on?
As the author of the marketing/service model of, and the term "Ethernet
Private Line", I can tell you that the only thing "Ethernet" about the
service is that Ethernet frames are maintained intact (even the FCS is
supposed to be maintained). Otherwise, this service used the existing
technology of the TDM transmission systems by replacing the IFG/IPG with
another "mapping" protocol.
I also authored the term and service model for "Ethernet Frame
Relay". "Ethernet Frame Relay" is however defined for implemenation over a
"switched packet/frame" service infrastructure. Again the only thing
"Ethernet" about this is that the original "Ethernet" frames are supposed
to be maintained. (Some would use an IETF draft that would substitute the
original Ethernet FCS with a different FCS and then recalculate it again at
the far end.)
Other than maintaining the "frame" integrity, none of these are based on
the IEEE standards. None of these have the same inherent characteristics
of data stability. The best case is of an Ethernet Private Line service
facility that uses LAPS, which has a minimum of 125us latency
variance. All of the others are potentially much worse. Some
implementations have no where near the data reliability as the IEEE standards.
These are uses and applications of the term "Ethernet" to create a
"marketing" label for a "service" that uses facilities built around
non-"Ethernet" technologies that just happen to carry "Ethernet"
frames. This goes to show that just because something is labeled
"Ethernet" does not necessarily make it 802.3 Ethernet.
Into this chasm goes EFM, MEF, and other groups. Other organizations have
already defined "mapping" technologies that allow service providers to
"map" Ethernet frames (I use this concept loosely here.) into existing
infrastructure technologies. Some of these are very low cost and compare
very favorably with what is being drafted by 802.3ah.
Being a technologist that has worked in the service provider and service
marketing areas I would not recommend that EFM gets too deep into this.
Thank you,
Roy Bynum
At 05:52 PM 12/19/2002 -0700, John Farnbach wrote:
>Steve, and all,
>
>Steve makes some good points below. It seems to me that the most
>compelling point is that the Ethernet standards have always specified the
>physical layer. 22 years ago when Ethernet was first being developed, it
>was necessary to specify it all the way down to the physical
>layer. Otherwise, how could you connect one ethernet port to another?
>
>Only consider this: What if we think about Ethernet as a service, rather
>than a physical network? Service providers today are very good at
>physical layer connectivity, they do it all the time over a variety of
>links, including HDSL, ADSL, and SHDSL. There would be less, not more,
>confusion by defining EFM above the byte pipe layer. Steve asks, which
>version of EoCu would a carrier install... They would install the byte
>pipe of their choice and layer Ethernet on top of that. Only one version
>of Metro Ethernet, not many. There is not any confusion in saying that
>EFM operates over any byte pipe--They already know how to make byte pipes
>work.
>
>And what about the carriers who have a kind of byte pipe installed tht may
>not be the one chosen for EFM? It would be much easier for them to
>provide Ethernet service over any byte pipe than to have to change out all
>their physical links to the one that might be chosen.
>
>Just seems to me that there is a simpler way to cut through the knot.
>
>John
>
>Steve Jackson wrote:
>> Threaded response:
>>-----Original Message-----
>>From: John Farnbach
>>[<mailto:john.farnbach@xxxxxxxxx>mailto:john.farnbach@xxxxxxxxx]
>>Sent: Thursday, December 19, 2002 2:37 PM
>>To: Steve Jackson
>>Subject: Re: [EFM-Copper] Long Reach Copper Presentations in Vancouver
>>
>>Steve, thanks for the info. You're welcome.I may be wrong, but it seems
>>to me that it is technically and logically possible to define the MAC and
>>the 'gamma" interface for an EoDSL layer and leave the lower layers open.
>>It is technically and logically possible, of course.Seems like that would
>>be very effective and would guarantee interoperability, provided that the
>>two ends of a link interoperated at the PMD layer. Um, no. Doing so
>>would create massive market confusion. Tell me, how many versions of
>>EoCu would show up on the market? Six? Eleven? Which one does
>>BellSouth use? Verizon? France Telecom?See what I mean?Are you saying
>>that the original PAR requires that 802.3ah must define the physical
>>layers as well?
>>
>>Yes. The 5 requirements include "broad market acceptance" and "technical
>>feasibility" among other definitive statements.
>>
>>That seems counter-effective.
>>
>>Hmmm. 100BASE-T specifies a PHY (actually, several) for example. Most
>>implementations have an embedded MII. Are you saying that we should have
>>just said "oh, use whatever you like, the MII is spec'd out" and let
>>vendors ensure PMD interoperability?
>>
>>No, you couldn't mean that. ;-) What did you mean?
>>
>>As demonstrated by the ADSL/SHDSL debate, over defining the standard just
>>gives more room for debate. Is it possible to go back and modify the PAR?
>>
>>The ADSL / SHDSL debate is caused by the semiconductor vendors who have
>>megabucks invested in DMT and QAM development. It's not a real argument
>>in and of itself. If SHDSL is approved, it's seen as a huge advantage to
>>the VDSL SCM vendors, and vice-versa.
>>Realistically, we're too far down the road to even re-write the
>>objectives, much less rewrite a PAR and start over. More likely, we'd
>>just drop the whole standards effort first.
>>
>>/steve
>--
>John Farnbach, Managing Partner
>Farnbach Associates
><john.farnbach@xxxxxxxxx>
>tel/fax: 303-448-9852
>4022 Old Westbury Court, Suite 202, Boulder CO 80301
>