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