Re: [STDS-802-3-EPOC] [802.3_EPOC] Synchronization Eval Criteria for EPoC - Presentation for Jan. 8 Eval Criteria Ad Hoc Call
Marek,
Thanks for your insights on 802.3bf. There will be time later to debate
the exact method we use on EPoC for time transfer and synchronization.
If we're going to continue to have MPCP counters on the CLT and CNU for
CLT-to-CNU synchronization (especially for upstream TDMA packet
alignment), then this tight level of synchronization could again be used
as the "flywheel" of our reconstructed ToD clock at the CNU, and a
slower protocol used for updating the local CNU ToD clock, similar to
what was done for EPON.
Even though the *target* numbers in my presentation for the EPoC link
time transfer error performance might seem somewhat premature, without a
goal that makes EPoC a useful extention of EPON for TOD delivery to the
customers and services that need it (and have hard requirements),
choosing an EPoC MAC-PHY architecture without a time transfer error
performance target in mind will be incomplete at best. We can change
the numbers (up or down) based on what's economically possible, and
performance simulations of possible architectures.
Regards,
Bill
-------- Original Message --------
Subject: RE: [STDS-802-3-EPOC] [802.3_EPOC] Synchronization Eval
Criteria for EPoC - Presentation for Jan. 8 Eval Criteria Ad Hoc Call
Date: Wed, 9 Jan 2013 09:01:00 +0000
From: Marek Hajduczenia <marek.hajduczenia@xxxxxx>
To: 'Bill Powell' <bill.powell@xxxxxxxxxxxxxxxxxx>,
<STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
CC: <scarlson@xxxxxxxxxxxxx>
Bill,
All respect to Geoff, but I believe there is some disconnect between
what 802.3bf does and what you describe below. I am CCing former Chair
of 802.3bf Task Force to correct anything I might misrepresent.
First, 802.3bf provides independent registers for transmit and receive
paths (see slide 16 and 17 in
http://grouper.ieee.org/groups/802/3/epoc/public/mar12/hajduczenia_01_0312.pdf),
allowing you to retrieve information on min/max delay in these
directions independently. That was geared towards P2MP systems from day
one (and some P2P as well), to accommodate burst mode transmission in
EPON, as well as any non-symmetric queuing you might have in any
station. Unless there is something we did not think of at the time, I'd
think P2MP systems are very much covered by 802.3bf. There is no reason
that I see why it would not work well in EPoC.
Second, 802.3bf is not limited to 1588v2, but works with 802.1AS (see
slide 8 in that deck). In fact, it was first conceived as hardware
support for 802.1AS (please look at the PAR and Task Force name -
http://www.ieee802.org/3/bf/), but we later became aware of its
applications go beyond 802.1AS, and in fact can be used not only for
synchronization and time transfer purposes. That fact was reflected in
the text of current Clause 90.
Third, the method described in Clause 13 of 802.1AS relies on your
802.1AS agent knowing (quite magically at the time) the residency time
in the PHY. 802.3bf was not done at the time when 802.1AS was completed,
and as such, it was not referenced in there. However, 802.3bf provides
the way to remove magic from the picture, allowing the 802.1AS agent to
actually calculate how much time it takes for a frame to propagate
through PHY in transmit and receive directions and the reference
timeframe for calculations (the now-famous transfer indication signals
-- see TS_TX.indication and TS_RX.indication on slide 10 in the deck),
giving the last missing piece of information to properly account for
residency time in the given station. The rest of the process is defined
in 802.1AS.
Last, but not least, when we talk about any budget, I assume you're
suggesting an NNI-to-UNI budget here, which immediately bears the
question -- how much of this budget we have for EPoC PHY to consume?
Sticking an E2E number (from our perspective NNI-to-UNI is E2E) for a
device comprising much more than 802.3 layers is not really helpful. Do
we consume all of this budget in the PHY? It is the very same problem
with the E2E delay we have been discussing for quite some time by now.
People want to see delay number for EPoC and forget that we cannot
normatively nail it down. We can provide delay budget for PHY but it
will not tell you what delay your application will experience in the
future, since there are so many more factors in play at that level.
To conclude: I think looking at this particular application for EPoC is
valuable, and we should assess the parameters you brought in when we
have PHY to work on, but I am very uncomfortable picking numbers for E2E
link right now and making them goals, when so much is up in the air
right now and we control only a small portion of it.
Marek
*From:*Bill Powell [mailto:bill.powell@xxxxxxxxxxxxxxxxxx]
*Sent:* Wednesday, January 09, 2013 00:28
*To:* STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
*Subject:* Re: [STDS-802-3-EPOC] [802.3_EPOC] Synchronization Eval
Criteria for EPoC - Presentation for Jan. 8 Eval Criteria Ad Hoc Call
Marek,
Yes, you are correct that 802.3bf does not include a mechanism for
timestamping packets. My understanding of the usefulness of 802.3bf
(after re-reading an email from Geoff Garner) was for use over full
duplex Ethernet where the time transport protocol was IEEE1588. This
could possibly also be used as a method of time synchronization of CNUs
to the EPoC CLT but might need additional study for use in the EPoC P2MP
environment.
What I've included as an _example_ of a time transport method between
the EPoC CLT and CNUs in my presentation (on slide 9) was a method
similar to the method implemented for EPON (MPCP counter synchronization
of OLT and ONU, and use of 802.1as Clause 13). This method does not
rely on the use of 802.3bf or the timestamping of the1588 messages.
Since this OLT-to-ONU synchronization method was already defined for
EPON , it was also utilized as part of the time transport protocol
defined in 802.1as Clause 13 for the media-dependent EPON time transport
method.
The main point of the presentation was to look at the overall picture
and try to suggest a practical time transport error budget for EPoC to
guide our choice of time transfer protocols relative to our EPoC MAC-PHY
decisions. It was not to propose a specific solution at this point.
Regards,
Bill
-------- Original Message --------
*Subject: *
Re: [STDS-802-3-EPOC] [802.3_EPOC] Synchronization Eval Criteria for
EPoC - Presentation for Jan. 8 Eval Criteria Ad Hoc Call
*Date: *
Tue, 8 Jan 2013 23:24:31 +0000
*From: *
Marek Hajduczenia <marek.hajduczenia@xxxxxx>
<mailto:marek.hajduczenia@xxxxxx>
*Reply-To: *
Marek Hajduczenia <marek.hajduczenia@xxxxxx>
<mailto:marek.hajduczenia@xxxxxx>
*To: *
<STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Thank you David,
For those interested in more details, please look at the presentation on
.3bf given already to this TF in March 2012 (link:
http://grouper.ieee.org/groups/802/3/epoc/public/mar12/hajduczenia_01_0312.p
df). Note the persistent lack of the word "time stamp" in this document as
well as in 802.3-2012, Clause 90. We do not do any time stamping in 802.3bf.
Marek
-----Original Message-----
From: Law, David [mailto:dlaw@xxxxxx]
Sent: Tuesday, January 08, 2013 23:14
To:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx <mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-3-EPOC] [802.3_EPOC] Synchronization Eval Criteria
for EPoC - Presentation for Jan. 8 Eval Criteria Ad Hoc Call
Hi Marek,
I believe that your description of the operation IEEE Std 802.3bf-2011 -
which now can be found in Clause 90 'Ethernet support for time
synchronization protocols' of IEEE Std 802.3-2012 - is entirely correct. As
stated in subclause 90.2 'Overview', 'The goal of this clause is to provide
an accurate indication of the transmission and reception initiation times of
all packets, as required to support various time synchronization protocols,
e.g., IEEE Std 1588-2008, and IEEE Std 802.1AS.'.
As stated in subclause IEEE Std 802.3-2012 subclause 90.7 'Data delay
measurement', 'The transmit path data delay is measured from the input of
the beginning of the SFD at the xMII to its presentation by the PHY to the
MDI. The receive path data delay is measured from the input of the beginning
of the SFD at the MDI to its presentation by the PHY to the xMII.'.
PHY registers provided maximum transmit path data delay, minimum transmit
path data delay, maximum receive path data delay and minimum receive path
data delay (for example see IEEE Std 802.3-2012 subclauses 45.2.1.104
through 45.2.1.106) which allow the calculation of the transmit and receive
path data delay variation. The critical value is this delay variation - not
the absolute delays. The greater the variation - these lower the accuracy of
the time synchronization.
Any proposal - such as the proposals we were talking about on today's call -
will have to be evaluated in respect to transmit and receive path data delay
variation to determine the accuracy of the time synchronization it will
provide.
Best regards,
David
-----
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxx]
Sent: 08 January 2013 22:05
To:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx <mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-3-EPOC] [802.3_EPOC] Synchronization Eval Criteria
for EPoC - Presentation for Jan. 8 Eval Criteria Ad Hoc Call
Bill,
If I recall correctly, 802.3bf does not deal with time stamping, especially
not with MPCP time stamping. All it does it provides indication of passage
of packets through the xMII, which can be then correlated with transmission
of selected packets across PHY. That combined with information on PHY delay
stored in 802.3bf registers provides enough information to calculate precise
residence time for the station.
So, I am confused what is really meant by "using a timestamping mechanism
for MPCP packets over EPoC similar to the method described in both 802.3bf
and 802.1as Clause 13". I think there is some misunderstanding as to what
802.3bf provides and misconception that it is a specification competitive to
802.1as (which it is not, it complements 802.1as as much as 1588v2).
Marek
From: Bill Powell [mailto:bill.powell@xxxxxxxxxxxxxxxxxx]
Sent: Tuesday, January 08, 2013 21:40
To: Marek Hajduczenia
Cc:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx <mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: Re: [802.3_EPOC] Synchronization Eval Criteria for EPoC -
Presentation for Jan. 8 Eval Criteria Ad Hoc Call
Marek,
Thanks for the review and comments. I agree, we have not proven yet that we
can meet this criteria, especially the time transfer error criteria on slide
17. However, due to industry requirements for MBH, and competing
technologies (GPON) that can provide even lower time transfer error
performance, I think we need to be aiming at architecting EPoC to try to
meet the goals in this presentation. Having a goal in this area will help
us when we start comparing potential implementations.
Note that on Slide 17 the time transfer error performance is labeled as
tentative, which in my mind would depend on physical limitations of what we
do in the MAC<->PHY layer for EPoC.
I agree that we will need to use a timestamping method for MPCP packets
described in 802.3bf. I discussed the differences between 802.3bf and
802.1as (the protocol for MPCP counter synchronization between the EPON OLT
and EPON ONU) with Geoff Garner at our last meeting in San Antonio. Geoff
mentioned that the timestamping method in 802.1as Clause 13 was essentially
similar to the MPCP timestamping criteria in 802.3bf, and the reason that
802.1as did not refer to 802.3bf directly is that 802.3bf was not completed
when 802.1as was balloted.
So, the intent here is to propose using a timestamping mechanism for MPCP
packets over EPoC similar to the method described in both 802.3bf and
802.1as Clause 13. I intentionally left off this level of
802.1as-vs-802.3bf detail in this presentation, as I thought it would not be
beneficial to the overall goal of:
(1) presenting a system level analysis relative to current MBH and CES
timing requirements, and
(2) propose specific Eval criteria for EPoC to support these requirements.
Regards,
Bill
-------- Original Message --------
Subject:
RE: [802.3_EPOC] Synchronization Eval Criteria for EPoC - Presentation for
Jan. 8 Eval Criteria Ad Hoc Call
Date:
Tue, 8 Jan 2013 21:13:46 +0000
From:
Marek Hajduczenia<marek.hajduczenia@xxxxxx> <mailto:marek.hajduczenia@xxxxxx>
To:
'Bill Powell'<bill.powell@xxxxxxxxxxxxxxxxxx> <mailto:bill.powell@xxxxxxxxxxxxxxxxxx>,
<STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx> <mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Bill,
My two cents on that would be simple - a valuable contribution, but adopting
such requirements without even knowing if they are achievable, is at least
premature. We do not have any working models that would allow to estimate
whether such stringent requirements are achievable.
Furthermore, despite multiple indications from my side, the support for IEEE
Std 802.3bf is being still ignored. Without it, I do not know how you can
even think of getting to the level of precision you're suggesting. The delay
through each layer in the EPoC PHY needs to be known if we can ever hope to
get 1588v2 to the precision level you're showing.
Regards
Marek
-----Original Message-----
From: Bill Powell [mailto:bill.powell@xxxxxxxxxxxxxxxxxx]
Sent: Tuesday, January 08, 2013 20:30
To:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx <mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: [802.3_EPOC] Synchronization Eval Criteria for EPoC - Presentation
for Jan. 8 Eval Criteria Ad Hoc Call
Hello All,
I've attached a presentation that I plan to present during the Eval Criteria
ad hoc call tomorrow (Jan. 9). Some of you may have seen most of this
presentation in a different forum, but I'm bringing this into 802.3bn
through the Eval criteria Ad Hoc for further discussion, with a recommended
performance limit for time and frequency transfer error over the EPoC link
on Slide 17 (new slide).
If the group thinks that it would be useful to present to the whole 802.3bn
group, I can also submit it for presentation for the upcoming Phoenix or a
future 802.3bn meeting.
Regards,
Bill
--
Bill Powell
Alcatel-Lucent
Fixed Access Systems Engineering
2301 Sugar Bush Road
Raleigh, NC 27612
bill.powell@xxxxxxxxxxxxxxxxxx <mailto:bill.powell@xxxxxxxxxxxxxxxxxx>
(O) 919-850-6462
(Cell) 919-614-3225
________________________________________________________________________
To unsubscribe from the STDS-802-3-EPOC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPOC&A=1 <https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPOC&A=1>
________________________________________
<="" p="">
________________________________________________________________________
To unsubscribe from the STDS-802-3-EPOC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPOC&A=1 <https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPOC&A=1>
________________________________________________________________________
To unsubscribe from the STDS-802-3-EPOC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPOC&A=1 <https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPOC&A=1>
------------------------------------------------------------------------
________________________________________________________________________
To unsubscribe from the STDS-802-3-EPOC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPOC&A=1