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

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