Browse Prior Art Database

Transmitting IP traffic over ARCNET networks (RFC1201)

IP.com Disclosure Number: IPCOM000002015D
Original Publication Date: 1991-Feb-01
Included in the Prior Art Database: 2019-Feb-11
Document File: 7 page(s) / 10K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

D. Provan: AUTHOR

Related Documents

10.17487/RFC1201: DOI

Abstract

This memo defines a protocol for the transmission of IP and ARP packets over the ARCnet Local Area Network.This memo specifies a method of encapsulating Internet Protocol (IP) and Address Resolution Protocol (ARP) datagrams for transmission across ARCNET using the "ARCNET Packet Header Definition Standard". [STANDARDS-TRACK]

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 23% of the total text.

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: 0xF...

Processing...
Loading...