Archived from groups: comp.dcom.lans.ethernet (More info?)

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'
(http://standards.ieee.org/regauth/ethertype/eth.txt), I saw type 888D.
Can this one could be used??




Any comments?

Regards
/Yxan

Archived from groups: comp.dcom.lans.ethernet (More info?)

"Yxan" <beach.dk@gmail.com> wrote:
>
> 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'
> (http://standards.ieee.org/regauth/ethertype/eth.txt), I saw type
> 888D.
> Can this one could be used??

Yes, the SNAP header is a good way of identifying your own protocol
running over Ethernet or other 802 LAN. But I don't think Ethertype 888D
applies here, since that seems assigned to ANSI for FiberChannel related
frames.

To use the SNAP header, use the "length" format of the Ethernet frame,
then follow the "length" field with a SAP of 0xAA-AA-03, which is the
so-called "SNAP SAP," then follow that with your company's OUI and the
Protocol ID you decide to assign.

So in your diagram (1) above, before the LLC header comes the length
field (2 bytes).

Bert

Archived from groups: comp.dcom.lans.ethernet (More info?)

In article <1119010656.965165.232840@f14g2000cwb.googlegroups.com>,
"Yxan" <beach.dk@gmail.com> wrote:

>
> 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....

> ...and in the 802.2 SNAP header ...

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

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.)

>
>
> (2) Use of "ethertype" 888D.
> When looking at the list of registered 'ethertypes'
> (http://standards.ieee.org/regauth/ethertype/eth.txt), I saw type 888D.
> Can this one could be used??
>

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

Archived from groups: comp.dcom.lans.ethernet (More info?)

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/

Archived from groups: comp.dcom.lans.ethernet (More info?)

"Rich Seifert" <usenet@richseifert.com.invalid> wrote:

> Alternatively, you could use the OUI-Extended Ethertype (0x88B7)
> format,
> which provides for OUI-specific, private protocols without using an
> LLC/SNAP header.

Cool, but it seems to be listed as belonging to the 802.1 wg of the
IEEE, with no description of what it's for:

http://standards.ieee.org/regauth/ethertype/eth.txt

The IANA doesn't even list it in its assigned numbers list, that I could
find.

http://www.iana.org/numbers.html

Bert

Archived from groups: comp.dcom.lans.ethernet (More info?)

OK, I found it myself.
http://standards.ieee.org/getieee8 [...] a-2003.pdf
(I 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/

Archived from groups: comp.dcom.lans.ethernet (More info?)

"Yxan" wrote:
> OK, I found it myself.
> http://standards.ieee.org/getieee8 [...] a-2003.pdf
> (I 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)

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.

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

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:

http://msdn.microsoft.com/library/ [...] 00.xml.asp

and it can be ordered here:

http://www.microsoft.com/whdc/devt [...] ddkcd.mspx

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

Thanks,

nobody

Archived from groups: comp.dcom.lans.ethernet (More info?)

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

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/

Archived from groups: comp.dcom.lans.ethernet (More info?)

Yxan wrote:

(snip)

> 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.

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