rfc760.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 2,014 行 · 第 1/5 页

             IHL <- (((OIHL*4)-(length of options not copied))+3)/4;
             TL <- OTL - NFB*8 - (OIHL-IHL)*4);
             FO <- OFO + NFB;  MF <- OMF;  Recompute Checksum;
        (10) Submit this fragment to the fragmentation test; DONE.

    Reassembly Procedure

      For each datagram the buffer identifier is computed as the
      concatenation of the source, destination, protocol, and
      identification fields.  If this is a whole datagram (that is both
      the fragment offset and the more fragments  fields are zero), then
      any reassembly resources associated with this buffer identifier
      are released and the datagram is forwarded to the next step in
      datagram processing.

      If no other fragment with this buffer identifier is on hand then
      reassembly resources are allocated.  The reassembly resources
      consist of a data buffer, a header buffer, a fragment block bit
      table, a total data length field, and a timer.  The data from the
      fragment is placed in the data buffer according to its fragment
      offset and length, and bits are set in the fragment block bit
      table corresponding to the fragment blocks received.

      If this is the first fragment (that is the fragment offset is
      zero)  this header is placed in the header buffer.  If this is the
      last fragment ( that is the more fragments field is zero) the
      total data length is computed.  If this fragment completes the
      datagram (tested by checking the bits set in the fragment block
      table), then the datagram is sent to the next step in datagram


[Page 24]                                                               


January 1980                                                            
                                                       Internet Protocol
                                                           Specification



      processing; otherwise the timer is set to the maximum of the
      current timer value and the value of the time to live field from
      this fragment; and the reassembly routine gives up control.

      If the timer runs out, the all reassembly resources for this
      buffer identifier are released.  The initial setting of the timer
      is a lower bound on the reassembly waiting time.  This is because
      the waiting time will be increased if the Time to Live in the
      arriving fragment is greater than the current timer value but will
      not be decreased if it is less.  The maximum this timer value
      could reach is the maximum time to live (approximately 4.25
      minutes).  The current recommendation for the initial timer
      setting is 15 seconds.  This may be changed as experience with
      this protocol accumulates.  Note that the choice of this parameter
      value is related to the buffer capacity available and the data
      rate of the transmission medium; that is, data rate times timer
      value equals buffer size (e.g., 10Kb/s X 15s = 150Kb).

      Notation:

        FO    -  Fragment Offset
        IHL   -  Internet Header Length
        MF    -  More Fragments flag
        TTL   -  Time To Live
        NFB   -  Number of Fragment Blocks
        TL    -  Total Length
        TDL   -  Total Data Length
        BUFID -  Buffer Identifier
        RCVBT -  Fragment Received Bit Table
        TLB   -  Timer Lower Bound




















                                                               [Page 25]


                                                            January 1980
Internet Protocol
Specification



      Procedure:

        (1)  BUFID <- source|destination|protocol|identification;
        (2)  IF FO = 0 AND MF = 0
        (3)     THEN IF buffer with BUFID is allocated
        (4)             THEN flush all reassembly for this BUFID;
        (5)          Submit datagram to next step; DONE.
        (6)     ELSE IF no buffer with BUFID is allocated
        (7)             THEN allocate reassembly resources
                             with BUFID;
                             TIMER <- TLB; TDL <- 0;
        (8)          put data from fragment into data buffer with
                     BUFID from octet FO*8 to
                                         octet (TL-(IHL*4))+FO*8;
        (9)          set RCVBT bits from FO
                                        to FO+((TL-(IHL*4)+7)/8);
        (10)         IF MF = 0 THEN TDL <- TL-(IHL*4)+(FO*8)
        (11)         IF FO = 0 THEN put header in header buffer
        (12)         IF TDL # 0
        (13)          AND all RCVBT bits from 0
                                             to (TDL+7)/8 are set
        (14)            THEN TL <- TDL+(IHL*4)
        (15)                 Submit datagram to next step;
        (16)                 free all reassembly resources
                             for this BUFID; DONE.
        (17)         TIMER <- MAX(TIMER,TTL);
        (18)         give up until next fragment or timer expires;
        (19) timer expires: flush all reassembly with this BUFID; DONE.

      In the case that two or more fragments contain the same data
      either identically or through a partial overlap, this procedure
      will use the more recently arrived copy in the data buffer and
      datagram delivered.

  Identification

    The choice of the Identifier for a datagram is based on the need to
    provide a way to uniquely identify the fragments of a particular
    datagram.  The protocol module assembling fragments judges fragments
    to belong to the same datagram if they have the same source,
    destination, protocol, and Identifier.  Thus, the sender must choose
    the Identifier to be unique for this source, destination pair and
    protocol for the time the datagram (or any fragment of it) could be
    alive in the internet.

    It seems then that a sending protocol module needs to keep a table
    of Identifiers, one entry for each destination it has communicated
    with in the last maximum packet lifetime for the internet.


[Page 26]                                                               


