|
Faye,
To
provide end to end QoS, the QoS mechanisms must be implemented at each node
along the way, including those on the ePON access links.
Public
access networks, such as ePON, must provide services to customers, including QoS
mechanisms to guarantee service delivery. This, I hope, is in the scope of the
group.
Harry
Charles,
Thank you for the prompt response. I agree with you. The
other side of the argument
trying not to get into SLA/QOS standardization at this forum is
also:
1. SLA/QOS is end to end. I don't believe this group, being only at
the edge or 'access
side', can dictate SLA/QOS.
2. SLA/QOS is a service issue. It is out of the scope from this
study group.
-faye
-----Original Message-----
From: Charles Cook
Sent: Mon 7/16/2001 11:52 AM
To: Faye Ly
Cc: glen.kramer@xxxxxxxxxxxx; zhangxu72@xxxxxxxxx;
RHirth@terawave.com; stds-802-3-efm@ieee.org
Subject: Re: [EFM]
RE: EPON TDMA
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
|