Re: [tcpdump-workers] Request for link-layer header type (XRA)

[Guy Harris]

On Jan 31, 2018, at 6:07 AM, Bruno Verstuyft  wrote:

> can I already commit the dissector code for the XRA header to wireshark, or
> is it best to wait for finalization of the spec details?

At this point, I don't have any further questions; are there any more changes 
you intend to make to the specification?
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] Request for link-layer header type (XRA)

[Bruno Verstuyft]

2018-01-19 23:21 GMT+01:00 Guy Harris :

> On Jan 19, 2018, at 5:03 AM, Bruno Verstuyft 
> wrote:
>
> > 2018-01-19 10:10 GMT+01:00 Guy Harris :
> >
> >> Is the Burst ID just a sequence of octets?
> >
> > For the moment, the Burst ID  is a uint64_t. Should this not be not
> enough
> > in future implementations, it can be increased to e.g. uint128_t
>
> So it should be treated as an opaque array of bytes, with no significance
> to the values of the bytes, and used only for matching bursts and the MAC
> frames contained within them by comparing the byte arrays for equality?
>

Yes, this is correct.


>
> >> What does the Burst ID Reference field contain?  Another burst ID?
> >
> > The Burst ID reference is the same as the Burst ID. Burst IDs are used in
> > databursts, while Burst ID references are used in Mac Frames. For the
> > moment, these are both uint64_t.
>
> I.e., one or more MAC frames can be transmitted in a burst, and a capture
> can contain a record for a burst as well as records for the MAC frames
> within the burst, with the record for the burst having a Burst ID
> parameter, and all the records for the MAC frames in that burst have a
> Burst ID Reference parameter containing the burst ID value for the burst in
> which it appeared?
>

This is also correct.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] Request for link-layer header type (XRA)

[Guy Harris]

On Jan 19, 2018, at 5:03 AM, Bruno Verstuyft  wrote:

> 2018-01-19 10:10 GMT+01:00 Guy Harris :
> 
>> Is the Burst ID just a sequence of octets?
> 
> For the moment, the Burst ID  is a uint64_t. Should this not be not enough
> in future implementations, it can be increased to e.g. uint128_t

So it should be treated as an opaque array of bytes, with no significance to 
the values of the bytes, and used only for matching bursts and the MAC frames 
contained within them by comparing the byte arrays for equality?

>> What does the Burst ID Reference field contain?  Another burst ID?
> 
> The Burst ID reference is the same as the Burst ID. Burst IDs are used in
> databursts, while Burst ID references are used in Mac Frames. For the
> moment, these are both uint64_t.

I.e., one or more MAC frames can be transmitted in a burst, and a capture can 
contain a record for a burst as well as records for the MAC frames within the 
burst, with the record for the burst having a Burst ID parameter, and all the 
records for the MAC frames in that burst have a Burst ID Reference parameter 
containing the burst ID value for the burst in which it appeared?
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] Request for link-layer header type (XRA)

[Bruno Verstuyft]

2018-01-19 10:10 GMT+01:00 Guy Harris :

> On Jan 4, 2018, at 5:47 AM, Bruno Verstuyft 
> wrote:
>
> > are any more clarifications needed for the XRA header spec?
>
> How is the Symbol ID used for timing calculations?
>

DOCSIS 3.1 PLC (PHY Link Channel) frames in the downstream contain an
absolute timestamp. For every packet in the downstream, the difference in
symbols between the previous PLC frame and the packet is calculated. With
the help of parameters from the OCD (discrete fourier transform size and
cyclic prefix), this difference in symbols can be converted in a difference
in nanoseconds. This time difference is then added to the absolute
timestamp of the previous PLC frame, which yields the absolute timestamp of
the packet. This timestamp is stored in the timestamp of the pcap packet
header. For debugging reasons, the symbol id TLV can also be added to the
packet.


>
> Is the Burst ID just a sequence of octets?
>

 For the moment, the Burst ID  is a uint64_t. Should this not be not enough
in future implementations, it can be increased to e.g. uint128_t


> What does the Burst ID Reference field contain?  Another burst ID?


