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

Re: [802.3_NGEPON] Delay constraints

Hi Duane,

 

Iâ??m equally having trouble understanding why something more complicated (more dissected?) than what was done in 75.3.1.1, 76.1.2, and 77.3.2.4 is needed (for us: 141.3.1.1, 143.4.3 and 144.3.1.2).    Why does the same level of specification not work for NGEPON?

 

Cheers,

Mark

 

From: Duane Remein [mailto:Duane.Remein@xxxxxxxxxx]
Sent: Monday, October 1, 2018 8:39 AM
To: STDS-802-3-NGEPON@xxxxxxxxxxxxxxxxx
Subject: [802.3_NGEPON] Delay constraints

 

I would like to begin an open discussion regarding how we specify Delay constraints in our draft (also see comment #434 againsse D1.2 from the Spokane meeting).

When I crafted this proposal I made the assumption that a supplier may be providing one or more layer functions and would need to know the amount of delay variation allocated to the partial system they were supplying.  Thus the proposed table provided allocations for everything from any single layer/sub-layer to an entire system. I broke the entire transmit data path into MAC/MAC Control/ MCRS (labeled MCRS for simplicity), PCS/PMA, PMD, PHY and MAC to PHY (i.e., the entire tx path).

One of the arguments against this idea was that our skew management system will remove any potential delay variation.  This is true up to a point, that being the amount accommodated by the 32 slots in our receive skew buffer or 81.92 ns total.  While it is true that the receiver will remove this skew we still need to constrain the transmitter so that the total skew is less than this 81.92 ns.

It was also argued that a PMD designer should not have to look in the MPCP clause to get a requirement.  I find this argument somewhat contradictory as we often write specifications that reference other clauses in the 802.3 book.  We even reference other specification when it is appropriate (for example we donâ??t spec the fiber itself).  So pointing to another clause should not be a problem.  Iâ??m not at all opposed to moving the proposed allocation table to Cl 141 but we need it somewhere with proper cross-references form other layer clauses.

Iâ??m also very open to discussing the actual values in the table.  For your convenience Iâ??ve included the proposed table below.

Assuming we can come to an agreement I will re-submit a comment on this topic against D1.3.

Best Regards,

Duane

 

Table 144-x Delay variation allocation in Nx25G-EPON

Layer/Sub-layer

Allowed Delay variation (EQT)

MCRS

1

Nx25G-EPON PCS/PMA

2

Nx25G-EPON PMD

1

MAC to PHY(1)

4

PHY(2)

3

Notes:

1) Total delay variation for an Nx25G-EPON implementation covering both MAC and PHY layers.

2) Total delay variation for an Nx25G-EPON implementation including PCS, PMA and PMD.

3) Total expected delay is declared as specified in {Cl 45 PMA/PMD Ref} and {Cl 45 PCS Ref}.  Implementations which combine MCRS, PCS, PMA and PMD may use either one or both of these mechanisms.

Editors Note: we will need to determine how to declare MCRS total delay which may affect Table 144-x"

 

 

FutureWei Technologies Inc.

duane.remein@xxxxxxxxxx

Director, Access R&D

919 418 4741

Raleigh, NC

 

To unsubscribe from the STDS-802-3-NGEPON list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGEPON&A=1

To unsubscribe from the STDS-802-3-NGEPON list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGEPON&A=1