RFC 2143

Encapsulating IP with the Small Computer System Interface

πŸ“… published May 1997, from ietf

RFC 2143: Encapsulating IP with the Small Computer System Interface πŸŽ€

okay bestie, this one is from May 1997 and it's an Experimental doc, so no official standard here, just a fun idea people can poke at πŸ§ͺ. It's written by Ben Elliston from Compucat Research, aka B. Elliston on the header πŸ’…. The title block doesn't list anything it obsoletes or updates, so it's standing on its own ✨


Status of This Memo πŸ“

This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited πŸ¦‹


Table of Contents πŸ—‚οΈ

1.   Introduction . . . . . . . . . . . . . . . . . . . . . . .  1
2.   Brief background to the Small Computer System Interface  .  2
3.   Link Encapsulation . . . . . . . . . . . . . . . . . . . .  3
4.   An Address Resolution Protocol . . . . . . . . . . . . . .  4
5.   Scalability  . . . . . . . . . . . . . . . . . . . . . . .  4
6.   Possible applications  . . . . . . . . . . . . . . . . . .  5
7.   Security considerations  . . . . . . . . . . . . . . . . .  5
8.   References . . . . . . . . . . . . . . . . . . . . . . . .  5
9.   Author's Address . . . . . . . . . . . . . . . . . . . . .  5

1. Introduction 🌸

okay so local area networks keep getting faster to handle all the high volume app data, and that opens the door for a whole class of network heavy problems that could be solved in small clusters of workstations with high bandwidth links between them πŸš€

here's the vibe: networks usually get slower the farther apart the hosts are. regional networks at 64Kbps are super common, and office networks at 100Mbps are everywhere, but the reverse setup is way less common πŸ’€

peripheral and memory connections have the same energy. memory right next to a CPU core can run at speeds equal to a gigabit network. and devices like disks can sit a number of metres away from their host while running way faster than current local area networks πŸ”₯

this document lays out a way to connect hosts running the TCP/IP protocol suite over a Small Computer System Interface (SCSI) bus. even though the distance between hosts is limited, SCSI lets close clusters of workstations talk to each other at speeds approaching 360 megabits per second 😭✨

and newer SCSI versions like serial SCSI are on the way, which means even faster communication over longer distances 🧚

2. Background to the Small Computer System Interface (SCSI) πŸ’œ

SCSI is a physical and data link protocol for hooking peripherals up to hosts. devices plug into a bus on their own and send synchronous or asynchronous messages to other devices πŸ”Œ

each device has a numeric identifier (ID). in the original SCSI protocol, you pick a user-selectable SCSI ID between 0 and 7. Wide SCSI goes up to 0 through 15 πŸ”’ the most typical setup is a host adapter plus one or more SCSI-capable peripherals that respond to asynchronous messages from that host adapter πŸ€“

this is the part that matters most for using SCSI as a data link for the Internet protocols: a SCSI device has to act as either an "initiator" (the one generating SCSI commands/requests) or a "target" (the one that responds to commands from the initiator). this model is correct for a master/slave relationship between a host adapter and devices πŸ‘‘ an initiator only gets a message addressed to it in response to a command it sent earlier, and a target always sends back a response to every command it gets πŸ’…

but that's giving "not peer-to-peer" πŸ™ˆ it's unsuitable for the peer-to-peer model you'd need for multiple host adapters to send SCSI commands to each other asynchronously without extra bus traffic. some host adapters also might refuse to accept a message from another adapter, since they only expect to start SCSI commands. so SCSI adapters used for IP encapsulation need to support what's called "target mode", with software device driver support to pass those messages up to higher layer modules for processing 🫢

the ANSI SCSI standard defines classes of peripherals that can be connected with the SCSI protocol. one of those classes is "communication devices" [1] πŸ“š

the standard defines three message types that can carry a general-purpose payload across communication devices. each one is known as the "SEND MESSAGE" message type, but the size and structure of the message header is different for each. the three header forms are six (6), ten (10) and twelve (12) bytes long ✨

