idnits 2.17.1 draft-rfced-exp-elliston-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 231 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 25 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** There are 9 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 1997) is 9904 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 10 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT EXPIRES: SEPTEMBER 1997 INTERNET-DRAFT 3 Network Working Group B. Elliston 4 INTERNET-DRAFT Compucat Research 5 Category: Experimental March 1997 7 Encapsulating IP with the Small Computer System Interface 8 10 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet-Drafts 19 as reference material or to cite them other than as "work in 20 progress". 22 To learn the current status of any Internet-Draft, please check the 23 "1id-abstract.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Table of Contents 30 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 1 31 2. Brief background to the Small Computer System Interface . . 1 32 3. Link Encapsulation . . . . . . . . . . . . . . . . . . . . . 1 33 4. An Address Resolution Protocol . . . . . . . . . . . . . . . 1 34 5. Scalability . . . . . . . . . . . . . . . . . . . . . . . . 1 35 6. Possible applications . . . . . . . . . . . . . . . . . . . 1 36 7. Security considerations . . . . . . . . . . . . . . . . . . 1 37 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 1 38 9. Author's Address . . . . . . . . . . . . . . . . . . . . . . 1 40 1. Introduction 42 As the capacity of local area networks increases to meet the demands 43 of high volume application data, there is a class of network 44 intensive problems which may be applied to small clusters of 45 workstations with high bandwidth interconnection. 47 A general observation of networks is that the bit rate of the data 48 path typically decreases as the distance between hosts increases. 49 It is common to see regional networks connected at a rate of 64Kbps 50 and office networks connected at 100Mbps, but the inverse is far less 51 common. 53 The same is true of peripheral and memory interconnection. Memory 54 close to a CPU's core may run at speeds equivalent to a gigabit 55 network. More importantly, devices such as disks may connect a 56 number of metres away from its host at speeds well in excess of 57 current local area network capacity. 59 This document outlines a protocol for connecting hosts running the 60 TCP/IP protocol suite over a Small Computer System Interface (SCSI) 61 bus. Despite the limitation in the furthest distance between hosts, 62 SCSI permits close clusters of workstations to communicate between 63 each other at speeds approaching 360 megabits per second. 65 The proposed introduction of newer SCSI implementations such as serial 66 SCSI will bring much faster communication at greater distances. 68 2. Background to the Small Computer System Interface (SCSI) 70 SCSI defines a physical and data link protocol for connecting peripherals 71 to hosts. Devices connect autonomously to a bus and send synchronous 72 or asynchronous messages to other devices. 74 Devices are identified by a numeric identifier (ID). For the original SCSI 75 protocol, devices are given a user-selectable SCSI ID between 0 and 7. 76 Wide SCSI specifies a range of SCSI IDs between 0 and 15. The most typical 77 SCSI configuration comprises of a host adapter and one or more SCSI- 78 capable peripherals responding to asynchronous messages from the host 79 adapter. 81 The most critical aspect of the protocol with respect to its use as a data 82 link for the Internet protocols is that a SCSI device must act as an 83 ``initiator'' (generator of SCSI commands/requests) or a ``target'' 84 (a device which responds to SCSI commands from the initiator). This model 85 is correct for a master/slave relationship between host adapter and 86 devices. The only time an initiator receives a message addressed to it 87 is in response to a command issued by it in the past and a target device 88 always generates a response to every command it receives. 90 Clearly this is unsuitable for the peer-to-peer model required for 91 multiple host adapters to asynchronously send SCSI commands to one another 92 without surplus bus traffic. Furthermore, some host adapters may refuse 93 to accept a message from another adapter as it expects to only initiate 94 SCSI commands. This restriction to the protocol requires that SCSI 95 adapters used for IP encapsulation support what is known as ``target 96 mode'', with software device driver support to pass these messages up 97 to higher layer modules for processing. 99 3. Link Encapsulation 101 The ANSI SCSI standard defines classes of peripherals which may be 102 interconnected with the SCSI protocol. One of these is the class of 103 ``communication devices'' [1]. 105 The standard defines three message types capable of carrying a 106 general-purpose payload across communication devices. Each of these 107 are known as the ``SEND MESSAGE'' message type, but the size and 108 and structure of the message header differs amongst them. The three 109 forms of message header are six (6), ten (10) and twelve (12) bytes 110 long. 112 It was decided that the ten byte header offers the greatest 113 flexibility for encapsulating version 4 IP datagrams for the 114 following reasons: 116 a. The transfer length field is 16 bits in size which is perfectly 117 matched to the datagram length field in IP version 4. 118 Implementations of IP will run efficiently as datagrams 119 will never be fragmented over SCSI networks. 121 b. The SCSI "stream select" field, which was designed to permit 122 a device to specify the stream of data to which a block belongs, 123 may be used to encode the payload type (in a similar manner to 124 the Ethernet frame type field). For consistency, the lowest 125 four bits of the ``stream select'' field should match the 126 set of values assigned by the IEEE for Ethernet protocol types. 128 Encapsulating an IP datagram within a SCSI message is straightforward: 130 +------------------+-----------------------------------+ 131 | SCSI header | IP datagram | 132 +------------------+-----------------------------------+ 134 The fields of the SCSI header should be completed as follows: 136 Byte 0: 0x2A (SEND_MESSAGE(10) opcode) 137 Byte 1: Logical unit number encoded into top 3 bits | 0x00 138 Byte 2: 0x00 139 Byte 3: 0x00 140 Byte 4: 0x00 141 Byte 5: Protocol type encoded into lowest 4 bits | 0x00 142 Byte 6: 0x00 143 Bytes 7/8: IP datagram length, big endian representation 144 Byte 9: 0x00 146 4. An Address Resolution Protocol 148 When IP decides that the next hop for a datagram will be onto a SCSI 149 network supported by a SCSI IP network interface implementation, it is 150 necessary to acquire a data link address to deliver the datagram. 152 Network interfaces such as Ethernet have well-known methods for acquiring 153 the media address for an Internet protocol address, the most common being 154 the Address Resolution Protocol (ARP). In existing implementations, the 155 forwarding host ``yells'' using a broadcast media address and expects the 156 named host to respond. 158 The SCSI protocol does not provide a broadcast data link address. An 159 acceptable solution to the address resolution problem for a SCSI network 160 is to simulate a broadcast by performing a series of round-robin 161 transmissions to each target. Depending on the SCSI protocol being used, 162 this would require upward of seven independent bus accesses. This is 163 not grossly inefficient, however, if combined with an effective ARP 164 caching policy. A further possible optimisation is negative ARP caching, 165 whereby incomplete ARP bindings are not queried for some period in the 166 future. 168 5. Scalability 170 While the utility of a network architecture based around a bus network 171 which can span less than ten metres and support only eight hosts may 172 be questionable, the flexibility of IP and in particular, IP routing, 173 improves the scalability of this architecture. 175 Consider a network of eight hosts connected to a SCSI bus in which 176 each host acts as a multi-homed host with a second host adapter 177 connecting another seven hosts to it. When configured with IP packet 178 routing capability, each of the 64 total hosts may communicate with 179 one another at high speed in a packet switched manner. 181 Depending on the I/O bus capabilities of certain workstations, it may 182 also be possible to configure a multi-homed host with a greater number 183 of SCSI host adapters, permitting centralised star configurations to 184 be constructed. 186 It should be apparent that for little expense, massively parallel 187 virtual machines can be built based upon the IP protocol running over 188 the high-bandwidth SCSI protocol. 190 6. Possible Applications 192 Research has been made into the capability of ``networks of 193 workstations'', and their performance compared to supercomputers. An 194 observation that has been made thus far is that bottlenecks exist in 195 the channels by which executable code is transported between hosts for 196 execution. A very high-speed network architecture based around the 197 Internet protocol would permit a seamless transition of existing 198 application software to a high-bandwidth environment. 200 Other applications that have been considered are server clusters for 201 fault-tolerant NFS, World-Wide Web and database services. 203 7. Security Considerations 205 Transmitting IP datagrams across a SCSI bus raises similar security 206 issues to other local area networking architectures. The scale 207 of security problems relating to protocols above the data link layer 208 should be obvious to a reader current in Internet security. 210 8. References 212 [1] ANSI X3T9 Technical Committee, "Small Computer System 213 Interface - 2", X3T9.2, Project 375D, Revision 10L, September 214 1993. 216 9. Author's Address 218 Ben Elliston 219 Compucat Research Pty Limited 220 Box 7305 Canberra Mail Centre 221 Canberra ACT 2610 222 Australia 224 Phone: +61 6 295 1331 225 Fax: +61 6 295 1855 226 Email: ben.elliston@compucat.com.au