Internet Draft P.Casagranda Document: draft-casagranda-vignaroli-btftp-01.txt L.Vignaroli Category: Experimental RAI - CRIT December 2000 Broadcast Trivial File Transfer Protocol Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering ask Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes the Broadcast Trivial File Transfer Protocol (BTFTP), a protocol designed to be used as a datagram based, multicast enabled protocol with optional back-channel. The main purpose of the protocol is data and file transfer over broadcast, wireless channels (e.g. Digital Video Broadcasting channels, like terrestrial DVB-T and satellite DVB-S [ISO13818]) without the need of a back-channel (which is optional). The efficiency of the protocol over a satellite and terrestrial wireless link has been widely tested. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. Acknowledgements The BFTP protocol has some functionality of TFTP protocol [RFC1350] but it has very few structural similarities with it. Table of Contents P. Casagranda L.Vignaroli Experimental - Expires: June 2001 1 Broadcast Trivial File Transfer Protocol December 2000 1. Overview of the Protocol 2. Protocol Specification 2.1. BTFTPPacket 2.2. BTFTPWriteRequest 2.3. BTFTPData 2.4. BTFTPNak 2.5. BTFTPWriteRequestExtension 2.6. Types Used in TLV fields 3. Typical Sequence of Operation 3.1. Operation without Back-Channel 3.2. Operation with Back-Channel 4. Security Considerations 5. References 6. AuthorsÆ Addresses 1. Overview of the Protocol The BTFTP protocol was created for the purpose of data and file transfer over digital broadcast channels, DVB like (DVB-S, DVB-T). The peculiar features of the protocol are: a) optional back-channel: the protocol works without back-channel, in a pure broadcasting way; an optional back-channel is nevertheless supported to increase reliability b) very low header overhead: the headers are kept as small as possible c) simplicity: the specification and implementation are very simple (more straightforward than DVB Object Carousel for example) d) extensibility: the BTFTPWriteRequest packet can easily be improved for particular needs. e) compatibility: is an IP based protocol (instead of DVB Data Carousel and Object Carousel Protocols) The protocol was thought to be implemented over User Datagram Protocol (UDP) but this does not exclude other datagram protocols. In that way it can be encapsulated in Digital Video Broadcasting transport stream (Multi-Protocol Encapsulation Profile [ISO13818]) and sent over wireless, broadcasting channels. BTFTP can work in two ways: without the back-channel and with a low bit-rate back-channel. - Operation without back-channel The protocol can be used without a back-channel, in a pure broadcasting manner, with no interactivity. This is the main purpose of the protocol. In that way the contents are fixed, and the user selects a channel and then begins downloading all or part of the data of that channel. Reliability is obtained in two ways: with the Forward Error Correction (FEC) of the underlying layers (e.g. Viterbi and Reed Solomon protection of a DVB channel) and/or redundancy, that is repeating the transmission. - Operation with back-channel P. Casagranda L.Vignaroli Experimental - Expires: June 2001 2 Broadcast Trivial File Transfer Protocol December 2000 The protocol can be used with a low bit-rate back-channel. This adds reliability at the expense of another channel that should carry the packet requests. The protocol in itself does not implement interactivity (it was not designed for this scenario): for this purpose HTTP or other protocols can be possibly used instead of BTFTP. The check of data integrity is provided in both scenarios by a CRC32 code. 2. Protocol Specification This section describes the format of the BTFTP packets. Below is shown the syntax of each type of packet and the semantic of each field. 2.1. BTFTPPacket This is the primary packet which contains the common header of all BTFTP packets. The packet format is: BTFTPPacket() Length in bits (big endian notation) { TID; 32 OPCODE; 8 BlockNumber; 32 BlockSize; 16 FutureUse; 5 LastPacketFlag; 1 RedundancyFlags; 2 if (OPCODE==0) BTFTPWriteRequest(); if (OPCODE==1) BTFTPData(); if (OPCODE==2) BTFTPNak(); if (OPCODE==3) BTFTPWriteRequestExtension(); if (RedundancyFlags==01) Chekcsum; 32 If (RedundancyFlags==10) CRC32; 32 If (RedundancyFlags==00) Ignored; 32 } Semantics: TID: it is the Transmission Identifier which is used to differentiate each file transmission from others, in this way we can have different multiplexed files transmissions. The value of this field is the same for each packet of the same file transmission, and must be different from other file transmissions at the same time. P. Casagranda L.Vignaroli Experimental - Expires: June 2001 3 Broadcast Trivial File Transfer Protocol December 2000 OPCODE: this field contains the operation code of current packet, this value specified the packet type which can be BTFTPWriteRequest (value = 0), BTFTPData (value = 1), BTFTPNak (value = 2) or BTFTPWriteRequestExtension (value = 3). BlockNumber: this is the packet counter of the protocol, it is used to enumerate packets of same type; the start value is one. BlockSize: It is the size in bytes of the current packet. There are no restrictions in the use of this field but it should be used a constant BlockSize value for BTFTPData packets for each file transmission. FutureUse: five bits field for future use. LastPacketFlag: this field is used only with OPCODE = 1 (BTFTPData), the value 1 indicates that this is the last data packet of a trasmitted file. If OPCODE is not BTFTPData the field is ignored. RedundancyFlags: these two bits specify the redundancy type of the BTFTP packet. Checksum: this is a 32 bits field which contain the sum of all bytes in the packet without carry. CRC32: this is an 32 bits field which contain the CRC calculated over this packet, which must be calculated in according to MPEG 2 system specifications, refer to [ISO13818] Ignored: if RedundancyFlags is 00 these 32 bits are ignored by the decoding procedure. 2.2. BTFTPWriteRequest (OPCODE = 0) The Write Request Packet is used to inform the receiver that a transmission is beginning, this packet carries the information necessary to file decoding, it contains information like file name (must be present if a file is trasmitted), file type or generic file information. All information in the Write Request part of packet are encapsulated as TLV (Type Length Value) format. There is only one Write Request packet for each file transmission (same TID), if the packet is to short to encapsulate file information or if there is the necessity to transmit extra file description it must be done using the BTFTPWriteRequestExtension. The format of the Write Request is: BTFTPWriteRequest() Length in bits (big endian notation) { TotalBlockNumberWRE; 32 TotalBlockNumberData; 32 TLV(); } Semantics: TotalBlockNumberWRE: this field carries to the receiver the total block number of Write Request Extension packets. If the value is 0 there are not Extension packets. Otherwise the value specify how many Write Request Extension packets the receiver must read to completely rebuild data description. P. Casagranda L.Vignaroli Experimental - Expires: June 2001 4 Broadcast Trivial File Transfer Protocol December 2000 TotalBlockNumberData: this field indicates the number of packets containing data, the value specifies how many BTFTPData packets the receiver has to read to rebuild the transmitted file. TLV(): indicates a sequential list of TLV fields which contains the data description, the file name TLV is mandatory. This TLV list terminates with a type '0' TLV. Look at TLV section for more information. So, the general form of a TLV() is: 2.3. BTFTPData (OPCODE =1) This is the data packet of the protocol. A portion of the file to transmit is stored in the payload. The length of payload depends on the BlockSize value and on the extra information optionally encapsulated. The format of this packet is: BTFTPData() { TLV(); Payload; } Semantics: TLV(): indicates an optional sequential list of TLV field which contains the extra data description, the type '0' TLV is mandatory. This TLV list must terminate with a type '0' TLV. See TLV section for more information. Payload: it contains a portion of transmitted file, the size depends on the BlockSize value and the length of previous TLV list (look at the meaning of BlockSize). 2.4. BTFTPNak (OPCODE = 2) This type of packet is used only in operation with back channel. BTFTPNak packets are sent by the receiver to the transmitter. BTFTPNak packets must be sent with the same TID of the requested packet and must be sigle packets (the BTFTPNak cannot be on multiple packets). For example, if packet n of a transmission with TID m has been lost, the BTFTPNak request is a packet with the same TID m. BTFTPNak packets contain requests of lost packets. The format of this packet is: BTFTPNak() { TLV(); } Semantics: TLV(): this is one Nak TLV field following by a type æ0Æ TLV. The Nak TLV indicate the list of lost packets. P. Casagranda L.Vignaroli Experimental - Expires: June 2001 5 Broadcast Trivial File Transfer Protocol December 2000 The TLV with the request(s) is of type 128: it contains a list of intervals of packets to be retransmitted (Nak list). Each entry of the list is 9 octets long. The format of the list is: à The notation is big endian. For example, if data packet 0x0A31 (hexadecimal) had been lost, the TLV content would be: 0x01 0x00 0x00 0x0A 0x31 0x00 0x00 0x00 0x01 If there were 0x39 lost packet from packet number 0x0A31, and 0x28 from data packet number 0xBA13, the content of the TLV would be: 0x01 0x00 0x00 0x0A 0x31 0x00 0x00 0x00 0x39 0x01 0x00 0x00 0xBA 0x13 0x00 0x00 0x00 0x28 2.5. BTFTPWriteRequestExtension (OPCODE = 3) This type of packet is optional and is used only if one BTFTPWriteRequest packet can not carry all the file and transmission description (because the description length is greater than the payload size of the BTFTPWriteRequest packet). The format is: BTFTPWriteRequestExtension() { TLV(); } Semantics: TLV(): it contains a list of TLV field following by a type '0' TLV. 2.6. Types used in TLV fields The TLV fields need a coherent convention to use the Type field. In general, the number of bytes of the field Length depends on the field Type; in other words it is not fixed for all Types. The Type field has to be specified with the following convention: Type = 0: There are no Length and Value fields. This must be the last TLV of the list. Type = 1: Length of 2 bytes. The Value contains the file name. Type = 2: Length of 2 bytes. The Value contains the type of the file. Type = 3: Length of 2 bytes. The Value contains information on the file. Type = 4: Length of 2 bytes. The Value contains a command file, to be executed on a local machine. Type = 128: Length of 2 bytes. The Value contains a Nak list. In greater detail we have: Type = 0: This Type tells the decoder that the TLV sequence has come to an end. P. Casagranda L.Vignaroli Experimental - Expires: June 2001 6 Broadcast Trivial File Transfer Protocol December 2000 Type = 1: The file name of the file that is going to be transmitted. The filename is encoded in standard 8 bits ASCII code. Type = 2: The type of the file. The possible types (e.g. gzip, text, html, png...) are not standardized in this document. The type is encoded in standard 8 bits ASCII code. Type = 3: Some useful information on the file. This can be an ASCII string that describes the file. It is, like the other TLV, optional. The information is encoded using standard 8 bits ASCII code. Type = 4: Sometimes it is useful to have a command file to be executed at application level and to be transmitted very rapidly, possibly on a single packet, which is the purpose of this TLV. This should be a text file. Type = 128: It contains a list of intervals of packets to be retransmitted (Nak list). Each entry of the list is 9 octets long. The format of the list is: ... Other values for the Type field are reserved for future use. 3. Typical Sequence of Operation This chapter describes two typical sequences of operation and it should clarify the previously stated concepts. Note that this document is not intended to specify a policy for requests (time-out algorithm, request reiteration, et al.) 3.1. Operation without Back-Channel In a typical scenario without back-channel, let's suppose the Receiver has begun listening on a channel (address and port). The Broadcaster begins transmitting a file: Transmitter Receiver BTFTPWriteRequest Receiving BTFTPWriteRequest, checking CRC32 BTFTPData Receiving BTFTPData, checking CRC32 and sequence number of the packet. The packet is out of sequence, set a timeout for previous packets. The packet is in sequence, but CRC32 is wrong: that TID is discarded. The timeout for that TID is reached: that TID is discarded. The packet is in sequence and CRC32 is right: continue until the last packet is correctly received. 3.2. Operation with Back-Channel P. Casagranda L.Vignaroli Experimental - Expires: June 2001 7 Broadcast Trivial File Transfer Protocol December 2000 In a typical scenario with back-channel, let's suppose the Receiver has begun listening on a channel (address and port). There is also a channel for request packets, that can be chosen as a low bit-rate channel. The Broadcaster begins transmitting a file: Transmitter Receiver BTFTPWriteRequest Receiving BTFTPWriteRequest, checking CRC32 BTFTPData Receiving BTFTPData, checking CRC32 and sequence number of the packet. If the packet is out of sequence, set a timeout for previous packets. If the packet is in sequence, but CRC32 is wrong: add to the list of packets to be requested. Periodically send a BTFTPAcknowledgement packet to request lost or wrong packets. If timeout for that TID is reached: that TID is discarded. If the packet is in sequence and CRC32 is right: continue until the last packet is correctly received. The implementation can chose a clever policy to request the lost packets and minimize the band of the back-channel; this policy is not specified in this document. 4. Security Considerations The protocol has to work without a back-channel too (and it is the main purpose for which it has been developed). So a session canÆt be established in all scenarios. The content can be protected through a mechanism like this: - the Receiver creates a private key and a public key pair - the Receiver sends the public key to the Transmitter, out of band if there is no back-channel - the Transmitter creates periodically symmetric keys (session keys). These keys are sent to the Receiver, encrypted with the ReceiverÆs public key - the Transmitter sends content (files) to the Receiver encrypting it with the session key The protocol works on an UDP/IP stack, so many security considerations concerning protocol on this stack can be applied to the BTFTP protocol. 5. References [RFC1350] K. Sollins: "The TFTP Protocol - Revision 2", RFC1350, July 1992 P. Casagranda L.Vignaroli Experimental - Expires: June 2001 8 Broadcast Trivial File Transfer Protocol December 2000 [RFC2119] S. Bradner: ôKey words for use in RFCs to Indicate Requirement Levelsö, RFC2119, March 1997 [ISO13818] "ISO/IEC 13818 Specification" 6. Authors' Addresses Paolo Casagranda RAI - CRIT Corso Giambone 68 10135 û Torino ITALY Email: p.casagranda@rai.it Luca Vignaroli RAI - CRIT Corso Giambone 68 10135 û Torino ITALY Email: l.vignaroli@rai.it P. Casagranda L.Vignaroli Experimental - Expires: June 2001 9 Broadcast Trivial File Transfer Protocol December 2000 Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into. draft-casagranda-vignaroli-btftp-01.txt Expires: June 2001 P. Casagranda L.Vignaroli Experimental - Expires: June 2001 10