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

Re: [EFM] TEST frames MAC_Control vs MAC client

[Date: 09/06/2001  From Seto]


>  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.  


>>>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.