| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi,
Let's
consider the case of a packet of data using IP over Ethernet protocols. As far
as I can tell, there are two possible interpretations of the 802.16-2004
standard. These are:
(a)
The service data unit (SDU) at the convergence sublayer SAP (CS SAP)
consists of Ethernet source address, destination address, type, and the IP
datagram. The convergence sublayer performs payload header suppression
(addressing fields both in the Ethernet headers and in the IP headers within the
IP datagram), and delivers an SDU to the MAC common part sublayer (MAC CPS). The
MAC CPS may assemble several SDUs (and fragments of SDUs) into one MAC PDU, and
may optionally protect the overall MAC PDU with an 802.16 MAC
CRC.
This
interpretation seems reasonable, and is in line with the definition of the
MA_DATA.request service primitive in 802.3. Note also that in 802.3, calculation
and checking of the FCS is clearly a responsibility of the 802.3 MAC
layer.
(b)
The service data unit at the CS SAP consists of Ethernet source address,
destination address, type, the IP datagram, and the Ethernet FCS calculated by
the higher-layer function (which is most likely a bridge or router). The
convergence sublayer performs payload header suppression (addressing fields in
the Ethernet headers and in the IP headers), treating the Ethernet FCS as
payload. I assume that the CS does not recalculate FCS following PHS. The
construction of the MAC PDU is then identical to case (a) above. At the
receiving system, the SDU at the CS SAP again consists of Ethernet source
address, destination address, type, the IP datagram, and FCS. Presumably the
higher-layer function must discard the Ethernet frame if the received FCS is
incorrect.
This
interpretation seems possible (because 802.16 is not specific on this point) but
unlikely given the distribution of functions between layers in other 802
standards. Also, the computation of the FCS may be excessively costly for some
systems with limited processing power.
It is
not possible for (a) and (b) to be true at the same time, and two systems based
on different conventions will not interwork. Isn't this something that we need
to agree on with some urgency?
Mark
From: Yerang Hur
[mailto:yehur@posdata-usa.com]
Sent: 26 December 2004 05:22 To: STDS-802-16@ieee.org Cc: Mark Thomas; yehur@posdata-usa.com Subject: RE: [STDS-802-16] Is the Ethernet CRC included in the MAC PDU? Dear Mark,
If there’s no convincing reason we
need to take the Ethernet CRC out from the Ethernet PDU, we may keep the
Ethernet CRC in the 16 payload. Regarding PHS, CS is in charge of
suppressing the payload header and rebuilding the suppressed payload header
information. The roles of CS should be transparent to computing the Ethernet
CRC. If individual Ethernet CRC checks
fail, responses will vary depending on what service flow is associated with the
connection. Yerang
Hur ------ E-mail:
-----Original
Message----- Mark Thomas
<mthomas@AIRSPAN.COM> wrote: Date: Thu, From: Mark Thomas
Subject: [STDS-802-16] Is the Ethernet CRC included in the MAC
PDU? To:
STDS-802-16@listserv.ieee.org Hi, The
802.16-2004 standard does not appear to specify clearly which Ethernet fields are to be included
in the MAC layer PDU when the convergence sublayer
type is Ethernet or IP over Ethernet. For instance, I assume that the Ethernet preamble
and start frame delimiter should not be included. Should the Ethernet CRC
be included? The DOCSIS standard does include a four-octet CRC on each
packet and fragment, but as far as I can see,
DOCSIS does not have the possibility of an overall MAC CRC to protect the
payload. 802.16 has an optional CRC on the whole MAC
PDU. If 802.16
includes the Ethernet CRC, then should we recalculate
the CRC after payload header suppression? What response is required if the MAC CRC on a MAC PDU is correct, but
individual Ethernet CRCs within the PDU fail? Mark |