3.4 INTERNET/TRANSPORT LAYER INTERFACE

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.

DISCUSSION:

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 Datagram

       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.

• Receive Datagram

       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.

• Select Source Address

       GET_SRCADDR(remote, TOS)  -> local
  
                  remote = remote IP address
                  TOS = Type-of-Service
                  local = local IP address
  

  See Section 3.3.4.3.

• Find Maximum Datagram Sizes

       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.

• Advice on Delivery Success

  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 Message

       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.

• Receive ICMP Message

       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:

  • Destination Unreachable

  • Source Quench

  • Echo Reply (to ICMP user interface, unless the Echo Request originated in the IP layer)

  • Timestamp Reply (to ICMP user interface)

  • Time Exceeded

DISCUSSION:

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.