Use of OUI in SNAP for defining a 'proprietary' protocol

Hi there,

The company I work for is registered at IEEE for an OUI that we use in our ethernet connected embedded devices.

We are currently running the TCP/IP protocol(s), but we would now like to implement a 'proprietary' protocol that we could use for upgrading/managing the firmware in these devices.

My question is, could we use our OUI in some way to 'define' the protocol without violating any "Ethernet standards".

(1) Can I use a 802.3 SNAP frame.... +----------+---------+----------+-----------+----------+ |802.3 MAC |802.2 LLC|802.2 SNAP|Data | CRC | |Header |Header |Header |(38 to | Checksum | |(14 bytes)|(3 bytes)|(5 bytes) |1492 bytes)| (4 bytes)| +----------+---------+----------+-----------+----------+

....and in the 802.2 SNAP header ... +---------------------+---------+ |OUI (Organizationally|Type | |Unique Id) |(2 bytes)| |(3 bytes) | | +---------------------+---------+

.....use the OUI of my company to define a set of 65536 types of protocols??

(2) Use of "ethertype" 888D. When looking at the list of registered 'ethertypes'

formatting link
I saw type 888D. Can this one could be used??

Any comments?

Regards /Yxan

Reply to
Yxan
Loading thread data ...

That is precisely the purpose of the OUI field in the SNAP header. Along with your OUI, you get 64K private protocol types.

(The use of an 00-00-00 "OUI" in the SNAP header means that the protocol type field in the SNAP header is interpreted as if it were the protocol type field in a Type encapsulated Ethernet frame, i.e., a public protocol type.)

If you put your OUI in the SNAP OUI field, the semantics of the protocol ID field are completely private. You can use any Pid you like; it means whatever you want it to mean.

If you use the 00-00-00 OUI in the SNAP OUI field, the semantics of the Pid field are publicly defined. 0x888D is assigned for FibreChannel use. Do you plan to use the semantics of Pid 0x888D (and I have no idea what those semantics are) for your new management protocol? If not, then don't use that protocol type.

Alternatively, you could use the OUI-Extended Ethertype (0x88B7) format, which provides for OUI-specific, private protocols without using an LLC/SNAP header. In addition, you can use one of the "Playpen" Ethertypes (0x88B5, 0x88B6) for private protocol development, but these should not be used in "production," i.e., final products. See IEEE

802a-2003 for a discussion of these alternative mechanisms.

-- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 228-0803 FAX

Send replies to: usenet at richseifert dot com

Reply to
Rich Seifert

OK, so I can use the SNAP header to define my own protocol. Great that means that I will not violate any standard.

Where can I find information about the "0x88B7-protocol". I did a quick search on the web but couldn't find anything. (I guess it nothing more but a header??)

Since I'm writing the firmware in my embedded device without any OS I can use either the SNAP or the 0x88B7 solution. But what about sending my own protocol from a windows application? Can I use the windows socket API? I know that this is not an windows API or driver group but does anyone have some information about "bypassing" the TCP/IP stack when using sockets.

Regards /Yxan/

Reply to
Yxan

OK, I found it myself.

formatting link
guess this/these protocols isn't widley used considering that one will get no "hits" at all when doing a search for "88B7 oui" in the usenet groups)

This will allow me to implement a 'light-weight' protocol (not needing to enable the TCP/IP stack in my embedded device while upgrading the firmware)

Any information regrading implementing this 'proprietary' protocol in windows (in an executable) without having to install any drivers would be appreciated. /Yxan/

Reply to
Yxan

I am dealing with essentially the same issue. Since my application will be required to send messages that exceed the maximum length of the data field for either the "OUI Extended Ethertype" 0x88B7 encapsulation or the SNAP encapsulation, I will need to implement a lightweight fragmentation and reassembly layer, and it turns out that having the length field is convenient for that purpose. So I plan to use the SNAP encapsulation.

As far as I am able to tell, you will need to write a Windows kernel driver to do this, regardless of which encapsulation you use. The Windows Driver Development Kit is a prerequisite for building such a driver. Technical information on the DDK is available here:

formatting link
and it can be ordered here:

formatting link
If you find a way to avoid building a Windows kernel driver, please post that information on this newsgroup.

Thanks,

nobody

Reply to
nobody

OK, here's how I ended up solving it. By using UDP-broadcasts.

PC->Embedded direction: In the PC side I'm broadcasting UDP packets. In the embedded side (which has no IP-address) I receive these ethernetframes and just checks that they are IP/UDP packets to a specific port. I do not support any of the advanced stuff like fragmenting etc. that IP supports. I also skip the validation of the IP and UDP checksums.

Embedded->PC direction: In the embedded side I'm also brodcasting UDP packets (to a specific port). I can skip the UDP checksum by setting it to 0. The IP checksum must be calculated/set.

Inside the UDP packets I have designed my own protocol with checksums and device addressning.

It was suprisingly simple to implement this very lightweight IP/UDP stack. One just has to make sure that the alignment and the sizes of the ethernet_frame_hdr/ip_hdr/udp_hdr are correct.

/Yxan/

Reply to
Yxan

(snip)

tftp, a UDP based file transfer protocol, has been used to boot diskless machines. It may have been implemented in an 8K ROM or so, along with other boot code.

-- glen

Reply to
glen herrmannsfeldt

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.