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

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

Geoff -

Sounds to me like this discussion is focussing too much on the "how" and 
not enough on the "what/why". There are a variety of possible "what/why" 
here which might sensibly lead to a variety of different "how". For 
example, looking at two extreme ends of the objective space:

- If the objective is to provide a means of testing an individual physical 
link between a pair of 802.3 MACs (without any intervening bridges...etc. 
in the path), then a L2 mechanism that restricted the path of a 
Loopback/Echo/Ping to just the [MAC 
Control][MAC][RS][PHY][Medium][PHY][RS][MAC][MAC Control] might well be an 
appropriate solution, as the MAC control frames are defined not to be 
relayed by Bridges. I would go further and suggest that, whether 
implemented using MAC control frames or not, it had better use a mechanism 
that is defined not to be propagated through Bridges.

- If the objective is to provide a means of testing a path between a pair 
of 802.3 devices that traverses an intervening network of unspecified 
structure, then the L2 mechanism isn't going to cut it, and we are left 
with making use of L3 (and above) to solve the problem, which is then out 
of scope as far as this PAR is concerned.

Which of these extremes are we really talking about, or is it 
both/somewhere in between?


At 17:08 04/09/2001 -0700, Geoff Thompson wrote:
>At 06:05 PM 9/4/01 -0500, Roy Bynum wrote:
>>Would a MAC Control frame with a specific opcode  be usable as an L2 
>>ping.  This would take the frame all the way to the MAC control layer, 
>>through all of the PHY and RS.
>This function "could" be added to MAC control.
>It is not clear that there would be any special reason to do so.
>You would have to make a convincing case that there was some special 
>advantage to doing this vs. using an existing, well known protocol. 
>According to my file copy of RFC 1060 (very old version of Assigned 
>Numbers) decimal 36864 (9000 Hex) packet type is assigned to Loopback.
>It is not clear to me that restricting the path of a Loopback/Echo/Ping to 
>just the [MAC Control][MAC][RS][PHY][Medium][PHY][RS][MAC][MAC Control] 
>would be any advantage. After all, the person machine that wants to do the 
>test would have to open a communications path to the testing [MAC 
>Control/OA&M] anyway.
>>There could also be a command within the OAM functionality that would 
>>generate a special MAC Control frame that would have an opcode that would 
>>specify a test pattern in the "parameters" field of the frame.  This 
>>could potentially provide a very valuable remote trouble shooting tool 
>>for service providers.
>>Roy Bynum
>>At 03:02 PM 9/4/01 -0700, Geoff Thompson wrote:
>>>I don't think this is a stupid question.
>>>I don't think we need an IP level PING
>>>A L2 ping would do, perhaps even better, the demarc would look for PING 
>>>type and then just swap SA & DA.
>>>My expectation is that the demarcation device will need a MAC address
>>>My expectation is that the demarcation device will probably end up with 
>>>an IP address in order to support:
>>>         SNMP for OA&M
>>>         Firewall services for the subscriber
>>>(That issue is, of course, beyond our scope)
>>>At 03:47 PM 9/4/01 -0400, Fletcher E Kittredge wrote:
>>>>On Fri, 31 Aug 2001 14:11:54 -0700  "Geoff Thompson" wrote:
>>>> > 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"
>>>>         Apologies if this is a stupid question, but does PING in this
>>>>context mean the utility that sends an IP ICMP ECHO REQUEST packet and
>>>>listens for an ECHO REPLY packet?  If so, am I correct in thinking this
>>>>means the demarcation device would require an IP address?