Hi,
For different antenna flows the flow_id should be used as the multiplexing information (assuming each antenna flow is really a different flow). For different payloads you need a pkt_type.. or
one RoE level pkt_type and your own L1 split specific subtypes within the format you need to defined for your payload.
- Jouni
From:
马世佳 [mailto:mashijia@xxxxxxxxxxxxxxx]
Sent: Tuesday, November 10, 2015 7:09 AM
To: 'Bross, Kevin'; 'Yasser Kilde Bajwa'; 'stds-1904-3-tf@xxxxxxxx'
Cc: Jouni Korhonen
Subject: 答复: hillsboro aftermath: timestamps/sequence numbers
Hi Kevin,Jouni,
I have another question. In our prototype, we split L1 functon. Then, there are several types data, include PRACH data and PUCCH data for uplink transmission , and others for downlink
transmission. Meanwhile, we have eight antennas data from RRH to BBU. So how can I identify these differnet type data?
For different antenna , should I use flow id ? and for different type payload ,should I use different pkt_type or the same pkt_type and different subtype to identify
?
马世佳
移动研究院千人计划创新基地3-绿色通信研究中心
地址：北京市西城区宣武门西大街32号中国移动创新大厦18层，100053
电话：010-15801696688-36058
Mobile:：13910391546
发件人:
stds-1904-3-tf@xxxxxxxx [mailto:stds-1904-3-tf@xxxxxxxx]
代表 马世佳
发送时间: 2015年11月10日 14:04
收件人: 'Bross, Kevin'; 'Yasser Kilde Bajwa'; 'stds-1904-3-tf@xxxxxxxx'
抄送: 'Jouni Korhonen'
主题: 答复: hillsboro aftermath: timestamps/sequence numbers
Thanks,
Acturally,there are two types of Ethernet header . One is IEEE802.3 header (which include dest mac ,src mac,length ,type ) ,the other is Ethernet II(which include dest mac, src mac, type ,there is
no length filed), which is showed as below,
And I use wireshark to capture network packets ,I find there is no length filed in Ethernet II . So I feel very confused.
马世佳
移动研究院千人计划创新基地3-绿色通信研究中心
地址：北京市西城区宣武门西大街32号中国移动创新大厦18层，100053
电话：010-15801696688-36058
Mobile:：13910391546
发件人:
stds-1904-3-tf@xxxxxxxx
[mailto:stds-1904-3-tf@xxxxxxxx]
代表 Bross, Kevin
发送时间: 2015年11月10日 13:32
收件人: mashijia@xxxxxxxxxxxxxxx;
'Yasser Kilde Bajwa'; 'stds-1904-3-tf@xxxxxxxx'
抄送: 'Jouni Korhonen'
主题: RE: hillsboro aftermath: timestamps/sequence numbers
1.
If we don’t define a new Ethertype, the length is shown in the standard 2-byte LEN field in the Ethernet header. The LEN value will be <=1500.
2.
If we do define a new Ethertype (LEN > 1500) to be used for RoE, then we should define a length field as part of the RoE header.
--kb
------------------------------------------------------------------
Kevin Bross
===================================================================
From:
马世佳 [mailto:mashijia@xxxxxxxxxxxxxxx]
Sent: Monday, November 09, 2015 9:00 PM
To: 'Yasser Kilde Bajwa'; 'stds-1904-3-tf@xxxxxxxx'
Cc: 'Jouni Korhonen'; Bross, Kevin
Subject: 答复: hillsboro aftermath: timestamps/sequence numbers
Hi Jouni and Kevin,
I have a question,that when I only use MAC header and ROE header , how can I get the packet length from header?
Thanks.
马世佳
移动研究院千人计划创新基地3-绿色通信研究中心
地址：北京市西城区宣武门西大街32号中国移动创新大厦18层，100053
电话：010-15801696688-36058
Mobile:：13910391546
发件人:
stds-1904-3-tf@xxxxxxxx
[mailto:stds-1904-3-tf@xxxxxxxx]
代表 Yasser Kilde Bajwa
发送时间: 2015年11月9日 14:04
收件人: stds-1904-3-tf@xxxxxxxx
抄送: Jouni Korhonen; kevin.bross@xxxxxxxxx
主题: RE: hillsboro aftermath: timestamps/sequence numbers
Hi Jouni and Kevin,
Apparently the reflector rejected my last mail so I try again with my signature removed completely.
Sounds great to remove the T flag.
I agree with the points brought up by Kevin except for the use of timestamp and sequence numbers only being based on packet type. I guess it’s really a question going back to how
we see the hierarchy of these 2 identifiers (Flow ID and packet type). We see Flow ID as the highest in this hierarchy with the different packet types as being right below that. Here we expected that the end points of that flow would either use timestamps
or sequence numbers which would be communicated out of band and be associated with the flow ID or possibly with a flow ID and packet type combination. If we associate it with the Packet type then we are essentially dedicating one bit in the header just for
this.
Regards,
Yasser
From:
stds-1904-3-tf@xxxxxxxx [mailto:stds-1904-3-tf@xxxxxxxx]
On Behalf Of Bross, Kevin
Sent: 6. november 2015 10:07
To: Jouni Korhonen <jouni.korhonen@xxxxxxxxxxxx>;
stds-1904-3-tf@xxxxxxxx
Subject: RE: hillsboro aftermath: timestamps/sequence numbers
Jouni,
Looks good. A few related thoughts:
1.
I think we should dump the extended header terminology entirely. Each pkt_type will determine the format of the payload.
2.
Should the use of timestamp or sequence be a function of pkt_type and flow_id, or should it be a function purely of pkt_type? [I think I would prefer the latter.]
3.
Does it make sense to break the timestamp/sequence into “Timestamp/sequence High Word” and “Timestamp/sequence Low Word”? This would still be a 32-bit composite field, but we could graphically show the position of the
high word and the low word in the packet layout diagrams like you show below.
Going with the logic that simpler is often better, I like how the header has simplified over the course of our discussions.
--kb
===================================================================
From:
stds-1904-3-tf@xxxxxxxx [mailto:stds-1904-3-tf@xxxxxxxx]
On Behalf Of Jouni Korhonen
Sent: Thursday, November 05, 2015 11:22 AM
To: stds-1904-3-tf@xxxxxxxx
Subject: hillsboro aftermath: timestamps/sequence numbers
Folks,
Coming back to discussion we had and kind of was let hanging on my next steps.. so the T-flag and alternating between sn/ts.. I am actually OK to go with what was proposed during the meeting and toss the T-flag.
If we need timestamps that can be decided per flow_id and packet type.
If folks agree with the above we would end up to a header as below:
So, everybody happy with this? I did collapse the extended_header_space and the payload into the same illustration, since they essentially are the same (subject to the packet type).
- Jouni
--
Jouni Korhonen, CTO Office, Networking, Broadcom Corporation
O: +1-408-922-8135, M: +1-408-391-7160
=== MICROELECTRONICS TECHNOLOGY INC. ===
This message (and any attachments) may contain information that is confidential, proprietary, privileged or otherwise protected by law. The message is intended solely for the named addressee (or a person responsible for delivering it to the addressee). If you
are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please destroy the message or delete it from your system immediately
and notify the sender.