Re: Request for link-layer header type (XRA)

[Bruno Verstuyft <bruno.verstuyft () gmail com>]

2017-12-11 22:31 GMT+01:00 Guy Harris <guy () alum mit edu>:

> On Dec 5, 2017, at 4:47 AM, Bruno Verstuyft <bruno.verstuyft () gmail com>
> wrote:
>
> > 2017-12-04 22:21 GMT+01:00 Guy Harris <guy () alum mit edu>:
> >
> > > On Nov 16, 2017, at 1:21 AM, Bruno Verstuyft <bruno.verstuyft () 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