[EFM] 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.
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.
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.
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.
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.
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.
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.
- Matt