Transport Group I. Bouazizi Internet Draft Nokia Research Center Expires: April 2007 October 30, 2006 Framing ALC Packets over Connection-Oriented Transport draft-bouazizi-rmt-alcframing-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task 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 This Internet-Draft will expire on April 30, 2007. Abstract ALC and FLUTE are reliable content delivery protocols designed mainly for scalable multicast distribution. However, this does not preclude their deployment in the Unicast distribution mode over connectionless or connection-oriented transport protocols. A method for framing ALC and FLUTE packets onto connection-oriented transport is presented. A definition of the descriptors of the framing method for those protocols is also given. Bouazizi Expires April 30, 2007 [Page 1] Internet-Draft ALC over Connection-Oriented Transport October 2006 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 Error! Reference source not found.. Table of Contents 1. Introduction ................................................ 2 2. The Framing Method .......................................... 3 3. Keep-Alive Mechanism......................................... 3 4. Further Considerations ....................................... 4 5. Session Descriptions for FLUTE over TCP ...................... 4 6. Example ..................................................... 4 7. Congestion Control .......................................... 5 8. Security Considerations...................................... 5 9. IANA Considerations ......................................... 5 10. Acknowledgments ............................................ 5 11. References ................................................. 6 11.1. Normative References ................................... 6 11.2. Informative References ................................. 6 Author's Addresses ............................................. 6 Intellectual Property Statement ................................. 6 Disclaimer of Validity ......................................... 7 Copyright Statement ............................................ 7 Acknowledgment ................................................. 7 1. Introduction The Asynchronous Layered Coding protocol [RFC3450] describes a massively scalable protocol for content delivery over multicast networks. ALC is composed of several building blocks such as the Layered Coding Transport building block [RFC3451] and the Forward Error Correction building block [RFC3452]. FLUTE [RFC3926] has been defined to allow for a specific delivery of files and is based on ALC. FLUTE is being deployed for file delivery in 3GPP Multimedia Broadcast/Multicast Services (MBMS) [3GPPTS26.346] and in IPDC over DVB-H [ETSITS102472]. In some situations, multicast delivery might not be possible or useful. This may happen e.g. in mobile multicast, when the receiver is out of coverage of the broadcast/multicast network. In such case, the delivery of the same content over Unicast reliably seems to be an attractive solution. However, none of the above protocols defines Bouazizi Expires April 30, 2007 [Page 2] Internet-Draft ALC over Connection-Oriented Transport October 2006 appropriate measures to allow for transport over connection-oriented protocols (e.g. TCP). This memo defines a framing method to allow for transport of ALC/FLUTE packets over connection-oriented transport protocols. Additionally, a mechanism for signaling the framing method use in session descriptions (SDP) is introduced. The memo follows the design principles and logic of [RFC4571], which defines a framing method for RTP and RTCP for connection-oriented transport. 2. The Framing Method The framing method is depicted in Figure 1. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------------------------------------------------------+ | LENGTH | ALC/FLUTE packet | +---------------------------------------------------------------+ Figure 1 Bit field definition of the framing method. The LENGTH field is a 16-bit field unsigned integer that is coded in network byte order (big-endian). If the LENGTH field is a non-zero value, an ALC or FLUTE packet follows the LENGTH field. The LENGTH field indicates the length in octets of the ALC/FLUTE packet. If the value of LENGTH is zero, a null packet is assumed. To check the validity of a frame (i.e. LENGTH field and ALC/FLUTE packet), receivers SHOULD monitor the LCT packet header that follows the LENGTH field. The header has predictable and locatable fields such as the version field, the Codepoint field, and the Transport Session Identifier (TSI) field. 3. Keep-Alive Mechanism This memo defines a keep-alive mechanism that MAY be used by the sender and receiver to terminate an inactive connection. The sender MAY indicate a keep-alive timeout interval that the receiver MAY use to teardown the session if no frames have been received during that interval. The keep-alive interval is signaled by an out-of-band mechanism. The usage of the session description to signal the keep-alive interval is described in section 5. Bouazizi Expires April 30, 2007 [Page 3] Internet-Draft ALC over Connection-Oriented Transport October 2006 If a keep-alive interval is signaled by the sender, the receiver SHOULD teardown the ALC/FLUTE session if no frames is received for a continuous period of time no shorter than the keep-alive time. When selecting the keep-alive time, the sender SHOULD account for all possible delay factors such as retransmission delays. The sender MAY use null-packets, as defined in section 2, to maintain the session if it anticipates that data will still be available for transmission to the receiver. 4. Further Considerations The framing method defined in this memo may be applied in an end-to- end system or at certain paths of the end-to-end system, where tunneling over TCP is required. This has the following consequences: o The order of the packets cannot be guaranteed. o Packet loss may occur and SHOULD be detected based on the EXT FTI header by detecting gaps in Source Block Number and Encoding Symbol IDs. 5. Session Descriptions for FLUTE over TCP This memo is based on the SDP descriptors for FLUTE [draft-mehta-rmt- flute-sdp]. Additionally, it defines the value "FLUTE/TCP" for the proto sub-field in the media description field. "FLUTE/TCP" refers to the deployment of FLUTE over TCP. This memo also defines a new session-level attribute "a=session- timeout", which is used to indicate the keep-alive time interval in seconds. The syntax of the attribute in ABNF format is as follows: session-timeout="a=session-timeout:" keep-alive-time keep-alive-time = 1*DIGIT ; value is the keep-alive time interval 6. Example The SDP description in Figure 2 is an example of the usage of the current memo to describe a FLUTE session over TCP along with a keep- alive time indication. v=0 o=user 17102006 524685645 IN IP6 120::42A:C1:7B64 s=FLUTE over TCP session i=Example of the session description Bouazizi Expires April 30, 2007 [Page 4] Internet-Draft ALC over Connection-Oriented Transport October 2006 t=3371675545 3371680487 a=source-filter: incl IN IP6 * 120::42A:C1:7B64 a=flute-tsi:145 a=flute-ch:1 a=session-timeout:200 m=application 12345 FLUTE/TCP * c=IN IP6 FF15::4040 Figure 2 Bit field definition of the framing method. 7. Congestion Control ALC and FLUTE MAY make use of the congestion control building block. Furthermore, the deployment over TCP ensures that the ALC/FLUTE session competes fairly with other TCP connections. 8. Security Considerations Implementers SHOULD pay attention to the security considerations that apply for FLUTE, ALC and LCT. Additionally, applications SHOULD be able to deal with any LENGTH field value from 0 to 2^^16-1, as attackers may use this field for exploiting security holes in the application. 9. IANA Considerations In section 5, a new value for the sub-field of the field "FLUTE/TCP" is defined. Section 5 also defines a session-level attribute . Section 6 gives an example of the usage of the new definitions in SDP. 10. Acknowledgments Bouazizi Expires April 30, 2007 [Page 5] Internet-Draft ALC over Connection-Oriented Transport October 2006 11. References 11.1. Normative References [RFC3450] M. Luby et al., "Asynchronous Layered Coding (ALC) Protocol Initiation", RFC 3450, December 2002. [RFC3451] M. Luby et al., "Layered Coding Transport (LCT) Building Block", RFC 3451, December 2002. [RFC3452] M. Luby et al., "Forward Error Correction (FEC) Building Block", RFC 3451, December 2002. [RFC3926] T. Paila et al., "FLUTE – File Delivery over Unidirectional Transport", RFC 3926, October 2004. [draft-mehta-rmt-flute-sdp] R. Walsh et al., "SDP descriptors for FLUTE", draft-meht-rmt-flute-sdp-05, January 2006. 11.2. Informative References rd [3GPPTS26.346] "3 Generation Partnership Project; Technical Specification Group Services and System Aspects; Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs (Release 7) ", September 2006. [ETSITS102472] "Digital Video Broadcasting; IP Datacast over DVB-H: Content Delivery Protocols", ETSI TS 102472, June 2006. [RFC4571] J. Lazzaro, "Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection- Oriented Transport", July 2006. Author's Addresses Imed Bouazizi Nokia Research Center Visiokatu 1, 33720, Tampere Email: imed.bouazizi@nokia.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has Bouazizi Expires April 30, 2007 [Page 6] Internet-Draft ALC over Connection-Oriented Transport October 2006 made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Bouazizi Expires April 30, 2007 [Page 7]