rfc1682.txt

RFC 的详细文档！

Network Working Group                                           J. Bound
Request for Comments: 1682                 Digital Equipment Corporation
Category: Informational                                      August 1994


                 IPng BSD Host Implementation Analysis

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Abstract

   This document was submitted to the IETF IPng area in response to RFC
   1550.  Publication of this document does not imply acceptance by the
   IPng area of any ideas expressed within.  Comments should be
   submitted to the [e-mail] mailing list.

Overview

   This IPng white paper, IPng BSD Host Implementation Analysis,
   was submitted to the IPng Directorate to provide a BSD host point of
   reference to assist with the engineering considerations during the
   IETF process to select an IPng proposal.  The University of
   California Berkeley Software Distribution (BSD) TCP/IP (4.3 + 4.4)
   system implementation on a host is used as a point of reference for
   the paper.

   This document only reflects the author's personal analysis based on
   research and implementation experience for IPng, and does not
   represent any product or future product from any host vendor.  Nor
   should it be construed that it is promoting any specific IPng at this
   time.

Acknowledgments

   The author would like to acknowledge the many host implementation
   discussions and inherent knowledge gained from discussions with the
   following persons within Digital over the past year: Peter Grehan,
   Eric Rosen, Dave Oran, Jeff Mogul, Bill Duane, Tony Lauck, Bill Hawe,
   Jesse Walker, John Dustin, Alex Conta, and Fred Glover.  The author
   would also like to acknowledge like discussions from outside his
   company with Bob Hinden (SUN), Bob Gilligan (SUN), Dave Crocker
   (SGI), Dave Piscitello (Core Competence), Tracy Mallory (3Comm), Rob
   Ullmann (Lotus), Greg Minshall (Novell), J Allard (Microsoft), Ramesh
   Govinden (Bellcore), Sue Thompson (Bellcore), John Curran (NEARnet),



Bound                                                           [Page 1]

RFC 1682         IPng BSD Host Implementation Analysis       August 1994


   Christian Huitema (INRIA), and Werner Volgels (INESC).  The author
   would also like to thank Digital Equipment Corporation for the
   opportunity to work on IPng within the IETF as part of his job.

1. Introduction

   A host in the context of this white paper is a system that contains
   an operating system supporting a network subsystem as one of its
   parts, and an interprocess communications facility to access that
   network subsystem.  These hosts are often referenced as a
   Workstation, Server, PC, Super Computer, Mainframe, or an Embedded
   System (Realtime Devices).

   IPng will require changes to a hosts network software architecture.
   Those changes should be as transparent as possible to the existing
   IPv4 applications executing on hosts.

   After discussing the network software architecture for a BSD host the
   paper will discuss the perceived network software alterations,
   extended capabilities, transition software, and a deployment
   consideration for IPng hosts.

   The inclusive OR of all IPng proposals was used to develop the
   engineering considerations discussed in this paper.

2. Network Software Architecture

   The BSD host network software architecture consists essentially of
   three components: the interprocess communications facility, the
   network communications subsystem, and the network protocols
   supported. These three components are tightly coupled and must be
   integrated in a way that affords high performance for the
   applications that are dependent on these components to interoperate
   efficiently.  A BSD host implementation view of the TCP/IP protocol
   suite is depicted in the following network architecture diagram.
















Bound                                                           [Page 2]

RFC 1682         IPng BSD Host Implementation Analysis       August 1994


   +-----------------------------------------------------------------+
   |                        Application Layer                        |
   |                                                                 |
   |                Socket and Network Library APIs                  |
   |                                                                 |
   |  BIND DNS                                                       |
   |  SNMP Management                                                |
   |                          User Space                             |
   +-----------------------------------------------------------------+
   |                         Kernel Space          AF_INET           |
   |                                        Communications Domain    |
   |  Socket Layer                                                   |
   |                                                                 |
   |                     Transport Layer TCP & UDP                   |
   |                                               Queues/Control    |
   |                                                 Blocks          |
   |                        Network Layer                            |
   |              +-----------------------------------+              |
   |              | IPv4 Modules  Discovery Multicast |              |
   |              |                ICMP       IGMP    |              |
   |              |                   Routing         |   Routing    |
   |              |                RIP        EGP     |   Tables     |
   |              |                OSPF       BGP     |              |
   |              |                I-IS-IS    IDRP    |              |
   |              +-----------------------------------+              |
   |                     Link Dependent Layer                        |
   |              +-----------------------------------+              |
   |              | ARP, RARP, InARP, NCPs, Addr Tbls |              |
   |              +-----------------------------------+              |
   |  Discovery & Interface                                          |
   |      Cache                                                      |
   |                     Data Link Layer                             |
   |              +-----------------------------------+              |
   |              | Ethernet, FDDI, ATM, HIPPI, PPP   |              |
   |              +-----------------------------------+              |
   +-----------------------------------------------------------------+