January 1980                                                            
                                                       Internet Protocol
                                                           Specification



    However, since the Identifier field allows 65,536 different values,
    some host may be able to simply use unique identifiers independent
    of destination.

    It is appropriate for some higher level protocols to choose the
    identifier. For example, TCP protocol modules may retransmit an
    identical TCP segment, and the probability for correct reception
    would be enhanced if the retransmission carried the same identifier
    as the original transmission since fragments of either datagram
    could be used to construct a correct TCP segment.

  Type of Service

    The type of service (TOS) is for internet service quality selection.
    The type of service is specified along the abstract parameters
    precedence, reliability, and speed.  A further concern is the
    possibility of efficient handling of streams of datagrams.  These
    abstract parameters are to be mapped into the actual service
    parameters of the particular networks the datagram traverses.

    Precedence.  An independent measure of the importance of this
    datagram.

    Stream or Datagram.  Indicates if there will be other datagrams from
    this source to this destination at regular frequent intervals
    justifying the maintenance of stream processing information.

    Reliability.  A measure of the level of effort desired to ensure
    delivery of this datagram.

    Speed over Reliability.  Indicates the relative importance of speed
    and reliability when a conflict arises in meeting the pair of
    requests.

    Speed.  A measure of the importance of prompt delivery of this
    datagram.

    For example, the ARPANET has a priority bit, and a choice between
    "standard" messages (type 0) and "uncontrolled" messages (type 3),
    (the choice between single packet and multipacket messages can also
    be considered a service parameter). The uncontrolled messages tend
    to be less reliably delivered and suffer less delay.  Suppose an
    internet datagram is to be sent through the ARPANET.  Let the
    internet type of service be given as:






                                                               [Page 27]


                                                            January 1980
Internet Protocol
Specification



      Precedence:    5
      Stream:        0
      Reliability:   1
      S/R:           1
      Speed:         1

    The mapping of these parameters to those available for the ARPANET
    would be  to set the ARPANET priority bit on since the Internet
    priority is in the upper half of its range, to select uncontrolled
    messages since the speed and reliability requirements are equal and
    speed is preferred.

    The following chart presents the recommended mappings from the
    internet protocol type of service into the service parameters
    actually available on the ARPANET, the PRNET, and the SATNET:

      +------------+----------+----------+----------+----------+
      |Application | INTERNET | ARPANET  | PRNET    | SATNET   |
      +------------+----------+----------+----------+----------+
      |TELNET      |S/D:stream| T: 3     | R: ptp   | T: block |
      |  on        |  R:normal| S: S     | A: no    | D: min   |
      |   TCP      |S/R:speed |          |          | H: inf   |
      |            |  S:fast  |          |          | R: no    |
      +------------+----------+----------+----------+----------+
      |FTP         |S/D:stream| T: 0     | R: ptp   | T: block |
      |  on        |  R:normal| S: M     | A: no    | D: normal|
      |   TCP      |S/R:rlblt |          |          | H: inf   |
      |            |  S:normal|          |          | R: no    |
      +------------+----------+----------+----------+----------+
      |interactive |S/D:strm* | T: 3     | R: ptp   | T: stream|
      |narrow band |  R:least | S: S     | A: no    | D: min   |
      |  speech    |  P:speed |          |          | H: short |
      |            |  S:asap  |          |          | R: no    |
      +------------+----------+----------+----------+----------+
      |datagram    |S/D:dtgrm | T: 3 or 0| R:station| T: block |
      |            |  R:normal| S: S or M| A: no    | D: min   |
      |            |S/R:speed |          |          | H: short |
      |            |  S:fast  |          |          | R: no    |
      +------------+----------+----------+----------+----------+
       key:    S/D=strm/dtgrm   T=type     R=route  T=type
               R=reliability    S=size     A=ack    D=delay
               S/R=speed/rlblt                      H=holding time
               S=speed                              R=reliability
               *=requires stream set up






[Page 28]                                                               


January 1980                                                            
                                                       Internet Protocol
                                                           Specification



  Time to Live

    The time to live is set by the sender to the maximum time the
    datagram is allowed to be in the internet system.  If the datagram
    is in the internet system longer than the time to live, then the
    datagram should be destroyed.  This field should be decreased at
    each point that the internet header is processed to reflect the time
    spent processing the datagram.  Even if no local information is
    available on the time actually spent, the field should be
    decremented by 1.  The time is measured in units of seconds (i.e.
    the value 1 means one second).  Thus, the maximum time to live is
    255 seconds or 4.25 minutes.

  Options

    The options are just that, optional.  That is, the presence or
    absence of an option is the choice of the sender, but each internet
    module must be able to parse every option.  There can be several
    options present in the option field.

    The options might not end on a 32-bit boundary.  The internet header
    should be filled out with octets of zeros.  The first of these would
    be interpreted as the end-of-options option, and the remainder as
    internet header padding.

    Every internet module must be able to act on the following options:
    End of Option List (0), No Operation (1), Source Route (3), Return
    Route (7), General Error Report (33), and Internet Timestamp (68).
    The Security Option (2) is required only if classified or
    compartmented traffic is to be passed.

  Checksum

    The internet header checksum is recomputed if the internet header is
    changed.  For example, a reduction of the time to live, additions or
    changes to internet options, or due to fragmentation.  This checksum
    at the internet level is intended to protect the internet header
    fields from transmission errors.












                                                               [Page 29]


                                                            January 1980
Internet Protocol
Specification



3.3.  Examples & Scenarios

  Example 1:

    This is an example of the minimal data carrying internet datagram:

                                    
    0                   1                   2                   3   
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Ver= 4 |IHL= 5 |Type of Service|        Total Length = 21      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Identification = 111     |Flg=0|   Fragment Offset = 0   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Time = 123  |  Protocol = 1 |        header checksum        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         source address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      destination address                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     data      |                                                
   +-+-+-+-+-+-+-+-+                                                

                       Example Internet Datagram

                               Figure 4.

    Note that each tick mark represents one bit position.

    This is a internet datagram in version 4 of internet protocol; the
    internet header consists of five 32 bit words, and the total length
    of the datagram is 21 octets.  This datagram is a complete datagram
    (not a fragment).

















[Page 30]                                                               


January 1980                                                            
                                                       Internet Protocol
                                                           Specification



  Example 2:

    In this example, we show first a moderate size internet datagram
    (552 data octets), then two internet fragments that might result
    from the fragmentation of this datagram if the maximum sized
    transmission allowed were 280 octets.