RE: [EFM] OAM loop back / echo server function
Hello Denton, _response_ to LLC TEST Command PDUs is mandatory in compliant
802.2 implementations, whether Class 1,2,3, or 4. _Initiating_ TEST Command
PDUs is optional however. Kind of a chicken-or-egg problem, since no one is
required to initiate (send) TEST Command PDUs, but they all must reply to
them if received. For EFM, as a minimum, the headend would need to be
required to support initiation of TEST Command PDUs. This is the quickest
route to a loopback capability that doesn't require a TCP/IP stack in ONUs.
How would this be captured, spec-wise? It wouldn't be a requirement change
to 802.2 since it is EFM-specific, and only headends at that. It doesn't
functionally change 802.2--it just turns an option into a requirement. Could
this be captured simply within a new RFC that covered 802.2 requirements for
EFM? Seems this would be sufficient. Comments anyone?
Regarding Bob's reply: This LLC TEST PDU is more like a layer-2 "ping" test,
so to speak, rather than a BER test. Meaningful BERT for 10**-10 (or lower)
error rates takes a *lot* of BER frames. How this is implemented may differ
between PON and P2P. Maybe for PON, if fixed slot sizes, an ONU pads the end
of all frames with BER test patterns until the headend tells it to stop. For
P2P they would just be inserted on a "space available" basis, with an option
to request it be labeled as high priority.
For PON, another possibility is that a couple fixed slot sizes be
interleaved, cyclically. For example, 100uS "best effort" slots across all
ONUs for one cycle, then switch to (for example) 20uS "priority" slot size
for priority traffic across all ONUs for the next cycle, then back to a
100uS cycle, then 20uS, etc. This "interleaved cycles of different slot
size" method may in fact be a sufficient way to meet upstream QoS
requirements without any complex signaling or setup parameters, if you think
about it. For 16 ONU's, a priority slot comes around to every station every
couple milliseconds. That is well within any reasonable latency and jitter
budget for the EFM portion of an end-to-end link, even if the ONU missed
several cycles in a row for some reason. If an ONU has no
high-priority-tagged frames to send, it uses its priority slot for whatever
data it has.
A request by the headend to send BER frames could be specifically tagged as
a priority request via the headend request message, and would go in the
ONU's next 20uS slot.
Also, on a related 802.2 note, the LLC XID PDU has "capability expansion"
possibilities that I think are also within the current scope of 802.2, and
could therefore just be defined in an EFM-specific 802.2 requirements RFC.
Currently the "format identifier" byte for XID PDUs only has one used value.
More could be defined via an EFM-specific RFC that defines 802.2 usage for
EFM. This could be used instead of adding new MAC Control frame types, and
has the added advantage of variable frame size, potentially. The default
behavior would be that the EFM MAC does not forward such frames beyond the
EFM realm, but even if it did, the receiving non-EFM-MAC would not recognize
the XID format identifier and would drop the entire frame anyway.
-----Original Message-----
From: Denton Gentry [mailto:denny@xxxxxxxxxxxxxxxxxx]
Sent: Thursday, August 30, 2001 12:02 PM
To: bob.barrett@xxxxxxxxxxxxxxx
Cc: stds-802-3-efm@ieee.org
Subject: RE: [EFM] OAM loop back / echo server function
> Remote loop back of Ethernet packets / 802.3 frames is a really bad idea.
> No mater how well intentioned it will go wrong sometimes and when it does
> it is really bad news.
> I thought we were looking at some form of simple echo server function i.e.
> take a received packet, swap the SA and DA, then send it back out with a
> new CRC, same payload ????
There was a presentation to that effect at the last meeting, describing
the merits of the LLC2 TEST frame and how having something like it be
widely implemented would be a good thing. There will likely be a followup
presentation in Copenhagen discussing details of the proposed mechanism.
I don't think an honest to goodness remote loopback, where the RX is
logically connected to the TX at the remote end, is even possible in EFM
for the simple reason that the links we're looking at may be asymmetric.
PONs and DSL-based copper solutions can provide more bandwidth in one
direction than another.