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

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