Re: [EFM] TEST frames MAC_Control vs MAC client
[Date: 09/06/2001 From Seto]
Denny,
> 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.
This is why I'm suggesting to assign an 802.1 reserved address.
The frames with 802.1 reserved address are defined to "not be
relayed by the Bridge." -- 802.1-1998 7.12.6 I'm also
suggesting to limit L2 ping use in P2P networks.
Seto
>
>>>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.