RE: [EFM] OAM loop back / echo server function
Roy-
I'm not sure that I understand what you mean.
You seem to be making some assumptions about what constitutes "OAM
overhead" that I do not.
What I meant was that tying the transmit data stream directly to the
receive data stream at the physical level is a bad idea when you are part
of a live network. Since we don't have the concept of turning circuits up
and down that means it is a bad idea all of the time.
That has nothing to do with any "Loopback Protocol" which might reflect a
payload back at a transmitting entity inside valid Ethernet packets.
Geoff
At 03:12 PM 9/4/01 -0500, Roy Bynum wrote:
>Geoff,
>
>What about a "loop back" within the OAM overhead? That would be able to
>function regardless of the Ethernet traffic and network. It may not be
>what some people are wanting, but it is better than nothing.
>
>Thank you,
>Roy Bynum
>
>
>At 02:11 PM 8/31/01 -0700, Geoff Thompson wrote:
>
>>All-
>>
>>This reminds me how dumb I get sometimes in that I did not jump on this
>>earlier.
>>I believe that Bob is correct in his statement that looping back Ethernet
>>is a really bad idea.
>>
>>I'll say it again more explicitly:
>>
>> Raw physical loopback of Ethernet is a really bad idea.
>>
>>It breaks/screws up networks that were not designed to tolerate it.
>>
>>As I have said before, I do believe that we will need a demarcation
>>device that has the capability to host OA&M functions.
>>We have talked about "loop back" from this point in the network.
>>Let us forevermore make that "PING"
>>
>>Geoff
>>
>>At 12:02 PM 8/30/01 -0700, Denton Gentry wrote:
>>
>>>>Bob Barrett wrote:
>>>>Remote loop back of Ethernet packets / 802.3 frames is a really bad idea.
>>>>No mater how well intentioned it will go wrong sometimes and when it does
>>>>it is really bad news.
>>>>I thought we were looking at some form of simple echo server function i.e.
>>>>take a received packet, swap the SA and DA, then send it back out with a
>>>>new CRC, same payload ????
>>>
>>> There was a presentation to that effect at the last meeting, describing
>>>the merits of the LLC2 TEST frame and how having something like it be
>>>widely implemented would be a good thing. There will likely be a followup
>>>presentation in Copenhagen discussing details of the proposed mechanism.
>>> I don't think an honest to goodness remote loopback, where the RX is
>>>logically connected to the TX at the remote end, is even possible in EFM
>>>for the simple reason that the links we're looking at may be asymmetric.
>>>PONs and DSL-based copper solutions can provide more bandwidth in one
>>>direction than another.