Re: [EFM] OAM transport:
[Date: 02/12/2002 From Seto]
Hello Suzuki-san,
>>1) Standardization complexity - How much do we have to change/write in
>>the 802.3 specification to support this transport mechanism? Being that
>>I'm personally very lazy, less is better. Which clauses would be
>>effected and to what extent in each clause?
>
>As we addressed in our presentation in Jan
>Clauses 22 / 35: RS to support OAM byte read/write capability
>Clause 36: GE PCS TX side to make sure preamble transparency for OAM.
This may be true only if we are supporting preamble based OAM
with 1000BASE-X and 100BASE-X PHY. If we are to support wider
applications including ones you mentioned, we'll end up changing
more and more exsiting cluases, I suppose.
I also want to know if preamble OAM has impacts on managed
objects, i.e. clause 30. Could both parties clarify?
Seto
>
>
>Hi Matt and OAM teams,
>
>I address in this mail about the individual items, from OAM Preamble point
>of view.
>
>At 08:05 PM 2/2/2002 -0500, Matt Squire wrote:
>
>>------------------
>>
>>1) Standardization complexity - How much do we have to change/write in
>>the 802.3 specification to support this transport mechanism? Being that
>>I'm personally very lazy, less is better. Which clauses would be
>>effected and to what extent in each clause?
>
>As we addressed in our presentation in Jan
>Clauses 22 / 35: RS to support OAM byte read/write capability
>Clause 36: GE PCS TX side to make sure preamble transparency for OAM.
>
>
>>2) Implementation complexity. Again, back to me being lazy, how much
>>work is it to implement the transport mechanism? What functional blocks
>>in the 802.3 spec need to be changed? How much new silicon/software is
>>needed for an implementation (relative to the alternate proposal(s))?
>>What is the component level backward compatibility (ie how much existing
>>hardware can I use)?
>
>Minimum HW would be Preamble field read/write and CRC for preamble bytes.
>plus dummy frame generation / termination.
>Each OAM byte & Message byte may be handles by SW or by HW logics.
>Protection ( for metro ethernet, optical network ) would need HW
>support of state machines, while event alarm in EFM application may use
>firmware
>to handle each byte.
>
>In EFM environment, flexibility is within message byte.
>We see VDSL VOC channel is used for read/write registration.
>So the usage of message byte would be limited in that simple level,
>rather than leaving many protocol heavy extensions like in frame based
>solution,
>which may cause inter-operability issue,
>especially when relying on firmware implementations.
>
>
>>3) Bandwidth transparency. What is the effect on user data with respect
>>to the OAM transport (ie delay/bandwidth implications of adding OAM to a
>>link)? Why is this acceptable?
>
>Zero overhead. BW transparent.
>
>
>>4) Applicablity to non-EFM PHYs/MACs. EFM will be defining new PHYs
>>over which we know OAM will operate. Can the OAM transport mechanism be
>>applied to other (non-EFM) PHYs? For example, people are using some 1G
>>fiber solutions for access now. Can the OAM transport mechanism be
>>applied to the current 'first mile' solutions? Should it apply to
>>current 'first mile' solutions or to other applications of Etherent?
>
>All full duplex Ethernet PHY which service providers are looking at
>have preamble.
>as in stated in
>http://grouper.ieee.org/groups/802/3/efm/public/jan02/suzuki_3_0102.pdf
>So it can be applied to non-EFM PHY/MAC as well.
>
>
>>5) Security. We've had some detailed discussions at the meetings on
>>security and threats in the access market. How are threats such as
>>denial of service or theft of service addressed by the OAM transport?
>>Should these issues be addressed?
>
>Definitely more secure than frame-oam since no MAC client access.
>Also does not need to mandate 802.1D Briding at demarc point.
>Simple = low cost media converter can support preamble OAM.
>Frame base OAM can not support such devices,
>meaning that user PCs behind simple media convert can send MAC frame OAM.
>
>Also if SP want to test PHY device only, Preamble OAM can do it.
>Frame OAM needs MAC to work properly.
>
>
>
>>6) Responsiveness. What is the comparative responsiveness of the
>>transport mechanism? What kind of responsiveness is necessary for the
>>problem?
>
>If we talk about protection in business application
>( though it is not residential EFM req, it is req for business users )
>it would need <50msec responsiveness. Preamble by HW can address this.
>
>
>>7) Data rate. Is the data rate for OAM transport fixed, variable,
>>configurable, or what? What data rate is necessary to support OAM
>>function?
>
>OAM rate is min=0.13%, max=2.4% of user data rate, but not invading user
>rate at all.
>If needed a couple of more byte can be allocated to increase the OAM BW
>without affecting user data.
>
>
>>8) Market acceptance. What do you view the market requirements for an
>>OAM transport mechanism are, and why does this transport suffice?
>
>This was addressed in my separate email, saying that
>preamble can address: all market requirements below.
>
>0) Ethernet to the home ( CO :"Central Office" to CPE )
>1) Metro Ethernet : CO to CO GE/10GE
>2) Ethernet for High-end Internet core routers ( CO to CO )
>3) Ethernet over DWDM ( on Optical boxes )
>
>
>
>>9) Standards acceptance and ethernetishness. Some claims have been made
>>that some techniques are more 'Ethernetish' than others - which to me
>>means that the transport fits within the meaning of Ethernet better - so
>>what are the main attributes of Ethernet and does this proposal fit
>>better within them than others?
>>
>
>Preamble scheme is included in Ethernet Frame.
>The proposal makes unused part of Ethernet frame more useful
>for service provider networks.
>So it is very Ethernetish.
>
>
>>10) PON. The P2P OAM is relatively straightforward. Are there any PON
>>implementation specifics that need to be addressed? How does the OAM
>>data rate change on a p2mp link, for example. Are there new/other
>>security threats? Is there, and should there be, any relationship to
>>the PON control protocol(s) (currently MPCP)?
>
>EPON will carry Logical PHY ID on preamble for 802.1D compliance
>which will identify each ONU. By combining preamble OAM with Logical PHY ID
>on preamble
>you can manage each ONU.
>
>Hiroshi
>
>>-------------------------------------
>