rfc1122.txt

windows 网络编程。pdf文档

         implied by these calls, but need not literally implement the
         calls themselves.  For example, many implementations reflect
         the coupling between the transport layer and the IP layer by
         giving them shared access to common data structures.  These
         data structures, rather than explicit procedure calls, are then
         the agency for passing much of the information that is
         required.

         In general, each major section of this document is organized
         into the following subsections:

         (1)  Introduction

         (2)  Protocol Walk-Through -- considers the protocol
              specification documents section-by-section, correcting
              errors, stating requirements that may be ambiguous or
              ill-defined, and providing further clarification or
              explanation.

         (3)  Specific Issues -- discusses protocol design and
              implementation issues that were not included in the walk-
              through.

         (4)  Interfaces -- discusses the service interface to the next
              higher layer.

         (5)  Summary -- contains a summary of the requirements of the
              section.


         Under many of the individual topics in this document, there is
         parenthetical material labeled "DISCUSSION" or
         "IMPLEMENTATION". This material is intended to give
         clarification and explanation of the preceding requirements
         text.  It also includes some suggestions on possible future
         directions or developments.  The implementation material
         contains suggested approaches that an implementor may want to
         consider.

         The summary sections are intended to be guides and indexes to
         the text, but are necessarily cryptic and incomplete.  The
         summaries should never be used or referenced separately from
         the complete RFC.

      1.3.2  Requirements

         In this document, the words that are used to define the
         significance of each particular requirement are capitalized.



Internet Engineering Task Force                                [Page 16]




RFC1122                       INTRODUCTION                  October 1989


         These words are:

         *    "MUST"

              This word or the adjective "REQUIRED" means that the item
              is an absolute requirement of the specification.

         *    "SHOULD"

              This word or the adjective "RECOMMENDED" means that there
              may exist valid reasons in particular circumstances to
              ignore this item, but the full implications should be
              understood and the case carefully weighed before choosing
              a different course.

         *    "MAY"

              This word or the adjective "OPTIONAL" means that this item
              is truly optional.  One vendor may choose to include the
              item because a particular marketplace requires it or
              because it enhances the product, for example; another
              vendor may omit the same item.


         An implementation is not compliant if it fails to satisfy one
         or more of the MUST requirements for the protocols it
         implements.  An implementation that satisfies all the MUST and
         all the SHOULD requirements for its protocols is said to be
         "unconditionally compliant"; one that satisfies all the MUST
         requirements but not all the SHOULD requirements for its
         protocols is said to be "conditionally compliant".

      1.3.3  Terminology

         This document uses the following technical terms:

         Segment
              A segment is the unit of end-to-end transmission in the
              TCP protocol.  A segment consists of a TCP header followed
              by application data.  A segment is transmitted by
              encapsulation inside an IP datagram.

         Message
              In this description of the lower-layer protocols, a
              message is the unit of transmission in a transport layer
              protocol.  In particular, a TCP segment is a message.  A
              message consists of a transport protocol header followed
              by application protocol data.  To be transmitted end-to-



Internet Engineering Task Force                                [Page 17]




RFC1122                       INTRODUCTION                  October 1989


              end through the Internet, a message must be encapsulated
              inside a datagram.

         IP Datagram
              An IP datagram is the unit of end-to-end transmission in
              the IP protocol.  An IP datagram consists of an IP header
              followed by transport layer data, i.e., of an IP header
              followed by a message.

              In the description of the internet layer (Section 3), the
              unqualified term "datagram" should be understood to refer
              to an IP datagram.

         Packet
              A packet is the unit of data passed across the interface
              between the internet layer and the link layer.  It
              includes an IP header and data.  A packet may be a
              complete IP datagram or a fragment of an IP datagram.

         Frame
              A frame is the unit of transmission in a link layer
              protocol, and consists of a link-layer header followed by
              a packet.

         Connected Network
              A network to which a host is interfaced is often known as
              the "local network" or the "subnetwork" relative to that
              host.  However, these terms can cause confusion, and
              therefore we use the term "connected network" in this
              document.

         Multihomed
              A host is said to be multihomed if it has multiple IP
              addresses.  For a discussion of multihoming, see Section
              3.3.4 below.

         Physical network interface
              This is a physical interface to a connected network and
              has a (possibly unique) link-layer address.  Multiple
              physical network interfaces on a single host may share the
              same link-layer address, but the address must be unique
              for different hosts on the same physical network.

         Logical [network] interface
              We define a logical [network] interface to be a logical
              path, distinguished by a unique IP address, to a connected
              network.  See Section 3.3.4.




Internet Engineering Task Force                                [Page 18]




RFC1122                       INTRODUCTION                  October 1989


         Specific-destination address
              This is the effective destination address of a datagram,
              even if it is broadcast or multicast; see Section 3.2.1.3.

         Path
              At a given moment, all the IP datagrams from a particular
              source host to a particular destination host will
              typically traverse the same sequence of gateways.  We use
              the term "path" for this sequence.  Note that a path is
              uni-directional; it is not unusual to have different paths
              in the two directions between a given host pair.

         MTU
              The maximum transmission unit, i.e., the size of the
              largest packet that can be transmitted.


         The terms frame, packet, datagram, message, and segment are
         illustrated by the following schematic diagrams:

         A. Transmission on connected network:
           _______________________________________________
          | LL hdr | IP hdr |         (data)              |
          |________|________|_____________________________|

           <---------- Frame ----------------------------->
                    <----------Packet -------------------->


         B. Before IP fragmentation or after IP reassembly:
                    ______________________________________
                   | IP hdr | transport| Application Data |
                   |________|____hdr___|__________________|

                    <--------  Datagram ------------------>
                             <-------- Message ----------->
           or, for TCP:
                    ______________________________________
                   | IP hdr |  TCP hdr | Application Data |
                   |________|__________|__________________|

                    <--------  Datagram ------------------>
                             <-------- Segment ----------->








Internet Engineering Task Force                                [Page 19]




RFC1122                       INTRODUCTION                  October 1989


   1.4  Acknowledgments

      This document incorporates contributions and comments from a large
      group of Internet protocol experts, including representatives of
      university and research labs, vendors, and government agencies.
      It was assembled primarily by the Host Requirements Working Group
      of the Internet Engineering Task Force (IETF).

      The Editor would especially like to acknowledge the tireless
      dedication of the following people, who attended many long
      meetings and generated 3 million bytes of electronic mail over the
      past 18 months in pursuit of this document: Philip Almquist, Dave
      Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve
      Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore),
      John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG),
      Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge
      (BBN), Drew Perkins (CMU), and James Van Bokkelen (FTP Software).

      In addition, the following people made major contributions to the
      effort: Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia
      (BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA),
      Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL),
      John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA), Bill
      Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul
      (DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue
      Technology), and Mike StJohns (DCA).  The following also made
      significant contributions to particular areas: Eric Allman
      (Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic
      (Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn
      (IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann
      (Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun
      Welch (Ohio State), Bill Westfield (Cisco), and Rayan Zachariassen
      (Toronto).

      We are grateful to all, including any contributors who may have
      been inadvertently omitted from this list.















Internet Engineering Task Force                                [Page 20]




RFC1122                        LINK LAYER                   October 1989


2. LINK LAYER