P.Casagranda L.Vignaroli Internet Draft RAI - CRIT Document: draft-casagranda-vignaroli-btftp-00.txt September 2000 Category: Experimental 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 - March 2001 1 Broadcast Trivial File Transfer Protocol September 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 - March 2001 2 Broadcast Trivial File Transfer Protocol September 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 - March 2001 3 Broadcast Trivial File Transfer Protocol September 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 carry the information necessary to file decoding, in contains information like file name (must be present if a file is trasmitted), file type or 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: BTFTPPacket() 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 rebuild all data description. P. Casagranda L.Vignaroli Experimental - March 2001 4 Broadcast Trivial File Transfer Protocol September 2000 TotalBlockNumberData: this field indicates the number of packets containing data, the value specifies how many BTFTPData 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. 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 only used during operation with back-channel. BTFTPNak packets are sent by the receiver to the transmitter. These packets contain a request for lost packets. The format of this packet is: BTFTPPacket() { TLV(); } Semantics: TLV(): this is one Nak TLV field following by a type '0' TLV. The Nak TLV indicates the list of lost packets. 2.5. BTFTPWriteRequestExtension (OPCODE = 3) P. Casagranda L.Vignaroli Experimental - March 2001 5 Broadcast Trivial File Transfer Protocol September 2000 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: BTFTPPacket() { 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. 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: ... P. Casagranda L.Vignaroli Experimental - March 2001 6 Broadcast Trivial File Transfer Protocol September 2000 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. 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 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 Acknowledgement 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. P. Casagranda L.Vignaroli Experimental - March 2001 7 Broadcast Trivial File Transfer Protocol September 2000 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 [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 Email: p.casagranda@rai.it Luca Vignaroli RAI - CRIT Corso Giambone 68 10135 - Torino Email: l.vignaroli@rai.it P. Casagranda L.Vignaroli Experimental - March 2001 8 Broadcast Trivial File Transfer Protocol September 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 implmentation 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: March 1, 2000 P. Casagranda L.Vignaroli Experimental - March 2001 9