IEEE HomeSearch IEEE ShopWeb Account Contact IEEE IEEE
MembershipPublicationsServicesStandardsConferencesCareers/Jobs
IEEE-SA IEEE-SA Member Area Search our standards database for Abstract, Sponsor, Status, Contact,Ordering and Historical information. IEEE-SA Standards Association
   Text Size: Small Text Normal Text Larger Text
Products & ServicesIEEE-SA MembershipStandards DevelopmentNews & InformationnavFillerHOMEHOME Icon

Use of the IEEE Assigned EtherType Field with IEEE Std 802.3, 1998 Edition Local and Metropolitan Area Networks

The EtherType Field provides a context for interpretation of the data field of the frame (protocol identification).

Well known protocols already have an EtherType Field. A public list of which can be found here.

The IEEE 802.3, 1998 Length/EtherType Field, originally known as EtherType, is a two-octet field which takes one of two meanings, depending on its numeric value. For numeric evaluation, the first octet is the most significant octet of this field. This document only deals with the type interpretation of the Length/EtherType Field.

See standards IEEE 802.3, 1998 Clause 3.2.6 Length/EtherType Field specifications and IEEE 802.1H-1995 for use of the EtherType Field with other media access methods.

When the value of this field is greater than or equal to 1536 decimal (equal to 0600 hexadecimal) the EtherType Field indicates the nature of the MAC client protocol (EtherType interpretation). The length and EtherType interpretations of this field are mutually exclusive.

Therefore when the value of the two octet field is equal to or greater than 0600 hex then it is a Type Field and the value of the Type Field is obtained from the IEEE EtherType Field Registrar. New values obtained from the IEEE EtherType Field Registrar will not interfere with the existing EtherType Field assignments from Xerox or the IEEE. Former assignments are still valid.

The EtherType Field is a very limited space and therefore its assignment will be limited. It is incumbent upon your company administration to ensure that requests for EtherType Fields be very limited and only on an as needed basis. Requests for multiple EtherType Fields by the same applicant will not be granted unless the applicaant certifies that they are for unrelated purposes. In particular, only one new EtherType Field is necessary to limit reception of a new protocol or protocol family to the intended class of devices. New protocols and protocol families should have provision for a sub-type field within the new specification to handle different aspects of the application (e.g., control vs. data) and future upgrades."

The following should be considered before requesting a new EtherType Field:

  • Use of an existing protocol with its currently allocated EtherType Field.
  • Use of further, as yet unexhausted, protocol identification capabilities (sub-types) within an existing protocol or protocol family.
  • Specification of additional protocol identification types within a new protocol to allow similar or related uses without the need for more than one EtherType Field assignment.

The conditions under which an organization must obtain an Organizationally Unique Identifier (OUI) or an EtherType Field are quite different. A manufacturer uses an OUI to generate a unique MAC address for each device they produce. Only developers of new data transport protocols require an EtherType Field, whether or not they actually manufacture any devices.

Each request for an EtherType Field sent to the IEEE EtherType Field Registrar will be forwarded to the IEEE RAC EtherType Field Approval Authority for review and approval. This review process will be completed in less than 90 days.

All information will be kept confidential until the request is approved.

IEEE STD 802.3, 1998 Local and Metropolitan Area Networks EtherType Field Tutorial Rev 0.7

spacer
Copyright ©2009 IEEE-SA
Contact IEEE-SA
(IEEE Registration Authority)
URL: http://standards.ieee.org/regauth/ethertype/type-tut.html
 spacer