Re: [EFM] OAM transport:
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
>-------------------------------------