diff options
Diffstat (limited to 'private/ntos/ndis/testprot/docs')
| -rw-r--r-- | private/ntos/ndis/testprot/docs/arcnet.doc | bin | 0 -> 41019 bytes | |||
| -rw-r--r-- | private/ntos/ndis/testprot/docs/rfc1051 | 227 | ||||
| -rw-r--r-- | private/ntos/ndis/testprot/docs/rfc1201 | 388 |
3 files changed, 615 insertions, 0 deletions
diff --git a/private/ntos/ndis/testprot/docs/arcnet.doc b/private/ntos/ndis/testprot/docs/arcnet.doc Binary files differnew file mode 100644 index 000000000..db7a2302e --- /dev/null +++ b/private/ntos/ndis/testprot/docs/arcnet.doc diff --git a/private/ntos/ndis/testprot/docs/rfc1051 b/private/ntos/ndis/testprot/docs/rfc1051 new file mode 100644 index 000000000..7121f0019 --- /dev/null +++ b/private/ntos/ndis/testprot/docs/rfc1051 @@ -0,0 +1,227 @@ + + + + + + +Network Working Group P. Prindeville +Request for Comments: 1051 McGill University + March 1988 + + + A Standard for the Transmission of IP Datagrams + and ARP Packets over ARCNET Networks + + +Status of this Memo + + This RFC specifies a standard protocol for the Internet community. + Distribution of this memo is unlimited. + +Introduction + + This RFC specifies a standard method of encapsulating Internet + Protocol (IP) [1] and Address Resolution Protocol (ARP) [2] datagrams + on an ARCNET [3]. + +Acknowledgements + + The author wishes to express thanks to Robert Craig of the McGill + University Computing Centre and Bruce Hughes of Datapoint Corporation + for their generous support of facilities and information. I also + extend my gratitude to the readers of the PCIP mailing list for their + helpful ideas and comments. + +Frame Format + + IP and ARP datagrams are transmitted in standard ARCNET packets. As + required by Datapoint Corporation, the first octet of the data field + is reserved for the network layer protocol identification (the + "system code" in Datapoint nomenclature), and must contain the value + 240 (F0 hex) for IP or 241 (F1 hex) for ARP. The ARP hardware + address type for ARCNET is 7 [9]. + + ARCNET supports packet formats containing 1-253 octets of data + (normal format) and 257-508 octets of data (extended format), + inclusive of system code. Note that there exists a range of data + lengths (254-256) which are 'forbidden'. IP packets within this + range should be padded (with octets of zero) to meet the minimum + extended packet size of 257 data octets. This padding is not part of + the IP packet and is not included in the total length field of the IP + header. + + + + + + +Prindeville [Page 1] + +RFC 1051 IP and ARP on ARCNET March 1988 + + + On networks where some hosts do not support extended packet format, + the IP Maximum Transmission Unit (MTU) should be set to 253, though + implementors are encouraged to support the extended packet format + mode of operation. + + Because the ARCNET maximum packet length is less than the Internet + default MTU, implementations are strongly encouraged to support IP + level fragmentation and reassembly. Hosts not supporting this should + take steps to discourage others from sending fragmented packets, such + as using the TCP Maximum Segment Size option [4]. + + The frame format is: + + Normal Packet Extended Packet + +----------------+ +----------------+ + | ALERT* | | ALERT* | + +----------------+ +----------------+ + | SOH (1) | | SOH (1) | + +----------------+ +----------------+ + | SID | | SID | + +----------------+ +----------------+ + | | | | + + DID + + DID + + | | | | + +----------------+ +----------------+ + | COUNT | | NUL (0) | + +----------------+ + + + | SYSTEM CODE | | COUNT | + +----------------+ +----------------+ + | | | SYSTEM CODE | + : DATA : +----------------+ + | | | | + +----------------+ : DATA : + | | | | + + CRC + +----------------+ + | | | | + +----------------+ + CRC + + | | + +----------------+ + + ALERT*: Six mark bits signifying the beginning of a frame. + SID: Sender's node ID. + DID: Receipient's node ID (repeated for reliability). + COUNT: Length of data and system code (one's complement). + SYSTEM CODE: 240 for IP, 241 for ARP (decimal). + DATA: Is either an IP or an ARP packet, padded with NULs so + as to not be between 254 and 256 octets long. + CRC: Cyclic redundancy check (CRC-16). + + + +Prindeville [Page 2] + +RFC 1051 IP and ARP on ARCNET March 1988 + + +Address Mappings + + The mappings between 32-bit Internet addresses to 8-bit ARCNET + addresses can be done several ways, recommended are: + + Host Number Extraction + + The easiest thing to do is to use the last eight bits of host + number part of the Internet address as the host's node id. This + has been implemented on Experimental Ethernet [5] and ProNET-10 + [6]. + + Dynamic Discovery + + Mappings between 32-bit Internet addresses and 8-bit ARCNET node + ids could be accomplished through ARP. Internet addresses are + assigned arbitrarily on some Internet networks. All + implementations supporting ARP must have a means of disabling ARP + and using the above Host Number Extraction method of address + mapping so that systems may interoperate. + + The use of ARP is optional. However, ARP is desirable when using + IP implementations that don't support subnetting [7], as in the + Proxy ARP scenario [8]. + +Broadcast Address + + The broadcast Internet address (the address on the network with a + host part of all binary ones) should be mapped to the broadcast node + id 0. + + + + + + + + + + + + + + + + + + + + + +Prindeville [Page 3] + +RFC 1051 IP and ARP on ARCNET March 1988 + + +References + + [1] Postel, J., "Internet Protocol", RFC-791, Network Information + Center, SRI, September 1981. + + [2] Plummer, D., "An Ethernet Address Resolution Protocol", RFC- 826, + Network Information Center, SRI, November 1982. + + [3] "ARCNET Designer's Handbook", Order Number 61610, Datapoint + Corporation, 1983. + + [4] Postel, J., "The TCP Maximum Segment Size Option and Related + Topics", RFC-879, Network Information Center, SRI, November 1983. + + [5] Postel, J., "A Standard for the Transmission of IP Datagrams over + Experimental Ethernet Networks", RFC-895, Network Information + Center, SRI, April 1984. + + [6] "ProNET-10 Model p1300 IBM PC Interface System Installation and + Programming Guide", Version 4.0, Proteon Inc., July 1986. + + [7] Mogul, J. and J. Postel, "Internet Standard Subnetting + Procedure", RFC-950, Network Information Center, SRI, October + 1984. + + [8] Carl-Mitchell, S. and J.S. Quarterman, "Using ARP to Implement + Transparent Subnet Gateways", RFC-1027, Network Information + Center, SRI, October 1987. + + [9] Reynolds, J., and J. Postel, "Assigned Numbers", RFC-1010, + Network Information Center, SRI, May 1987. + + + + + + + + + + + + + + + + + + + + +Prindeville [Page 4] + diff --git a/private/ntos/ndis/testprot/docs/rfc1201 b/private/ntos/ndis/testprot/docs/rfc1201 new file mode 100644 index 000000000..8f7d90890 --- /dev/null +++ b/private/ntos/ndis/testprot/docs/rfc1201 @@ -0,0 +1,388 @@ +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 + acknowledged. Consequently, retransmission by the datalink + implementation can cause duplicate packets or duplicate fragments. + Duplicate packets are not a problem for IP or ARP. As mentioned in + the previous section, ARCNET reassembly support should ignore any + redundant fragments. + +3. Transmitting IP and ARP Datagrams + + IP and ARP datagrams are carried in the client data area of ARCNET + packets. Datalink support places each datagram in an appropriate + size ARCNET frame, fragmenting IP datagrams larger than 504 octets + into multiple frames as described in the previous section. + +4. IP Address Mappings + + This section explains how each of the three basic 32-bit internet + address types are mapped to 8-bit ARCNET addresses. + +4.1. Unicast Addresses + + A unicast IP address is mapped to an 8-bit ARCNET address using ARP + as specified in [2]. A later section covers the specific values + 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 eight + bits are the same as the 8-bit ARCNET address. This would allow + direct mapping of IP address to ARCNET address without using a + discovery protocol. Some implementations might provide this as an + option, but it is not recommended practice. Although such hard- + wired mapping is initially appealing, experience shows that ARP is + a much more flexible and convenient approach which has a very + small cost. + +4.2. Broadcast Addresses + + All IP broadcast addresses must be mapped to the ARCNET broadcast + address of 0. + + Unlike unicast packets, ARCNET does not attempt to insure delivery + of broadcast packets, so they may be lost. This will not have a + major impact on IP since neither IP nor ARP expect all packets to + be delivered. + +4.3. Multicast Addresses + + Since ARCNET provides no support for multicasts, all IP multicast + addresses must be mapped to the ARCNET broadcast address of 0. + +5. ARP + + The hardware address length is 1 octet for ARP packets sent over + ARCNET networks. The ARP hardware type for ARCNET is 7. ARP request + packets are broadcast by directing them to ARCNET broadcast address, + which is 0. + +6. RARP + + Reverse Address Resolution Protocol [6] packets can also be + transmitted over ARCNET. For the purposes of datalink transmission + and reception, RARP is identical to ARP and can be handled the same + way. There are a few differences to notice, however, between RARP + when running over ARCNET, which has a one octet hardware address, and + Ethernet, which has a six octet hardware address. + + First, there are only 255 different hardware addresses for any given + ARCNET while there's an very large number of possible Ethernet + addresses. Second, ARCNET hardware addresses are more likely to be + duplicated on different ARCNET networks; Ethernet hardware addresses + will normally be globally unique. Third, an ARCNET hardware address + is not as constant as an Ethernet address: ARCNET hardware addresses + 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 Unit + + The maximum IP packet length possible using this encapsulation method + is 60,480 octets. Since this length is impractical, all ARCNET + implementations on a given ARCNET network will need to agree on a + smaller value. Therefore, the maximum packet size MUST be + configurable in implementations of this specification. + + In any case, implementations must be able to send and receive IP + datagrams up to 576 octets in length, and are strongly encouraged to + handle IP datagrams up to 1500 octets in length. + + Implementations may accept arriving IP datagrams which are larger + than their configured maximum transmission unit. They are not + required to discard such datagrams. + + To minimize the amount of ARCNET fragmentation, implementations may + want to aim at an optimum IP packet size of 504 bytes. This avoids + the overhead of datalink fragmentation, but at the expense of + increasing the number of IP packets which must be handled by each + node in the path. In addition to encouraging local applications to + generate smaller packets, an implementation might also use the TCP + maximum segment size option to indicate a desire for 464 octet TCP + segments [7], or it might announce an IP MTU of 504 octets through + an MTU discovery mechanism such as [8]. These would inform non- + ARCNET nodes of the smaller optimum packet size. + +8. Assigned Numbers + + Datapoint Corporation assigns ARCNET protocol IDs to identify + different protocols running on the same ARCNET medium. For + implementations of this specification, Datapoint has assigned 212 + decimal to IP, 213 decimal to ARP, and 214 decimal to RARP. These + are not the numbers assigned to the IP encapsulation defined by RFC + 1051 [5]. Implementations of RFC 1051 can exist on the same ARCNET + as implementations of this specification, although the two would not + be able to communicate with each other. + + The Internet Assigned Numbers Authority (IANA) assigns ARP hardware + type values. It has assigned ARCNET the ARP hardware type of 7 [9]. + +Acknowledgements + + Several people have reviewed this specification and provided useful + input. I'd like to thank Wesley Hardell at Datapoint and Troy Thomas + at Novell's Provo office for helping me figure out ARCNET. In + addition, I particularly appreciate the effort by James VanBokkelen + at FTP Software who picked on me until all the fuzzy edges were + + + +Provan [Page 6] + +RFC 1201 IP on ARCNET February 1991 + + + smoothed out. + + The pioneering work in transmitting IP traffic on ARCNET networks was + done by Philippe Prindeville. + +References + + [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 Number + 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 Datagrams + and ARP Packets over ARCNET Networks", RFC 1051, McGill + University, March 1988. + + [6] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse + 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 MTU + 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 Considerations + + Security issues are not discussed in this memo. + +Author's Address + + Don Provan + Novell, Inc. + 2180 Fortune Drive + San Jose, California, 95131 + + Phone: (408) 473-8440 + EMail: donp@Novell.Com + + + + +Provan [Page 7] |