Interface between IP and Ethernet MAC

[240RS]

Is there a formal definition of the interface between layer 3 and 2 for wired Ethernet? Like there is MII between MAC and PHY?

I am trying to understand the configuration of the MAC, the different commands and then the actual data flowing. I could not find the info (IP and MAC unlucky words to get good search results) and tried to read some datasets of MAC IC’s instead. Hard, unstructured lists of registers. Not helpful to get overall understanding.

I ended up buying a simple 10BASE-T MAC/PHY RJ45 module in the hope to get it to work an a STM32 or RPi. I am OK with SPI in general and expect to learn a lot about the MAC interface by trial and error.

I suspect it is not standardized though. But could anybody point me in a direction of some reading material on this subject?

[rstofer]

You might look for a working lwIP project for the STM32.  This will give you a snapshot of one way to implement the MAC layer.

You will have to paw through the code emitted by Cube for a lwIP project to find what you need but it has to be there somewhere.

https://www.st.com/resource/en/user_manual/um1713-developing-applications-on-stm32cube-with-lwip-tcpip-stack-stmicroelectronics.pdf

[magic]

Layer 3 is protocols like IP.
You handle that on your own.

MAC is a layer 2 device, it will want to work with raw Ethernet frames that you need to prepare for it.

Yet another question is how to feed Ethernet frames to a given MAC chip, no idea here.

[gf]

Is there a formal definition of the interface between layer 3 and 2 for wired Ethernet? Like there is MII between MAC and PHY?

From the protocol point of view, the IP packet is simply the payload of the Ethernet frame, and the EtherType in the frame is 0x0800.
[ Assuming IPV4 and Ethernet II framing, and not considering stuff like VLAN tagging, LLC, SNAP, etc. ]

Different protocol stack implementations use different software interfaces between the protocol layers. There is no common standard.

Many today's Ethernet controllers do not only support sending/receiving Ethernet frames, but also have some offload capabilities (e.g. compute and fill-in or check TCP or UDP checksum).

[240RS]

Thanks. I will plough through the cube code (used to all the overhead of it, but it reads quite easily). But it is reverse engineering again.

I understand the ip frame format (and tcp above). And I trust when things are configured right it is indeed just a matter of sending the ip frame down to the MAC (thanks for the 0x8000 info and CRC functions at hw level) over SPI. And I am fine with limited bandwidth of SPI. It is just a matter of seeing it all work together.

Let me conclude there is no prescribed interface. Any help on a reference to an explanation of the functions in such interface would still be appreciated. Thanks!

[gf]

For instance, inside the Linux kernel there is dev_queue_xmlt().

[ve7xen]

Let me conclude there is no prescribed interface. Any help on a reference to an explanation of the functions in such interface would still be appreciated. Thanks!

The layered model does offer a notional interface, but not a concrete one, because the details of the lower layer will define what must be passed down. You need to provide the (non-inferred) header values for layer-2, and the higher-layer PDU. In the Ethernet case, that would be the source MAC, destination MAC, and ethertype. Also be careful of typos, IPv4 ethertype is 0x0800 not 0x8000.

lwIP for example has exactly that:

Code: [Select]

err_t ethernet_output ( struct netif *  netif,
struct pbuf *  p,
const struct eth_addr *  src,
const struct eth_addr *  dst,
u16_t  eth_type
)

[240RS]

For instance, inside the Linux kernel there is dev_queue_xmlt().

Thanks. Seeing it now makes it look that simple.

Let me conclude there is no prescribed interface. Any help on a reference to an explanation of the functions in such interface would still be appreciated. Thanks!

The layered model does offer a notional interface, but not a concrete one, because the details of the lower layer will define what must be passed down. You need to provide the (non-inferred) header values for layer-2, and the higher-layer PDU. In the Ethernet case, that would be the source MAC, destination MAC, and ethertype. Also be careful of typos, IPv4 ethertype is 0x0800 not 0x8000.

lwIP for example has exactly that:

Code: [Select]

err_t ethernet_output ( struct netif *  netif,
struct pbuf *  p,
const struct eth_addr *  src,
Lulll
u16_t  eth_type
)

Thanks. This frame would seem level 2 to me. And then the ip layer will not have a notion of mac &@@@ most probably. Based on the pointer to lwip I read into ARP that I know of (of course), but never realized layer 2 keeps that mapping and not layer 3.

