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

RE: [EFM] OAM loop back / echo server function


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.


At 03:12 PM 9/4/01 -0500, Roy Bynum wrote:
>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:
>>This reminds me how dumb I get sometimes in that I did not jump on this 
>>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"
>>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.