RE: [EFM] OAM transport: Target Market.
Bill,
There are two ways to handle busy hour demographics. One way is to deny
access to the service facilities. This is what the current POTS services
do. The other way is to degrade services. This is what the Internet and
other shared media/bandwidth data services do, also the highway systems in
the USA.
In the POTS example, the switched voice network has to be scaled to a point
that the busy hour demographics are handled in such a way that is
acceptable to the customer base. The worst busy hour is "Mothers'
Day". Fortunately, this is a day that few businesses are hitting their
busy hour, so that the large switches that cross demographic lines can be
dedicated to the residential traffic. Conversely, when businesses are
hitting busy hour usage, residential customers are not at a demographic
busy hour. Unfortunately, it means that in all of the different
demographic service areas, the edge access subscription networks have to be
sized to fully support the busy hour requirements of that area. This is
the reason that very few people get a "line not available" message when
they try to call someone.
In the second example, the edge access subscription network, whether it is
the Internet subscriber line, or the city streets, the bandwidth is sized
to support the busy hour requirements. Even though people are willing to
accept degraded services, they do require full access to those
services. Just as in the case of telephone services, people get irritated
when that get a busy tone for their dial up Internet access.
All of this means, that regardless of whether the service is based on
statistical gain or service blockage, the edge subscription network will
still need to be sized to support the demographic busy hours of the
customer base it is supporting.
Thank you,
Roy Bynum
At 09:37 AM 2/13/2002 -0500, Bill Crick wrote:
>How does one possibly get by "busy hour demographics"? Aren't they just a
>fact of life?
>Businesses peak at fairly predictable times during the day, as do
>residences?
>If you can solve this problem, we could stop building new roads too.
>
>Bill Crick
>Nortel
>
>
>-----Original Message-----
>From: Roy Bynum [mailto:rabynum@xxxxxxxxxxxxxx]
>Sent: Monday, February 11, 2002 3:08 PM
>To: Bruce Tolley; Hiroshi Suzuki; mattsquire@xxxxxxx
>Cc: stds-802-3-efm@ieee.org
>Subject: Re: [EFM] OAM transport: Target Market.
>
>
>
>Bruce,
>
>Because VPNs still require statistical gain in order to be economically
>sound, they are only a "Better than best effort" type of Internet
>service. Service providers believe that they can garner major numbers for
>VPNs if they can just get past the problem of "busy hour
>demographics". So far, even after several years, they have not been able
>to do that.
>
>Thank you,
>Roy Bynum
>
>At 12:03 PM 2/11/2002 -0800, Bruce Tolley wrote:
> >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)?
> >>>>
> >>>>-------------------------------------