[EFM] RE: [EFM-OAM] This is Ethernet Bob but not as we know it
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.