RE: [EFM] TEST frames MAC_Control vs MAC client
Really low cost 10/100/1GE p2p EFM CPEs could be repeaters / media
converters with management.
That spec. supports demac and OAM at minimal cost and complexity.
The user's bridge / router can sort out what traffic gets access to the
service provider's EFM port.
This is a very clean architecture that we are finding acceptance for.
Naturally vendors can build systems with higher layer funtions and EFM
ports. The demarc is then vitualised within the system, but it still a
demarc (like a T1 DSU/CSU with FDL that I keep harping back to).
What say the service providers on this exploder regarding how much
functionality should be within the EFM device?
Is it preferable that the demarc is a physical port and a cable rather than
virtualised within a bigger system that may be owned by the user? (T1
DSU/CSUs were owned by the user after the break up of AT&T, prior to that ma
bell owned 'everything' related to the service.)
Bob Barrett
> -----Original Message-----
> From: owner-stds-802-3-efm@majordomo.ieee.org
> [mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf Of Denton
> Gentry
> Sent: 05 September 2001 21:01
> To: stds-802-3-efm@ieee.org
> Subject: [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.