|Thread Links||Date Links|
|Thread Prev||Thread Next||Thread Index||Date Prev||Date Next||Date Index|
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,
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,
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
everybody who has been involved so far, and added the updated list in
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
that there is more than what we agreed on the previous call. Please express
The presentation addresses the overall solution as a justification of the
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
between what is currently agreed on and what is recommended. The
contains question marks if there are different opinions. As we reach
question marks will reduce and as requirements are being approved in the
would be filling the current column.
The idea is to take this presentation more to help reaching consensus than
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
start the discussion.
Next conference call on Wed Sept 5, 2001 at 3:00pm EST.
I'll send call number and details tomorrow.
Dolors Sala wrote:
> Thanks for the clarification.
> Onn Haran wrote:
> > Dolors,
> > As I remember, we didn't agree that reporting queue status per queue is
> > 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
> > 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,
> > 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
> 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
> > 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
> 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
> they are not feasible today (regardless of what this value is, how about
> of splits ;-)
> > 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
> > full range of applications that the system will be used for in
> > future.
> > It was felt that we could talk just about the properties that
> > different flows might need. Examples of these properties are
> > 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
> > 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
> > 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
FEC in PON.doc