The Burst ID reference is the same as the Burst ID. Burst IDs are used in
databursts, while Burst ID references are used in Mac Frames. For the
moment, these are both uint64_t.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] Request for link-layer header type (XRA)

[Guy Harris]

On Jan 4, 2018, at 5:47 AM, Bruno Verstuyft  wrote:

> are any more clarifications needed for the XRA header spec?

How is the Symbol ID used for timing calculations?

Is the Burst ID just a sequence of octets?

What does the Burst ID Reference field contain?  Another burst ID?
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] Request for link-layer header type (XRA)

[Bruno Verstuyft]

Hi,

are any more clarifications needed for the XRA header spec?

Best regards,

Bruno

2017-12-12 11:17 GMT+01:00 Bruno Verstuyft :

>
>
> 2017-12-11 22:31 GMT+01:00 Guy Harris :
>
>> On Dec 5, 2017, at 4:47 AM, Bruno Verstuyft 
>> wrote:
>>
>> > 2017-12-04 22:21 GMT+01:00 Guy Harris :
>> >
>> >> On Nov 16, 2017, at 1:21 AM, Bruno Verstuyft <
>> bruno.verstu...@gmail.com>
>> >> wrote:
>> >>
>> >>> we put the specification of the XRA header online.
>> >>
>> >> The MAC document speaks of "logical" upstream and downstream channels;
>> are
>> >> those what the "Downstream Channel ID" and "Upstream Channel ID" TLVs
>> refer
>> >> to?
>> >>
>> > Yes, from the MULPI spec:
>> > Logical (Upstream) Channel: A MAC entity identified by a unique channel
>> ID
>> > and for which bandwidth is allocated by an
>> > associated MAP message. A physical upstream channel may support multiple
>> > logical upstream
>> > channels. The associated UCD and MAP messages completely describe the
>> > logical channel.
>>
>> You might want to say "ID of downstream *logical* channel" in the remarks
>> for "Downstream Channel ID"; the remarks for "Upstream Channel ID" already
>> say "logical upstream channel" (is it best to say "logical XXX channel" or
>> "XXX logical channel"?).
>>
>
> In the DOCSIS specs, there is no occurence of the term downstream logical
> channel, since there are only physical downstream channels.
> In the upstream, a physical upstream channel (channel around a center
> frequency) can be divided into multiple logical channels. This division is
> time based.
> More information can be found  in 5.2.1.1.3.1 "Downstream Data Forwarding
> in a MAC Domain" and 5.2.1.1.3.2 " Upstream Data Forwarding in a MAC
> Domain" in the DOCSIS MULPI spec.
>
> It is best to say logical upstream channel, since this is the term used in
> the DOCSIS specs.
>
>
>
>>
>> >> To what do the start and stop minislots in the "Minislot ID" TLV refer?
>> >
>> > These are the minislots, relative in an OFDMA frame. The minislot with
>> the
>> > lowest subcarriers has id 0.
>>
>> So those are the minislots from section 7.4.1 "Signal Processing
>> Requirements" of the PHY specification?
>>
>
> Yes, updated in the Xra Header spec.
>
>>
>> >> What do the "Symbol ID", "Burst ID", and "Subplot ID" TLVs contain?
>> >
>> > Symbol ID is a number assigned to each symbol by our hardware. This is
>> > mainly used for timing calculations. It can also be used to visualize
>> the
>> > correlation between NCP (Next Codeword Pointers) and the corresponding
>> > downstream data packets.
>>
>> So to which symbol in the packet does that refer?
>>
>
> The first symbol of the packet. Updated in the spec.
>
>>
>> > Burst ID is used to map mac frames to the corresponding databurst. A
>> > databurst can e.g. contain a segment:(see MULPI 7.2.4
>> > Continuous Concatenation and Fragmentation). This means a segment can
>> > contain multiple Mac frames, or a Mac frame can be spread over multiple
>> > segments. In our sniffer, we extract these Mac frames from the
>> segments. To
>> > save the information of which Mac frame belongs to which segment (or
>> > multiple segments), we use the Burst ID: each data burst gets a unique
>> > Burst ID. In the Mac Frame the "Burst Info"/"Burst ID reference" is
>> used to
>> > reference these Burst IDs.
>>
>> So your sniffer assigns the Burst IDs?
>>
>> There's a variable-length "Burst ID" field and a "Burst ID Reference"
>> field.  Does the "Burst ID" field contain a single burst ID?  If so, to
>> which burst was that ID assigned?  And what does the "Burst ID Reference"
>> field contain?
>>
>> Added extra explanation in the spec.
>
>
>> >> Does the SID TLV contain the Service Identifier for the service flow in
>> >> which the packet was sent?
>> >
>> > Yes
>>
>> You might want to spell out "Service Identifier" in the remarks.
>>
>
> Updated in spec.
>
>
>>
>> >> Does the IUC TLV contain the Interval Usage Code for the burst if the
>> >> packet is a burst?
>> >
>> > Yes
>>
>
> You might want to spell out "Interval Usage Code" in the remarks.
>>
>>
> Updated in spec
>
>
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] Request for link-layer header type (XRA)

