MMUSIC P. Stallard Internet-Draft TANDBERG Television Expires: August 11, 2003 T. Paila Nokia Corporation February 10, 2003 DVB thoughts on Service Discovery and Selection draft-stallard-mmusic-dvb-thoughts-on-sds-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 August 11, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This memo presents some thoughts on the requirements of Internet Media Guides. It is based on some similar work undertaken by the Digital Video Broadcasting (DVB) group. Stallard & Paila Expires August 11, 2003 [Page 1] Internet-Draft DVB thoughts on SDS February 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1 Service Provider and Service Discovery . . . . . . . . . . . . 4 4.2 Selection . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.3 General . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.4 Transport/Network . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . 10 Stallard & Paila Expires August 11, 2003 [Page 2] Internet-Draft DVB thoughts on SDS February 2003 1. Introduction The Digital Video Broadcasting Project (DVB) is an industry-led consortium of over 300 broadcasters, manufacturers, network operators, software developers and others in over 40 countries committed to designing global standards for the delivery of digital media including digital television and data services. DVB has established a working group called DVB-IPI (IP Infrastructure) responsible for solutions to carry DVB services over IP networks. In addition to the traditional DVB services that include digital TV and radio services, DVB-IPI will also consider new purely IP-based services. Several activities of the DVB apply protocols of the IETF and DVB-IPI is committed to use existing protocols wherever possible. The work of DVB-IPI has been divided into several areas, one of which is "Service Discovery and Selection" (SD&S). SD&S provides a mechanism for receivers to discover both service providers and services and sufficient information on these services to initiate reception. This document is an informative input to the IETF MMUSIC WG while working on "Internet Media Guides". It is drawn from the DVB's baseline requirements for Service Discovery and Selection and is provided here for information. Some requirements are annotated with comments preceded by "INFORMATIVE". These comments are for information/clarification only and are not part of the requirements. 2. Terminology The following terms are used throughout this document: HNED (Home Network End Device): For the purpose of this document, the HNED can be thought of a set top box capable of functioning as a network node in an IP network. SD&S: Refers to the entire Service Discovery and Selection mechanism, including the transport protocols and data structures. SD&S information: Refers specifically to the SD&S data structures and their representation. Service provider: An entity offering DVB services over IP. For the purposes of this document, a service provider can be regarded as an IP unicast or multicast source. Stallard & Paila Expires August 11, 2003 [Page 3] Internet-Draft DVB thoughts on SDS February 2003 3. Assumptions It is assumed that SD&S is provided with an entry point from which the process begins. (This could be something like a well-known multicast address or a web server URL). This entry point may be statically configured, provided as part of a network provisioning step, or acquired by some other mechanism outside the scope of SD&S. 4. Requirements The requirements are grouped under the following headings that vaguely reflect the chronological order in which SD&S is expected to operate. 1. Service Provider and Service Discovery 2. Selection 3. General 4. Transport/Network The headings do not impose any restrictions on the implementation of the mechanism. 4.1 Service Provider and Service Discovery 1000. SD&S shall enable the HNED to receive/retrieve, parse and render SD&S information for all available service providers and services. Services shall include multicast services, unicast services and scheduled services. INFORMATIVE: As examples, multicast services may include traditional broadcast services, unicast services may include content on demand and scheduled services may include pay-per-view events and Near Video on Demand. 1002. SD&S shall enable the discovery and selection of local DVB-over-IP services that originate from within the home network. INFORMATIVE: For example, services originating from a personal video recorder. 1005. SD&S shall allow the discovery of service providers. INFORMATIVE: This could be an automatic or manual process so both must be possible. Users might learn of a new service provider and want to type in the address and/or the HNED may choose to scan for Stallard & Paila Expires August 11, 2003 [Page 4] Internet-Draft DVB thoughts on SDS February 2003 new service providers. Some HNEDs may choose to disable this feature (if provided by a specific service provider for example). 1006. SD&S information shall be dynamic, enabling service providers to be created and removed, and for their service announcements to be updated as required. 1010. SD&S shall enable service providers to package sets of services such that, for example, packages can be offered to subscribers as a single entity. INFORMATIVE: This can provide a mechanism similar to the bouquet table of existing DVB Service Information. 1015. Service providers shall have the option to identify themselves by means of a name and a logo. 1016. SD&S shall provide service information likely to be used by filtering operations to present services of interest to the user. INFORMATIVE: The intention here is that SD&S shall give sufficient information to allow first-pass filtering so as to present only services which match certain criteria set by the user. Examples include the language, the country where a service is available and the genre/theme. 1017. SD&S shall provide a mechanism to acquire more comprehensive information on a given service if requested by the viewer. 1020. SD&S shall allow multiple service providers to coexist on a network. 1025. SD&S shall support service providers aggregating services from multiple service providers 1030. It shall be possible to uniquely identify services and service providers. INFORMATIVE: This is intended to enable HNEDs to determine that an identical service offered by different service providers is indeed the same service. The identifiers may be globally unique or unique to a particular domain of operation. Unique identifiers could be based on URLs. 4.2 Selection Prior to selection, a list (or some other representation) of the Stallard & Paila Expires August 11, 2003 [Page 5] Internet-Draft DVB thoughts on SDS February 2003 discovered services will be presented to the user. Selection (in terms of SD&S) takes place after the user has made a choice about which service to view. The "user" could be a person, system agent, terminal or some other entity. This presentation phase is private to the HNED and it therefore imposes no requirements on SD&S. 2000. SD&S shall allow the HNED to acquire all the information required to receive the chosen service. INFORMATIVE: This is the information required by the corresponding transport specification. Examples include a multicast address/ source address/port number, or an RTSP URL. For MPEG-2 TS, a mapping for the RTP payload type is also required. 2010. SD&S shall allow the description of all DVB services contained in MPEG-2 transport streams. INFORMATIVE: This includes MPEG-2 video and audio services (digital TV) and MPEG-1/MPEG-2 audio services (radio channels). Later transport mechanisms will be dealt with by Requirement 2020. 2020. This mechanism shall be extensible to support the selection of services not yet defined in TM-IPI transport specifications. An open-ended requirement. INFORMATIVE: The intent is that a reasonable level of flexibility is available that will allow the mechanism to be reasonably future proof. For example, MPEG-2 TS services are a single stream - it is likely that other formats will have separate streams for audio/ video etc. 4.3 General 3015. It shall be possible for part or all of the SD&S information to be encrypted. 3020. SD&S shall enable HNEDs to authenticate the source of service discovery and selection information. INFORMATIVE: There needs to be some way of ensuring that one service provider cannot masquerade as another service provider. 3025. SD&S shall enable HNEDs to verify the integrity of SD&S information. Stallard & Paila Expires August 11, 2003 [Page 6] Internet-Draft DVB thoughts on SDS February 2003 INFORMATIVE: A companion requirement to 3020. In addition to knowing that the information has come from where it says, the HNED should be able to verify that it hasn't been modified en route. 3030. SD&S shall provide a mechanism for HNEDs to detect when information has been added, updated, and deleted. INFORMATIVE: Without wanting to get in to the implementation choices, the premise is that the HNEDs need some way of keeping up to date with the minimum of effort. Of course some HNED manufacturers might opt to ignore this mechanism. 3035. It shall be possible to specify a valid-from and/or valid-until time for SD&S information. INFORMATIVE: This enables new SD&S information to be sent in advance with a time at which it will become valid, and to specify an expiry time after which the information will be invalid. 3040. SD&S shall allow the carriage of application-specific extensions. INFORMATIVE: The intention is to allow service providers to add proprietary features. 3045. SD&S shall be extensible for future use. INFORMATIVE: This is current DVB practice to support future requirements. 3050. SD&S information shall be encoded in an efficient manner to minimise/reduce the bandwidth required for its delivery. The coding may be different for different network paths and constituent links to enable optimisation between bandwidth and processing efficiency. INFORMATIVE: This is a non-testable requirement but it is included as a reminder that an efficient representation will be required. 3060. Any descriptor that can currently be carried in the service discovery tables of DVB SI shall have an equivalent representation in SD&S, unless there is a clear reason that it is not needed. INFORMATIVE: The intention here is that a piece of information that DVB previously described as necessary for service discovery (and filtering) should be present under SD&S unless we can clearly argue why it is not needed. Stallard & Paila Expires August 11, 2003 [Page 7] Internet-Draft DVB thoughts on SDS February 2003 4.4 Transport/Network 4000. SD&S shall support push and pull models of delivery. INFORMATIVE: The model used will be a deployment decision. It is a trade off between bandwidth usage (push) and server capability (pull). 4010. The contents and representation of the SD&S information shall be independent of the delivery model (pull or push). INFORMATIVE: This enables a service provider to offer both models without having to duplicate data. This requirement is applicable end-to-end such that it does not conflict with requirement 3050, which allows for transcoding for certain links. 4020. Any SD&S information that can be pushed may also be pulled, and vice-versa. INFORMATIVE: This implies that there is neither data that must be multicast, nor data that cannot be multicast. This is a deliberate clarification of 4000 to make it clear that the push/ pull applies to all data items and not to any single point. 4030. SD&S shall be scalable. It shall work efficiently from small to large HNED populations, and from small to large service offerings. 4040. Carriage of SD&S information should be as efficient as possible to reduce distribution costs and network congestion. INFORMATIVE: For example, it is expected that the option of multicast delivery will need to be provided. Authors' Addresses Paul Stallard TANDBERG Television Strategic Park Comines Way Hedge End Southampton SO30 4DA United Kingdom EMail: pstallard@tandbergtv.com URI: http://www.tandbergtv.com/ Stallard & Paila Expires August 11, 2003 [Page 8] Internet-Draft DVB thoughts on SDS February 2003 Toni Paila Nokia Corporation Itamerenkatu 11-13 00180 Helsinki Finland EMail: toni.paila@nokia.com URI: http://www.nokia.com/ Appendix A. Acknowledgements The authors gratefully acknowledges the contributions of their colleagues within DVB. Stallard & Paila Expires August 11, 2003 [Page 9] Internet-Draft DVB thoughts on SDS February 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). 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 languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Stallard & Paila Expires August 11, 2003 [Page 10] Internet-Draft DVB thoughts on SDS February 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Stallard & Paila Expires August 11, 2003 [Page 11]