rfc1201.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                          D. Provan
Request for Comments: 1201                                  Novell, Inc.
Obsoletes:  RFC 1051                                       February 1991


              Transmitting IP Traffic over ARCNET Networks

Status of this Memo

   This memo defines a protocol for the transmission of IP and ARP
   packets over the ARCnet Local Area Network.  This RFC specifies an
   IAB standards track protocol for the Internet community, and requests
   discussion and suggestions for improvements.  Please refer to the
   current edition of the "IAB Official Protocol Standards" for the
   standardization state and status of this protocol.  Distribution of
   this memo is unlimited.

1.  Introduction

   This memo specifies a method of encapsulating Internet Protocol (IP)
   [1] and Address Resolution Protocol (ARP) [2] datagrams for
   transmission across ARCNET [3] using the "ARCNET Packet Header
   Definition Standard" [4].  This memo offers a replacement for RFC
   1051.  RFC 1051 uses an ARCNET framing protocol which limits
   unfragmented IP packets to 508 octets [5].

2.  ARCNET Packet Format

   In 1989, Apple Computers, Novell, ACTINET Systems, Standard
   Microsystems, and Pure Data Research agreed to use the ARCNET
   datalink protocol defined in "ARCNET Packet Header Definition
   Standard" [4].  We'll begin with a brief description of that
   protocol.

2.1.  ARCNET Framing

   ARCNET hardware supports two types of frames: short frames, which are
   always 256 octets long, and long frames, which are always 512 octets
   long.  All frames begin with a hardware header and end with the
   client's data preceded by a software header.  Software places padding
   in the middle of the packet between the hardware header and the
   software header to make the frame the appropriate fixed length.
   Unbeknown to the software, the hardware removes this padding during
   transmission.

   Short frames can hold from 0 to 249 octets of client data.  Long
   frames can hold from 253 to 504 octets of client data.  To handle
   frames with 250, 251, or 252 octets of data, the datalink protocol



Provan                                                          [Page 1]

RFC 1201                      IP on ARCNET                 February 1991


   introduces a third frame type: the exception frame.

   These three frame formats are shown here.  Except as noted, each
   block represents one octet.


       Short Frame             Long Frame          Exception Frame

    +---------------+      +---------------+      +---------------+
    |     source    |      |     source    |      |     source    |
    +---------------+      +---------------+      +---------------+
    |  destination  |      |  destination  |      |  destination  |
    +---------------+      +---------------+      +---------------+
    |     offset    |      |       0       |      |       0       |
    +---------------+      +---------------+      +---------------+
    .     unused    .      |     offset    |      |     offset    |
    .  (offset - 3  .      +---------------+      +---------------+
    .     octets)   .      .     unused    .      .     unused    .
    +---------------+      .  (offset - 4  .      .  (offset - 4  .
    |  protocol ID  |      .     octets)   .      .     octets)   .
    +---------------+      +---------------+      +---------------+
    |  split flag   |      |  protocol ID  |      |  protocol ID  |
    +---------------+      +---------------+      +---------------+
    |   sequence    |      |  split flag   |      | flag: FF hex  |
    +    number     +      +---------------+      +---------------+
    |  (2 octets)   |      |   sequence    |      | padding: 0xFF |
    +---------------+      +    number     +      +---------------+
    .               .      |  (2 octets)   |      | padding: 0xFF |
    .  client data  .      +---------------+      +---------------+
    . (256 - offset .      .               .      | (protocol ID) |
    .   - 4 octets) .      .               .      +---------------+
    .               .      .               .      |  split flag   |
    +---------------+      .               .      +---------------+
                           .               .      |   sequence    |
                           .  client data  .      +    number     +
                           . (512 - offset .      |  (2 octets)   |
                           .   - 4 octets) .      +---------------+
                           .               .      .               .
                           .               .      .  client data  .
                           .               .      . (512 - offset .
                           .               .      .   - 8 octets) .
                           .               .      .               .
                           +---------------+      +---------------+

      These packet formats are presented as software would see them
      through ARCNET hardware.  [3] refers to this as the "buffer
      format".  The actual format of packets on the wire is a little
      different: the destination ID is duplicated, the padding between



Provan                                                          [Page 2]

RFC 1201                      IP on ARCNET                 February 1991


      the offset field and the protocol ID field is not transmitted, and
      there's some hardware framing information.  In addition, the
      hardware transmits special packets for buffer allocation and
      reception acknowledgement which are not described here [3].

2.2.  Datalink Layer Fragmentation

   ARCNET hardware limits individual frames to 512 octets, which allows
   504 octets of client data.  This ARCNET datalink protocol allows the
   datalink layer to break packets into as many as 120 fragments for
   transmission.  This allows ARCNET clients to transmit up to 60,480
   octets in each packet.

   The "split flag" describes datalink layer packet fragments.  There
   are three cases: an unfragmented packet, the first fragment of a
   fragmented packet, and any other fragment of a fragmented packet.

   Unfragmented packets always have a split flag of zero.

   The first fragment of a fragmented packet has a split flag equal to
   ((T-2)*2)+1, where T is the total number of fragments to expect for
   the packet.

   Subsequent fragments of a fragmented packet have a split flag equal
   to ((N-1)*2), where N is the number of this fragment.  For example,
   the fourth fragment of a packet will always have the split flag value
   of six ( (4-1)*2 ).

   The receiving station can identify the last fragment of a packet
   because the value of its 8-bit split flag will be one greater than
   the split flag of the first fragment of the packet.

      A previous version of this ARCNET datalink protocol definition
      only allowed packets which could be contained in two fragments.
      In this older standard, the only legal split flags were 0, 1, and
      2.  Compatibility with this older standard can be maintained by
      configuring the maximum client data length to 1008 octets.

   No more that 120 fragments are allowed.  The highest legal split flag
   value is EE hex.  (Notice that the split flag value FF hex is used to
   flag exception packets in what would otherwise be a long packet's
   split flag field.)

   All fragments of a single packet carry the same sequence number.

2.3.  Datalink Layer Reassembly

   The previous section provides enough information to implement



Provan                                                          [Page 3]

RFC 1201                      IP on ARCNET                 February 1991


   datalink reassembly.  To avoid buffer allocation problems during
   reassembly, we recommend allocating enough space for the entire
   reassembled packet when the first fragment arrives.

   Since fragments are sent in order, the reassembly procedure can give
   up on a packet if it receives a fragment out of order.  There is one
   exception, however.  It is possible for successfully received
   fragments to be retransmitted.  Reassembly software should ignore
   repetitious fragments without giving up on the packet.

   Since fragments will be sent briskly, the reassembly procedure can
   give up on a partially reassembled packet if no additional fragments
   for it arrive within a few seconds.

2.4.  Datalink Layer Retransmission

   For each unicast ARCNET packet, the hardware indicates to the sender
   whether or not the receiver acknowledged the packet.  To improve
   reliability, datalink implementations are encouraged to retransmit
   unacknowledged packets or packet fragments.  Several retransmissions
   may be necessary.  Broadcast packets, however, are never acknowledged
   and, therefore, they should never be retransmitted.

   Packets which are successfully received may not be successfully