Network Working Group
`Request for Comments: 783
`
`Updates: TEN 133
`
`K. R. Sollins
`MIT
`June, 1981
`
`THE TFTP PROTOCOL (REVISION 2)
`
`Summary
`
`TFTP
`
`is
`
`a very
`
`simple protocol used to transfer files.
`
`It is from
`
`this that its name comes, Trivial File Transfer Protocol or TFTP.
`
`Each
`
`nonterminal
`
`packet is acknowledged separately. This document describes
`
`the protocol and its types of packets.
`
`The document also explains
`
`the
`
`reasons behind some of the design decisions.
`
`PMC Exhibit 2123
`
`Apple v. PMC
`|PR2016-00755
`
`Page 1
`
`1
`
`PMC Exhibit 2123
`Apple v. PMC
`IPR2016-00755
`Page 1
`
`
`Request for Comments: 783
`
`Updates: TEN 133
`
`K. R. Sollins
`MIT
`June, 1981
`
`THE TFTP PROTOCOL (REVISION 2)
`
`Summary
`
`TFTP
`
`is
`
`a very
`
`simple protocol used to transfer files.
`
`It is from
`
`this that its name comes, Trivial File Transfer Protocol or TFTP.
`
`Each
`
`nonterminal
`
`packet is acknowledged separately. This document describes
`
`the protocol and its types of packets.
`
`The document also explains
`
`the
`
`reasons behind some of the design decisions.
`
`PMC Exhibit 2123
`
`Apple v. PMC
`|PR2016-00755
`
`Page 1
`
`1
`
`PMC Exhibit 2123
`Apple v. PMC
`IPR2016-00755
`Page 1
`
`
`
`ACKNOWLflDGflMflNTS
`
`The protocol was originally designed by Noel Chiappa,
`
`and
`
`was
`
`redesigned by him, Bob Baldwin and Dave Clark,
`
`with comments from
`
`Steve
`
`Szymanski.
`
`The current revision of the document
`
`includes modifications
`
`stemming f:om discussions with and suggestions from
`
`Larry Allen,
`
`Chiappa, Dave Clark, Geoff Cooper,
`
`Mike Greenwald, Liza Martin,
`
`Noel
`
`David
`
`Reed, Craig Milo Rogers
`
`(of UCS—ISI), Kathy Yellick,
`
`and
`
`the
`
`au
`
`:hor.
`
`The
`
`acknowledgement
`
`and retransmission scheme was inspired by TCP,
`
`and
`
`the error mechanism was suggested by PARC’s EFTP abort message.
`
`This
`
`the
`
`research was supported by the Advanced Research Projects Agency
`
`of
`
`Department
`
`of
`
`Defense
`
`and
`
`was
`
`monitored by the Office of Naval
`
`Research under contract number NOOO14—75—C—O661.
`
`PMC Exhibit 2123
`
`Apple v. PMC
`|PR2016-00755
`
`Page 2
`
`PMC Exhibit 2123
`Apple v. PMC
`IPR2016-00755
`Page 2
`
`
`
`1. Purpose
`
`TFTP
`
`is
`
`a simple protocol to transfer files,
`
`and therefore was named
`
`the Trivial File Transfer Protocol or TFTP.
`
`It has been implemented
`
`on
`
`top
`
`of
`
`the Internet User Datagram protocol
`
`(UDP or Datagram)
`
`[2]
`
`so it
`
`may be used
`
`to move
`
`files
`
`between machines
`
`on different
`
`networks
`
`implementing
`
`UDP.
`
`(This
`
`should not
`
`exlude
`
`the possibility of
`
`implementing TFTP on top of other datagram protocols.)
`
`It
`
`is
`
`designed
`
`to be
`
`small
`
`and
`
`easy to implement. Therefore, it lacks most of the
`
`features of a regular FTP.
`
`The only thing it can do is read and write
`
`files
`
`(or mail)
`
`from/to a remote server.
`
`It cannot list directories,
`
`and currently has no provisions for user authentication.
`
`In common with
`
`other Internet protocols, it passes 8 bit bytes of data.
`
`Three modes of transfer are currently supported: netascii
`
`;
`
`octet
`
`,
`
`1
`
`2
`
`raw 8 bit bytes; mail, netascii characters sent
`
`to a user rather than a
`
`file. Additional modes can be defined by pairs of cooperating hosts.
`
`1
`
`This is ascii as defined in "USA Standard Code
`
`for
`
`Information
`
`[1] with the modifications specified in "Telnet Protocol
`Interchange"
`Specification" [3]. Note that it is 8 bit ascii.
`The
`term "netascii"
`will be used throughout this document to mean this particular version of
`ascii.
`2
`
`This
`
`replaces
`
`the
`
`"binary" mode
`
`of previous versions
`
`of
`
`this
`
`PMC Exhibit 2123
`
`Apple v. PMC
`|PR2016-00755
`
`Page 3
`
`PMC Exhibit 2123
`Apple v. PMC
`IPR2016-00755
`Page 3
`
`
`
`2. Overview of the Protocol
`
`Any transsfer begins with a request to read or write a file, which also
`
`serves
`
`to request a connection.
`
`If the server grants the request,
`
`the
`
`connection is opened and the file is sent in fixed length blocks of
`
`512
`
`bytes.
`
`Each data
`
`packet
`
`contains
`
`one
`
`block
`
`of data,
`
`and must be
`
`acknowledged by an acknowledgment packet before the next packet
`
`can
`
`be
`
`sent.
`
`A data packet of less than 512 bytes signals termination of a
`
`transfer.
`
`If a packet gets lost in the network,
`
`the intended recipient
`
`will timeout and may retransmit his last packet
`
`(which may be data or an
`
`acknowledgment),
`
`thus
`
`causing the
`
`sender
`
`of
`
`the
`
`lost packet
`
`to
`
`retransmit that lost packet.
`
`The sender has to keep just one packet
`
`on
`
`hand
`
`for
`
`retransmission, since the lock step acknowledgment guarantees
`
`that all older packets have been received. Notice
`
`that both machines
`
`involved in a transfer are considered senders and receivers.
`
`One sends
`
`data and receives acknowledgments,
`
`the other sends
`
`acknowledgments
`
`and
`
`receives data.
`
`Most
`
`errors
`
`cause
`
`termination of
`
`the
`
`connection.
`
`An error is
`
`signalled by sending an error packet. This packet is not
`
`acknowledged,
`
`and not
`
`retransmitted (i.e., a TFTP server or user may terminate after
`
`sending an error message),
`
`so the other end of the
`
`connection may not
`
`get
`
`it.
`
`Therefore timeouts are used to detect such a termination when
`
`the error packet has been lost. Errors are caused by
`
`three
`
`types
`
`of
`
`events:
`
`not being able
`
`to satisfy the request (e.g., file not found,
`
`access violation, or no such user), receiving a packet which
`
`cannot
`
`be
`
`explained by a delay or duplication in the network
`
`(e.g.
`
`an incorrectly
`
`PMC Exhibit 2123
`
`Apple v. PMC
`|PR2016-00755
`
`Page 4
`
`PMC Exhibit 2123
`Apple v. PMC
`IPR2016-00755
`Page 4
`
`
`
`formed packet),
`
`and
`
`losing access to a necessary resource (e.g., disk
`
`full or access denied during a transfer).
`
`TFTP
`
`recognizes
`
`only one
`
`error
`
`condition that
`
`does
`
`not
`
`cause
`
`termination,
`
`the
`
`source port of a received packet being incorrect.
`
`In
`
`this case, an error packet is sent to the originating host.
`
`This protocol
`
`is
`
`very
`
`restrictive,
`
`in
`
`order
`
`to
`
`simplify
`
`implementation.
`
`For
`
`example,
`
`the fixed length blocks make allocation
`
`straight forward,
`
`and
`
`the
`
`lock
`
`step acknowledgement provides
`
`flow
`
`control and eliminates the need to reorder incoming data packets.
`
`3. Relation to other Protocols
`
`As mentioned TFTP is designed to be implemented on top of the Datagram
`
`protocol.
`
`Since Datagram
`
`is
`
`implemented
`
`on the Internet p:otocol,
`
`packets will have an Internet header, a Datagram header,
`
`and
`
`a
`
`TFTP
`
`header. Additionally,
`
`the packets may have a header
`
`(LNI, ARPA header,
`
`etc.)
`
`to allow them through the local transport medium.
`
`As
`
`shown
`
`in
`
`Figure 3-1,
`
`the order of the contents of a packet will be:
`
`local medium
`
`header,
`
`if used, Internet header, Datagram header, TFTP header,
`
`followed
`
`by
`
`the
`
`remainder
`
`of
`
`the
`
`TFTP packet.
`
`(This may or may not be data
`
`depending on the type of packet as specified in the TFTP header.)
`
`TFTP
`
`does not specify any of the values in the Internet header.
`
`On the other
`
`hand,
`
`the source and destination port fields of the Datagram header
`
`(its
`
`format
`
`is given in the appendix) are used by TFTP and the length field
`
`reflects the size of the TFTP packet.
`
`The transfer identifiers
`
`(TIiD’S)
`
`PMC Exhibit 2123
`
`Apple v. PMC
`|PR2016-00755
`
`Page 5
`
`PMC Exhibit 2123
`Apple v. PMC
`IPR2016-00755
`Page 5
`
`
`
`used by
`
`TFTP
`
`are passed
`
`to the
`
`Datagram layer to be used as ports;
`
`therefore they must be between 0 and
`
`65,535.
`
`The
`
`initialization of
`
`TID’s is discussed in the section on initial connection protocol.
`
`The
`
`TFTP header consists of a 2 byte opcode field which indicates the
`
`packet’s type (e.g., DATA, ERROR, etc.)
`
`These opcodes and
`
`the
`
`formats
`
`of
`
`the various types of packets are discussed further in the section on
`
`TFTP packets.
`
`Figure 3-1: Order of Headers
`
`Local Medium
`
`Internet
`
`Datagram
`
`TFTP
`
`4. Initial Connection Protocol
`
`A transfer is established by sending a request
`
`(WRQ to write
`
`onto a
`
`foreign file system, or RRQ to read from it), and receiving a positive
`
`reply, an acknowledgment packet for write, or the first data packet
`
`for
`
`read.
`
`In general an acknowledgment packe: will contain the block number
`
`of
`
`the data packet being acknowledged.
`
`Each data packet has associated
`
`with it a block number; block numbers are
`
`consecutive
`
`and begin with
`
`one.
`
`Since
`
`the positive
`
`response
`
`to a write
`
`request
`
`is
`
`an
`
`acknowledgment packet,
`
`in this special case the block number will
`
`be
`
`zero.
`
`(Normally, since an acknowledgment packet is acknowledging a data
`
`packet,
`
`the
`
`acknowledgment packet will contain the block number of the
`
`data packet being acknowledged.)
`
`If the reply is an error packet,
`
`then
`
`PMC Exhibit 2123
`
`Apple v. PMC
`|PR2016-00755
`
`Page 6
`
`PMC Exhibit 2123
`Apple v. PMC
`IPR2016-00755
`Page 6
`
`
`
`the request has been denied.
`
`In order to create a connection, each end of the connection chooses a
`
`TID for itself,
`
`to be used for the duration of
`
`that
`
`connection.
`
`The
`
`TID’s
`
`chosen
`
`for
`
`a
`
`connection should be randomly chosen,
`
`so that the
`
`probability that the same number is chosen twice in immediate succession
`
`is very low. Every packet has associated with it the two TID’s
`
`of
`
`the
`
`ends
`
`of
`
`the connection,
`
`the source TID and the destination TID.
`
`These
`
`TID’s are handed to the supporting UDP (or other datagram protocol)
`
`as
`
`the
`
`source and destination ports.
`
`A requesting host chooses its source
`
`TID as described above, and sends its initial request to the
`
`known
`
`TID
`
`69
`
`decimal
`
`(105 octal)
`
`on
`
`the
`
`serving host.
`
`The response to the
`
`request, under normal operation, uses a TID chosen by the server as
`
`its
`
`source
`
`TID and the TID chosen for the previous message by the requestor
`
`as its des:ination TID.
`
`The two chosen TID’s
`
`are
`
`then used
`
`for
`
`the
`
`remainder
`
`of
`
`the
`
`transfer.
`
`As an example,
`
`the following shows
`
`the
`
`steps
`
`used to establish a
`
`connection to write a file. Note that WRQ, ACK, and DATA are the names
`
`of
`
`the write
`
`request,
`
`acknowledgment,
`
`and data
`
`:ypes
`
`of packets
`
`respectively.
`
`The
`
`appendix contains a similar exanple for reading a
`
`file.
`
`a
`1. Host A sends
`destination= 69.
`
`"WRQ"
`
`to host
`
`B with
`
`source: A's
`
`TID,
`
`sends
`B
`2. Host
`source= B's TID,
`
`(with block number= O)
`a "ACK"
`destination: A's TID.
`
`to host A with
`
`PMC Exhibit 2123
`
`Apple v. PMC
`|PR2016-00755
`
`Page 7
`
`PMC Exhibit 2123
`Apple v. PMC
`IPR2016-00755
`Page 7
`
`
`
`At this point the connection has been established and
`
`the
`
`first data
`
`packet
`
`can
`
`be sent by Host A with a sequence number of 1.
`
`In the next
`
`step, and in all succeeding steps,
`
`the hosts should make sure
`
`that
`
`the
`
`source
`
`TID matches the value that was agreed on in steps 1 and 2.
`
`If a
`
`source TID does not match,
`
`the packet should be discarded as erroneously
`
`sent
`
`from somewhere else.
`
`An error packet should be sent to the
`
`SOUJCCE
`
`of the incorrect packet, while not disturbing the transfer.
`
`This
`
`can be
`
`done
`
`only if the
`
`TFTP in fact
`
`receives a packet with an
`
`incorrect TID.
`
`If the
`
`supporting protocols
`
`do not
`
`allow it,
`
`this
`
`particular error condition will not arise.
`
`The following example demonstrates a correct operation of the protocol
`
`in which the above situation can occur. Host A sends a request
`
`to host
`
`B. Somewhere in the network,
`
`the request packet is duplicated, and as
`
`a
`
`result
`
`two acknowledgments are returned to host A, with different TID’s
`
`chosen on host B in response to the
`
`two
`
`requests.
`
`When
`
`the
`
`fi:st
`
`response arrives,
`
`host
`
`A
`
`continues
`
`the connection. When the second
`
`response to the request arrives, it should be rejected, but there is
`
`no
`
`reason to terminate the first connection. Therefore,
`
`if different TID’s
`
`are
`
`chosen
`
`for
`
`the
`
`two
`
`connections
`
`on host B and host A checks :he
`
`source TID’s of the messages it receives,
`
`the first
`
`connection can
`
`be
`
`maintained while the second is rejected by returning an error packet.
`
`PMC Exhibit 2123
`
`Apple v. PMC
`|PR2016-00755
`
`Page 8
`
`PMC Exhibit 2123
`Apple v. PMC
`IPR2016-00755
`Page 8
`
`
`
`5. TFTP Packets
`
`TFTP
`
`supports five types of packets, all of which have been mentioned
`
`above:
`
`opcode operation
`1
`Read request
`2
`Write cequest
`3
`Data (DATA)
`
`(RRQ)
`(WRQ)
`
`4
`5
`
`Acknowledgment
`Error
`(ERROR)
`
`(ACK)
`
`The TFTP header of a packet contains the
`
`opcode
`
`associated with that
`
`packet.
`
`Figure 5-1: RRQ/WRQ packet
`
`2 bytes
`
`string
`
`1 byte
`
`string
`
`1 byte
`
`1_£)g;;§1;_]"§li;§.;.};"["3"]"_}};;;""]"_6"1
`
`RRQ
`
`and WRQ packets
`
`(opcodes 1 and 2 respectively) have the format
`
`shown in Figure 5-1.
`
`The file name is a sequence of bytes
`
`in netascii
`
`terminated by
`
`a
`
`zero byte.
`
`The mode
`
`field contains
`
`the string
`
`"netascii", "octet", or "mail"
`
`(or any comibnation of
`
`upper
`
`and
`
`lower
`
`case,
`
`such
`
`as
`
`"NETASCII", NetAscii", etc.) in netascii indicating the
`
`three modes defined in the protocol.
`
`A host which
`
`receives netascii
`
`mode data must translate the data to its own format. Octet mode is used
`
`to transfer a file that is in the 8-bit format of the machine from which
`
`the
`
`file is being transferred.
`
`It is assumed that each type of machine
`
`has a single 8-bit format that is more common, and that that
`
`format
`
`is
`
`PMC Exhibit 2123
`
`Apple v. PMC
`|PR2016-00755
`
`Page 9
`
`PMC Exhibit 2123
`Apple v. PMC
`IPR2016-00755
`Page 9
`
`
`
`chosen.
`
`For example, on a DEC-20, a 36 bit machine,
`
`this is four 8-bit
`
`bytes to a word with four bi:s of breakage.
`
`If a host receives a octet
`
`file and
`
`then returns
`
`it,
`
`the returned file must be identical to the
`
`original. Mail mode uses the name of a mail recipient
`
`in place
`
`of
`
`a
`
`file and must begin with a WRQ. Otherwise it is identical to netascii
`
`mode.
`
`The mail recipient string should be of
`
`the
`
`form "username"
`
`or
`
`"username@hostname".
`
`If the second form is used, it allows the option
`
`of mail forwarding by a relay computer.
`
`The discussion above assumes that both the sender
`
`and
`
`recipient
`
`are
`
`operating in the same mode, but there is no reason that this has to be
`
`the case.
`
`For example, one might build a storage server. There
`
`is
`
`no
`
`reason that such a machine needs to translate netascii into its own form
`
`of
`
`text.
`
`Rather,
`
`the
`
`sender might send files in netascii, but
`
`the
`
`storage server might simply store
`
`them without
`
`trans_ation in 8-bit
`
`format.
`
`Another
`
`such situation is a problem that cu:rently exists on
`
`DEC-20 systems.
`
`Neither netascii nor octet accesses all the bits
`
`in a
`
`word.
`
`One might create a special mode for such a machine which read all
`
`the bits in a word, but
`
`in which the receiver stored the information in
`
`8-bit format. When such a file is retrieved from the storage
`
`site,
`
`it
`
`must
`
`be restored to its original form to be useful,
`
`so the reverse mode
`
`must also be implemented.
`
`The user site will
`
`have
`
`to remember
`
`some
`
`information to achieve
`
`this.
`
`In both of these examples,
`
`the request
`
`packets would specify octet mode to the foreign host, but the local host
`
`would be in some other mode.
`
`No such machine or application specific
`
`modes have been specified in TFTP, but one would be compatible with this
`
`10
`
`PMC Exhibit 2123
`
`Apple v. PMC
`|PR2016-00755
`
`Page 10
`
`PMC Exhibit 2123
`Apple v. PMC
`IPR2016-00755
`Page 10
`
`
`
`specification.
`
`It
`
`is
`
`also possible
`
`to define other modes for cooperating pairs of
`
`hosts, although this must be done with care. There
`
`is
`
`no
`
`requirement
`
`that
`
`any other hosts
`
`implement these. There is no central authority
`
`that will define these modes or assign them names.
`
`Figure 5-2:
`
`DATA packet
`
`Data is actually transferred in DATA packets depicted in Figure
`
`5-2.
`
`DATA packets (opcode = 3)
`
`have a block number and data field.
`
`The block
`
`numbers
`
`on data packets begin with one and increase by one for each new
`
`block of data. This restriction allows the
`
`program to use
`
`a
`
`single
`
`number
`
`to discriminate
`
`between new packets and duplicates.
`
`The data
`
`field is from zero to 512 bytes long.
`
`If it
`
`is
`
`512 bytes
`
`long,
`
`the
`
`block
`
`is not
`
`the
`
`last block of data;
`
`if it is from zero to 511 bytes
`
`long, it signals the end of the transfer.
`
`(See the
`
`section on Normal
`
`Termination for details.)
`
`All packets other
`
`than those used for termination are acknowledged
`
`individually unless a timeout occurs.
`
`Sending
`
`a
`
`DATA packet
`
`is
`
`an
`
`acknowledgment
`
`for the ACK packet of the previous DATA packet.
`
`The WRQ
`
`and DATA packets are acknowledged by ACK or ERROR packets,
`
`while RRQ and
`
`ll
`
`PMC Exhibit 2123
`
`Apple v. PMC
`|PR2016-00755
`
`Page 11
`
`PMC Exhibit 2123
`Apple v. PMC
`IPR2016-00755
`Page 11
`
`
`
`Figure 5-3: ACK packet
`
`ACK packets
`
`are
`
`acknowledged
`
`by
`
`DATA or ERROR packets.
`
`Figure 5-3
`
`depicts an ACK packet;
`
`the opcode is 4.
`
`The block number
`
`in an
`
`ACK
`
`echoes the block number of the DATA packet being acknowledged.
`
`A WRQ is
`
`acknowledged with an ACK packet having a block number of zero.
`
`Figure 5-4: ERROR packet
`
`An
`
`ERROR packet
`
`(opcode 5)
`
`takes the form depicted in Figure 5-4.
`
`An
`
`ERQOR packet can be the acknowledgment of any other type of packet.
`
`The
`
`error code is an integer indicating the nature of the error.
`
`A table of
`
`va_ues and meanings is given in the appendix.
`
`(Note that several
`
`error
`
`codes
`
`have
`
`been
`
`added
`
`to this version of this document.)
`
`The error
`
`message is intended for human consumption, and should be
`
`in netascii.
`
`Like all other strings, it is terminated with a zero byte.
`
`12
`
`PMC Exhibit 2123
`
`Apple v. PMC
`|PR2016-00755
`
`Page 12
`
`PMC Exhibit 2123
`Apple v. PMC
`IPR2016-00755
`Page 12
`
`
`
`6. Normal Termination
`
`The end of a transfer is marked by a DATA packet that contains between
`
`0
`
`and
`
`511 bytes of data (i.e. Datagram length < 516). This packet is
`
`acknow_edged by an ACK packet like all other
`
`DATA packets.
`
`The host
`
`acknow_edging
`
`the
`
`final
`
`DATA packet may
`
`terminate
`
`its side of the
`
`connection on sending the final ACK.
`
`On the other
`
`hand,
`
`dallying is
`
`encouraged.
`
`This means that the host sending the final ACK will wait
`
`for a while before terminating in order to retransmit the final
`
`ACK
`
`if
`
`it has been lost.
`
`The acknowledger will know that the ACK has been lost
`
`if
`
`it
`
`receives the final DATA packet again.
`
`The host sending the last
`
`DATA must retransmit it until the packet is acknowledged or the
`
`sending
`
`1OSt
`
`times out.
`
`If
`
`the
`
`response
`
`is
`
`an ACK,
`
`the transmission was
`
`completed successfully.
`
`If the sender of the data times out and is
`
`not
`
`prepared to retransmit
`
`any more,
`
`the
`
`transfer may still have been
`
`completed successfully, after which the acknowledger or network may have
`
`experienced a problem.
`
`It is
`
`also possible
`
`in this
`
`case
`
`that
`
`the
`
`transfer was unsuccessful.
`
`In any case,
`
`the connection has been closed.
`
`7. Premature Termination
`
`If
`
`a
`
`request
`
`can not
`
`be granted, or some error occurs during the
`
`transfer,
`
`then an ERROR packet
`
`(opcode 5)
`
`is
`
`sent.
`
`This
`
`is
`
`only a
`
`courtesy since
`
`i: will not be retransmitted or acknowledged,
`
`so it may
`
`never be received. Timeouts must also be used to detect errors.
`
`13
`
`PMC Exhibit 2123
`
`Apple v. PMC
`|PR2016-00755
`
`Page 13
`
`PMC Exhibit 2123
`Apple v. PMC
`IPR2016-00755
`Page 13
`
`
`
`1. Appendix
`
`Order of Headers
`
`"LQQRIRRQRJRI2iiERRRRRREii273;;;;R;R"TRRRRERSQQQR?
`
`2 bytes
`
`TFTP Formats
`
`Type
`
`Op #
`2 bytes
`
`Format without header
`string
`1 byte
`
`string
`
`1 byte
`
`RQQ/
`WQQ
`
`l\EJ1flJ2T__};'i1enar;1e_T"_EJ_T""1;Idde"_T—"EJ"|
`— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — --
`
`2 bytes
`
`2 bytes
`
`n bytes
`
`DATA 1Q}222}22*Ri;;R}IT"73;;;""1
`
`R};;;;;""R};;;;; iiiiiiiiiiiii *2
`
`ACK
`
`.Q§CT"*Ri;;R}I|
`
`R};;;;;"R};;;;;""
`
`string
`
`1byte
`
`ERROR 1Q;222]2TRRRARERQQRJT7;;;R;;{"T*EC1
`
`14
`
`PMC Exhibit 2123
`
`Apple v. PMC
`|PR2016-00755
`
`Page 14
`
`PMC Exhibit 2123
`Apple v. PMC
`IPR2016-00755
`Page 14
`
`
`
`Initial Connection Protocol for reading a file
`
`sends
`A
`1. Host
`destination= 69.
`
`a
`
`H
`
`H
`
`to host
`
`B
`
`with
`
`source:
`
`A’ S TI:
`
`(with block nunber=
`2. Host B sends a "DATA"
`source: B's TID, destination= A's TID.
`
`1)
`
`to host
`
`A wi
`
`15
`
`PMC Exhibit 2123
`
`Apple v. PMC
`|PR2016-00755
`
`Page 15
`
`PMC Exhibit 2123
`Apple v. PMC
`IPR2016-00755
`Page 15
`
`
`
`Error Codes
`
`H C (D
`
`4mmmmNHog
`
`Weaning
`Vot defined, see error message (if any).
`File not found.
`Access violation.
`Disk full or allocation exceeded.
`
`TFTP opera:ion.
`I1'ega
`Jnknown transfer ID.
`
`F1 e a ready exists.
`Vo such user.
`
`16
`
`PMC Exhibit 2123
`
`Apple v. PMC
`|PR2016-00755
`
`Page 16
`
`PMC Exhibit 2123
`Apple v. PMC
`IPR2016-00755
`Page 16
`
`
`
`Internet User Datagram Header
`
`[2]
`
`3
`
`Format
`
`0
`O 1 2 3 4 5
`
`6 7 8
`
`9
`
`1
`O 1 2 3 4 5
`
`6
`
`2
`O 1 2 3 4 5
`
`9
`
`6 7 8
`
`9
`
`3
`O
`
`Soucce Po:t
`
`Destination Port
`
`Length
`
`Checksum
`
`Values of Fields
`
`Source Port
`
`Picked by originator of packet.
`
`Dest. Port
`
`Picked by destination machine (69 for RRQ or WRQ).
`
`Length
`
`Number of bytes in packet after Datagram header.
`
`Checksum
`
`Reference 2 describes rules for computing checksum.
`Field contains zero if unused.
`
`4
`
`Vote:
`
`TFTP passes
`
`transfer
`
`identifiers
`
`(TID’s)
`
`to the Internet User
`
`Datagram protocol to be used as the source and destination ports.
`
`3
`
`This has been included only
`implemented on top of the Internet User
`4
`
`for
`
`convenience.
`
`TFTP
`
`need not
`
`be
`
`Datagram Protocol.
`
`The
`implementor of this should be su
`used here.
`
`re that the correct algorithm is
`
`17
`
`PMC Exhibit 2123
`
`Apple v. PMC
`|PR2016-00755
`
`Page 17
`
`PMC Exhibit 2123
`Apple v. PMC
`IPR2016-00755
`Page 17
`
`
`
`References
`
`[1]
`
`USA Standard Code
`
`for
`
`Information Interchange, USASI X3.4—
`
`1968.
`
`[2]
`
`Postel, Jon.,
`
`"User Datagram Protocol," RFC768, August
`
`28,
`
`1980.
`
`[3]
`
`"Telnet Protocol Specification," RFC764, June, 1980.
`
`18
`
`PMC Exhibit 2123
`
`Apple v. PMC
`|PR2016-00755
`
`Page 18
`
`PMC Exhibit 2123
`Apple v. PMC
`IPR2016-00755
`Page 18
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
