Kevin,
Regarding 3. this is what I think we agreed during the meeting:
Where 0 <= q <= p < 32
- Jouni
From: Bross, Kevin [mailto:kevin.bross@xxxxxxxxx]
Sent: Thursday, November 05, 2015 6:07 PM
To: Jouni Korhonen; 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
===================================================================
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