it was decided that the ten byte header gives the most flexibility for encapsulating version 4 IP datagrams, for these reasons:

  1. the transfer length field is 16 bits, which is perfectly matched to the datagram length field in IP version 4. IP implementations will run efficiently because datagrams will never be fragmented over SCSI networks πŸƒβ€β™€οΈ
  2. the SCSI "stream select" field was designed to let a device specify which stream of data a block belongs to, and it can be used to encode the payload type (kind of like the Ethernet frame type field). for consistency, the lowest four bits of the "stream select" field should match the set of values assigned by the IEEE for Ethernet protocol types 🧠

encapsulating an IP datagram inside a SCSI message is pretty straightforward πŸŽ€

+------------------+-----------------------------------+
| SCSI header      | IP datagram                       |
+------------------+-----------------------------------+

the fields of the SCSI header should be filled in like this:

Byte  0:    0x2A (SEND_MESSAGE(10) opcode)
Byte  1:    Logical unit number encoded into top 3 bits | 0x00
Byte  2:    0x00
Byte  3:    0x00
Byte  4:    0x00
Byte  5:    Protocol type encoded into lowest 4 bits | 0x00
Byte  6:    0x00
Bytes 7/8:  IP datagram length, big endian representation
Byte  9:    0x00

4. An Address Resolution Protocol πŸ”

when IP decides the next hop for a datagram is going to be on a SCSI network that's supported by a SCSI IP network interface implementation, it needs to get a data link address so it can deliver the datagram πŸ“¬

interfaces like Ethernet already have well-known ways of getting the media address for an Internet protocol address, the most common being the Address Resolution Protocol (ARP). in existing implementations, the forwarding host "yells" using a broadcast media address and waits for the named host to respond πŸ“’

SCSI doesn't have a broadcast data link address, though 😭 the workaround is to simulate a broadcast by doing a series of round-robin transmissions to each target. depending on the SCSI protocol in use, that means upward of seven independent bus accesses. that's not terribly inefficient as long as you combine it with a good ARP caching policy πŸ’… one more possible optimisation is negative ARP caching, where incomplete ARP bindings aren't queried again for some period of time ⏳

5. Scalability 🌈

a bus network that can span less than ten metres and only support eight hosts might sound questionable, but IP and especially IP routing make this architecture way more scalable πŸ€”

imagine eight hosts on a SCSI bus, where each host is a multi-homed host with a second host adapter connecting seven more hosts. with IP packet routing set up, all 64 hosts can talk to each other at high speed in a packet switched manner 🀯

depending on what the I/O bus of certain workstations can handle, a multi-homed host might even have more SCSI host adapters, which would let you build centralised star configurations 🌟

and honestly? for not much money you can build massively parallel virtual machines on top of IP running over the high-bandwidth SCSI protocol. it's iconic πŸ‘‘

6. Possible Applications 🧚

researchers have looked into "networks of workstations" and how their performance compares to supercomputers πŸ’» one thing they've noticed so far is that the channels used to move executable code between hosts for execution are bottlenecks 🚧 a very high-speed network built on the Internet protocol would let existing application software move over to a high-bandwidth environment without a hitch ✨

other applications that have been considered include server clusters for fault-tolerant NFS, World-Wide Web and database services πŸ“

7. Security Considerations πŸ”

sending IP datagrams across a SCSI bus raises security issues that are similar to other local area networking architectures 😬 and the scale of the security problems for protocols above the data link layer should be obvious to any reader who's current on Internet security ⚠️

8. References πŸ“š

[1]  ANSI X3T9 Technical Committee, "Small Computer System
     Interface - 2", X3T9.2, Project 375D, Revision 10L, September
     1993.

9. Author's Address πŸ’Œ

Ben Elliston
Compucat Research Pty Limited
Box 7305 Canberra Mail Centre
Canberra ACT 2610
Australia

Phone: +61 6 295 1331
Fax:   +61 6 295 1855
Email: ben.elliston@compucat.com.au
πŸ“¦ where this page comes from