I have so much more questions to come. Allow me, with your inputs provided, to try to get two 20 year old layer 1 and 2 chips (ENC28J60) to talk to each other, connected via SPI to an RPi or stm32 and see initialization, discovery and useful payloads in action.

As for the work to come: I want to interface to Powerline communications (Homeplug AV MAC/PHY interfaced via SPI) chips and focus on the OFDM and tonemaps part. But not without truly understanding a simple IP connection over twisted pair works.

[ve7xen]

Thanks. This frame would seem level 2 to me. And then the ip layer will not have a notion of mac &@@@ most probably. Based on the pointer to lwip I read into ARP that I know of (of course), but never realized layer 2 keeps that mapping and not layer 3.

I would say it goes more the other way. Layer-3 needs to have a notion of Layer-2, since it needs to provide (and possibly interpret) the information in the Layer-2 header, but Layer-2 doesn't need to know anything at all about Layer-3. In a similar way as TCP needs to know the source/destination IPs, IP needs to know the source/destination MACs. You may put ARP at 'Layer-2.5' as the bridge between the two layers, but personally I consider this is just part of Layer-3, though it is not itself a Layer-3 protocol.

Remember the OSI model is just a model, and may not map exactly to real implementations, though it's usually pretty close up until layer-4.

[mikeselectricstuff]

The Wiznet chips like W5500 are a nice way to do ethernet without the need to get into too much details or use sofwtare stacks - they have an internal PHY and do UDP and TCP/IP internally, via a fast (60MHZ I think) SPI interface. If your overall throughput isn't that high, you could easily use one on a low-end 8-bit MCU.

[240RS]

You may put ARP at 'Layer-2.5' as the bridge between the two layers, but personally I consider this is just part of Layer-3, though it is not itself a Layer-3 protocol.

Remember the OSI model is just a model, and may not map exactly to real implementations, though it's usually pretty close up until layer-4.

Yes, I got your point in ARP being kinda 2.5 and that that relates directly to the OSI model does not have to be super rigid. If all is integrated, it doesn’t really matter (as with the Wiznet 5500).

But…. In my case I am preparing to work with a chip that HAS a very rigid boundary: it is a PLC PHY over 917 QPSK modulated carriers combined with an onboard MAC. All running on an embedded ARM A9 with 4MB of hidden source code and crappy documentation. Interface to host: SPI slave with additional HW interrupt. And it is ipv6 which adds some extra as well. But the question is answered: “No, there is no standard interface between L3 and L2 in general and boundaries aren’t that rigid”.

Any reading material on the “layer 2.5 in the middle” is still appreciated. Learned a lot based on this thread already. Thanks everybody!

[madires]

Be careful with "OSI layer 2.5". It could be also MPLS for example. For anything IP related check out the RFCs. Regarding IPv6 you might be interested in ND and SLAAC. The Ethernet world is also changing. More and more of the inexpensive low-end chips come with hardware offloading features and things like DSA (each vendor with their own variant).

[240RS]

RFC’s it then. Thanks. Googled ND (and SLAAC) will be relevant indeed thanks.

[ve7xen]

Yes, I got your point in ARP being kinda 2.5 and that that relates directly to the OSI model does not have to be super rigid. If all is integrated, it doesn’t really matter (as with the Wiznet 5500).

But…. In my case I am preparing to work with a chip that HAS a very rigid boundary: it is a PLC PHY over 917 QPSK modulated carriers combined with an onboard MAC. All running on an embedded ARM A9 with 4MB of hidden source code and crappy documentation. Interface to host: SPI slave with additional HW interrupt. And it is ipv6 which adds some extra as well. But the question is answered: “No, there is no standard interface between L3 and L2 in general and boundaries aren’t that rigid”.

Any reading material on the “layer 2.5 in the middle” is still appreciated. Learned a lot based on this thread already. Thanks everybody!

ARP is a client of layer-2, so in that sense it is well defined, it will generate layer-2 frames. But it's neither a 'layer-2' or 'layer-3' protocol since it doesn't accept PDUs. Address mapping is service that's part of layer-3 (whether it is ARP in IPv4 or ND in IPv6) and you will find its documentation with the related layer-3 protocol. As far as the OSI model though this necessary address mapping function is not really modelled. So I agree with madires that 'layer-2.5' isn't an appropriate way to refer to it, since it's not actually a packet handling protocol itself it doesn't server as a layer in the OSI model at all, it's just part of layer-3.

