I believe both Jouni’s and Liquan’s requests are valid. But, I think they should be specified by a structure-aware frame format
and we should leave the structure-agnostic frames completely structure-agnostic.
・
For 8B/10B or 64B/66B encoded CPRI frames, it may not be possible to start a new Ethernet frame on the desired 10B or 66B
encoded character. In fact, it may not even be possible to guarantee how that character is aligned to the Ethernet bytes. So, a simple 1-bit indicator in the frame header may not be sufficient to identify the start of a CPRI hyperframe.
・
In the other email stream on this topic, it was revealed that 8B/10B and 64B/66B encoding may need to be undone before
mapping into Ethernet (depending on the CPRI rate and the Ethernet rate). With this, the inband CPRI hyperframe marker is lost and, thus, must be indicated by a header byte. However, this simple mechanism for CPRI may not be sufficient for other radio data
structures.
・
For the start/end of upper-layer data package indicators, we should devise a mechanism that is forward compatible with
future radio data structures. Since we do not know what the future brings, the only way to do this is to leave it to an upper-layers structure-aware mechanism, which will be defined later for that particular structure.
Rich
From: stds-1904-3-tf@xxxxxxxx [mailto:stds-1904-3-tf@xxxxxxxx]
On Behalf Of Jouni Korhonen
Sent: Monday, May 11, 2015 9:14 AM
To: yuan.liquan@xxxxxxxxxx
Cc: stds-1904-3-tf@xxxxxxxx
Subject: RE: RE: structure agnostic transport and a start of a frame
Hi Liquan,
Okay.. defining full blown fragmentation support into RoE was not what I had in mind originally. If people see need for it, then we probably need to do it.
Following on that path we most likely also need to able to indicate that the RoE has “no idea of upper layer framing”. So with “start, mid and end frame” information that would fit into two bits field.
- Jouni
Hi Jouni,
Assuming upper layer data(like CPRI super frame), the size of package is larger than RoE package, the upper layer data will map to several RoE frames, so we need to know which is the start of package(SoP),
the reciever may has no information how many RoE frames are needed for one upper layer data package, then the end of package(EoP) is needed, if the bits of EoP/SoP is false, the this frame is normal.
This kind of idea is used by other mapper map a varied upper layer package to lower layer frames, for example, in DSL bonding system. we can consider whether this idea is used for RoE mapper.
BR.
Liquan, ZTE Corp.
发件人:
Jouni Korhonen <jouni.korhonen@xxxxxxxxxxxx>
收件人:
"yuan.liquan@xxxxxxxxxx" <yuan.liquan@xxxxxxxxxx>,
抄送: "stds-1904-3-tf@xxxxxxxx"
<stds-1904-3-tf@xxxxxxxx>, "STDS-1904-3-TF@xxxxxxxxxxxxxxxxx" <STDS-1904-3-TF@xxxxxxxxxxxxxxxxx>
日期:
2015/05/09 04:12
主题: RE: structure agnostic transport and
a start of a frame
发件人: stds-1904-3-tf@xxxxxxxx
Hi,
How would an “end marker” help here in that case? Or are you suggesting that we should be able to figure out “first fragment”, “normal fragment” and the “last fragment” of the structure
agnostic payload? Because that is what you essentially get with separate start & end flags..
- jouni
From:
yuan.liquan@xxxxxxxxxx [mailto:yuan.liquan@xxxxxxxxxx]
Sent: Wednesday, May 06, 2015 6:08 PM
To: Jouni Korhonen
Cc: stds-1904-3-tf@xxxxxxxx;
STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
Subject: 答复: structure agnostic transport and a start of a frame
Jouni,
There may be some varied types of upper layer data carried over RoE frame, so the size is also varied, which RoE frame is the first part of upper layer data package and which RoE frame is the end of upper layer data package should be indicated, then 1 more
bit may be needed.
BR.
Liquan
ZTE CORP.
发件人:
Jouni Korhonen <jouni.korhonen@xxxxxxxxxxxx>
收件人:
"STDS-1904-3-TF@xxxxxxxxxxxxxxxxx"
<STDS-1904-3-TF@xxxxxxxxxxxxxxxxx>,
日期:
2015/05/07 00:41
主题: structure agnostic transport
and a start of a frame
发件人: stds-1904-3-tf@xxxxxxxx
Folks,
Kevin brought up an interesting point a while back. If we want a truly structure agnostic transport mode be supported that would imply just a stream of bits. For example, in a case of CPRI we would not even touch 8B/10B or 64B/66B coding to preserve e.g. K-characters
etc. I am fine with this (with some pain). However, it could be beneficial to indicate the start of a frame in the RoE header (1 bit flag). The assumption I have is that all data streams to be carried over RoE in structure agnostic mode still have some kind
of framing. As an example we could indicate the start of each hyper frame in a case of CPRI.
The same flag would also serve structure aware modes & native RoE flows. Just to indicate when some packet is a start of a radio frame or other framing..
This is a small optimization that may or may not be worth it.. Comments/thoughts?
- Jouni
--
Jouni Korhonen, CTO Office, Networking, Broadcom Corporation
O: +1-408-922-8135, M: +1-408-391-7160