Connected: An Internet Encyclopedia
RFC 791 - 3.3. Interfaces

Top: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 791
Up: 3. SPECIFICATION
Prev: 3.2. Discussion
Next: APPENDIX A: Examples & Scenarios

### 3.3. Interfaces

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.

Next: APPENDIX A: Examples & Scenarios

Connected: An Internet Encyclopedia
RFC 791 - 3.3. Interfaces