Re: [EFM] OAM transport: Target Market.
Hiroshi,
To the markets that you trying to target, I would add:
4) Multi-Tenant Business Parks with business customers requiring something
other than "Internet" type services
5) Multi-Tenant Buildings with business customers requiring something other
than "Internet" type services
6) Multi-Use Buildings with a mix of residential and businesses both of
which may require something other than "Internet" type services
7) High-end market services for Ethernet Private Line
For all of these, to use your wording, "out-of-band/side-band" becomes
critical to the operations support of the service delivery.
Thank you,
Roy Bynum
At 10:09 AM 2/11/2002 -0800, Hiroshi Suzuki wrote:
>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)?
>>
>>-------------------------------------