RE: [EFM] RE: EPON TDMA
Rick,
Rick,
If any work is to be done to support specific Internet type
"burstable" services at the link level then it will have to be
done by 802.2 or 802.1. The only thing that OAM will do will be to
provide performance information and possibly a channel outside of the
customer bearing traffic to do service provisioning for upper level
applications and services. Remote fault, remote loop, remote BER
performance reporting, remote frame error rate performance reporting,
remote link management, remote node/ONI label administration are what EFM
OAM should be doing, and very little else.
Thank you,
Roy Bynum
At 01:54 PM 7/21/01 -0700, Rick Li wrote:
Roy,
I was not suggesting that we
modify the ethernet header and add FECH/BECN or EFCI into it (my mistake
if I misled you to believe
that's the suggestion). The
point is that to maximize link utilization, to accommodate IP burst and
to satisfy defined SLA/QOS,
congestion status information
can be included in the link OAM to facilitate excess bandwidth
redistribution at the link layer.
Rick
- -----Original Message-----
- From: Roy Bynum
[mailto:rabynum@xxxxxxxxxxxxxx]
- Sent: Saturday, July 21, 2001 5:02 AM
- To: Rick Li; Charles Cook; Faye Ly
- Cc: glen.kramer@xxxxxxxxxxxx; zhangxu72@xxxxxxxxx;
RHirth@terawave.com; stds-802-3-efm@ieee.org
- Subject: RE: [EFM] RE: EPON TDMA
- Rick,
- Unless you are wanting to make major changes to 802.2 as well as
802.1, I would not attempt to do the same things that were done in
FR. Besides, part of the reason for things like FECN and BECN is
because of the performance problems that were seen by the users/service
providers when FR was mapped into another protocol in order to scale the
service core. EFM does not have that issue because it is supposed
to be a closed infrastructure with only one, or maybe a very few
customers on each link. EFM needs to keep things simple.
Other, telephony centric protocols tend to complicate things like has
been done with other protocols, which not only makes the hardware more
expensive, but deployment and support more expensive as well.
- Keep It Simple!
- Thank you,
- Roy Bynum
- At 06:52 PM 7/19/01 -0700, Rick Li wrote:
- Agree with the points Roy is making. Deliver 10Mbps pipe definitely
is a service to one
- set of end customers, however, the ability to allow service provider
to divide the 10Mbps
- further into 5Mbps, 4Mbps and 1Mbps chunks, each with its own SLA/COS
and thereby
- chargeable separately, is another service with value add to both
service providers and end users.
- As a result, SLA/QoS should be included on the equipments end to end,
access euipments
- (EPON for example) included. The actual definition of the
SLA/QoS/COS, IMHO, should be
- left to be dealt by others such as IETF, but the ability at layer 2
to support those SLA/QoS/COS should
- be (ditto Harry's points in a previous email) covered in EFM. These
would include similar
- things such as congestion notification (forward, backward) (as FECN
and BECN in Frame Relay and EFCI in ATM or pause in ethernet), packet
priority marking (as CLP in ATM), grant scheduling to support the
required QOS etc.
- Rick
- Salira Optical Network
- -----Original Message-----
- From: Roy Bynum
[mailto:rabynum@xxxxxxxxxxxxxx]
- Sent: Tuesday, July 17, 2001 10:20 AM
- To: Charles Cook; Faye Ly
- Cc: glen.kramer@xxxxxxxxxxxx; zhangxu72@xxxxxxxxx;
RHirth@xxxxxxxxxxxx;
- stds-802-3-efm@ieee.org
- Subject: Re: [EFM] RE: EPON TDMA
- Charles,
- If the EFM TF does not deliver an infrastructure will directly
support
- services with SLAs then there is no market for EFM technology.
The low
- margins for best effort, statistically multiplexed services is so low
that
- they may not even be in business unless they raise their prices
within the
- next year. The cost of infrastructure remains the same.
Talk to your
- accounting organization about how much it costs per Mb per distance
to
- deploy your network. Talk to your accounting department about
how much it
- costs for right of way to put fiber into and though buildings.
Talk to you
- accounting department about how much it costs for power and other
- facilities to house and operated the equipment that you put your
services
- over. The Internet service providers are charging about as
little as ~$180
- per Mbps for IP wholesale bandwidth, yet many of them are spending
well
- over $200 per Mbps to provide that service. (These costs
include
- facilities, operations, back office systems, engineering, and
- administration.) Private line services are well over $500 per
Mbps and
- cost about the same as, and sometimes less than the IP best effort
- services. If a service company is to stay in business, it has
to be
- profitable and to have the ability to provide high margin services in
- addition to the low margin services. This is an issue that has
to be
- addressed by EFM.
- Thank you,
- Roy Bynum
- At 12:52 PM 7/16/01 -0600, Charles Cook wrote:
- >I don't think that trying to do a true SLA over Ethernet is the
- >requirement. Other
- >methods at higher layers should be doable.
- >
- >Charles
- >
- >Faye Ly wrote:
- >
- > > Something I need clarification on: As far as I know,
there are multiple
- > > solutions to SLA
- > > or QOS in the IP world such as diffserv or MPLS TE (Traffic
- > > Engineering). EFM provides
- > > bandwidth allocation and implementation which can be a part
of the
- > > higher layer parameters?
- > > Or it is our intention to try to do a true SLA over
Ethernet? If this
- > > is the case, what application
- > > will that be? Thanks.
- > >
- > > -faye
- > >
- > > -----Original Message-----
- > > From: Charles Cook
- > > Sent: Mon 7/16/2001 7:47 AM
- > > To: glen.kramer@xxxxxxxxxxxx
- > > Cc: zhangxu72@xxxxxxxxx; RHirth@xxxxxxxxxxxx;
stds-802-3-efm@ieee.org
- > > Subject: Re: [EFM] RE: EPON TDMA
- > >
- > > This is
turning into an interesting discussion. One thing to
- > > consider for EFM
- > > is that
from a carrier perpective, EFM will most likely not be a
- > > peer-to-peer
- > >
implementation. Particularly if a carrier needs to manage SLAs
- > > etc. DBA and
- > > stat muxing
will both be essential for success. If portions of
- > > this are not
- > > addressed
in the lower layers, we may be sacrificing some
- > > channel efficiencies.
- > > We will
need to strike an appropriate balance. I'm in agreement
- > > that we should
- > > be careful
not to use statements like,
- > >
- > >
"Ethernet never did that..." or "Ethernet traditionally
does
- > > that...".
- > >
- > > However, I
do believe we also need to find a sufficiently
- > > elegant solution so
- > > that we can
take advantage of the Ethernet cost model.
- > >
- > > Charles
- > >
- > >
glen.kramer@xxxxxxxxxxxx wrote:
- > >
- > > > These
are comments for both Xu's and Ryan's postings.
- > > >
- > > > First
let's not mix stat muxing and dynamic bandwidth
- > > allocation. These are
- > > >
different concepts.
- > > >
- > > > DBA is
a method allowing "just-in-time" bandwidth allocation
- > > to an
- > > >
application that requires it. As an example, consider a
- > > network carrying
- > > > voice
and data. In the absence of voice traffic all the
- > > bandwidth is given
- > > > to
data traffic. When new voice call arrives "some
- > > mechanisms" will reduce
- > > > the
bandwidth available to data traffic and will allocate it
- > > to voice
- > > >
traffic. This bandwidth will be guaranteed to voice traffic
- > > in a sense that
- > > > each
voice packet won't need to struggle to get its share of
- > > the bandwidth.
- > > > When
voice call completes, the same "mechanisms" will return
- > > the bandwidth
- > > > back
to data traffic.
- > > >
- > > >
Statistical multiplexing is a way of statistically allocating
- > > channel
- > > >
bandwidth, i.e., stealing chunks of bandwidth when other users
- > > (node) failed
- > > > to do
so. "Statistical" nature means that bandwidth available
- > > to a user
- > > > will
converge to some fixed value only when averaged over long
- > > observation
- > > >
time. But there is no way to predict how much bandwidth will
- > > be available
- > > > to a
node in any given short interval of time.
- > > >
- > > >
Ethernet (specifically CSMA/CD) uses statistical multiplexing.
- > > DBA, on the
- > > > other
hand, was never part of Ethernet. But when we think of
- > > Ethernet in
- > > > the
First Mile, we realize that this is whole new world for
- > > the Ethernet,
- > > > where
it has never gone before. Suddenly stat muxing in its
- > > current form
- > > >
(CSMA/CD) becomes very harmful due to its statistical nature.
- > > Yes, we want
- > > > to
utilize bandwidth efficiently, but most importantly - we
- > > need to provide
- > > > SLAs
to users. CSMA/CD is a non-deterministic service:
- > > packets may collide
- > > > some
number of times and then be discarded. DBA in this new
- > > world becomes
- > > >
important, as we want to be able to deliver all services:
- > > voice, video,
- > > > data,
etc.
- > > >
- > > > How
this could be solved in EFM? Let's first consider P2P
- > > solution as I see
- > > >
it. In P2P deployment a very smart switch will be located in
- > > CO. This
- > > > switch
will monitor traffic for each user in terms of both
- > > volume and
- > > >
application. As the uplink bandwidth is clearly a limited
- > > resource, the
- > > > switch
will make an arbitration decision of which packets to
- > > drop in terms
- > > > of
both keeping the user within its pipe and maintaining some
- > > sort of DBA
- > > > within
each pipe. We hope the switch will be SLA-aware. Of
- > > course, it will
- > > > be
proprietary to each vendor how switch fabric will be
- > > implemented. It is
- > > > higher
level, above MAC and PHY, and the standard is not
- > > concerned with it.
- > > > The
point is that both decision of how to keep user within its
- > > pipe and
- > > >
execution of this decision are done in the CO.
- > > >
- > > > Now
consider P2MP. In the same way as in P2P, higher layers
- > > in OLT will
- > > > make a
decision how to keep user within its SLA. The only
- > > difference is
- > > > that
execution of this decision and ensuring DBA within user's
- > > pipe are
- > > >
delegated to an ONU. And if in P2P the switch may decide to
- > > give entire
- > > > uplink
bandwidth to one ONU, so in P2MP, the OLT may do so by
- > > giving all
- > > >
timeslots to one ONU, or just by making it one large timeslot.
- > > Of course,
- > > > real
implementation is a bit more complicated: changed ONU
- > > state needs to be
- > > >
propagated to OLT. This may be done through OAM communication
- > > channels,
- > > >
proactively of otherwise, and except increased delay has no
- > > side effects.
- > > >
Letting PHY be timeslot-aware is just a mechanism for ONU to
- > > execute the
- > > > OLT's
decision. OLT may choose to modify timeslot assignments
- > > or size as
- > > > often
as it deems feasible. Specific values of timeslot,
- > > frequency of
- > > >
updates, and algorithm used to make such decisions are all
- > > outside the scope
- > > > of the
project.
- > > >
- > > > I
readily agree with Xu's comment that we need a model to
- > > analyze. Once EFM
- > > >
graduates into a work group and technical work begins, I think
- > > we will
- > > >
proceed by building a simulation model for various approaches.
- > > >
- > > > On a
general note, I would like to suggest to group members to
- > > refrain from
- > > >
comments like "Ethernet never did that..." or "Ethernet
- > > traditionally does
- > > >
that...". Ethernet traditionally supported CSMA/CD, and in
- > > 802.3ae it
- > > >
doesn't anymore. And it never was used in WAN and now it is.
- > > Ethernet
- > > > never
had OAM, and now it will. Without fair amount of
- > > "heresy" in each new
- > > >
project Ethernet would never become ubiquitous protocol as it
- > > is now. We
- > > > have
PAR and objectives to govern our direction. Tradition and
- > > religion is
- > > > not
one of them.
- > > >
- > > > Thank
you,
- > > >
- > > > Glen
- > > >
- > > >
-----Original Message-----
- > > > From:
xu zhang [
mailto:zhangxu72@xxxxxxxxx]
- > > > Sent:
Friday, July 13, 2001 7:28 PM
- > > > To:
Ryan Hirth
- > > > Cc:
stds-802-3-efm@ieee.org
- > > >
Subject: RE: [EFM] RE: EPON TDMA
- > > >
- > > > I
agree with Hirth's opinion, in order to keep the
- > > >
statistic multiplexing nature of ethernet, the DBA
- > > > is
needed.
- > > > in a
large time solt. such as 125us, if the ONU has
- > > > large
traffic, the time solt may be not enough, if the
- > > > ONU
has little traffic, the bandwidth utilization will
- > > > be
reduced a lot. In a fixed size time solt, the DBA
- > > > is
easy to implement, but in order to achieve high
- > > >
bandwidth utilization the time solt need to be small,
- > > > when
using variable size time solt, the DBA is hard to
- > > >
implement, but it can keep statistic multiplexing
- > > > nature
of ethernet and at the same time achieve high