Re: [EFM] OAM transport: Target Market.
Hi Matt and OAM teams,
I try to respond for the OAM Preamble.
First of all, I would like to state from where we are coming.
We'd like to emphasize that OAM for the Ethernet is not only for EFM market.
We have the following Ethernet market waiting for OAM standardization.
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 )
Metro Ethernet Forum ( MEF ) team working very hard for the markets 1)& 2)
very much focusing on Etherent protection ( Line and end-end ). They want
to leverage
IEEE802.3 EFM OAM work for their network. At least OAM transport mechanism
should support their requirements.
ITU-T which initiated their work on native Ethernet service discussion
last week
and we also got a letter from NTT to EFM. If we look at their documents, it
states
all 1)2)3) configurations. Ane the main focus seems like defect indication
at link level as well as end-end levels.
A) These service provider networks would like to use common Ethernet OAM
transport schemes
with EFM and looking at EFM is the group which standardize the OAM
transport at least for the link level.
And the market size for 1)2)3) ( mainly for business users ) is bigger than
EFM ( residential ) right now.
We can not ignore this point.
B) Both Forum / standardization look at the common requirement :
Protection. <50msec( both for Link and End-end ).
This is one of the most significant requirement
which OAM transport needs to address for them.
C)We are hearing from SP people that they would need
out of band strongly which does not affect user bandwidth.
Even though, we can prove frame base usage of bandwidth is minimum, in EFM,
going to core network, the arguments are likely not acceptable.
D) Especially, Ethernet Re-generator, Ethernet DWDM transponder / optical
switch can never insert OAM frames
between user frames ( unless you make it much more expensive packet
buffering box)
Frame in the optical network is not an option at all.
These are main reason why we want out-of-band/side-band OAM which can fully
support
carrier class Ethernet protection as well as optical Ethernet OAM. EFM
does NOT need to specify all the
OAM features for outside the subscriber networks, but the OAM transport
mechanism itself should address
these capabilities.
I will address the individual items which Matt asked below in a separate email.
Hiroshi
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?
>
>
>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)?
>
>
>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?
>
>
>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?
>
>
>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?
>
>
>6) Responsiveness. What is the comparative responsiveness of the
>transport mechanism? What kind of responsiveness is necessary for the
>problem?
>
>
>7) Data rate. Is the data rate for OAM transport fixed, variable,
>configurable, or what? What data rate is necessary to support OAM
>function?
>
>
>8) Market acceptance. What do you view the market requirements for an
>OAM transport mechanism are, and why does this transport suffice?
>
>
>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?
>
>
>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)?
>
>-------------------------------------