RE: [EFM] RE: EPON TDMA
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
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@yahoo.com; RHirth@terawave.com; 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
>
> > bandwidth
utilization.
>
> >
> > > I
think whether the frame will be segmented of not
> > >
segmented, how long the time solt will be,
>
> > the DBA or
SBA(static bandwidth allocate£(c)£¬
>
> > using variable
size time slot or fixed size time slot,
>
> > we need a model to
calculate.
>
> >
> > > ---
Ryan Hirth <RHirth@xxxxxxxxxxxx> wrote:
>
> > > Ethernet has
always had an inherent form of DBA in
>
> > > the fact it
allows a
>
> > > station with
traffic to send at up to the line rate
>
> > > or an
arbitrated rate
>
> > > less than
that. However in a connectionless system
>
> > > there are no
service
>
> > > contracts or
allocations of that bandwidth, but
>
> > > bandwidth of
the media is
>
> > > divided
dynamically. SLAs are features which do not
> > > >
belong in the Ethernet
>
> > > MAC layer,
however dynamic bandwidth allocation is
>
> > > inherent
within Ethernet
>
> > > and that is
why Ethernet is so well suited for data
>
> > >
traffic.
>
> > >
> >
> > By creating fixed timeslots in the upstream you are
> >
> > changing the nature of
>
> > >
Ethernet. Now the maximum bit rate of one station
> > > >
to burst upstream is
>
> > > limited to
its timeslot. I believe according to the
>
> > > AllOptic
presentation
>
> > > this would be
25 - 50 Mbps/ station (without DBA).
>
> > > This creates
asymmetry
>
> > > which has
never been an explicit form of Ethernet.
>
> > >
> >
> > A new media for Ethernet should present similar
> > > >
characteristics of
>
> > > traditional
Ethernets. There is certain level of
>
> > > service which
Ethernet
>
> > > has. If
you increase the latencies across the media
>
> > > ten fold, is
it still
>
> > >
Ethernet? The end user will perceive a difference
> > > >
in service.
>
> > >
> >
> > Ryan Hirth
>
> > > Terawave
Communications
>
> > >
rhirth@xxxxxxxxxxxx
>
> > >
(707)769-6311
>
> > >
> >
> >
>
> > >
> >
> > -----Original Message-----
>
> > > From:
jc.kuo@xxxxxxxxxxxx
>
> > > [ mailto:jc.kuo@xxxxxxxxxxxx]
> >
> > Sent: Friday, July 13, 2001 4:06 PM
>
> > > To:
glen.kramer@xxxxxxxxxxxx; zhangxu72@xxxxxxxxx
>
> > > Cc:
stds-802-3-efm@ieee.org
>
> > > Subject: RE:
[EFM] RE: EPON TDMA
>
> > >
> >
> >
>
> > >
> >
> >
>
> > > As PON is
just a new media of Ethernet, the overall
>
> > > system will
be a base on
>
> > > "Switched
Ethernet" architecture.
>
> > > Under this
architecture, bandwidth shaping and
>
> > > priority
queuing will only be
>
> > > done in the
switch fabric. In the MAC and PHY, a
>
> > > mechanism
which allow
>
> > > flexibly
assign the data rate may benefit the DBA
>
> > >
implementation but DBA
>
> > > algorithm
will not be implemented as part of MAC and
>
> > > PHY layer
function.
>
> > >
> >
> > There is always trade-offs between delay and
> > > >
utilization. Reduce the guard
>
> > > band and do
the packet fragmentation will help the
>
> > > bandwidth
utilization,
>
> > > then the
delay can be minimized. EPON is under the
>
> > > umbrella of
Ethernet,
>
> > > keep the
Ethernet frame integrity is one of the
>
> > > religions of
802.3 team,
>
> > > packet
fragmentation is not considered as an option
>
> > > for the
standard.
>
> > >
> >
> > JC Kuo
>
> > >
jc.kuo@xxxxxxxxxxxx
>
> > > Alloptic,
Inc.
>
> > > 2301
Armstrong St.
>
> > > Livermore, CA
94550
>
> > > Phone: (925)
245-7641
>
> > > Fax: (925)
245-7601
>
> > > www.alloptic.com
> >
> >
>
> > >
> >
> > -----Original Message-----
>
> > > From:
glen.kramer@xxxxxxxxxxxx
>
> > > [ mailto:glen.kramer@xxxxxxxxxxxx]
> >
> > Sent: Friday, July 13, 2001 2:55 PM
>
> > > To:
zhangxu72@xxxxxxxxx; glen.kramer@xxxxxxxxxxxx
>
> > > Cc:
stds-802-3-efm@ieee.org
>
> > > Subject:
[EFM] RE: EPON TDMA
>
> > >
> >
> >
>
> > >
> >
> > Dear Xu,
>
> > >
> >
> > I think I know what confused you in the presentation
> >
> > as I got several
>
> > > similar
questions.
>
> > >
> >
> > Timeslot is not an analog to a cell. While, from the
> >
> > slide 4 in the
>
> > > presentation
you may conclude that one timeslot is
>
> > > only large
enough to hold
>
> > > one maximum
size packet, that is not the case.
>
> > > Timeslot in
our example was
>
> > > 125 us, which
equals to 15625 byte times. Then you
>
> > > can see that
in the
>
> > > worst case it
will have 1518 + 4(VLAN) +
>
> > >
8(preamble)+12(IPG) - 1 = 1541
>
> > > bytes of
unused space at the end of timeslot
>
> > > (assuming
there is data to be
>
> > > sent and no
fragmentation). With realistic packet
>
> > > size
distribution (like
>
> > > the one
presented by Broadcom), the average unused
>
> > > portion of
the timeslot
>
> > > is only about
570 bytes. That gives channel
>
> > > efficiency of
96%, or
>
> > > accounting
for 8 us guard bands - 90%
>
> > >
> >
> > DBA is a separate question. While it may be
> > > >
important for an ISP to have
>
> > > DBA
capabilities in their system, I believe it will
>
> > > not be part
of the 802.3
>
> > >
standard. But a good solution would provide
> > > >
mechanisms for equipment
>
> > > vendors to
implement DBA. These mechanisms may
>
> > > include, for
example, an
>
> > > ability to
assign multiple timeslots to one ONU or
>
> > > to have
timeslot of
>
> > > variable
size. Grant/Request approach is trying to
>
> > > achieve the
same by
>
> > > having
variable grant size.
>
> > >
> >
> > Having small timeslots will not solve QOS either.
> > > >
Breaking packet into
>
> > > fixed small
segments allows efficient memory access
>
> > > and a
cut-through
>
> > > operation of
a switch where small packets are not
>
> > > blocked
behind the long
>
> > > ones (and it
assumes that short packets have higher
>
> > > QOS
requirements). In
>
> > > such a
distributed system as EFM is trying to
>
> > > address
(distances in excess
>
> > > of 10 km) the
gain of cutting through is negligible
>
> > > comparing to
propagation
>
> > > delay or even
the time interval before ONU can
>
> > > transmit in a
time-sharing
>
> > > access mode
(be that TDMA or grant/request method).
>
> > >
> >
> >
>
> > > Thank
you,
>
> > >
> >
> > Glen
>
> > >
> >
> > -----Original Message-----
>
> > > From: xu
zhang [ mailto:zhangxu72@xxxxxxxxx]
> >
> > Sent: Thursday, July 12, 2001 7:01 PM
>
> > > To:
glen.kramer@xxxxxxxxxxxx
>
> > > Cc:
stds-802-3-efm@ieee.org
>
> > > Subject: EPON
TDMA
>
> > >
> >
> > hi, glen:
>
> > > I had
seen your presentation file about EPON TDMA
>
> > > in
> >
> > PHY, it help me a lot to understand your EPON
> > > >
system.
>
> > > We had
developed the first APON system in china,
>
> > > when
> >
> > I think of the TDMA of EPON, I think though the
> > > >
uplink
>
> > > data rate is
1Gbits/s when shared by 16 or 32 users
>
> > > is
> >
> > still not enough, so the dynamic bandwidth
> > > >
allocate(DBA) protocal must be a requiremant
>
> > > especially
when take care of the QoS performance. In
>
> > > DBA protocal,
in order to achieve high performance
>
> > > the
> >
> > time slot need be to small, I think why not we
> > > >
divide
>
> > > the ethernet
packet to 64 byte per solt, it is often
>
> > > used in
ethernet switch when store packet in SRAM.
>
> > >
> >
> > best regards
>
> > > xu
zhang
>
> > >
> >
> >
>
> > >
__________________________________________________
> > > >
Do You Yahoo!?
>
> > > Get
personalized email addresses from Yahoo! Mail
>
> > > http://personal.mail.yahoo.com/
> >
> >
>
> >
> > >
__________________________________________________
> > > Do You
Yahoo!?
>
> > Get personalized
email addresses from Yahoo! Mail
>
> > http://personal.mail.yahoo.com/
> >
> >
> >
> >
------------------------------------------------------------------------
>
>
Name: winmail.dat
> >
winmail.dat Type: DAT File
>
(application/x-unknown-content-type-dat_auto_file)
>
>
Encoding: base64