[EFM] TEST frames MAC_Control vs MAC client
>>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.
> --On Sept 04, 2001 Geoff Thompson <gthompso@xxxxxxxxxxxxxxxxxx> wrote:
> 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.
(I hope I've attributed the quotes correctly, the messages are flying fast
and furious)
I believe there is a reason to implement it in the MAC Control layer,
because the test frame will most likely be sent to a multicast destination
address. There is not a way to learn the unicast address(es) at the remote
end until they send data traffic, and many of the cases where you would want
to send TEST frames are precisely because there is no regular traffic flowing
and you need to verify the link.
In many deployment scenarios the device at the other end of an EFM link
will be an L2 bridge. It might be an L2 bridge with some amount of L3 knowledge
(to implement firewalling/filtering rules), but it would still fundamentally
operate as a bridge.
This means a couple things:
1. if you send a TEST frame, you can get multiple responses.
This is manageable, though unwieldy. I doubt the service providers
want to get a response from the subscriber's printer, for example.
2. if there is nothing connected to the bridge, you will get no response.
This would be bad. There is no way to distinguish between a failed link
and an unutilized link.
We could define TEST as an ethertype and hope that all the bridge vendors
implement MAC Clients to handle it... but I doubt this would happen.
Denton Gentry
Dominet Systems
PS: I just noticed an earlier response from Tony Jeffree also mentioning
bridges, but I'm gonna send this one anyway.