[Bruno Verstuyft]

2017-12-11 22:31 GMT+01:00 Guy Harris :

> On Dec 5, 2017, at 4:47 AM, Bruno Verstuyft 
> wrote:
>
> > 2017-12-04 22:21 GMT+01:00 Guy Harris :
> >
> >> On Nov 16, 2017, at 1:21 AM, Bruno Verstuyft  >
> >> wrote:
> >>
> >>> we put the specification of the XRA header online.
> >>
> >> The MAC document speaks of "logical" upstream and downstream channels;
> are
> >> those what the "Downstream Channel ID" and "Upstream Channel ID" TLVs
> refer
> >> to?
> >>
> > Yes, from the MULPI spec:
> > Logical (Upstream) Channel: A MAC entity identified by a unique channel
> ID
> > and for which bandwidth is allocated by an
> > associated MAP message. A physical upstream channel may support multiple
> > logical upstream
> > channels. The associated UCD and MAP messages completely describe the
> > logical channel.
>
> You might want to say "ID of downstream *logical* channel" in the remarks
> for "Downstream Channel ID"; the remarks for "Upstream Channel ID" already
> say "logical upstream channel" (is it best to say "logical XXX channel" or
> "XXX logical channel"?).
>

In the DOCSIS specs, there is no occurence of the term downstream logical
channel, since there are only physical downstream channels.
In the upstream, a physical upstream channel (channel around a center
frequency) can be divided into multiple logical channels. This division is
time based.
More information can be found  in 5.2.1.1.3.1 "Downstream Data Forwarding
in a MAC Domain" and 5.2.1.1.3.2 " Upstream Data Forwarding in a MAC
Domain" in the DOCSIS MULPI spec.

It is best to say logical upstream channel, since this is the term used in
the DOCSIS specs.



>
> >> To what do the start and stop minislots in the "Minislot ID" TLV refer?
> >
> > These are the minislots, relative in an OFDMA frame. The minislot with
> the
> > lowest subcarriers has id 0.
>
> So those are the minislots from section 7.4.1 "Signal Processing
> Requirements" of the PHY specification?
>

Yes, updated in the Xra Header spec.

>
> >> What do the "Symbol ID", "Burst ID", and "Subplot ID" TLVs contain?
> >
> > Symbol ID is a number assigned to each symbol by our hardware. This is
> > mainly used for timing calculations. It can also be used to visualize the
> > correlation between NCP (Next Codeword Pointers) and the corresponding
> > downstream data packets.
>
> So to which symbol in the packet does that refer?
>

The first symbol of the packet. Updated in the spec.

>
> > Burst ID is used to map mac frames to the corresponding databurst. A
> > databurst can e.g. contain a segment:(see MULPI 7.2.4
> > Continuous Concatenation and Fragmentation). This means a segment can
> > contain multiple Mac frames, or a Mac frame can be spread over multiple
> > segments. In our sniffer, we extract these Mac frames from the segments.
> To
> > save the information of which Mac frame belongs to which segment (or
> > multiple segments), we use the Burst ID: each data burst gets a unique
> > Burst ID. In the Mac Frame the "Burst Info"/"Burst ID reference" is used
> to
> > reference these Burst IDs.
>
> So your sniffer assigns the Burst IDs?
>
> There's a variable-length "Burst ID" field and a "Burst ID Reference"
> field.  Does the "Burst ID" field contain a single burst ID?  If so, to
> which burst was that ID assigned?  And what does the "Burst ID Reference"
> field contain?
>
> Added extra explanation in the spec.


