home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1201 < prev    next >
Text File  |  1991-04-21  |  17KB  |  395 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          D. Provan
  8. Request for Comments: 1201                                  Novell, Inc.
  9. Obsoletes:  RFC 1051                                       February 1991
  10.  
  11.  
  12.               Transmitting IP Traffic over ARCNET Networks
  13.  
  14. Status of this Memo
  15.  
  16.    This memo defines a protocol for the transmission of IP and ARP
  17.    packets over the ARCnet Local Area Network.  This RFC specifies an
  18.    IAB standards track protocol for the Internet community, and requests
  19.    discussion and suggestions for improvements.  Please refer to the
  20.    current edition of the "IAB Official Protocol Standards" for the
  21.    standardization state and status of this protocol.  Distribution of
  22.    this memo is unlimited.
  23.  
  24. 1.  Introduction
  25.  
  26.    This memo specifies a method of encapsulating Internet Protocol (IP)
  27.    [1] and Address Resolution Protocol (ARP) [2] datagrams for
  28.    transmission across ARCNET [3] using the "ARCNET Packet Header
  29.    Definition Standard" [4].  This memo offers a replacement for RFC
  30.    1051.  RFC 1051 uses an ARCNET framing protocol which limits
  31.    unfragmented IP packets to 508 octets [5].
  32.  
  33. 2.  ARCNET Packet Format
  34.  
  35.    In 1989, Apple Computers, Novell, ACTINET Systems, Standard
  36.    Microsystems, and Pure Data Research agreed to use the ARCNET
  37.    datalink protocol defined in "ARCNET Packet Header Definition
  38.    Standard" [4].  We'll begin with a brief description of that
  39.    protocol.
  40.  
  41. 2.1.  ARCNET Framing
  42.  
  43.    ARCNET hardware supports two types of frames: short frames, which are
  44.    always 256 octets long, and long frames, which are always 512 octets
  45.    long.  All frames begin with a hardware header and end with the
  46.    client's data preceded by a software header.  Software places padding
  47.    in the middle of the packet between the hardware header and the
  48.    software header to make the frame the appropriate fixed length.
  49.    Unbeknown to the software, the hardware removes this padding during
  50.    transmission.
  51.  
  52.    Short frames can hold from 0 to 249 octets of client data.  Long
  53.    frames can hold from 253 to 504 octets of client data.  To handle
  54.    frames with 250, 251, or 252 octets of data, the datalink protocol
  55.  
  56.  
  57.  
  58. Provan                                                          [Page 1]
  59.  
  60. RFC 1201                      IP on ARCNET                 February 1991
  61.  
  62.  
  63.    introduces a third frame type: the exception frame.
  64.  
  65.    These three frame formats are shown here.  Except as noted, each
  66.    block represents one octet.
  67.  
  68.  
  69.        Short Frame             Long Frame          Exception Frame
  70.  
  71.     +---------------+      +---------------+      +---------------+
  72.     |     source    |      |     source    |      |     source    |
  73.     +---------------+      +---------------+      +---------------+
  74.     |  destination  |      |  destination  |      |  destination  |
  75.     +---------------+      +---------------+      +---------------+
  76.     |     offset    |      |       0       |      |       0       |
  77.     +---------------+      +---------------+      +---------------+
  78.     .     unused    .      |     offset    |      |     offset    |
  79.     .  (offset - 3  .      +---------------+      +---------------+
  80.     .     octets)   .      .     unused    .      .     unused    .
  81.     +---------------+      .  (offset - 4  .      .  (offset - 4  .
  82.     |  protocol ID  |      .     octets)   .      .     octets)   .
  83.     +---------------+      +---------------+      +---------------+
  84.     |  split flag   |      |  protocol ID  |      |  protocol ID  |
  85.     +---------------+      +---------------+      +---------------+
  86.     |   sequence    |      |  split flag   |      | flag: FF hex  |
  87.     +    number     +      +---------------+      +---------------+
  88.     |  (2 octets)   |      |   sequence    |      | padding: 0xFF |
  89.     +---------------+      +    number     +      +---------------+
  90.     .               .      |  (2 octets)   |      | padding: 0xFF |
  91.     .  client data  .      +---------------+      +---------------+
  92.     . (256 - offset .      .               .      | (protocol ID) |
  93.     .   - 4 octets) .      .               .      +---------------+
  94.     .               .      .               .      |  split flag   |
  95.     +---------------+      .               .      +---------------+
  96.                            .               .      |   sequence    |
  97.                            .  client data  .      +    number     +
  98.                            . (512 - offset .      |  (2 octets)   |
  99.                            .   - 4 octets) .      +---------------+
  100.                            .               .      .               .
  101.                            .               .      .  client data  .
  102.                            .               .      . (512 - offset .
  103.                            .               .      .   - 8 octets) .
  104.                            .               .      .               .
  105.                            +---------------+      +---------------+
  106.  
  107.       These packet formats are presented as software would see them
  108.       through ARCNET hardware.  [3] refers to this as the "buffer
  109.       format".  The actual format of packets on the wire is a little
  110.       different: the destination ID is duplicated, the padding between
  111.  
  112.  
  113.  
  114. Provan                                                          [Page 2]
  115.  
  116. RFC 1201                      IP on ARCNET                 February 1991
  117.  
  118.  
  119.       the offset field and the protocol ID field is not transmitted, and
  120.       there's some hardware framing information.  In addition, the
  121.       hardware transmits special packets for buffer allocation and
  122.       reception acknowledgement which are not described here [3].
  123.  
  124. 2.2.  Datalink Layer Fragmentation
  125.  
  126.    ARCNET hardware limits individual frames to 512 octets, which allows
  127.    504 octets of client data.  This ARCNET datalink protocol allows the
  128.    datalink layer to break packets into as many as 120 fragments for
  129.    transmission.  This allows ARCNET clients to transmit up to 60,480
  130.    octets in each packet.
  131.  
  132.    The "split flag" describes datalink layer packet fragments.  There
  133.    are three cases: an unfragmented packet, the first fragment of a
  134.    fragmented packet, and any other fragment of a fragmented packet.
  135.  
  136.    Unfragmented packets always have a split flag of zero.
  137.  
  138.    The first fragment of a fragmented packet has a split flag equal to
  139.    ((T-2)*2)+1, where T is the total number of fragments to expect for
  140.    the packet.
  141.  
  142.    Subsequent fragments of a fragmented packet have a split flag equal
  143.    to ((N-1)*2), where N is the number of this fragment.  For example,
  144.    the fourth fragment of a packet will always have the split flag value
  145.    of six ( (4-1)*2 ).
  146.  
  147.    The receiving station can identify the last fragment of a packet
  148.    because the value of its 8-bit split flag will be one greater than
  149.    the split flag of the first fragment of the packet.
  150.  
  151.       A previous version of this ARCNET datalink protocol definition
  152.       only allowed packets which could be contained in two fragments.
  153.       In this older standard, the only legal split flags were 0, 1, and
  154.       2.  Compatibility with this older standard can be maintained by
  155.       configuring the maximum client data length to 1008 octets.
  156.  
  157.    No more that 120 fragments are allowed.  The highest legal split flag
  158.    value is EE hex.  (Notice that the split flag value FF hex is used to
  159.    flag exception packets in what would otherwise be a long packet's
  160.    split flag field.)
  161.  
  162.    All fragments of a single packet carry the same sequence number.
  163.  
  164. 2.3.  Datalink Layer Reassembly
  165.  
  166.    The previous section provides enough information to implement
  167.  
  168.  
  169.  
  170. Provan                                                          [Page 3]
  171.  
  172. RFC 1201                      IP on ARCNET                 February 1991
  173.  
  174.  
  175.    datalink reassembly.  To avoid buffer allocation problems during
  176.    reassembly, we recommend allocating enough space for the entire
  177.    reassembled packet when the first fragment arrives.
  178.  
  179.    Since fragments are sent in order, the reassembly procedure can give
  180.    up on a packet if it receives a fragment out of order.  There is one
  181.    exception, however.  It is possible for successfully received
  182.    fragments to be retransmitted.  Reassembly software should ignore
  183.    repetitious fragments without giving up on the packet.
  184.  
  185.    Since fragments will be sent briskly, the reassembly procedure can
  186.    give up on a partially reassembled packet if no additional fragments
  187.    for it arrive within a few seconds.
  188.  
  189. 2.4.  Datalink Layer Retransmission
  190.  
  191.    For each unicast ARCNET packet, the hardware indicates to the sender
  192.    whether or not the receiver acknowledged the packet.  To improve
  193.    reliability, datalink implementations are encouraged to retransmit
  194.    unacknowledged packets or packet fragments.  Several retransmissions
  195.    may be necessary.  Broadcast packets, however, are never acknowledged
  196.    and, therefore, they should never be retransmitted.
  197.  
  198.    Packets which are successfully received may not be successfully
  199.    acknowledged.  Consequently, retransmission by the datalink
  200.    implementation can cause duplicate packets or duplicate fragments.
  201.    Duplicate packets are not a problem for IP or ARP.  As mentioned in
  202.    the previous section, ARCNET reassembly support should ignore any
  203.    redundant fragments.
  204.  
  205. 3.  Transmitting IP and ARP Datagrams
  206.  
  207.    IP and ARP datagrams are carried in the client data area of ARCNET
  208.    packets.  Datalink support places each datagram in an appropriate
  209.    size ARCNET frame, fragmenting IP datagrams larger than 504 octets
  210.    into multiple frames as described in the previous section.
  211.  
  212. 4.  IP Address Mappings
  213.  
  214.    This section explains how each of the three basic 32-bit internet
  215.    address types are mapped to 8-bit ARCNET addresses.
  216.  
  217. 4.1.  Unicast Addresses
  218.  
  219.    A unicast IP address is mapped to an 8-bit ARCNET address using ARP
  220.    as specified in [2].  A later section covers the specific values
  221.    which should be used in ARP packets sent on ARCNET networks.
  222.  
  223.  
  224.  
  225.  
  226. Provan                                                          [Page 4]
  227.  
  228. RFC 1201                      IP on ARCNET                 February 1991
  229.  
  230.  
  231.       It is possible to assign IP addresses such that the last eight
  232.       bits are the same as the 8-bit ARCNET address.  This would allow
  233.       direct mapping of IP address to ARCNET address without using a
  234.       discovery protocol.  Some implementations might provide this as an
  235.       option, but it is not recommended practice.  Although such hard-
  236.       wired mapping is initially appealing, experience shows that ARP is
  237.       a much more flexible and convenient approach which has a very
  238.       small cost.
  239.  
  240. 4.2.  Broadcast Addresses
  241.  
  242.    All IP broadcast addresses must be mapped to the ARCNET broadcast
  243.    address of 0.
  244.  
  245.       Unlike unicast packets, ARCNET does not attempt to insure delivery
  246.       of broadcast packets, so they may be lost.  This will not have a
  247.       major impact on IP since neither IP nor ARP expect all packets to
  248.       be delivered.
  249.  
  250. 4.3.  Multicast Addresses
  251.  
  252.    Since ARCNET provides no support for multicasts, all IP multicast
  253.    addresses must be mapped to the ARCNET broadcast address of 0.
  254.  
  255. 5.  ARP
  256.  
  257.    The hardware address length is 1 octet for ARP packets sent over
  258.    ARCNET networks.  The ARP hardware type for ARCNET is 7.  ARP request
  259.    packets are broadcast by directing them to ARCNET broadcast address,
  260.    which is 0.
  261.  
  262. 6.  RARP
  263.  
  264.    Reverse Address Resolution Protocol [6] packets can also be
  265.    transmitted over ARCNET.  For the purposes of datalink transmission
  266.    and reception, RARP is identical to ARP and can be handled the same
  267.    way.  There are a few differences to notice, however, between RARP
  268.    when running over ARCNET, which has a one octet hardware address, and
  269.    Ethernet, which has a six octet hardware address.
  270.  
  271.    First, there are only 255 different hardware addresses for any given
  272.    ARCNET while there's an very large number of possible Ethernet
  273.    addresses.  Second, ARCNET hardware addresses are more likely to be
  274.    duplicated on different ARCNET networks; Ethernet hardware addresses
  275.    will normally be globally unique.  Third, an ARCNET hardware address
  276.    is not as constant as an Ethernet address:  ARCNET hardware addresses
  277.    are set by switches, not fixed in ROM as they are on Ethernet.
  278.  
  279.  
  280.  
  281.  
  282. Provan                                                          [Page 5]
  283.  
  284. RFC 1201                      IP on ARCNET                 February 1991
  285.  
  286.  
  287. 7.  Maximum Transmission Unit
  288.  
  289.    The maximum IP packet length possible using this encapsulation method
  290.    is 60,480 octets.  Since this length is impractical, all ARCNET
  291.    implementations on a given ARCNET network will need to agree on a
  292.    smaller value.  Therefore, the maximum packet size MUST be
  293.    configurable in implementations of this specification.
  294.  
  295.    In any case, implementations must be able to send and receive IP
  296.    datagrams up to 576 octets in length, and are strongly encouraged to
  297.    handle IP datagrams up to 1500 octets in length.
  298.  
  299.    Implementations may accept arriving IP datagrams which are larger
  300.    than their configured maximum transmission unit.  They are not
  301.    required to discard such datagrams.
  302.  
  303.    To minimize the amount of ARCNET fragmentation, implementations may
  304.    want to aim at an optimum IP packet size of 504 bytes.  This avoids
  305.    the overhead of datalink fragmentation, but at the expense of
  306.    increasing the number of IP packets which must be handled by each
  307.    node in the path.  In addition to encouraging local applications to
  308.    generate smaller packets, an implementation might also use the TCP
  309.    maximum segment size option to indicate a desire for 464 octet TCP
  310.    segments [7], or it might  announce an IP MTU of 504 octets through
  311.    an MTU discovery mechanism such as [8].  These would inform non-
  312.    ARCNET nodes of the smaller optimum packet size.
  313.  
  314. 8.  Assigned Numbers
  315.  
  316.    Datapoint Corporation assigns ARCNET protocol IDs to identify
  317.    different protocols running on the same ARCNET medium.  For
  318.    implementations of this specification, Datapoint has assigned 212
  319.    decimal to IP, 213 decimal to ARP, and 214 decimal to RARP.  These
  320.    are not the numbers assigned to the IP encapsulation defined by RFC
  321.    1051 [5].  Implementations of RFC 1051 can exist on the same ARCNET
  322.    as implementations of this specification, although the two would not
  323.    be able to communicate with each other.
  324.  
  325.    The Internet Assigned Numbers Authority (IANA) assigns ARP hardware
  326.    type values.  It has assigned ARCNET the ARP hardware type of 7 [9].
  327.  
  328. Acknowledgements
  329.  
  330.    Several people have reviewed this specification and provided useful
  331.    input.  I'd like to thank Wesley Hardell at Datapoint and Troy Thomas
  332.    at Novell's Provo office for helping me figure out ARCNET.  In
  333.    addition, I particularly appreciate the effort by James VanBokkelen
  334.    at FTP Software who picked on me until all the fuzzy edges were
  335.  
  336.  
  337.  
  338. Provan                                                          [Page 6]
  339.  
  340. RFC 1201                      IP on ARCNET                 February 1991
  341.  
  342.  
  343.    smoothed out.
  344.  
  345.    The pioneering work in transmitting IP traffic on ARCNET networks was
  346.    done by Philippe Prindeville.
  347.  
  348. References
  349.  
  350.    [1] Postel, J., "Internet Protocol", RFC 791, DARPA, September 1981.
  351.  
  352.    [2] Plummer, D., "An Ethernet Address Resolution Protocol", RFC 826,
  353.        MIT, November 1982.
  354.  
  355.    [3] Datapoint, Corp., "ARCNET Designer's Handbook", Document Number
  356.        61610, 2nd Edition, Datapoint Corporation, 1988.
  357.  
  358.    [4] Novell, Inc., "ARCNET Packet Header Definition Standard", Novell,
  359.        Inc., November 1989.
  360.  
  361.    [5] Prindeville, P., "A Standard for the Transmission of IP Datagrams
  362.        and ARP Packets over ARCNET Networks", RFC 1051, McGill
  363.        University, March 1988.
  364.  
  365.    [6] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse
  366.        Address Resolution Protocol", RFC 903, Stanford, June 1984.
  367.  
  368.    [7] Postel, J., "Transmission Control Protocol", RFC 793, DARPA,
  369.        September 1981.
  370.  
  371.    [8] Mogul, J., Kent, C., Partridge, C., and K. McCloghrie, "IP MTU
  372.        Discovery Options", RFC 1063, DEC, BBN, TWG, July 1988.
  373.  
  374.    [9] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060,
  375.        USC/Information Sciences Institute, March 1990.
  376.  
  377. Security Considerations
  378.  
  379.    Security issues are not discussed in this memo.
  380.  
  381. Author's Address
  382.  
  383.    Don Provan
  384.    Novell, Inc.
  385.    2180 Fortune Drive
  386.    San Jose, California, 95131
  387.  
  388.    Phone: (408) 473-8440
  389.    EMail: donp@Novell.Com
  390.  
  391.  
  392.  
  393.  
  394. Provan                                                          [Page 7]
  395.