Re: [EFM] OAM loop back / echo server function
At 01:03 PM 9/5/01 +0900, Seto, Koichiro wrote:
[Date: 09/05/2001 From Seto]
I can think of one compelling reason for having L2 ping in MAC control
which is that service providers do not need to configure unique IP
address to each demarc box they would provide to their subscriber
customers. Better yet, a customer may be able to buy a 802.3ah EFM
modem at RadioShack and the service provider can check the connectivity
without the box being properly IP configured by the
I agree with this goal.
I agree that it should not require IP.
I don't think that means that it needs to be done in MAC Control (but I
am certainly open to discussion)
If we are talking about P2P configuration
only, each demarc point may not need a unique MAC address provided we
standardize one unique MAC control address and EtherType for L2
ping. At least, service providers do not need to know each MAC
address of each customer's demarc box. (In this case EPON needs to
be P2P emulated.)
This brings up the much uglier issue of discovery, also a topic that has
always been outside the scope of 802.3.
If there is going to be a bridge or router at the demarc then there will
have to be a discovery process that effectively logs the MAC address into
the service provider's system. The service provider won't be able to
Ping/Echo the box until it knows the MAC address.
I would assume that it would be useful to have an upstream Ping/Echo in
the demarc. This one might be advantageous to have a response that comes
from the MAC Control sub-layer of the head-end MAC. This would protect
the service provider from denial-of-service attacks from a flood of
Pings/Echos. Presumably there would be a management object/attribute in
the head end that kept track at some level of the p/echo requests (i.e.
their SA and how many)
>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
>>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
>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
>It is not clear to me that restricting the path of a
>just the [MAC Control][MAC][RS][PHY][Medium][PHY][RS][MAC][MAC
>would be any advantage. After all, the person machine that wants to
>test would have to open a communications path to the testing [MAC
>>There could also be a command within the OAM functionality that
>>generate a special MAC Control frame that would have an opcode
>>specify a test pattern in the "parameters" field of the
frame. This could
>>potentially provide a very valuable remote trouble shooting tool
>>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
>>>My expectation is that the demarcation device will probably
end up with
>>>an IP address in order to support:
>>> SNMP for
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
>>>> > As I have said before, I do believe that we will
need a demarcation
>>>> > that has the capability to host OA&M
>>>> > 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