> >> Does the SID TLV contain the Service Identifier for the service flow in
> >> which the packet was sent?
> >
> > Yes
>
> You might want to spell out "Service Identifier" in the remarks.
>

Updated in spec.


>
> >> Does the IUC TLV contain the Interval Usage Code for the burst if the
> >> packet is a burst?
> >
> > Yes
>

You might want to spell out "Interval Usage Code" in the remarks.
>
>
Updated in spec
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] Request for link-layer header type (XRA)

[Guy Harris]

On Dec 5, 2017, at 4:47 AM, Bruno Verstuyft  wrote:

> 2017-12-04 22:21 GMT+01:00 Guy Harris :
> 
>> On Nov 16, 2017, at 1:21 AM, Bruno Verstuyft 
>> wrote:
>> 
>>> we put the specification of the XRA header online.
>> 
>> The MAC document speaks of "logical" upstream and downstream channels; are
>> those what the "Downstream Channel ID" and "Upstream Channel ID" TLVs refer
>> to?
>> 
> Yes, from the MULPI spec:
> Logical (Upstream) Channel: A MAC entity identified by a unique channel ID
> and for which bandwidth is allocated by an
> associated MAP message. A physical upstream channel may support multiple
> logical upstream
> channels. The associated UCD and MAP messages completely describe the
> logical channel.

You might want to say "ID of downstream *logical* channel" in the remarks for 
"Downstream Channel ID"; the remarks for "Upstream Channel ID" already say 
"logical upstream channel" (is it best to say "logical XXX channel" or "XXX 
logical channel"?).

>> To what do the start and stop minislots in the "Minislot ID" TLV refer?
> 
> These are the minislots, relative in an OFDMA frame. The minislot with the
> lowest subcarriers has id 0.

So those are the minislots from section 7.4.1 "Signal Processing Requirements" 
of the PHY specification?

>> What do the "Symbol ID", "Burst ID", and "Subplot ID" TLVs contain?
> 
> Symbol ID is a number assigned to each symbol by our hardware. This is
> mainly used for timing calculations. It can also be used to visualize the
> correlation between NCP (Next Codeword Pointers) and the corresponding
> downstream data packets.

So to which symbol in the packet does that refer?

> Burst ID is used to map mac frames to the corresponding databurst. A
> databurst can e.g. contain a segment:(see MULPI 7.2.4
> Continuous Concatenation and Fragmentation). This means a segment can
> contain multiple Mac frames, or a Mac frame can be spread over multiple
> segments. In our sniffer, we extract these Mac frames from the segments. To
> save the information of which Mac frame belongs to which segment (or
> multiple segments), we use the Burst ID: each data burst gets a unique
> Burst ID. In the Mac Frame the "Burst Info"/"Burst ID reference" is used to
> reference these Burst IDs.

So your sniffer assigns the Burst IDs?

There's a variable-length "Burst ID" field and a "Burst ID Reference" field.  
Does the "Burst ID" field contain a single burst ID?  If so, to which burst was 
that ID assigned?  And what does the "Burst ID Reference" field contain?

>> Does the SID TLV contain the Service Identifier for the service flow in
>> which the packet was sent?
> 
> Yes

You might want to spell out "Service Identifier" in the remarks.

>> Does the IUC TLV contain the Interval Usage Code for the burst if the
>> packet is a burst?
> 
> Yes

You might want to spell out "Interval Usage Code" in the remarks.

___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] Request for link-layer header type (XRA)

[Bruno Verstuyft]

Updated the specification with clarifications below.

2017-12-05 13:47 GMT+01:00 Bruno Verstuyft :

