Re: [EFM] RE: OAM Transport 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.
>
Fair enough. We're in a little bit of a chicken-and-egg problem. We
didn't think we'd get approval without explicitly addressing the EOC/voc
work for copper, but we can't really address it until more has been
officially adopted by the copper group. My suggestion to move past this
point is to:
a) Remove reference to EOC/voc
b) Replace it with statement to the effect that copper-specific OAM
enhancements are expected but not included in this baseline
> 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?
>
Mostly one gives up a certain amount of timeliness in alarm signaling,
and loses a PHY ping ability to monitor the link. By using a few bits
in the preamble, one can commuicate a few states across the link
immediately and with no interference with user data. Currently these
states are targeted at sectionalization/RFI (i.e. I'm not receiving from
you), a lower layer ping (i.e. hello request/response), and a basic
alarm (without diagnostis). These functions are supported in frames but
the data may take a little longer to get across the link. So the
enhanced signaling aspects are intended to increase the timeliness of
communicated a selected few states across the link.
> 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?
>
802.3 defines Ethernet links and not Ethernet networks, so how one
extends the ideas of the OAM capabilities defined here to a general
network is out of scope. Certainly one could put some type of
management entity in place to forward OAM-in-frames across multiple
links - nothing we do prevents this. One could also use the same
principles and use a different MAC address to communicate across a
multi-hop Ethernet network. Possibilities exist for extension, but we
can't specify them here.
> 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.
>
The enhanced signaling aspects were targeted as optional enhancements in
P2P and P2MP environments. I believe the intent behind the dummy/null
frame was to take up as few bits on the link as possible, and to add as
little latency/buffering as possible. Several people have suggested
that the benefits of optimization in that regard may not be worth the
complexity. Enough people voted for preamble OAM at to imply that the
complexity may be worth the optimization. Its a fair question and one
on which we're looking for feedback.
>
> 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.
I'm not sure I understand this point. You're mixing management 'frames'
with the responsiveness of signaling bits in the preamble. The preamble
is communicated across the MII along with all frames, management frames
or user frames or whatever.
- Matt