RE: [EFM] TEST frames MAC_Control vs MAC client
Bob,
As is the case today, sometimes the customer owns the CSU/DSU, sometime the
service provider owns it. No matter who owns it, the CSU/DSU supports an
L1 framing protocol that gives the service provider an OAM management
channel that is out-of-band to the customer revenue bearing traffic. For
the classic "T1" that is several kilobits per second and includes basic
synchronization, labeling/performance, and a low bandwidth comm
function. One of my proposed methods of providing OAM is based on this
technology, modified to a data centric bandwidth rate model.
Thank you,
Roy Bynum
At 11:29 AM 9/16/01 +0100, Bob Barrett wrote:
>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.