>
>
> 2017-12-04 22:21 GMT+01:00 Guy Harris :
>
>> On Nov 16, 2017, at 1:21 AM, Bruno Verstuyft 
>> wrote:
>>
>> > we put the specification of the XRA header online.
>>
>> The MAC document speaks of "logical" upstream and downstream channels;
>> are those what the "Downstream Channel ID" and "Upstream Channel ID" TLVs
>> refer to?
>>
> Yes, from the MULPI spec:
> Logical (Upstream) Channel: A MAC entity identified by a unique channel ID
> and for which bandwidth is allocated by an
> associated MAP message. A physical upstream channel may support multiple
> logical upstream
> channels. The associated UCD and MAP messages completely describe the
> logical channel.
>
> 5.2.1.1.3.1  Downstream Data Forwarding in a MAC Domain:
> A MAC Domain provides downstream DOCSIS data forwarding service using the
> set of downstream channels
> associated with the MAC Domain. Each downstream channel in a MAC Domain is
> assigned an 8-bit Downstream
> Channel ID (DCID).
>
>
>
>>
>> To what do the start and stop minislots in the "Minislot ID" TLV refer?
>>
>
> These are the minislots, relative in an OFDMA frame. The minislot with the
> lowest subcarriers has id 0.
>
>
>>
>> What do the "Symbol ID", "Burst ID", and "Subplot ID" TLVs contain?
>>
>
> Symbol ID is a number assigned to each symbol by our hardware. This is
> mainly used for timing calculations. It can also be used to visualize the
> correlation between NCP (Next Codeword Pointers) and the corresponding
> downstream data packets.
>
> Burst ID is used to map mac frames to the corresponding databurst. A
> databurst can e.g. contain a segment:(see MULPI 7.2.4
>  Continuous Concatenation and Fragmentation). This means a segment can
> contain multiple Mac frames, or a Mac frame can be spread over multiple
> segments. In our sniffer, we extract these Mac frames from the segments. To
> save the information of which Mac frame belongs to which segment (or
> multiple segments), we use the Burst ID: each data burst gets a unique
> Burst ID. In the Mac Frame the "Burst Info"/"Burst ID reference" is used to
> reference these Burst IDs.
>
> Subslot ID: A minislot can be divided into multiple subslots to provide
> multiple transmission opportunities for Bandwidth requests
> (see PHY 8.2.4.1  Subslot Structure). This is the ID of this subslot. The
> leftmost subslot has id 0.
>
>
>
>
>>
>> Does the SID TLV contain the Service Identifier for the service flow in
>> which the packet was sent?
>>
>
> Yes
>
>>
>> Does the IUC TLV contain the Interval Usage Code for the burst if the
>> packet is a burst?
>
>
> Yes
>
>
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] Request for link-layer header type (XRA)

[Bruno Verstuyft]

2017-12-04 22:21 GMT+01:00 Guy Harris :

> On Nov 16, 2017, at 1:21 AM, Bruno Verstuyft 
> wrote:
>
> > we put the specification of the XRA header online.
>
> The MAC document speaks of "logical" upstream and downstream channels; are
> those what the "Downstream Channel ID" and "Upstream Channel ID" TLVs refer
> to?
>
Yes, from the MULPI spec:
Logical (Upstream) Channel: A MAC entity identified by a unique channel ID
and for which bandwidth is allocated by an
associated MAP message. A physical upstream channel may support multiple
logical upstream
channels. The associated UCD and MAP messages completely describe the
logical channel.

5.2.1.1.3.1  Downstream Data Forwarding in a MAC Domain:
A MAC Domain provides downstream DOCSIS data forwarding service using the
set of downstream channels
associated with the MAC Domain. Each downstream channel in a MAC Domain is
assigned an 8-bit Downstream
Channel ID (DCID).



>
> To what do the start and stop minislots in the "Minislot ID" TLV refer?
>

These are the minislots, relative in an OFDMA frame. The minislot with the
lowest subcarriers has id 0.


>
> What do the "Symbol ID", "Burst ID", and "Subplot ID" TLVs contain?
>

Symbol ID is a number assigned to each symbol by our hardware. This is
mainly used for timing calculations. It can also be used to visualize the
correlation between NCP (Next Codeword Pointers) and the corresponding
downstream data packets.

Burst ID is used to map mac frames to the corresponding databurst. A
databurst can e.g. contain a segment:(see MULPI 7.2.4
 Continuous Concatenation and Fragmentation). This means a segment can
