Re: [tcpdump-workers] Link type proposal, IEEE 802.1Qbu Frame Preemption Protocol
Correct. I think that CRC(or mCRC for preemption) is also important and I would like to add it too. So finally we have: Preamble with SFD | Mac header | Payload | CRC/mCRC 2017-12-01 5:56 GMT+01:00 Guy Harris : > On Nov 30, 2017, at 2:27 AM, Anton Glukhov > wrote: > > > 1. You are right, I'm not subscribed there. I will fix this problem) > > OK, I'm moving the discussion to tcpdump-workers. > > > 2. I'd like to have completely separate LinkType number and this is not > LINKTYPE_ETHERNET, because preamble must be shown > > So for the new link-layer header type will the frame begin with metadata > indicating the frame type, followed by, preamble/SFD bytes, followed by the > MAC header, rather than beginning with the MAC header, without the preamble > and SFD bytes as LINKTYPE_ETHERNET frames do? > ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Link type proposal, IEEE 802.1Qbu Frame Preemption Protocol
You are right, “express" packet is exactly the same as “ordinary”. From my point of view it’s ok to show express traffic as part of preemption traffic, hence I’d like to see Express packets in favour of “ordinary” one. Anyway I guess If we choose specific link type for 802.1qbu & 802.1br it would be the “context” in which “ordinary” traffic is called “express” packets. > On 1 Dec 2017, at 23:08, Guy Harris wrote: > > On Dec 1, 2017, at 12:56 AM, Anton Glukhov wrote: > >> Correct. I think that CRC(or mCRC for preemption) is also important and I >> would like to add it too. So finally we have: >> Preamble with SFD | Mac header | Payload | CRC/mCRC > > OK, so I guess the idea is that the payload of this link type is what IEEE > 802.3br calls an "mPacket" as shown in Figure 99-4, always containing, in > order: > > either a 7-octet 0x55 preamble followed by a 1-octet 0xD5 SMD-E/SFD or > a 6-octet 0x55 preamble followed by another SMD value from Table 99-1 > followed by a FRAG_COUNT with a value from Table 99-2; > > the MDATA of the mPacket; > > the CRC field, containing either an FCS or an mCRC. > > If so, then the first of those contains the metadata necessary to determine > what type of mPacket this is. > > I also infer that if an "ordinary" Ethernet packet were encapsulated in this > fashion, it would look like an "express" packet, given that the SFD for > "ordinary" packets is 0xD5, which is the same value as an SMD-E, and that the > SFD for "ordinary" packets is preceded by 7 octets of 0x55 preamble. This > would mean, however, that "ordinary" traffic would look like "express" > traffic; would that be misleading? ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Link type proposal, IEEE 802.1Qbu Frame Preemption Protocol
Yes, absolutely. Thank you! > On 2 Dec 2017, at 18:56, Guy Harris wrote: > > On Dec 2, 2017, at 4:06 AM, Anton Glukhov wrote: > >> You are right, “express" packet is exactly the same as “ordinary”. From my >> point of view it’s ok to show express traffic as part of preemption traffic, >> hence I’d like to see Express packets in favour of “ordinary” one. Anyway I >> guess If we choose specific link type for 802.1qbu & 802.1br it would be the >> “context” in which “ordinary” traffic is called “express” packets. > > OK, so we'll have LINKTYPE_ETHERNET_MPACKET/DLT_ETHERNET_MPACKET, specified > as: > > mPackets, as specified by IEEE 802.3br Figure 99-4, starting with the > preamble and always ending with a CRC field > > Does that make sense? ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
