blank.gif (43 bytes)

Church Of The
Swimming Elephant

Search:
3.4 INTERNET/TRANSPORT LAYER INTERFACE Connected: An Internet Encyclopedia
3.4 INTERNET/TRANSPORT LAYER INTERFACE

Up: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1122
Up: 3. INTERNET LAYER PROTOCOLS
Prev: 3.3.8 Error Reporting
Next: 3.5 INTERNET LAYER REQUIREMENTS SUMMARY

3.4 INTERNET/TRANSPORT LAYER INTERFACE

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.


Next: 3.5 INTERNET LAYER REQUIREMENTS SUMMARY

Connected: An Internet Encyclopedia
3.4 INTERNET/TRANSPORT LAYER INTERFACE

Cotse.Net

Protect yourself from cyberstalkers, identity thieves, and those who would snoop on you.
Stop spam from invading your inbox without losing the mail you want. We give you more control over your e-mail than any other service.
Block popups, ads, and malicious scripts while you surf the net through our anonymous proxies.
Participate in Usenet, host your web files, easily send anonymous messages, and more, much more.
All private, all encrypted, all secure, all in an easy to use service, and all for only $5.95 a month!

Service Details

 
.
www.cotse.com
Have you gone to church today?
.
All pages ©1999, 2000, 2001, 2002, 2003 Church of the Swimming Elephant unless otherwise stated
Church of the Swimming Elephant©1999, 2000, 2001, 2002, 2003 Cotse.com.
Cotse.com is a wholly owned subsidiary of Packetderm, LLC.

Packetderm, LLC
210 Park Ave #308
Worcester, MA 01609