The functional description of user interfaces to the IP is, at best, fictional, since every operating system will have different facilities. Consequently, we must warn readers that different IP implementations may have different user interfaces. However, all IPs must provide a certain minimum set of services to guarantee that all IP implementations can support the same protocol hierarchy. This section specifies the functional interfaces required of all IP implementations.
Internet protocol interfaces on one side to the local network and on the other side to either a higher level protocol or an application program. In the following, the higher level protocol or application program (or even a gateway program) will be called the "user" since it is using the internet module. Since internet protocol is a datagram protocol, there is minimal memory or state maintained between datagram transmissions, and each call on the internet protocol module by the user supplies all information necessary for the IP to perform the service requested.
An Example Upper Level Interface
The following two example calls satisfy the requirements for the user to internet protocol module communication ("=>" means returns):
SEND (src, dst, prot, TOS, TTL, BufPTR, len, Id, DF, opt => result)
where: src = source address dst = destination address prot = protocol TOS = type of service TTL = time to live BufPTR = buffer pointer len = length of buffer Id = Identifier DF = Don't Fragment opt = option data result = response OK = datagram sent ok Error = error in arguments or local network error Note that the precedence is included in the TOS and the security/compartment is passed as an option.
RECV (BufPTR, prot, => result, src, dst, TOS, len, opt)
where: BufPTR = buffer pointer prot = protocol result = response OK = datagram received ok Error = error in arguments len = length of buffer src = source address dst = destination address TOS = type of service opt = option data
When the user sends a datagram, it executes the SEND call supplying all the arguments. The internet protocol module, on receiving this call, checks the arguments and prepares and sends the message. If the arguments are good and the datagram is accepted by the local network, the call returns successfully. If either the arguments are bad, or the datagram is not accepted by the local network, the call returns unsuccessfully. On unsuccessful returns, a reasonable report must be made as to the cause of the problem, but the details of such reports are up to individual implementations.
When a datagram arrives at the internet protocol module from the local network, either there is a pending RECV call from the user addressed or there is not. In the first case, the pending call is satisfied by passing the information from the datagram to the user. In the second case, the user addressed is notified of a pending datagram. If the user addressed does not exist, an ICMP error message is returned to the sender, and the data is discarded.
The notification of a user may be via a pseudo interrupt or similar mechanism, as appropriate in the particular operating system environment of the implementation.
A user's RECV call may then either be immediately satisfied by a pending datagram, or the call may be pending until a datagram arrives.
The source address is included in the send call in case the sending host has several addresses (multiple physical connections or logical addresses). The internet module must check to see that the source address is one of the legal address for this host.
An implementation may also allow or require a call to the internet module to indicate interest in or reserve exclusive use of a class of datagrams (e.g., all those with a certain value in the protocol field).
This section functionally characterizes a USER/IP interface. The notation used is similar to most procedure of function calls in high level languages, but this usage is not meant to rule out trap type service calls (e.g., SVCs, UUOs, EMTs), or any other form of interprocess communication.