Re: [EFM] Re: OAM Transport Proposal
Matt,
I agree with your viewpoints on minor issues 1:5 except for the part
where you say that OAM in Preamble is PHY specific. OAM in Preamble is
architected to be PHY independent. It is architected to apply to as many
optical and copper PHYs as possible while simultaneously being very
"close" to the PHY for performance reasons.
On the major issue 6, I have the following comment:
6) Null/dummy frames bad in general: I believe that the problem here is
that there is a perception that an OAMinP null frame acts like a frame,
which it does not. It's simply an 8-byte OAM data entity sent during IPG
in the absence of Packets. The entity never gets to the
MAC, so it cannot be mistaken for an Ethernet frame or packet. The
8-byte entity has the same format as the OAM preamble sent along with an
Ethernet packet for reasons of architectural simplicity. Perhaps
changing the name to OAM IPG report or something like that is far more
appropriate than null frame.
Best Regards,
Rich
Matt Squire wrote:
>
> 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