Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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)?
>>
>>-------------------------------------