RE: [EFM] [EFM-OAM] OAM Transport Proposal
Kevin,
Some follow-up below.
Thanks,
Brad
-----Original Message-----
From: Kevin Daines [mailto:Kevin.Daines@xxxxxxxxxxxxxxxxxxxx]
Sent: Friday, April 19, 2002 6:02 PM
To: Booth, Bradley
Cc: stds-802-3-efm@ieee.org
Subject: RE: [EFM] [EFM-OAM] OAM Transport Proposal
Brad,
All good questions. Responses in-line below:
-----Original Message-----
From: Booth, Bradley [mailto:bradley.booth@xxxxxxxxx]
Sent: Friday, April 19, 2002 2:58 PM
To: stds-802-3-efm@ieee.org
Subject: RE: [EFM] [EFM-OAM] OAM Transport Proposal
Kevin,
I have a few questions:
* OAM in VOC/eoc is not explained in the document. Is there a
proposal that should be referenced?
KQD> To date, I am not aware of a proposal that has been made to 802.3ah.
VOC/eoc refers to the operations channel embedded in VDSL today. I believe
there is an ITU-T specification which could (should) be referenced. At this
point, we're floating the idea of OAM in Frames as mandatory for Copper
making it similar to its optical brethren.
BJB> Without VOC/eoc spelt out in the presentation, that does leave a big
hole for interpretation of what can and should be used. If the idea is to
make OAM in Frames mandatory for Copper, then I would recommend just doing
that and removing the reference to VOC/eoc.
* Do these OAM protocols assume no repeaters? Is the OAM scheme
designed to work in half-duplex?
KQD> The proposal precludes the use of OAM on half-duplex links. This should
probably be clarified in the presentation. Slide 20 of the following
presentation subtly mentioned "full duplex", in red, in the upper left hand
corner.
http://grouper.ieee.org/groups/802/3/efm/public/mar02/suzuki_2_0302.pdf
This should be called out in the proposal.
BJB> Is there concern that this is going to preclude some possible
implementation scenarios because the exclusion of half-duplex? Could OAM in
Frames be used for half-duplex?
* Is there a specific OAM scheme that should be used for end-to-end
(versus link-by-link) OAM messaging? Carrier class equipment has section,
line and path, do we have something similar?
KQD> The EFM OAM Sub-Task Force has as a non-requirement the following:
"Anything outside of a single link (station management, monitoring of
CPE-sided links, etc) is not part of EFM OAM".
Reference the following presentation for more information on requirements
and non-requirements discussed within the OAM STF:
http://grouper.ieee.org/groups/802/3/efm/public/jan02/squire_2_0102.pdf
BJB> I was referring to what I believe was MO4(b) in that presentation. I'm
not sure if I'm explaining this really well, because I'm not sure of the
terminology that EFM is using, so you'll have to excuse me if I'm not
articulating this well. I'm curious if between a CO and the end user if
there is bound to be multiple links that may use different OAM protocols.
If that is the case, how do we ensure that each link carries the important
information for the overall OAM of the communication between endpoints? If
I have a device that sits between the end user and the CO and use OAM in
Frames on one side and OAM in Preamble on the other, how do I ensure that
all the important information makes it through my device and is there
information that is going to be lost?
* IEEE Std. 802.3z currently permits GbE fiber links to generate
either 7 or 8 bytes of preamble. How does the OAM in preamble compensate
for this?
KQD> This proposal would require a change to 1000BASE-X PCS (for
implementations opting to provide OAM in Preamble functionality), in that
preamble would be fixed at 8 bytes, requiring the IPG to vary between 11 and
13 bytes. The result would appear similar to 10 Gigabit Ethernet and its
requirement to align the Start of Packet to Lane 0 causing IPG to vary
between 8 and 15 bytes (as I recall).
BJB> This would probably result in everyone that developed or develops
full-duplex 1000BASE-X MACs to open their design files to add this feature.
Please correct me if I'm wrong, but I believe that anyone that designed a
1000BASE-X PCS for fiber GbE built it in their MAC device. This means that
it's not going to be a simple PHY change and re-use of existing MACs, but
that this would require a MAC device change and re-use of existing PHYs. In
my humble opinion, this doesn't sound like a pleasant proposition to me.
Also, unlike 10 Gigabit Ethernet where this function is easily performed in
the XGMII/RS sublayer (Clause 46), this cannot happen in the GMII/RS
sublayer (Clause 35) because the 1000BASE-X PCS (Clause 36) transmit state
machine decides which bytes are even and odd. In other words, the solution
is not the same as what was done for 10 Gigabit Ethernet.
Thanks,
Brad
KQD> Thanks for reading and asking questions.
BJB> No problem! Just want to fully understand this stuff before I make any
decision. Thanks for answering my questions! :)