|
Harry,
It
really all depends on how do you define QoS. I believe ePON qualifies for
bandwidth allocation
only
at the PHY layer. QoS, as normally defined as shaping, policing and
queuing, belong to
a
higher layer and largely depends on the vendor's offering. I do believe
strongly that QoS is
vital
important as part of the service provided to the subscriber but that does not
mean we have
to
jump in and re-define QoS for ePON. This is simply a matter of figuring
out how does ePON
fits
into, say diffserv.
I do
agree with you that ePON, as it offers the 'first' segment, should provide
QoS. But I don't
believe that is the subject we are trying to
standardize in this forum. Leave it to the IETF where
issues
are largely considered already.
-faye
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
|