If your device is truly IPv6 and not dual-stack (IPv4+IPv6), then don't confuse yourself and just learn IPv6, because it is fairly different than IPv4. For example, ND generates normal and valid IPv6 'layer-3' packets, rather than having its own format.

[240RS]

Yes, the network will be ipv6 only. Thanks for the suggestion to skip understanding v4.

[CaptDon]

One of the projects where I worked wanted to use the robustness of ethernet electrical signaling across the noisy 'backplane' environment. They had a notion of simply passing raw data without any formatting, addressing and so forth since it was a 'card to card' signal they deemed 'no address required'. WOW was that a crash and burn!!!! Jabber errors, runt errors, totally broken idea, the phy's said "Oh no, your not going to just pass raw data back and forth!! So they had to add an FPGA at each end to handle all the 'details' of transmittable packets. They solved the issue and ended up with 3 card to card dedicated signal paths as well as two signal paths local to the CPU card, one of those paths being a 'diagnostic port' for troubleshooting and software uploads/upgrades. Fun times!! I guess they needed a 'dumb phy' that would simply be a level shifter from logic level to ethernet level. I believe what ever dumb phy's may have once existed were by this time obsolete.

[240RS]

Haha, thanks this info. I am learning more and more about Ethernet by the day and the PHY part is adding a lot of “value” indeed. (Some) forward error correction, scrambling to limit EMC, NRZ/NRZI encoding. If I am not wrong, connecting a gigabit Ethernet (8 wires) PHY to a MAC requires 70 or so lines on the PCB.

[westfw]

I think the usual interface to Ethernet MACs is "sockets."
But IP will usually bypass that in the interests of better efficiency, and the APIs become highly dependent on the actual MAC implementation.  I think it's pretty common to reserve space in packet buffers "before" the IP payload to add the Ethernet headers, especially if you don't have full scatter/gather DMA or IO operations.

[ve7xen]

Haha, thanks this info. I am learning more and more about Ethernet by the day and the PHY part is adding a lot of “value” indeed. (Some) forward error correction, scrambling to limit EMC, NRZ/NRZI encoding. If I am not wrong, connecting a gigabit Ethernet (8 wires) PHY to a MAC requires 70 or so lines on the PCB.

The PHY handles the 'physical media dependent' (PMD) part of the link. Depending on the media standard in use, it could be as simple as a SERDES, but yeah in a complex PHY like 1000base-T it will be doing quite a bit.

The standard interface between MAC and PHY at gigabit is GMII, it's a full-duplex 8-bit parallel interface + a few clocks and enables @ 125MHz. I believe it's 27 lines if you include everything optional. There is also RGMII which runs at double the speed, so uses ~half the lines.

[David Hess]

Is there a formal definition of the interface between layer 3 and 2 for wired Ethernet? Like there is MII between MAC and PHY?

...

I think you are looking for Address Resolution Protocol (ARP) which converts local IP addresses (layer 3) into MAC addresses (layer 2).

[madires]

With IPv6 we should be a little bit more pedandic about ARP and IPv4 addresses.

[240RS]

Thanks everybody. Very helpful. Starting experiments with two MAC/PHY twister pair Ethernet controllers over SPI. And then PLC. Waiting for $50 TinySA spectrum analyzer to not being completely blind debugging PLC.

[David Hess]

With IPv6 we should be a little bit more pedandic about ARP and IPv4 addresses.

How is the MAC discovered with IPv6?

[madires]

With IPv6 it's done by Neighbor Discovery (ND) which is based on ICMPv6.

[240RS]

Tip to focus on ipv6 right away proved really helpful. Is quite different.

[240RS]

And I now have enough understanding of the interface between MAC and IP. The simple part is what we know (creating frames, ARP/ND). Hard part is reading the data sheet of the specific MAC to see what needs to be initialized/monitored. But got there by just doing it. Thanks for all the pointers. Kept me sharper in the process. I used the simplest ETH board I could find. ENC28J60. With great documentation.