1.2.4.5.1 Abstraction Model
This module provides software abstraction of the IPv4 module existent in any TCP/IP Stack implementation.
The typical usage of the IP layer_in a TCP/IP stack for transmitting a packet is shown in the following diagram:
Core Functionality
To transmit an IP packet over the network, the application has to prepare an IPV4_PACKET data structure and properly format it so that the recipients of this packet (the IP and the MAC layers) can process the packet.
The TCP/IP Stack modules allocate the IPV4_PACKET data structures dynamically using the TCP/IP Stack private heap using packet allocation functions.
The IPV4_PACKET packet can be allocated statically by the application.
When the IPV4_PACKET is constructed an important thing to remember is to fill in the appropriate packet acknowledge function. Once the MAC layer/driver is done with processing the packet (successfully or not) it will call the IPV4_PACKET acknowledge function, indicating that the packet is now available (and could be freed or reused).
The next step is to fill in the packet source and destination addresses, as well as the outgoing interface (please keep in mind that the TCP/IP stack supports multiple network interfaces).
This could be done with a call to TCPIP_IPV4_SelectSourceInterface or the application can select all these addresses manually.
All that’s left before handing the packet is to call TCPIP_IPV4_PacketFormatTx. This call fills in the supplied packet with the IP header structure and updates the IP checksum. Please note that this function expects a properly formatted packet, with the source and destination addresses filled in.
After this, the application can call TCPIP_IPV4_PacketTransmit. This function does some basic packet checks and expects that the packet has a valid network interface selected otherwise the call will fail.
After further formatting (with the MAC required headers), the IP layer_will try to send the packet over the network. If the destination hardware address is known (the ARP resolve call succeeds) the packet is handed over to the MAC. Otherwise, the IP will insert the packet into a queue, waiting for the ARP resolution. When ARP signals that the request is done (either success or timeout) the IP layer_intercepts the signal and removes the packet from the wait queue: either hands it over to the MAC for transmission or it discards it if the ARP resolution failed.
The MAC layer/driver in its turn can transmit it immediately, queue the packet for transmission or discard it (if, for example the network link is down). Regardless, once the packet is processed, the packet acknowledge function is called with an updated acknowledge result. This informs the owner of the packet about the result of the operation and also that the packet is no longer in traffic.
How the Library Works
On the transmit side, the IP layer_is responsible for routing and forwarding the IP datagrams to the required destination host. To do that, the IP layer_has internal functionality that allows the selection of the proper network interface and destination hardware address of a packet.
Based on the destination of a packet/datagram, the IP layer_will send the packet to either a host on the network or to a gateway if either is available. To accomplish this, the IP module works closely with the ARP layer_from which it requests the destination hardware addresses for outgoing packets. If the destination address of a packet is not known, the IP module will request an ARP probe and will wait for the ARP module reply. Whenever ARP signals that the solicited address is available, the IP module will send the packet over the network. If a time-out is reported (no such host could be found on that particular network), the packet is silently discarded.
On the receive side, the IP module processes all the incoming IPv4 packets and performs a basic sanity check of the packet checksum and other attributes. If the packet check fails, the packet is simply discarded. Otherwise, it is dispatched for further processing to the appropriate module (UDP, TCP, ICMP, etc.).
The IP layer_operation within the TCP/IP stack is transparent to the applications using the preferred_socket_API (MCHP UDP, TCP or BSD). This means that normally an application does not need to interface directly to the IP_layer. However, the IP module exposes an API that can be used by the application for sending IP datagrams directly, bypassing the normal higher layer_protocols (UDP, TCP).
> Notes:
- Currently, it is not possible for an application to intercept the incoming IP datagrams and interfere with the default IP processing. However, this may change in the future and support can be added for the receive side.
- For a detailed description of the IP layer_functionality, please consult RFC 791, RFC 1122, RFC 2474, etc.
- This implementation supports packet fragmentation both on transmit and receive side.