contain multiple Mac frames, or a Mac frame can be spread over multiple
segments. In our sniffer, we extract these Mac frames from the segments. To
save the information of which Mac frame belongs to which segment (or
multiple segments), we use the Burst ID: each data burst gets a unique
Burst ID. In the Mac Frame the "Burst Info"/"Burst ID reference" is used to
reference these Burst IDs.

Subslot ID: A minislot can be divided into multiple subslots to provide
multiple transmission opportunities for Bandwidth requests
(see PHY 8.2.4.1  Subslot Structure). This is the ID of this subslot. The
leftmost subslot has id 0.




>
> Does the SID TLV contain the Service Identifier for the service flow in
> which the packet was sent?
>

Yes

>
> Does the IUC TLV contain the Interval Usage Code for the burst if the
> packet is a burst?


Yes
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] Request for link-layer header type (XRA)

[Guy Harris]

On Nov 16, 2017, at 1:21 AM, Bruno Verstuyft  wrote:

> we put the specification of the XRA header online.

The MAC document speaks of "logical" upstream and downstream channels; are 
those what the "Downstream Channel ID" and "Upstream Channel ID" TLVs refer to?

To what do the start and stop minislots in the "Minislot ID" TLV refer?

What do the "Symbol ID", "Burst ID", and "Subplot ID" TLVs contain?

Does the SID TLV contain the Service Identifier for the service flow in which 
the packet was sent?

Does the IUC TLV contain the Interval Usage Code for the burst if the packet is 
a burst?
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] Request for link-layer header type (XRA)

[Bruno Verstuyft]

2017-12-01 18:25 GMT+01:00 Guy Harris :

> On Dec 1, 2017, at 3:34 AM, Bruno Verstuyft 
> wrote:
>
> >> Type 75 is still labeled as "ODMA REQ" rather than "OFDMA REQ".  Also,
> it
> >> says "ODMA REQ (75): as described by section 7.4.8 "REQ Messages" of the
> >> DOCSIS 3.1 Physical Layer Specification. This is the "REQ message in
> MAC"
> >> in figure 7-11 (56 bits).", but I don't see a figure numbered 7-11 in
> the
> >> DOCSIS 3.1 Physical Layer Specification (CM-SP-PHYv3.1-I12-171026) - is
> >> this from another version of that document?
> >
> > Apparently, the figure had number 7-11 in version I11 of the PHY spec,
> and
> > is figure number 14 in version I12 of the spec. I updated the number to
> 14,
> > to reflect the number in the more recent spec. I also added references to
> > the DOCSIS MULPI and PHY specification version numbers, to avoid
> confusion
> > in the future.
>
> Figure 14 shows how it's generated, but the surrounding text doesn't say
> what the content is; it just says "REQ messages are short messages used by
> the CM to request transmission opportunities from the CMTS. These messages
> have a different structure than the data messages: they are always 56 bits
> long, they always use QPSK modulation, do not apply any FEC and are block
> interleaved."
>
> What do the 56 bits in question contain?  Are they one of the -REQ
> messages described in the DOCSIS 3.1 MAC and Upper Layer Protocols
> Interface Specification, or are they something else?
>
> These are the Queue-depth Based Request Frames described in the MULPI
spec. Changed the reference from the section in the PHY spec to the section
in the MULPI spec.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] Request for link-layer header type (XRA)

[Bruno Verstuyft]

2017-12-01 5:09 GMT+01:00 Guy Harris :

> On Nov 29, 2017, at 5:57 AM, Bruno Verstuyft 
> wrote:
>
> > thanks for the remarks. The specification is now updated with more
> > clarifications
>
> So "Segment Header Present" is 1 if it's present and 0 if it's absent?
>

indeed. This is updated in the document.


> Type 75 is still labeled as "ODMA REQ" rather than "OFDMA REQ".  Also, it
> says "ODMA REQ (75): as described by section 7.4.8 "REQ Messages" of the
> DOCSIS 3.1 Physical Layer Specification. This is the "REQ message in MAC"
> in figure 7-11 (56 bits).", but I don't see a figure numbered 7-11 in the
> DOCSIS 3.1 Physical Layer Specification (CM-SP-PHYv3.1-I12-171026) - is
> this from another version of that document?


