Draft Version 1, 2008-09-02  Matthew Wilcox <matthew@wil.cx>

A new design for the USBIP protocol.  See discussion at
http://marc.info/?l=linux-kernel&m=122001863119269&w=2 and followups.


USBIP allows the transport of USB transactions over a network.  It is
fundamentally a call/reply protocol.  It is also unidirectional -
the host calls the client, and the client replies.  The client does
not call the host.  It can be run over packet protocols directly or,
by encapsulating with RM, over stream protocols such as TCP.

If using a streaming protocol such as TCP, all packets start with a
Record Marker.  This is simply a 31-bit quantity representing the length.
If the packet is >2^31 bits in size, the top bit is set to indicate
the next RM should be appended to this one.  See RFC 1831 section 10.
This is transmitted in network (big) endian.

The first 4 bytes of every packet are an identifier for the call.  This is
chosen by the caller and is opaque to the receiver.  The receiver should
copy this value to the reply.

The second 4 bytes of every call is the call number.  These are defined
in the table below and transmitted in network (big) endian:

Calls:

Get version		1
List exported devices	2
Claim device		3
Release device		4
Submit control command	5 (*)
Submit data command	6 (*)
Submit isoc command	7 (*)
Submit irq command	8 (*)
Unlink command		9

(*) For submit commands, the direction and endpoint number are encoded
in the top byte of the call number.  The direction is encoded in bit 31;
the endpoint as bits 24-27.  Bits 28-30 are reserved.


Similarly, the second 4 bytes of every reply reports the status of the
call.  The possible values for status are defined in the table below:

Status:

Success			0
Unknown call		1
Device not known	2
Device busy		3


ASCII strings are used in this protocol to identify devices.  Since they
are short identifiers, they are represented as a single byte for the
length, followed by 'length' bytes of ASCII data.  Unicode, while considered,
is not thought necessary to identify devices.


Get Version Call:

4 bytes call identifier
4 bytes command

Get Version Reply:

4 bytes call identifier
4 bytes status
4 bytes version number (1 for this version)


List Exports Call:

4 bytes call identifier
4 bytes command

List Exports Reply:

4 bytes call identifier
4 bytes status
4 bytes count (network order)
count ASCII strings


Claim Device Call:
4 bytes call identifier
4 bytes command
ASCII string device

Claim Device Reply:
4 bytes call identifier
4 bytes status


Release Device Call:
4 bytes call identifier
4 bytes command
ASCII string device

Release Device Reply:
4 bytes call identifier
4 bytes status


Submit Control Command Call:

4 bytes call identifier
4 bytes command, direction and endpoint
4 bytes length
8 bytes setup
length bytes data (if direction is 'out')

Submit Control Command Reply:

4 bytes call identifier
4 bytes status
4 bytes length
length bytes data (if direction was in)


Submit Data Command Call:

4 bytes call identifier
4 bytes command, direction and endpoint
4 bytes length
length bytes data (if direction is 'out')

Submit Data Command Reply:

4 bytes call identifier
4 bytes status
4 bytes length
length bytes data (if direction was in)


Submit Isoc Command Call:
Submit Isoc Command Reply:

To Be Defined.


Submit IRQ Command Call:
Submit IRQ Command Reply:

To Be Defined.


Unlink Command Call:
4 bytes call identifier
4 bytes command
4 bytes victim seqnum

Unlink Command Reply:
4 bytes call identifier
4 bytes status