| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
The intention of this presentation was not to make any proposal. Instead, it was a recompilation of the potential functionality that may be implemented and it is under study by different members of the committee. (I am personally not involved in any FEC proposal.)
The presentation is a recompilation of what has been suggested and hence under discussion. But only things under the current column of the table were accepted requirements. This was intended to be a living table that as consensus is reached things would move from recommended column to current column. (Writing about it now, I see that the naming was not appropriate. Maybe "under study" and "adopted" columns would have been more appropriate naming) .
It has not been well received because it has been interpreted as a list of actual recommendations, as you also interpret. So I am planning to modify/reduce significantly to avoid any of this confusion.
So I let the experts in FEC to answer your question.
Thank you very much to all who has helped identifying this misinterpretation, it is important to identify misinterpretation earlier so it can be fixed.
More comments/suggestions are welcome.
Dolors
Tonyshouse@xxxxxxx wrote:
Dolors,I have a comment in the presentation you are working on in P2 called
EFM-PON-ReqV0.pdf. In this presentation you suggest using FEC for PON to
achieve a higher split ratio. At first glance FEC seem like an ideal solution
for
increasing reach and number of splits. I looked into this a year ago and
determined
that the cost was just too high and its still true today. Today's Adv. FEC
implementations require 750,000 to 1,000,000 gates for the encode and decode
logic to achieve 5.5 - 6.0db of gain using various Reed Solomon codes. Since a
basic MAC block is <= 20,000 gates and various proposed PON protocol's which
could be implemented in the PHY layer or as other suggest in higher layers.
In either case these chips would be roughly <= 200,000 gates. The main point
I am trying to
make is the relative $ cost one would be adding to the very cost sensitive
ONU, by
adding encode/decode FEC logic. Another issue to consider is the FEC chip has
to
sit between the SERDES (PHY) and before any MAC or ePON protocol functions,
which means it would need to be powered up to support life line services. The
power
draw from the FEC chip alone would put further burden on the cost of an ONU if
battery back up were chosen.I know the Operators would like to see 64 splits @ 20Km but I'm not sure they
would
be willing to pay added cost of FEC to achieve this. Another approach is to
consider
the relative cost of two 32 split PON networks. This means an increase in the
outside
plant cost. It means double the feeder fibers from the OLT, but the number of
passive
splitters does not increase by that much. And finally its a second OLT node,
but it's
cost is a ratio of the total PON cost 32 ONU / OLT versus 64:1. Thus this
would be
far cheaper then having an FEC encode/decode chip in every ONU.Regards,
Tony Anderson
ZONU
Reply to: tony@xxxxxxxx
In a message dated 9/3/01 8:22:24 PM Pacific Daylight Time,
dolors@xxxxxxxxxxxx writes:
Subj: P2: EPON requirements draft (next call 09/05/01 3:00pm EST)
Date: 9/3/01 8:22:24 PM Pacific Daylight Time
From: dolors@xxxxxxxxxxxx (Dolors Sala)
To: Glen.kramer@xxxxxxxxxxxx, jc.kuo@xxxxxxxxxxxx, rhirth@xxxxxxxxxxxx,
onn.haran@xxxxxxxxxxx, ariel.maislos@xxxxxxxxxxx,
kobi.mizrahi@xxxxxxxxxxxx, HHvostov@xxxxxxxxxxxx, RShamsi@xxxxxxxxxxxx,
eyal@xxxxxxxxxxxxxxxxxxxxxx, meir@xxxxxxxx, tony@xxxxxxxx,
jstiscia@xxxxxxxxxx, glen@xxxxxxxxxxx, cicook@xxxxxxxxx,
carlosal@xxxxxxxxxxxxxxxxxx, ajay@xxxxxxxxxxxx, limb@xxxxxxxxxxxx,
jpickens@xxxxxxxxx, jcpoint@xxxxxxxx, lior.khermosh@xxxxxxxxxxx,
gerry.pesavento@xxxxxxxxxxxx, dolors@xxxxxxxxxxxxFile:EFM-PON-ReqV0.pdf (27335 bytes) DL Time (26400 bps): < 1 minute
Attach is the first draft of the EPON requirements presentation. I am
sending to
everybody who has been involved so far, and added the updated list in
Gerry's table
and others who has expressed interest on the topic.The presentation contains the information discussed in the previous
conference call and
some additional information gathered from service providers and others. So
please note
that there is more than what we agreed on the previous call. Please express
your
opinion.The presentation addresses the overall solution as a justification of the
defined
requirements. Understanding the viability of an overall solution given these
requirements seems needed.I have tried to represent all information obtained although not every body
may agree on
everything. The last two slides is where I tried to capture the opinions
separating
between what is currently agreed on and what is recommended. The
recommendation column
contains question marks if there are different opinions. As we reach
consensus the
question marks will reduce and as requirements are being approved in the
future they
would be filling the current column.The idea is to take this presentation more to help reaching consensus than
to capture
only the things we have agreements. We can take this as initial baseline
and have a
second conference call for discussing it. Please send comments earlier by
email to
start the discussion.Next conference call on Wed Sept 5, 2001 at 3:00pm EST.
I'll send call number and details tomorrow.
Dolors
Dolors Sala wrote:
> Onn,
>
> Thanks for the clarification.
>
> Onn Haran wrote:
>
> > Dolors,
> >
> > As I remember, we didn't agree that reporting queue status per queue is
a
> > part of EPON requirement.
> >
> > What I said is that DBA is a requirement, but reporting queue status per
> > queue is a specific protocol suggestion. Other protocol suggestions may
not
> > include reporting state of individual queue. I don't believe that such a
> > protocol will be accepted by 802.3 group. Of course you may suggest it,
but
> > don't state it as a general EPON requirement.
>
> I sincerely understood that we agreed on that the reporting information
from OLT to
> ONU was a requirement. But it seems I misinterpreted the discussion, so
it should
> be taken out. As you say this can be considered part of a specific
proposal, if we
> all don't agree now that this is part of the interface between MAC and
client.
>
> > In addition, I haven't heard anybody talking in the conference about
> > thousands of splits. I'm wondering if there is somebody that thinks that
> > this is feasible. It certainly isn't a fact that this will happen.
>
> Feasibility changes in time and hence I believe we agreed that the
solution should
> be long lasting. And hence the solution should not be limited to the
lower bound of
> parameters, but it should also be operational to much larger upper bounds
even if
> they are not feasible today (regardless of what this value is, how about
millions
> of splits ;-)
>
> Dolors
>
> > Best regards,
> > Onn.
> >
> > -----Original Message-----
> > From: Dolors Sala [mailto:dolors@xxxxxxxxxxxx]
> > Sent: Wednesday, August 01, 2001 9:49 PM
> > To: Harry Hvostov; Ariel Maislos; Onn Haran; J.C. Kuo; Glen Kramer;
> > Deepak Ayyagari; Ryan Hirth; John Limb; Ajay Gummalla; Jean Charles
> > Point; John Pickens; Gerry Pesavento
> > Subject: Summary of EPON requirements conference call on 07/31/2001
> >
> > Participants:
> > ADC (Deepak Ayyagari)
> > Alloptic (Glen Kramer)
> > Broadcom (Ajay Gummalla, John Limb, Dolors Sala)
> > Passave (Onn Haran, Ariel Maislos)
> > Terawave (Ryan Hirth)
> >
> > The objective of the discussion was to identify the service
> > specification between 802.3 MAC and MAC client layers.
> >
> > The following terms were defined:
> > Scalability: ability to operate in different scenarios
> > Upgradability: ability to migrate from one scenario to another
> > Statistical multiplexing across ONUs: ability to oversubscribe
> >
> > The discussion centered around the following topics:
> > 1.Do we need to first specify the applications that the system will
> > be used for before we can specify the interface? We do not know
the
> > full range of applications that the system will be used for in
the
> > future.
> > It was felt that we could talk just about the properties that
> > different flows might need. Examples of these properties are
latency,
> > speed (bandwidth), jitter and error tolerance.
> >
> > 2.Stress the fact that the specification indicates
> > lower bounds and the solution should not limit the upper
> > bound (of future technology advances). Solution should
> > operate in all market spaces (FTTB,FFTH,FTTC,..). Service
providers
> > in the residential market will try to extend the split as far as
> > possible. The technology will probably be the limiter of the
> > size of the split for the next few years. We prepare for the
> > fact that well within the lifetime of the standard split ratios
> > of a thousand might well be possible.
> >
> > 3.Dynamic bandwidth allocation. It is needed for scenarios with
> > large splitting ratios such as FTTH. It is expected that
providers
> > will oversubscribe in these scenarios.
> >
> > 4.QoS delineation. The classification, policing and other QoS
> > functionality is out of the scope of 802.3. However, there
> > is a need to differentiate service on the feedback message
> > sent by the ONU to the OLT to indicate queue state information.
> > The interface should allow to send the state for
> > each individual queue. This state information should be
> > interpreted at the layer where the bandwidth allocation
> > resides.
> >
> > 5.Security delineation. Some level of link security is needed.
> > It will be specified in a separate effort (P10 Gerry's list).
> >
> > The specific requirements agreed through this discussion are:
> > 1. Scalability in rate, number of ONUs and distances
> > 2. Statistical multiplexing across ONUs
> > 3. The need to report queue state information for each queue
> > from ONU to OLT.
> > 4. Need of link security
> >
> > Next steps:
> > * Prepare a presentation that captures this generality and
> > justification of the requirements so we can reach
> > consensus with the entire group.
> > I'll prepare the draft.
> > * Discuss evaluation criteria
> > * We will have another call in a couple of weeks to
> > target these issues.
> >
> > Please comment if there are any additional suggestions or if I
> > misinterpreted or left out any important agreement.
> >
> > Dolors
Tony Anderson