[EFM] RE: OAM Transport Proposal
Matt,
Thanks for the response. Questions and comments inserted below.
Cheers,
Brad
-----Original Message-----
From: Matt Squire [mailto:mattsquire@xxxxxxx]
Sent: Monday, April 22, 2002 9:36 PM
To: stds-802-3-efm@ieee.org; bradley.booth@intel.com;
gthompso@xxxxxxxxxxxxxxxxxx; rabynum@xxxxxxxxxxxxxx;
Kevin.Daines@xxxxxxxxxxxxxxxxxxxx
Subject: Re: OAM Transport Proposal
I wanted to try to address several question/issues that have been raised
by the publishing of the recent baseline proposal.
1) Eliminate reference to the EOC/voc. We (those working on the OAM)
have been working under the assumption that the copper track will
solidify on an Ethernet over xDSL technology, and the xDSL technology
will be an already defined DSL technology such as VDSL. Such DSL
technologies provide a management channel with the EOC/voc. The members
of the copper track have repeatedly expressed the opinion that the
EOC/voc managmeent channel should continue to be used for most PHY
management functionality. What we are really proposing is a layered OAM
scheme. Certain OAM functions are common across all Ethernets and are
communicated using a frame-based OAM mechanism. Other OAM functions are
PHY specific and communicated using the preamble (for P2P full-duplex
Ethernet) or EOC/voc (for Ethernet over copper). The proposal for
Ethernet over copper is that the common Ethernet functions be
communicated via a frame-based mechanism, and any PHY specific functions
performed in the EOC/voc. This would permit, as an example, using a
standard Ethernet MAC over a standard xDSL chip. So I don't think we
can eliminate the reference.
BJB> If you do not plan to eliminate the reference, then please provide the
data where others can read about how this is performed. It seems premature
to ask the task force and the working group to support something that is
undefined. I know you may be waiting for the copper track to provide you
with some direction, but it's hard to say I agree with a management scheme
when I don't know what it is.
2) Full-duplex only? The common OAM functions will be communicated in
frames and thus operate for half and full duplex operation. The
signaling enhancements obtainable via preamble signaling are intended to
be applicable to full-duplex operation only.
BJB> What OAM features are given up in a system that is not operating in
full-duplex mode? Do the features that would normally be in the preamble
get mapped into the frames?
3) How address multiple links? We are explicitly not addressing
multi-link scenarios. The common transport mechanism is a MAC control
frame that cannot be forwarded off the local link. For end-to-end or
multi-hop Etherent OAM, I'd refer you to some of the work happening in
the MEF.
BJB> MEF is not a standards body. Is there something in this OAM proposal
that permits other standards bodies (i.e. IETF, etc.) to create an overall
management structure? It would seem to me that if OAM in frames is
mandatory across all links, that it could be used to carry information
end-to-end, but that it would be up to the management entity to perform this
operation. Is this a correct assumption?
4) Null/dummy frames break MIBs? I don't think its that bad. Certainly
the MIB would have to be enhanced with a counter for the number of such
frames, but the changes are minimal.
BJB> I'd prefer to let the MIB experts speak to this one.
5) PHY ID in baseline. I think this is a relatively minor presentation
point. Granted, the PHY ID has no meaning in P2P links, and as such I
personally agree it shouldn't have appeared in the baseline. But we're
not arguing about anything technical, just descriptive. Noone refutes
the point that PHYID has no application to P2P.
BJB> I agree that this is a minor point.
I don't think the above issues are particular troublesome. They seem to
be focused on how the proposal was described, not what the proposal
was.
But there are several issues that seem more serious:
6) Null/dummy frames bad in general. Its a fair point that the
null/dummy frame concept is new, and would require some changes. The
goal of the null/dummy frame is to provide a mechanism to carry
signaling bits across the link without data. An alternative would be to
use a true Ethernet frame of minimum size with a reserved MAC address
that causes the frame to get discarded but allows the preamble to be
used. I believe the intended benefit of the null/dummy frame is that
only a 20B buffer or so is required to detect that a dummy frame can be
inserted. If a normal frame were used, the buffer size (and hence
latency) would be bumped by 60B or so. The latency goes up but I don't
think the complexity goes up. I'm not sure how people would feel about
such an approach vs the dummy frame approach, but I wanted to put it out
there to get reaction either way.
BJB> I was trying to understand why you wouldn't use a MAC control frame and
then use its preamble. The concern that I have with null/dummy frame
insertion is that you have to buffer and then have a scheme to empty that
buffer. Below the MAC sublayer, this scheme is not as easy as it sounds.
P2MP could also be hampered by this (trying to remember if OAM in preamble
was included in the P2MP scenario... and thinking that it was) due to having
to wait for idle moments to empty the buffer. This could effective increase
the size of the buffer and hence the latency.
7) Break GbE that shrink preamble. First, this is not exactly true. In
the most general sense, the ability to carry enhanced signaling in the
preamble bytes is an option. Existing GbE that shrink the preamble
would not be broken - they would simply not have the ability to include
signaling in the preamble. Ethernet OAM would be supported and
transported in frames. This is an important motivator for the
'optional' description of OAM signaling in the preamble. Granted,
options aren't looked upon fondly, and maybe having something as an
option shouldn't be an option, but the claim that existing GbE would be
broke is not accurate.
BJB> Your interpretation is incorrect. By break GbE, I'm referring to going
in and re-writing Clause 36 to move the generation of the SFD to a boundary
to guarantee 8 bytes of preamble. This means that if I have PCS logic
designed, I will have to redesign it to work with the OAM in preamble
feature. If this logic existed in the PHY, this might be a simple change,
but the logic is in the MAC. This says to me that most 1000BASE-X devices
will use OAM in frames rather than OAM in preamble, begging the question,
why do the OAM in preamble at all?
BJB> Another point that came to mind is the access to the preamble
information. If the PHY is filtering this and we're relying on the typical
MII management interface to access this data, isn't this going to be quite
slow? To read one management frame is going to take over 25 us. And it's
going to take another 25 us to write a management frame. I would think that
the MAC control sublayer using OAM in frames would have a faster
communication to the host processor than OAM in preamble using MII
management interface.