The interface between the IP layer and the transport layer MUST provide full access to all the mechanisms of the IP layer, including options, Type-of-Service, and Time-to-Live. The transport layer MUST either have mechanisms to set these interface parameters, or provide a path to pass them through from an application, or both.
Applications are urged to make use of these mechanisms where applicable, even when the mechanisms are not currently effective in the Internet (e.g., TOS). This will allow these mechanisms to be immediately useful when they do become effective, without a large amount of retrofitting of host software.
We now describe a conceptual interface between the transport layer and the IP layer, as a set of procedure calls. This is an extension of the information in Section 3.3 of RFC-791 [IP:1].
SEND(src, dst, prot, TOS, TTL, BufPTR, len, Id, DF, opt => result )
where the parameters are defined in RFC-791. Passing an Id parameter is optional; see Section 3.2.1.5.
RECV(BufPTR, prot => result, src, dst, SpecDest, TOS, len, opt)
All the parameters are defined in RFC-791, except for:
SpecDest = specific-destination address of datagram (defined in Section 3.2.1.3)
The result parameter dst contains the datagram's destination address. Since this may be a broadcast or multicast address, the SpecDest parameter (not shown in RFC-791) MUST be passed. The parameter opt contains all the IP options received in the datagram; these MUST also be passed to the transport layer.
GET_SRCADDR(remote, TOS) -> local remote = remote IP address TOS = Type-of-Service local = local IP address
See Section 3.3.4.3.
GET_MAXSIZES(local, remote, TOS) -> MMS_R, MMS_S MMS_R = maximum receive transport-message size. MMS_S = maximum send transport-message size. (local, remote, TOS defined above)
See Sections 3.3.2 and 3.3.3.
ADVISE_DELIVPROB(sense, local, remote, TOS)
Here the parameter sense is a 1-bit flag indicating whether positive or negative advice is being given; see the discussion in Section 3.3.1.4. The other parameters were defined earlier.
SEND_ICMP(src, dst, TOS, TTL, BufPTR, len, Id, DF, opt) -> result (Parameters defined in RFC-791).
Passing an Id parameter is optional; see Section 3.2.1.5. The transport layer MUST be able to send certain ICMP messages: Port Unreachable or any of the query-type messages. This function could be considered to be a special case of the SEND() call, of course; we describe it separately for clarity.
RECV_ICMP(BufPTR ) -> result, src, dst, len, opt
(Parameters defined in RFC-791).
The IP layer MUST pass certain ICMP messages up to the appropriate transport-layer routine. This function could be considered to be a special case of the RECV() call, of course; we describe it separately for clarity.
For an ICMP error message, the data that is passed up MUST include the original Internet header plus all the octets of the original message that are included in the ICMP message. This data will be used by the transport layer to locate the connection state information, if any.
In particular, the following ICMP messages are to be passed up:
In the future, there may be additions to this interface to pass path data (see Section 3.3.1.3) between the IP and transport layers.