Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [802.3_NGEPON] Objectives



Marek: So we are on the same page for 25G EPON to be first and servers a a building block for multi-lane EPON. Channel bonding without mix generations is fine.  Mix generations with channel bonding is problematic, however, if we develop multiple rates specifications now, mixed generation seems the way for coexistence. We'll face it one way or another.

Eugene 


________________________________________
From: Marek Hajduczenia <marek.hajduczenia@xxxxxxxxx>
Sent: Tuesday, September 15, 2015 7:43 AM
To: Dai, Eugene (CCI-Atlanta); STDS-802-3-NGEPON@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_NGEPON] Objectives

Eugene,

Just to be clear: 25/25G could be a base PHY, and would not require any
lanes to be disabled.

Now, as far as disabling lanes is concerned - yes, it is something to be
paid for up front but on the *OLT side*. Whether we can support channel
bonding, it is not clear now and honestly, not required as per objectives we
have discussed so far.

Marek

-----Original Message-----
From: Dai, Eugene (CCI-Atlanta) [mailto:Eugene.Dai@xxxxxxx]
Sent: Tuesday, September 15, 2015 7:32 AM
To: STDS-802-3-NGEPON@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_NGEPON] Objectives

One of my concerns is the assumption of build a 100G MAC multi-lane EPON
then disable lanes to get sub rate. This approach is paying the tax upfront
like the mortgage. In order to have a 25G EPON one have to build a 100G
EPON. Given the high cost of 10G EPON today, I can not imagine when the 100G
EPON will be economic.

The feasible approach is to develop 25G single lane EPON first, its market
will arrive much early, at the same time it will also provide a building
block for for multi-lane 100G EPON.

Besides, "disable lane" approach assume channel bonding with mixed
generations - it may or may not technically feasible. We have discussed the
similar approach at EPOC, for a long story short, we killed it.


Eugene

________________________________________
From: Salinger, Jorge <Jorge_Salinger@xxxxxxxxxxxxxxxxx>
Sent: Tuesday, September 15, 2015 7:00 AM
To: STDS-802-3-NGEPON@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_NGEPON] Objectives

What Marek proposes seems like a reasonable approach.

Incidentally, JD, Kevin, Peter, Phil and I got together during dinner. We
reviewed the objective of supporting 10G US and concluded that we don't
really need this asymmetry. ‎Supporting Nx25 DS and US is really all we need
in addition of WDM coexistence with existing 10G EPON and staying silent on
1G WDM coexistence. This should also simplify things considerably.

Thanks!
Jorge


  Original Message
From: Marek Hajduczenia
Sent: Tuesday, September 15, 2015 6:54 AM
To: STDS-802-3-NGEPON@xxxxxxxxxxxxxxxxx
Reply To: Marek Hajduczenia
Subject: Re: [802.3_NGEPON] Objectives


Ed et al.,

The concern in the past was about the use of the word "lane" which has been
used and abused around (not in this group) to the point where it became
meaningless. Why not just simply state:

Provide specifications for physical layers operating over a single SMF
strand and supporting the MAC data rate of:
- At least 25 Gb/s in downstream and at least 25 Gb/s in upstream
- Up to 100 Gb/s in downstream and up to 100 Gb/s in upstream

The first one would be the base PHY, where the majority of the work would
have to be done. The second option is essentially a combination of multiple
base PHYs together into a larger capacity system. As we discussed before,
once we get 25/25G designed, doing asymmetric 25/10G will be easy (just
steal upstream from 10G-EPON and put them together, we know that is simple
enough to do spec-wise). If we have a mechanism to disable lanes in PHY,
then we do not really need to worry about intermediate speeds and
combinations - that would become a product problem, rather than a spec
problem. We would need to specify a protocol to discover the number of
supported wavelengths, set ground rules for ONUs to play with the OLT, etc..
but it seems more reasonable than specifying a horde of PHY types.

Marek

-----Original Message-----
From: Harstead, Edward E (Ed) [mailto:ed.harstead@xxxxxxxxxxxxxxxxxx]
Sent: Tuesday, September 15, 2015 6:32 AM
To: STDS-802-3-NGEPON@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_NGEPON] Objectives

All,

I thought the table was a great idea, but I am now not so sure.  What
happens if you start with 25 down/10 up, and later you add a 25 down/25 up?
Sounds like a reasonable scenario.  The MAC then must support 50 down/35 up.
That would be disallowed by the table.  You would have to replace all the
25/10 ONUs before you could add any more upstream capacity.

As an example, NG-PON2 simply said that any downstream lane is either 2.5G
or 10G, and every upstream lane is either 2.5G or 10G (it only disallowed
2.5 down/10 up wavelength pairs).  They did not build a table of all the
permutations, they never worried that the PON could have a "weird" total
capacity of, say, 12.5 down/5 up.  (I realize a difference is that we are
grouping all wavelengths under a single MAC, but I'm just trying to make a
point with this example.)

So I wonder if we should go back to text.  What about:

Provide specifications for a downstream physical layer that operates over
one, two, three, or four lanes of 25 Gb/s each, supported by a single MAC.
Provide specifications for an upstream physical layer that operates over
one, two, three, or four lanes, each of which may be either 10 or 25 Gb/s,
supported by a single MAC.

Ed
________________________________________
From: Curtis Knittle [C.Knittle@xxxxxxxxxxxxx]
Sent: Monday, September 14, 2015 10:59 PM
To: STDS-802-3-NGEPON@xxxxxxxxxxxxxxxxx
Subject: [802.3_NGEPON] Objectives

Colleagues,

Please find attached the PowerPoint file we used this evening to
consider/massage new objectives. We'll pick up with this file in the
morning, 8 am EDT.

Curtis




Curtis Knittle
Director, Optical Technologies

CableLabs
858 Coal Creek Circle
Louisville, CO 80027
Office: 303-661-3851
Mobile: 303-589-6869
Email: c.knittle@xxxxxxxxxxxxx<mailto:c.knittle@xxxxxxxxxxxxx>