Network Working Group T. Lohmar Internet-Draft T. Einarsson Intended status: Standards Track M. Westerlund Expires: June 22, 2007 I. Johansson Ericsson December 19, 2006 Controlling FLUTE sessions with Real-Time Streaming Protocol (RTSP) draft-lohmar-mmusic-rtsp-flute-01 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 June 22, 2007. Copyright Notice Copyright (C) The IETF Trust (2006). Abstract File Delivery over Unidirectional Transport (FLUTE) is defined in RFC 3926 and provide an extensible framework for delivering any type of files over UDP. FLUTE is mostly intended for IP multicast communication, but the use with IP unicast is not excluded. Real- time Streaming Protocol (RTSP) allow the play-out of media packets to multicast and unicast sessions. Lohmar, et al. Expires June 22, 2007 [Page 1] Internet-Draft Controlling FLUTE sessions with RTSP December 2006 Requirements Language 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]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. On-demand Playback using Multicast . . . . . . . . . . . . 3 2.2. Unicast distribution of Live and Stored content . . . . . 3 3. General RTSP extensions . . . . . . . . . . . . . . . . . . . 4 3.1. General Procedure Description . . . . . . . . . . . . . . 4 3.2. FLUTE specific SDP extensions . . . . . . . . . . . . . . 4 3.3. RTSP Method Handling . . . . . . . . . . . . . . . . . . . 4 3.3.1. Session Set-up . . . . . . . . . . . . . . . . . . . . 4 3.3.2. RTSP PLAY method . . . . . . . . . . . . . . . . . . . 5 3.3.3. RTSP PAUSE method . . . . . . . . . . . . . . . . . . 5 3.3.4. RTSP Teardown method . . . . . . . . . . . . . . . . . 6 3.4. RTSP feature tag . . . . . . . . . . . . . . . . . . . . . 6 4. Flute Data Considerations . . . . . . . . . . . . . . . . . . 6 4.1. Congestion Control . . . . . . . . . . . . . . . . . . . . 6 4.2. Adaptation of FLUTE data flow . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Lohmar, et al. Expires June 22, 2007 [Page 2] Internet-Draft Controlling FLUTE sessions with RTSP December 2006 1. Introduction File Delivery over Unidirectional Transport (FLUTE) is defined in RFC 3926 [RFC3926] and provide an extensible framework for delivering any type of files over UDP. FLUTE is primarily intended for multicast communication, but not restricted to it. 3GPP Multimedia Broadcast and Multicast Service (MBMS) [3GPP.26.346], and Open Mobile Alliance (OMA) BAC BCAST specifications [OMA-BCAST]) supports the usage of FLUTE sessions in combination with RTP sessions. One important use- case of FLUTE transmissions simultaneously to RTP transmissions are voting and general interactivity services for Mobile TV applications. OMA BAC BCAST defines so-called Interactivity Media documents, which may be transmitted simultaneously with RTP sessions using FLUTE. OMA BAC BCAST [OMA-BCAST] also allows the usage of FLUTE on unicast IP sessions. This internet-draft proposes the definition of a FLUTE session establishment and control with RTSP 1.0 [RFC2326] and RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis] . RTSP already allows to control the playback of content into both unicast and multicast groups. Therefore, it is natural to extend RTSP to control also FLUTE sessions. An additional convience is that MPEG is currently defining FLUTE hint-tracks for the ISO file format. Thus a FLUTE enabled streaming server can be controlled using the RTSP protocol to playback a predefined session to a unicast address or a mutlicast group. Enabling efficient use of RTSP for contolling a OMA BAC BCAST multicast server. 2. Use Cases This section describes two use cases for FLUTE play-out control by RTSP. The use-cases here are aligned to the use-cases described in RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis]. 2.1. On-demand Playback using Multicast It is possible to use RTSP to request that media is delivered to a multicast group. FLUTE may be used together with a multicast session, since it was primarily designed for File-delivery over multicast IP session. The content may be pre-recorded or generated on the fly (live). 2.2. Unicast distribution of Live and Stored content FLUTE is primarily designed for multicast transmissions. However, the use on unicast is not restricted by FLUTE. A live server may offer a session via multicast and also via unicast distribution. In Lohmar, et al. Expires June 22, 2007 [Page 3] Internet-Draft Controlling FLUTE sessions with RTSP December 2006 such a case, the same UDP payload may be transmitted towards the multicast session and the unicast on-demand sessions. The streaming server however needs to be configured with the destination address and port. In the unicast case the streaming server will need to adjust the IP and UDP headers of the flute packets for the distribution method. 3. General RTSP extensions This section first describe the general procedures of RTSP 1.0 and RTSP 2.0 for the FLUTE session configuration. Further the necessary RTSP Method handling is described. 3.1. General Procedure Description FLUTE [RFC3926] is a unidirectional file delivery protocol. A file is partitioned into smaller chunks, which fit into UDP packets of predefined size. The file properties, such as the file name, MIME type, etc are described in the FLUTE File Delivery Table (FDT). The FDT is send in-band in the FLUTE session and is identified by a well- defined value in the FLUTE packet header (i.e. Transport Object Identifier is set to zero). A FLUTE session may utilize several UDP ports simultaneously. If more than one UDP port is required, this is indicated in the "a=flute-ch:" attribute in the SDP. 3.2. FLUTE specific SDP extensions The FLUTE specific SDP extensions are defined in [I-D.mehta-rmt-flute-sdp]. For the FLUTE session establishment using RTSP, control URI on media level as defined in RTSP 1.0 [RFC2326] SHALL be present for the FLUTE media description. The media control URI is used within the RTSP SETUP method to establish the described FLUTE sessions. 3.3. RTSP Method Handling 3.3.1. Session Set-up The control URI on media level as defined in RTSP 1.0 [RFC2326] and RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis] is used to control the FLUTE session. The control URI is used within the RTSP SETUP method to establish the described FLUTE sessions. The RTSP transport protocol specifie, profile and lower layer transport for FLUTE as defined in RTSP 1.0 [RFC2326] SHALL be "FLUTE/ UDP". Note that RTSP 1.0 does not allow any extension of this field in its syntax. However the intention seems to allow it, and we will Lohmar, et al. Expires June 22, 2007 [Page 4] Internet-Draft Controlling FLUTE sessions with RTSP December 2006 use it under a feature tag to prevent non-updated implementations from handling this extended field. One and only one UDP port is allocated for each FLUTE channel. If the "flute-ch" attribute is present for the FLUTE session, an according number of FLUTE sessions is established. The following RTSP 1.0 defined RTP specific parameters SHALL be used in the transport request and responds header for FLUTE sessions. o port: This parameter provides the FLUTE port(s) for a multicast session. If more than one channel is defined in the SDP, then it is specified as a range, e.g., port=3456-3457. o client_port: This parameter provides the unicast FLUTE port(s) on which the client has chosen to receive FLUTE data. If more than one channel is defined in the SDP, then it is specified as a range, e.g., client_port=3456-3457. o server_port: This parameter provides the unicast FLUTE port(s) on which the server has chosen to receive data. If more than one FLUTE channel is defined in the SDP, then it is specified as a range, e.g., server_port=3456-3457. The syntax for transport protocol specifiers in RTSP 2.0 transport header is defined as one or more tokens separated by a "/" (See ABNF in section 19.2.3 of RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis]. 3.3.2. RTSP PLAY method The PLAY method tells the server to start sending data including FLUTE session data as defined in [I-D.ietf-mmusic-rfc2326bis]. For "Live" session, the RTSP server forwards the FLUTE packets as they are received. For stored sessions, it is expected that transmission timing information for the FLUTE packets are stored with the FLUTE session. ntp, smpte or clock range units MAY be used with the "Range" headers. Normal play time (NPT) indicates the stream absolute position relative to the beginning of the presentation. The timestamp consists of a decimal fraction. The clock range header describe the absolute time expressed as ISO 8601 timestamps, using UTC (GMT). 3.3.3. RTSP PAUSE method The PAUSE request causes the stream delivery including all FLUTE sessions to be interrupted (halted) as defined in Lohmar, et al. Expires June 22, 2007 [Page 5] Internet-Draft Controlling FLUTE sessions with RTSP December 2006 [I-D.ietf-mmusic-rfc2326bis]. 3.3.4. RTSP Teardown method The TEARDOWN client to server request stops the stream delivery including all FLUTE data delivery for the given URI, freeing the resources associated with it. Details for the TEARDOWN method are defined in [I-D.ietf-mmusic-rfc2326bis]. 3.4. RTSP feature tag To ensure that this extension is not sent to a server not capable of handling it we define a RTSP feature tag (also called option tag) "flute-ctrl". This feature tag SHALL be included in all SETUP requests which contains the "FLUTE/UDP" transport specification. 4. Flute Data Considerations There are a few considerations need when implementing the support for controlling FLUTE sessions. 4.1. Congestion Control For all type of networks it is recommended that one monitor the congestion state of the paths between sender and receiver to avoid causing severe congestion or being significantly unfair to other flows. This is a requirement for non-managed networks where resources are not specifically set aside for the FLUTE/UDP flows. But also in managed networks this is recommended to handle error cases, such as re-routing due to link layer failures. If FLUTE/UDP traffic is sent over multicast a receiver driven congestion control algorithm, such as WEBRC [RFC3738], could be used. In this case the usage of RTSP to control the transmission would be completely separate from the congestion control mechanism. For FLUTE/UDP to unicast recipients the situation is not as simple. In cases where multicast is used to deliver media to the RTSP servers back-end then WEBRC could be propogated forward towards the unicast connected client. However that would require a control channel to enable and disable delivery to between the RTSP server and the client to replace IGMP or MLD as used in WEBRC. The method for accomplishing this is for future study. If FLUTE/UDP packets transmitted would not be using WEBRC towards the client another method for congestion control would be needed. This is for future study. Possible solutions are usage of DCCP [RFC4340], Lohmar, et al. Expires June 22, 2007 [Page 6] Internet-Draft Controlling FLUTE sessions with RTSP December 2006 a feedback protocol integrated with the RMT builings blocks to enable usage of TFMCC [RFC4654] or other similar solutions. 4.2. Adaptation of FLUTE data flow The FLUTE data flow may contain FEC data. In these case the streaming server MAY adapt the flow to the known error properties of the path between the server and the client. However, the feasability of this is dependent on the FEC code in use. 5. IANA Considerations The transport header protocol specifier: "FLUTE/UDP" will be registered with the IANA. The registration will follow the rules defined in section 21.5 of RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis]. 6. Security Considerations See [I-D.ietf-mmusic-rfc2326bis] for security considerations related to the Real-Time Streaming Protocol. There are some confidentiality and integrity issues with FLUTE sessions. Please also see the security considerations in [I-D.ietf-rmt-flute-revised]and in [I-D.mehta-rmt-flute-sdp]. There might be a need to confidentiality protect the files in a FLUTE session. It is possible to use SMIME within FLUTE sessions. There is currently no approach to confidentiality and/or integrity protect the FLUTE FDT. Malicious FLUTE FDT packets might detern a FLUTE client from receiving files. There is ongoing work in the RMT and MSEC WGs to provide security solutions to secure the media transport. The usage of RTSP to configure delivery of FLUTE/UDP packets and control when delivery happens does result in the following issues: o Authorization to access the content needs to be verified in cases the content's distribution is restricted. o To prevent denial of service attacks either by congestion or simply by injection of confusing or potentially overlapping FLUTE traffic the right to request delivery to an address or multicast group must be verified. o To ensure confidentiality or privacy against eavsdropping network devices the usage of TLS for RTSP signalling is recommended. Lohmar, et al. Expires June 22, 2007 [Page 7] Internet-Draft Controlling FLUTE sessions with RTSP December 2006 7. Acknowledgements The authors would like to thank all the people who gave feedback on this document. 8. References 8.1. Normative References [I-D.ietf-mmusic-rfc2326bis] Schulzrinne, H., "Real Time Streaming Protocol 2.0 (RTSP)", draft-ietf-mmusic-rfc2326bis-13 (work in progress), June 2006. [I-D.ietf-rmt-flute-revised] Paila, T., "FLUTE - File Delivery over Unidirectional Transport", draft-ietf-rmt-flute-revised-02 (work in progress), August 2006. [I-D.mehta-rmt-flute-sdp] Mehta, H., "SDP Descriptors for FLUTE", draft-mehta-rmt-flute-sdp-05 (work in progress), January 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. [RFC3926] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh, "FLUTE - File Delivery over Unidirectional Transport", RFC 3926, October 2004. 8.2. Informative References [3GPP.26.346] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs", 3GPP TS 26.346 6.6.0, October 2006. [OMA-BCAST] Open Mobile Alliance BAC BCAST, "Mobile Broadcast Services, OMA-TS-BCAST_Services-V1_0", OMA TS OMA-TS- BCAST_Services-V1_0, April 2006. [RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate Control (WEBRC) Building Block", RFC 3738, April 2004. Lohmar, et al. Expires June 22, 2007 [Page 8] Internet-Draft Controlling FLUTE sessions with RTSP December 2006 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006. [RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast Congestion Control (TFMCC): Protocol Specification", RFC 4654, August 2006. Authors' Addresses Thorsten Lohmar Ericsson Ericsson Allee 1 Herzogenrath, D-52134 Germany Phone: +49-2407-5757816 Fax: Email: thorsten.lohmar@ericsson.com URI: Torbjoern Einarsson Ericsson Torshamnsgatan 23 Stockholm, SE-16480 Sweden Phone: +46-8-7190000 Fax: Email: torbjorn.einarsson@ericsson.com URI: Magnus Westerlund Ericsson Torshamnsgatan 23 Stockholm, SE-16480 Sweden Phone: +46-8-7190000 Fax: Email: magnus.westerlund@ericsson.com URI: Lohmar, et al. Expires June 22, 2007 [Page 9] Internet-Draft Controlling FLUTE sessions with RTSP December 2006 Ingemar Johansson Ericsson Laboratoriegrand 11 Lulea, SE-976 32 SWEDEN Phone: +46 8 7190000 Fax: Email: ingemar.s.johansson@ericsson.com URI: Lohmar, et al. Expires June 22, 2007 [Page 10] Internet-Draft Controlling FLUTE sessions with RTSP December 2006 Full Copyright Statement Copyright (C) The IETF Trust (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. 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, THE IETF TRUST 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. Intellectual Property 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 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Lohmar, et al. Expires June 22, 2007 [Page 11]