As per Relevance of the word hardware, we have this rfc below:
Network Working Group D.
Request for Comments: 1201 Novell, Inc
Obsoletes: RFC 1051 February 1991
Transmitting IP Traffic over ARCNET
Status of this
This memo defines a protocol for the transmission of IP and
packets over the ARCnet Local Area Network. This RFC specifies
IAB standards track protocol for the Internet community, and
discussion and suggestions for improvements. Please refer to
current edition of the "IAB Official Protocol Standards" for
standardization state and status of this protocol. Distribution
this memo is unlimited
1.
This memo specifies a method of encapsulating Internet Protocol (IP
[1] and Address Resolution Protocol (ARP) [2] datagrams
transmission across ARCNET [3] using the "ARCNET Packet
Definition Standard" [4]. This memo offers a replacement for
1051. RFC 1051 uses an ARCNET framing protocol which
unfragmented IP packets to 508 octets [5].
2. ARCNET Packet
In 1989, Apple Computers, Novell, ACTINET Systems,
Microsystems, and Pure Data Research agreed to use the
datalink protocol defined in "ARCNET Packet Header
Standard" [4]. We'll begin with a brief description of
protocol
2.1. ARCNET
ARCNET hardware supports two types of frames: short frames, which
always 256 octets long, and long frames, which are always 512
long. All frames begin with a hardware header and end with
client's data preceded by a software header. Software places
in the middle of the packet between the hardware header and
software header to make the frame the appropriate fixed length
Unbeknown to the software, the hardware removes this padding
transmission
Short frames can hold from 0 to 249 octets of client data.
frames can hold from 253 to 504 octets of client data. To
frames with 250, 251, or 252 octets of data, the datalink
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,
block represents one octet
Short Frame Long Frame Exception
+---------------+ +---------------+ +---------------+
| 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
through ARCNET hardware. [3] refers to this as the "
format". The actual format of packets on the wire is a
different: the destination ID is duplicated, the padding
Provan [Page 2]
RFC 1201 IP on ARCNET February 1991
the offset field and the protocol ID field is not transmitted,
there's some hardware framing information. In addition,
hardware transmits special packets for buffer allocation
reception acknowledgement which are not described here [3].
2.2. Datalink Layer
ARCNET hardware limits individual frames to 512 octets, which
504 octets of client data. This ARCNET datalink protocol allows
datalink layer to break packets into as many as 120 fragments
transmission. This allows ARCNET clients to transmit up to 60,480
octets in each packet
The "split flag" describes datalink layer packet fragments.
are three cases: an unfragmented packet, the first fragment of
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
((T-2)*2)+1, where T is the total number of fragments to expect
the packet
Subsequent fragments of a fragmented packet have a split flag
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
of six ( (4-1)*2 ).
The receiving station can identify the last fragment of a
because the value of its 8-bit split flag will be one greater
the split flag of the first fragment of the packet
A previous version of this ARCNET datalink protocol
only allowed packets which could be contained in two fragments
In this older standard, the only legal split flags were 0, 1,
2. Compatibility with this older standard can be maintained
configuring the maximum client data length to 1008 octets
No more that 120 fragments are allowed. The highest legal split
value is EE hex. (Notice that the split flag value FF hex is used
flag exception packets in what would otherwise be a long packet'
split flag field.)
All fragments of a single packet carry the same sequence number
2.3. Datalink Layer
The previous section provides enough information to
Provan [Page 3]
RFC 1201 IP on ARCNET February 1991
datalink reassembly. To avoid buffer allocation problems
reassembly, we recommend allocating enough space for the
reassembled packet when the first fragment arrives
Since fragments are sent in order, the reassembly procedure can
up on a packet if it receives a fragment out of order. There is
exception, however. It is possible for successfully
fragments to be retransmitted. Reassembly software should
repetitious fragments without giving up on the packet
Since fragments will be sent briskly, the reassembly procedure
give up on a partially reassembled packet if no additional
for it arrive within a few seconds
2.4. Datalink Layer
For each unicast ARCNET packet, the hardware indicates to the
whether or not the receiver acknowledged the packet. To
reliability, datalink implementations are encouraged to
unacknowledged packets or packet fragments. Several
may be necessary. Broadcast packets, however, are never
and, therefore, they should never be retransmitted
Packets which are successfully received may not be
acknowledged. Consequently, retransmission by the
implementation can cause duplicate packets or duplicate fragments
Duplicate packets are not a problem for IP or ARP. As mentioned
the previous section, ARCNET reassembly support should ignore
redundant fragments
3. Transmitting IP and ARP
IP and ARP datagrams are carried in the client data area of
packets. Datalink support places each datagram in an
size ARCNET frame, fragmenting IP datagrams larger than 504
into multiple frames as described in the previous section
4. IP Address
This section explains how each of the three basic 32-bit
address types are mapped to 8-bit ARCNET addresses
4.1. Unicast
A unicast IP address is mapped to an 8-bit ARCNET address using
as specified in [2]. A later section covers the specific
which should be used in ARP packets sent on ARCNET networks
Provan [Page 4]
RFC 1201 IP on ARCNET February 1991
It is possible to assign IP addresses such that the last
bits are the same as the 8-bit ARCNET address. This would
direct mapping of IP address to ARCNET address without using
discovery protocol. Some implementations might provide this as
option, but it is not recommended practice. Although such hard
wired mapping is initially appealing, experience shows that ARP
a much more flexible and convenient approach which has a
small cost
4.2. Broadcast
All IP broadcast addresses must be mapped to the ARCNET
address of 0.
Unlike unicast packets, ARCNET does not attempt to insure
of broadcast packets, so they may be lost. This will not have
major impact on IP since neither IP nor ARP expect all packets
be delivered
4.3. Multicast
Since ARCNET provides no support for multicasts, all IP
addresses must be mapped to the ARCNET broadcast address of 0.
5.
The hardware address length is 1 octet for ARP packets sent
ARCNET networks. The ARP hardware type for ARCNET is 7. ARP
packets are broadcast by directing them to ARCNET broadcast address
which is 0.
6.
Reverse Address Resolution Protocol [6] packets can also
transmitted over ARCNET. For the purposes of datalink
and reception, RARP is identical to ARP and can be handled the
way. There are a few differences to notice, however, between
when running over ARCNET, which has a one octet hardware address,
Ethernet, which has a six octet hardware address
First, there are only 255 different hardware addresses for any
ARCNET while there's an very large number of possible
addresses. Second, ARCNET hardware addresses are more likely to
duplicated on different ARCNET networks; Ethernet hardware
will normally be globally unique. Third, an ARCNET hardware
is not as constant as an Ethernet address: ARCNET hardware
are set by switches, not fixed in ROM as they are on Ethernet
Provan [Page 5]
RFC 1201 IP on ARCNET February 1991
7. Maximum Transmission
The maximum IP packet length possible using this encapsulation
is 60,480 octets. Since this length is impractical, all
implementations on a given ARCNET network will need to agree on
smaller value. Therefore, the maximum packet size MUST
configurable in implementations of this specification
In any case, implementations must be able to send and receive
datagrams up to 576 octets in length, and are strongly encouraged
handle IP datagrams up to 1500 octets in length
Implementations may accept arriving IP datagrams which are
than their configured maximum transmission unit. They are
required to discard such datagrams
To minimize the amount of ARCNET fragmentation, implementations
want to aim at an optimum IP packet size of 504 bytes. This
the overhead of datalink fragmentation, but at the expense
increasing the number of IP packets which must be handled by
node in the path. In addition to encouraging local applications
generate smaller packets, an implementation might also use the
maximum segment size option to indicate a desire for 464 octet
segments [7], or it might announce an IP MTU of 504 octets
an MTU discovery mechanism such as [8]. These would inform non
ARCNET nodes of the smaller optimum packet size
8. Assigned
Datapoint Corporation assigns ARCNET protocol IDs to
different protocols running on the same ARCNET medium.
implementations of this specification, Datapoint has assigned 212
decimal to IP, 213 decimal to ARP, and 214 decimal to RARP.
are not the numbers assigned to the IP encapsulation defined by
1051 [5]. Implementations of RFC 1051 can exist on the same
as implementations of this specification, although the two would
be able to communicate with each other
The Internet Assigned Numbers Authority (IANA) assigns ARP
type values. It has assigned ARCNET the ARP hardware type of 7 [9].
Several people have reviewed this specification and provided
input. I'd like to thank Wesley Hardell at Datapoint and Troy
at Novell's Provo office for helping me figure out ARCNET.
addition, I particularly appreciate the effort by James
at FTP Software who picked on me until all the fuzzy edges
Provan [Page 6]
RFC 1201 IP on ARCNET February 1991
smoothed out
The pioneering work in transmitting IP traffic on ARCNET networks
done by Philippe Prindeville
[1] Postel, J., "Internet Protocol", RFC 791, DARPA, September 1981.
[2] Plummer, D., "An Ethernet Address Resolution Protocol", RFC 826,
MIT, November 1982.
[3] Datapoint, Corp., "ARCNET Designer's Handbook", Document
61610, 2nd Edition, Datapoint Corporation, 1988.
[4] Novell, Inc., "ARCNET Packet Header Definition Standard", Novell
Inc., November 1989.
[5] Prindeville, P., "A Standard for the Transmission of IP
and ARP Packets over ARCNET Networks", RFC 1051,
University, March 1988.
[6] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A
Address Resolution Protocol", RFC 903, Stanford, June 1984.
[7] Postel, J., "Transmission Control Protocol", RFC 793, DARPA
September 1981.
[8] Mogul, J., Kent, C., Partridge, C., and K. McCloghrie, "IP
Discovery Options", RFC 1063, DEC, BBN, TWG, July 1988.
[9] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060,
USC/Information Sciences Institute, March 1990.
Security
Security issues are not discussed in this memo
Author's
Don
Novell, Inc
2180 Fortune
San Jose, California, 95131
Phone: (408) 473-8440
EMail: donp@Novell.
Provan [Page 7]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
