|
Faye,
Standard definition of node QoS:
Classification, Queing, and Scheduling mechanisms which ensure
traffic flow delivery guarantees such as b/w, delay, jitter, packet
loss.
There
is no need to redefine QoS for ePON - there are solid definitions and
implementations already available on public
access
networks. DiffServ is aggregate QoS technology, typically used on transport
networks with thousands of traffic flows.
On
subscriber access network links, more granular per application flow QoS is
typically more suitable. A handoff between the per flow QoS and behavior
aggregate mechanisms such as DiffServ is quite feasible, e.g. with the OLT
acting as an edge Layer 2/3 switch.
Again,
no QoS on EPON = no differential services. IETF cooperation to define a viable
public access network model is key.
Harry
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@xxxxxxxxx;
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
|