Here is how I see it ( based on my current understanding of the various bits and pieces ):
Structure agnostic requires a sequence number so that in the event of loss a dummy frame can be inserted. Strucutre agnostic requires SynchEth (or other) to .002ppm frequency precision (time of day not required). The output frames have to be
generated at exactly their input frequency. Some amount of delay has to be artificially introduced to absorb jitter to ensure the output buffer always has packets to play out. early crude simulations indicate that say 500ns-1us is likely required and
that pre-emption is required to be supported on all intermediate switches to keep the jitter in these bounds (card to card fabric jitter will make this worse and was not simulated). An interesting issue is how to 'learn' the correct amount of buffering. You
want enough that new connections being added do not cause more buffer to be required.. i.e. has to be a worst case for the lifetime of the deployment so likely this has to be configured not learned. So here are two configured parameters already, output_rate
and buffer_size.
Structure aware is a totally different animal. If there is any kind of compression or variable rate then time stamping is required and in this case SynchEth is not sufficient and time of day synch to single digit ns is required i.e. 1588++.
Even small changes in transmit/receiver fiber lengths will effect the time synch and very precise one way measures of the fiber lengths will be required to get the proper clock offsets. I.e. 1/2 RTD won't cut it. Its possible even temperature changes will
effect the time offsets enough to be a concern and possibly have to be tracked and corrected [Google CERN "White Rabbit Project"] showing temperature causing 2ns delay difference. Of course complete out of band time synch is possible for example GPS can yield
+/- 10ns [Google "Common View GPS Time Transfer"] but GPS is not a good indoor solution for obvious reasons and we are trying to get away from it outdoor for expense and dependency reasons (it can be degraded at the push of a button).
Cheers,
Peter
________________________________________
From: Aleksandra Checko [amch@xxxxxxxxxxxxxx]
Sent: Tuesday, February 24, 2015 5:38 AM
To: Bross, Kevin; Jouni Korhonen; Steinar Bjørnstad; AshwoodsmithPeter
Cc: Raz Gabe; STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
Subject: RE: RoE header and mapper thoughts: sequence numbering..
Dear All,
As synchronization is seen as one of the main challenges for IQ over Ethernet transport I think it is important to identify possible synchronization solutions and make a room to accommodate them. It could be a flexible arrangement e.g. setting a flag whether
the header will include a timestamp.
Otherwise the protocol may need additional solutions to be used.
Best Regards,
Aleksandra Checko
Industrial PhD Student
Networks Technology and Service Platforms
DTU Fotonik
Technical University of Denmark
Department of Photonics Engineering
Mobile +45 50395225
________________________________________
From: stds-1904-3-tf@xxxxxxxx [stds-1904-3-tf@xxxxxxxx] on behalf of Bross, Kevin [kevin.bross@xxxxxxxxx]
Sent: 24 February 2015 14:21
To: Jouni Korhonen; Steinar Bjørnstad; AshwoodsmithPeter
Cc: Raz Gabe; STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
Subject: RE: RoE header and mapper thoughts: sequence numbering..
Jouni,
I would encourage us to separate the encapsulation method from the node synchronization requirement. If both sides are somehow time-synchronized to atomic time (TAI), then we can minimize the synchronization needs for the protocol.
There are many different ways of getting each end node synchronized to TAI, including GPS and 1588. I think we should identify the expectations for how synchronized each side is to TAI, but that should be external to this protocol.
--kb
===================================================================
-----Original Message-----
From: Jouni Korhonen [mailto:jouni.korhonen@xxxxxxxxxxxx]
Sent: Monday, February 23, 2015 11:46 PM
To: Steinar Bjørnstad; AshwoodsmithPeter
Cc: Bross, Kevin; Raz Gabe; STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
Subject: RE: RoE header and mapper thoughts: sequence numbering..
If your end points are already in "perfect" sync I do not think you need a timestamp for de-jitter - because you would send stuff in a TDM fashion anyway (at the end points). I can be convinced otherwise, though. On the other hand I could use timestamp for
other purposes like measuring the end-to-end link propagation delay. The issue with timestamps is the size.. a meaningful timestamp takes quite a few bits (32 bits at nsec accuracy overflows in ~4 secs etc).
- Jouni
> -----Original Message-----
> From: Steinar Bjørnstad [mailto:Steinar.Bjornstad@xxxxxxxxxxxxxxx]
> Sent: Monday, February 23, 2015 11:22 PM
> To: AshwoodsmithPeter
> Cc: Bross, Kevin; Raz Gabe; Jouni Korhonen; STDS-1904-3-
> TF@xxxxxxxxxxxxxxxxx
> Subject: Re: RoE header and mapper thoughts: sequence numbering..
>
> Hello,
> Probably both a sequence number and time-stamping is required.
> Time-stamping is required for de-jittering if there are cases where
> the data rate varies (e.g. compression).
> Sequence numbering is required for detecting packet loss (packets out
> of order can be found from the time-stamping). As far as I have
> understood, CPRI is highly dependent on a low bit error rate.
> Any comments?
>
> Best regards
>
> Steinar
>
>
> 23. feb. 2015 kl. 16:33 skrev AshwoodsmithPeter
> <Peter.AshwoodSmith@xxxxxxxxxx>:
>
> > If you know exact frame generation rate and frame sizes then yes you
> > can use
> frame sequence number and ultra precise synch ethernet to generate
> them at the exact same rate at the egress but if compression is
> varying then you need absolute time and a time stamp.
> >
> > Peter
> >
> > ________________________________________
> > From: Bross, Kevin [kevin.bross@xxxxxxxxx]
> > Sent: Monday, February 23, 2015 7:17 AM
> > To: AshwoodsmithPeter; Raz Gabe; Jouni Korhonen; STDS-1904-3-
> TF@xxxxxxxxxxxxxxxxx
> > Subject: RE: RoE header and mapper thoughts: sequence numbering..
> >
> > Alternatively, can a sequence number be a de-facto timestamp? If
> > both (all?)
> sides know how to correlate one sequence number to a timestamp, can
> subsequent timestamps at this deterministic rate serve as an entry
> from which the timestamp can be re-created?
> >
> > --kb
> >
> >
> =================================================================
> ==
> >
> >
> > -----Original Message-----
> > From: stds-1904-3-tf@xxxxxxxx [mailto:stds-1904-3-tf@xxxxxxxx] On
> > Behalf Of
> AshwoodsmithPeter
> > Sent: Monday, February 23, 2015 7:10 AM
> > To: Raz Gabe; Jouni Korhonen; STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
> > Subject: RE: RoE header and mapper thoughts: sequence numbering..
> >
> > Keep in mind that time stamping is going to be required to
> > de-jitter. So
> anything that can be done with a time-stamp should not be replicated
> by a sequence number.
> >
> > Peter
> >
> >
> >
> > ________________________________________
> > From: stds-1904-3-tf@xxxxxxxx [stds-1904-3-tf@xxxxxxxx] on behalf of
> > Raz
> Gabe [Raz.Gabe@xxxxxxxx]
> > Sent: Saturday, February 21, 2015 9:14 PM
> > To: Jouni Korhonen; STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
> > Subject: RE: RoE header and mapper thoughts: sequence numbering..
> >
> > HI Jouni,
> > A sequence number is one the things that is missing in L2 protocol
> > (which been
> exists in higher layers...), I think that it is needed here .
> > About its size, at that step, I think that 20bits are better than
> > 16bits, based on
> your below arguments.
> >
> > Rgrds
> > --Raz
> >
> > -----Original Message-----
> > From: stds-1904-3-tf@xxxxxxxx [mailto:stds-1904-3-tf@xxxxxxxx] On
> > Behalf Of
> Jouni Korhonen
> > Sent: Saturday, February 21, 2015 12:04 AM
> > To: STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
> > Subject: RoE header and mapper thoughts: sequence numbering..
> >
> > Folks,
> >
> > I have been thinking about the RoE header and a need for sequence
> > number in
> it. There would be two uses for it, at least initially. First, we need
> that in the mapper to regenerate the CPRI HFN and BFN fields. Second,
> it would allow us to detect possible lost packet. Maybe there could be a case as well for reordering?
> Anyway, in the RoE example I had I reserved 16 bits for the sequence
> number space. That is enough to number >10ms worth of CPRI BFs and HFs
> for the mapper purposes. However, 16 bits is not enough to explicitly
> transport CPRI HFN and BFN information (that's 20bits worth data).
> Anyway, generating those missing 4 bits is not imho a big deal.. we
> already do that routinely with ESP etc (64bits extended sequence
> number but only transport low order 32bits). Again I am assuming the
> sequence number space is unique between two endpoints (whether mechanism we use to determine endpoints).
> >
> > Any thoughts?
> >
> > - Jouni
> >
> > --
> > Jouni Korhonen, Ph.D, Associate Technical Director CTO Office,
> > Networking,
> Broadcom Corporation
> > O: +1-408-922-8135, M: +1-408-391-7160