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:
yehur@posdata-usa.com
Posdata
America
R&D
Center
Santa
Clara, CA
95054,
USA
-----Original
Message-----
Mark Thomas
<mthomas@AIRSPAN.COM> wrote:
Date: Thu,
23 Dec
2004 08:17:50
-0000
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