2.1 Interprocess Communications Facility

   The interprocess communications (IPC) facilities includes three
   critical parts:

      1.  The IPC mechanism to the network communications subsystem.
      2.  The ability to access a network protocol set within that
          subsystem.
      3.  The structures supporting the network communications
          subsystem.




Bound                                                           [Page 3]

RFC 1682         IPng BSD Host Implementation Analysis       August 1994


   The IPC facility has two implementation parts.  The part in user
   space and the part in kernel space within the operating system. This
   is often not differentiated and why in the previous network
   architecture diagram you will see sockets in both user and kernel
   space.  An IPC supports in user space an application program
   interface (API) which application developers use to access the
   network communications features of the host. These APIs have
   corresponding functions in the kernel space which execute the
   functions requested by the user space requests through the APIs.

   The sockets paradigm on a BSD host defines the data structure of the
   network address within a selected protocol family (communications
   domain) in the network subsystem.  This data structure consists of an
   address family, a port for the protocol selected, and a network
   address.

   The IPC facility on a host is dependent upon its interface to the
   BIND DNS application which is the defacto method when using TCP/IP to
   retrieve network addresses.

   Other interfaces that may be required by applications to properly set
   up the network connection within the IPC facility include:
   setting/getting options for the protocols used, obtaining/accessing
   information about networks, protocols, and network services, and
   sending/transmitting datagrams.

2.2 Network Communications Subsystem

   The network communications subsystem consists of the following
   generic parts as depicted in the previous network architecture
   diagram: transport layer, network layer, link dependent layer, and
   data link layer.  These may not be implemented as true distinct
   layers on a BSD host, but they are referenced in this white paper in
   that manner for purposes of discussion.

   The transport layer supports the application interface into the
   network communications subsystem and sets up the parametric pieces to
   initiate and accept connections.  The transport layer performs these
   functions through requests to the lower layers of the network
   communications subsystem.  The transport layer also supports the
   queues and protocol control blocks for specific network connections.

   The network layer supports the modules to build and extend the
   network layer datagram, the control protocol datagrams, and the
   routing abstraction on the host.  This layer of the network
   communications subsystem on a BSD host is often extended to provide
   both interior and exterior routing functionality.




Bound                                                           [Page 4]

RFC 1682         IPng BSD Host Implementation Analysis       August 1994


   The link dependent layer supports the modules that provide an
   interface for the network communications subsystem to map network
   addresses to physical addresses, and build the necessary cache so
   this information is available to the host network software.

   On a BSD host the network layer and link dependent layer together
   provide system discovery for hosts and routers.

   The data link layer supports the modules that define the structures
   for communicating with the hardware media used by the host on the
   local network.

2.3 Network Protocols

   The TCP/IP protocol suite as defined by the IETF RFC specifications
   are the set of network protocols used by this white paper for
   reference.

3. Network Software Alterations

   The IPng network software alterations to a BSD host perceived at this
   time are as follows:

      1.  Applications Embedding IPv4 Addresses.
      2.  Transport Interfaces and Network APIs.
      3.  Socket Layer and Structures.
      4.  Transport Layer.
      5.  Network Layer Components.
      6.  Link dependent Layer.

3.1 Applications Embedding IPv4 Addresses

   Internet style applications in this white paper are the set of
   protocols defined for an end user using TCP/IP to exchange messages,
   transfer files, and establish remote login sessions.

   Applications use the sockets network APIs to maintain an opaque view
   of the network addresses used to support connections across a
   network. Opaque in this context means that the application determines
   the network address for the connection and then binds that address to
   a socket.  The application then uses the reference defined for that
   socket to receive and transmit data across a network.

   An application that embeds an IPv4 network address within its
   datagram has made an underlying assumption that the format of that
   address is permanent.  This will cause a great problem when IPng
   causes addresses to change.  Thus far only one Internet style
   application has been determined to cause this problem and that is FTP



Bound                                                           [Page 5]