Apparently, the figure had number 7-11 in version I11 of the PHY spec, and
is figure number 14 in version I12 of the spec. I updated the number to 14,
to reflect the number in the more recent spec. I also added references to
the DOCSIS MULPI and PHY specification version numbers, to avoid confusion
in the future.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] Request for link-layer header type (XRA)

[Guy Harris]

On Nov 29, 2017, at 5:57 AM, Bruno Verstuyft  wrote:

> thanks for the remarks. The specification is now updated with more
> clarifications

So "Segment Header Present" is 1 if it's present and 0 if it's absent?

Type 75 is still labeled as "ODMA REQ" rather than "OFDMA REQ".  Also, it says 
"ODMA REQ (75): as described by section 7.4.8 "REQ Messages" of the DOCSIS 3.1 
Physical Layer Specification. This is the "REQ message in MAC" in figure 7-11 
(56 bits).", but I don't see a figure numbered 7-11 in the DOCSIS 3.1 Physical 
Layer Specification (CM-SP-PHYv3.1-I12-171026) - is this from another version 
of that document?
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] Request for link-layer header type (XRA)

[Bruno Verstuyft]

Hi,

thanks for the remarks. The specification is now updated with more
clarifications

Best Regards,

Bruno

2017-11-23 0:08 GMT+01:00 Guy Harris :

> On Nov 21, 2017, at 6:34 AM, Bruno Verstuyft 
> wrote:
>
> > we updated the XRA header specification with more clarifications.
>
> So:
>
> A "collection of NCP message blocks within a symbol" is a sequence of N-1
> 3-byte NCP Data Message Blocks followed by a 3-byte NCP CRC Message Block?
>
> A "PLC structure as described by section 6.5.1 "PLC Structure" of the
> DOCSIS 3.1 MAC and Upper Layer Protocols Interface Specification" is a
> sequence of message blocks defined in that section?
>
> In an A-TDMA Burst or an OFDMA Data Burst, what indicates whether it's a
> segment or a MAC frame?
>
> An OFDMA REQ (the spec has a typo, referring to it as an "ODMA REQ") is 7
> bytes of - something?
>
> An OFDMA Probing Sequence is a sequence of OFDMA symbols; how are those
> symbols represented?
>
> "BCH Decoding Successful" and "LDPC Decoding Successful" are Booleans,
> with 0 being "false" (unsuccessful) and 1 being "true" (successful)?
>
> What are the units of the Estimated Power Level?
>
> Is the Configuration Info just a text string intended to be read by humans?
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] Request for link-layer header type (XRA)

[Bruno Verstuyft]

Hi,

we updated the XRA header specification with more clarifications.

Best Regards,

Bruno

2017-11-16 22:30 GMT+01:00 Guy Harris :

> On Nov 16, 2017, at 1:21 AM, Bruno Verstuyft 
> wrote:
>
> > we put the specification of the XRA header online.
>
> It mentions tcpdump in the page header and Wireshark in the page body; it
> should probably just talk about pcap and pcapng, as the whole point of the
> pcap and pcapng specifications, and the list of link-layer header type
> specifications for pcap and pcapng, is to allow those file formats, and
> packets with particular link-layer header types, to be read and written by
> arbitrary software, developed by people who might never have read the
> libpcap, tcpdump, or Wireshark source code.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] Request for link-layer header type (XRA)

[Guy Harris]

On Nov 14, 2017, at 1:35 AM, Bruno Verstuyft  wrote:

> thanks a lot. Is there any other action needed from our side to be added to
> the online linktype list (http://www.tcpdump.org/linktypes.html)?

Other than completing the specification at

http://www.xra31.com/xra-header

there's nothing more you need to do.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] Request for link-layer header type (XRA)

[Michael Richardson]

Bruno Verstuyft  wrote:
> we are putting the last hand to the Xra header specification.  The
> specification will be put on http://www.xra31.com/xra-header when
> completed.

I meant to ACK that I added that link to comments.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[

___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers