Re: [EFM] OAM transport: Target Market.
Roy
Just to make the obvious clear, "something other than Internet access" ends
up being the types of services network operators either are 1) deriving
revenue from today or 2) planning to deliver services that deliver revenue
tomorrow (for example VPNs).
//Bruce
At 01:09 PM 2/11/2002 -0600, Roy Bynum wrote:
>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)?
>>>
>>>-------------------------------------