Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-16] Is the Ethernet CRC included in the MAC PDU?



I agree with John.
Ethernet FCS does not protect the payload if the payload is fragmented.
It is generated / dropped by Ethernet controllers. It is an overhead in case CRC of MAC PDU is present.
No convincing reason to keep it in air interface.
Note that in 802.11 CRC is generated over wireless frame while original Ethernet CRC is dropped.
Vladimir
 
-----Original Message-----
From: John Chan [mailto:jchan@WI-LAN.COM]
Sent: Wednesday, January 05, 2005 9:02 PM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] Is the Ethernet CRC included in the MAC PDU?

Ethernet FCS is error checking at the 802.3 layer. Ethernet FCS is commonly generated or verified by this layer with Ethernet MAC hardware support. Higher layers as in router should not do the FCS generation or checking. For 802.16 as a wireless MAC, I think there should not be Ethernet FCS embedded.
 
John.
-----Original Message-----
From: owner-stds-802-16@LISTSERV.IEEE.ORG [mailto:owner-stds-802-16@LISTSERV.IEEE.ORG]On Behalf Of Mark Thomas
Sent: Wednesday, January 05, 2005 11:08 AM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] Is the Ethernet CRC included in the MAC PDU?

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



This mail passed through mail.alvarion.com

************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************


This mail passed through mail.alvarion.com

************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************
This mail was sent via mail.alvarion.com

************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************