Re: [EFM] RE: [EFM-OAM] This is Ethernet Bob but not as we know it
Bob,
Given 802.3ae WIS, I would suggest that adding "frames" for OAM or
inserting data into a previous sacrosanct preamble is not "Ethernet".
Thank you,
Roy Bynum
At 12:45 AM 1/29/2002 +0000, Bob Barrett wrote:
>Denny
>
>Good answer. And this is one of my more constructive emails (imho) :-).
>
>On the priority and 100% load issue:
>
>Are you proposing that the system use pause to back pressure the sender in
>the 100% load case? That would prevent a loss of packet if the buffers were
>large enough for the pause to work in time. Or we could suggest a
>pre-emptive pause be sent to create a gap for the OAM frame i.e. a bigger
>IPG between two of the subscriber packets large enough for an OAM frame. A
>'wee pause' should not affect video, iSCSI and encrypted data flows.
>
>I guess we are well into the proverbial 'implementation specific' here. It
>doesn't solve the issue of looking at the frame stream to find the OAM data,
>but it is an Ethernet answer to the issue I raised about the 100% loading.
>
>The one about the 'looking at the frame stream' is a matter of semantics
>that I am inclined to leave to the lawyers, but I have given it a lot of
>thought, so here goes:
>
>
>On the 'just what constitutes a private line' issue:
>
>I went round the T1 framer case with a thought experiment (been doing a lot
>of driving this past week).
>
>T1 framers recognise the sync pattern when there is no payload on the line,
>and then keep in sync by counting bits and checking the pattern (those that
>have designed T1 framers please chime in if this is an incorrect assumption,
>but it is what they look like from the outside). There is a race condition
>between two framers when first connected to see which sync's first, so
>customer data could flow in one direction (with a minor alarm condition)
>whilst the framer receiving that data is still looking for the sync pattern
>(still looking at every symbol).
>
>If there is a hardware recognition of OAM transport (frames, IPG, preamble,
>whatever) then it could be argued that the mechanism does not look at
>customer frames, it only looks at symbols. It works the way that T1 framers
>work and they are acceptable for private line. Roy will probably disagree
>with this, but I have another card to play here that I didn't think of when
>I went over this with him on the 'phone a few days ago.
>
>We know that IPG transport (if there was a proposal for thsi) would be in
>the IPG.
>
>We know that preamble follows IPG.
>
>We know that DA follows preamble.
>
>We can turn off symbol recognition after the IPG, or after the preamble, or
>after the DA, until a number of bytes has passed equivalent to the end point
>of a minimum sized frame. We can count bit times like a T1 farmer does, we
>have a clock good enough for that. We can then look for idle / IPG.
>
>Not looking at 50+ symbols will ensure that the EFM device can't decode the
>customer data stream even within the chip. The symbols never get out of the
>chip to be probed.
>
>Now, is looking at a partial stream of symbols looking at customer data?
>That's the one for the lawyers to answer. I would say not so long as the
>symbols are not accessible outside of the chip. EFM PHYs can be self
>contained just like T1 framers are self contained. If you bring the symbols
>out of the chip then that looks to me like having the potential to inspect
>the customer data.
>
>Alas, anyone of the OAM transports implemented in this way would not be
>implementable in existing silicon, apart from the 1G PLD implementations
>perhaps. However, this solution would be within the scope and spirit of 802
>standards. After all, silicon is but yet another implementation specific, is
>it not.
>
>This suggested mechanism will probably not go down well with those hoping to
>leverage existing implementations with the EFM conformance tag, but I'll
>take the flack for that in the interests of contributing to a professional
>engineering standard that meets the broad market need.
>
>I think this approach to solving two of the key issues in the OAM track will
>be acceptable to the traditional Ethernet fraternity, of which I am old
>enough to be a member, although I am a newbie to 802.3. I do have a copy of
>the original blue book, the data from which provided the company that I was
>with in 1981 to build a two and a half card S100 Ethernet card. My first
>experience of remote access was a teletype and a 110 baud acoustic modem
>:-).
>
>Best regards
>
>Bob Barrett
>
>-----Original Message-----
>From: owner-stds-802-3-efm-oam@majordomo.ieee.org
>[mailto:owner-stds-802-3-efm-oam@majordomo.ieee.org]On Behalf Of Denton
>Gentry
>Sent: 28 January 2002 08:09
>To: stds-802-3-efm-oam@ieee.org
>Subject: [EFM-OAM] Re: OAM - this is Ethernet Bob but not as we know it
>
>
>
> > I think it would be a good idea to ask Denny for some further explanation
> > as
> > to how the 'management in frames' frames take priority over payload frames
> > within the scope of 802.3.
>
> OAM in Frames proposes placing the OAM function in the Mac Control layer.
>OAM frames would be inserted in exactly the same way the Mac Control layer
>currently inserts PAUSE frames. This is described in Clause 31,
>
> > I think I remember (seeing or hearing the answer)
> > that this relied on an implementation specific use of two queues which is
> > outside of the scope of 802.3.
>
> The standard does call out how Mac Control works. I believe what you
>heard was that very few MACs implement their topside interface in exactly
>the way it is defined in the 802.3 spec. In particular, many MACs contain
>a great deal more knowledge about prioritization of data frames, and their
>client interfaces generally do not resemble the DATA_REQUEST/INDICATION
>mechanism (instead resembling a FIFO interface).
> I expect that OAM implementations in vendor products will take advantage
>of these features in their systems. As long as the implementation matches
>the externally visible behavior called out in the spec, these
>implementations
>would be standards compliant.