I think there will have to be some amount of traffic engineering for the networks used for RoE. If we start with the initial encapsulation of CPRI:
·
There is no opportunity to retry dropped packets.
o
The RoE traffic must have guaranteed bandwidth (they’ll keep using it constantly) and the network must not drop RoE packets
o
It may be good practice to reserve a little extra headroom with RoE to handle some management packet overhead
·
As Peter indicated in his foils at our first meeting, there are some benefits to doing egress buffering
o
I’m not sure why/if packets would get re-ordered on a well-engineered network, but this egress buffering should hide the effect of any such re-ordering, provided
that the re-ordered packet still arrives inside of the egress buffer window
o
Packet sequence numbers would greatly aid in ensuring packets egress in the proper order (re-ordered packets can be properly ordered prior to egress)
o
If needed, timestamps can be reconstructed from packet sequence numbers (assuming a constant bit rate from CPRI) and baseline correlations of one sequence number
to a given timestamp
--kb
From: Lars Ellegaard [mailto:le@xxxxxxxxxxx]
Sent: Friday, February 27, 2015 5:00 AM
To: Matsushima Satoru; Jouni Korhonen
Cc: Steinar Bjørnstad; AshwoodsmithPeter; Bross, Kevin; Raz Gabe; STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
Subject: RE: RoE header and mapper thoughts: sequence numbering..
Under stable conditions Ethernet switches/networks are not allowed to reorder packets.
It can occur in transient situations though
From:
stds-1904-3-tf@xxxxxxxx [mailto:stds-1904-3-tf@xxxxxxxx]
On Behalf Of Matsushima Satoru
Sent: 27 February 2015 09:27
To: Jouni Korhonen
Cc: Steinar Bjørnstad; AshwoodsmithPeter; Bross, Kevin; Raz Gabe;
STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
Subject: Re: RoE header and mapper thoughts: sequence numbering..
I would imagine that when RoE packets are reordered caused by switches. I suppose BBU/RRH need to detect when it happened.
I suppose that current CPRI can't be tolerable because there's no packetalization now. So I think that RoE spec need to take into account at least in the case of reorder detection.
Packet order assurance might be too much.
On Tue, Feb 24, 2015 at 4:45 PM, Jouni Korhonen <jouni.korhonen@xxxxxxxxxxxx> wrote:
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
|