[EFM] RE: FEC in: P2: EPON requirements draft

["Ajay Gummalla" <ajay@xxxxxxxxxxxx>]

Tony:

    There is an ad-hoc group looking at the economic viability and advantage of using

FEC vs improved optics or other system design issues.  That group is planning

to make a presentation (unfortunately) only in November. Further, FEC can be

considered optional which will be attractive to some service providers.  I am ccing

Steve MacLaughlin on this, as he is leading the FEC interest group.  I will leave it

to this group to present the justification

 

Some comments on actual implementation:

 

We have implemented FEC at 10Gig rates  A RS(255,239) encoder-decoder

can implemented with ~400K gates. The power dissipation is not a significant 

problem at Gigabit rates. With today's VLSI technology, this takes up

very little silicon area. Further with today's level on integration, the FEC would not

be a different chip but will be embedded in the 1000BaseX Phy chips.

 

Further, most of the complexity is in the decoder. One option could be

to consider FEC only on the upstream (and use higher power optics on the

downstream). Not that i am suggesting this as a solution but can be a potential

cost tradeoff.

 

Regards,

Ajay

-----Original Message-----
From: Tonyshouse@xxxxxxx [mailto:Tonyshouse@xxxxxxx]
Sent: Friday, September 07, 2001 8:02 AM
To: dolors@xxxxxxxxxxxx; 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
Cc: stds-802-3-efm@ieee.org
Subject: FEC in: P2: EPON requirements draft

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@xxxxxxxxxxxx

File: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