P2PSIP WG Seok-Kap Ko Internet Draft Young-Han Kim Intended status: Standards Track Soongsil University Expires: August 21, 2009 Byoung-Tak Lee ETRI February 21, 2009 An IPTV Usage for RELOAD draft-softgear-p2psip-iptv-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 August 21, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Seokkap, et al. Expires August 21, 2009 [Page 1] Internet-Draft RELOAD IPTV Usage February 2009 Abstract This document defines a distributed IPTV Usage for Resource Location And Discovery (RELOAD). The IPTV Usage provides lookup service for IPTV channel information and IPTV metadata stored in the overlay. The Attach method is used to establish a direct connection between a distributed channel manager and a viewer. IPTV control messages are exchanged through this connection. Table of Contents 1. Overview .................................................... 2 2. Terminology ................................................. 6 3. Registering IPTV information ................................ 7 3.1. Registering IPTV Channel information ................... 7 3.2. Registering IPTV Metadata .............................. 9 4. Looking up IPTV information ................................ 11 4.1. Looking up IPTV Metadata .............................. 12 4.2. Looking up IPTV Channel information ................... 12 4.3. Forming a Direct Connection ........................... 12 5. IPTV-CHANINFO Kind Definition .............................. 12 6. IPTV-METADATA Kind Definition .............................. 13 7. Security Considerations .................................... 13 8. IANA Considerations ........................................ 13 9. Acknowledgments ............................................ 14 10. References ................................................ 14 10.1. Normative References ................................. 14 10.2. Informative References ............................... 14 1. Overview RELOAD provides distributed storage and distributed service [I- D.ietf-p2psip-base]. RELOAD does not only support SIP based VoIP service but also other services. This IPTV (Internet Protocol Television) Usage of RELOAD allows RELOAD to store IPTV related information within the overlay. The following figure illustrates a distributed IPTV system. The network supporting the distributed IPTV service consists of a Distributed Management Network, a Distributed Delivery network, and some additional servers. The Distributed Delivery Network consists of media Relays for the overlay multicast network. A Contents Provider who wants to broadcast its own IPTV contents, registers its contents information to one of Channel Managers in the Distributed Management Network. The Channel Manager manages a Contents Provider, Relays, and Viewers for the IPTV channel. The Channel Manager controls media Seokkap, et al. Expires August 21, 2009 [Page 2] Internet-Draft RELOAD IPTV Usage February 2009 flows among Relays so that the contents of the Contents Provider are delivered to the Viewers via the Relays. The Channel Manager uses a specific protocol to control entities in a Distributed Delivery Network. This protocol MAY be SIP(Session Initiation Protocol). The Viewer who wants to watch a certain channel finds an appropriate Channel Manager for the channel from the Distributed Management Network. After a Viewer finds a Channel Manager, the Viewer connects to the Channel Manager. The Channel Manager allows Viewers to receive contents from the Relays. +------------------------------+ |Distributed Management Network| | +------------------+ | +------------+ Channel Manager +--------------+ | | +--+------------+--+ | | | +------|------------|----------+ | | | | | | +------|------------|----------+ | | | | | | | +----+-----+ | +-------+ +-------+ | +---+----+ | Contents |=====| Relay |= ... =| Relay |======| Viewer | | Provider | | +-------+ +-------+ | +--------+ +----------+ |Distributed Delivery Network | +------------------------------+ Figure 1 Distributed IPTV Usage Overview. In the distributed IPTV service, there is one channel manager for one channel logically. A Channel Manager manages Viewer list and forms a media delivery tree. The IPTV Usage of RELOAD distributes channel managers to the overlay. A Viewer who wants to watch a certain IPTV channel looks up a corresponding Channel Manager for the channel from the overlay, and establishes a connection to the Channel Manager. Also, IPTV Usage for RELOAD allows a node to look up channel information with a certain keyword or a category from the overlay. For example, if Bob is a Contents Provider and Alice is a Viewer who wants to watch Bob's channel, it works as the following sequence. 1. First, Bob makes a channel ID "ch-b1" and hashes it to the Hashed Channel ID "3333" using a consistent hash function like SHA-1. Bob fills additional information about this channel. Bob sends RELOAD StoreReq message to store channel information within the overlay. This channel information contains Channel-ID, Title, Contents Provider Node-ID, and optionally Application Server Node-ID. Seokkap, et al. Expires August 21, 2009 [Page 3] Internet-Draft RELOAD IPTV Usage February 2009 2. Assume that Charlie(PeerID 3344) is the responsible peer of the hashed Channel ID "3333". Charlie stores this channel information and works as a Channel Manager for this "ch-b1" channel. 3. The Channel Manager, Charlie distributes the metadata about this channel within the overlay. The Channel Manager hashes keywords in metadata and stores them within the overlay. For example, if the title description of this channel is "Bob's Live Show", the channel manager divides this title to "Bob", "Live", and "Show". The channel manager hashes each word and stores each partial metadata within the overlay. This partial metadata contains description type, full description of this type and a Hashed Channel ID. 4. Now, the Viewer, Alice (Node ID "5678") inputs the keyword, "Live Show" to find a channel. Alice divides the keyword into "Live" and "Show" and sends two RELOAD FetchReqs to the overlay. And, it finds "Bob's Live Show". The result of the FetchReq has Hashed Channel ID. 5. Alice can see the channel list from the results. This channel list consists of channels which have the title including "Live" and "Show". Alice chooses "Bob's Live Show" from the channel list. Alice sends RELOAD FetchReq with the Hashed Channel ID. From the result of the FetchReq, Alice gets the Channel Manager Node-ID. 6. Alice sends AttachReq to the Channel Manager. Now, She can connect to the Channel Manager, Charlie. 7. According to Channel Management Mechanism, Channel Manager, Charlie, sends AttachReq to the contents providers, Bob. 8. After that, Alice, Bob, and Charlie exchange a certain IPTV Media Delivery Network Control Protocol messages. Seokkap, et al. Expires August 21, 2009 [Page 4] Internet-Draft RELOAD IPTV Usage February 2009 Overlay Alice Overlay PeerCharie Bob (5678) Peers (3344) (1234) --------------------------------------------------------------- <<----- StoreReq(3333) StoreAns ---------->> <<-StoreReq(H"Bob") StoreAns ----->> <<-StoreReq(H"Live") StoreAns ----->> <<-StoreReq(H"Show") StoreAns ----->> FetchReq(H"Live")->> <<---- FetchAns(3333) FetchReq(H"Bob")-->> <<---- FetchAns(3333) FetchReq(3333)---------------------->> <<--------------------------- FetchAns AttachReq(3333)--------------------->> <<-------------------------- AttachAns <------------ ICE CHECK ------------> AttachReq(1234)----->> <<---------- AttachAns <----- ICE CHECK ----> (ChannelManager) <--- MEDIA CONTROL --> <------------ MEDIA CONTROL ---------> <--------------------------- MEDIA --------------------------> Figure 2 IPTV Usage Overview. As SIP Usage for RELOAD[I-D.ietf-p2psip-sip], RELOAD's role in a distributed IPTV system is forming a direct connection between a Channel Manager and a Contents Provider, or between a Channel Manager and a Viewer. The application field in a AttachReq message SHOULD be a specific Media Delivery Network Control Protocol's port number. This document doesn't define IPTV Media Delivery Network Control Protocol. A Channel Manager or all nodes in RELOAD may use private IP address. Therefore, the IPTV Usage exchanges ICE Candidates using RELOAD Seokkap, et al. Expires August 21, 2009 [Page 5] Internet-Draft RELOAD IPTV Usage February 2009 AttachReq/Ans messages. To do NAT traversal, IPTV Nodes MAY use TURN Service which RELOAD provides. IPTV Usage allows the RELOAD overlay to be a distributed IPTV channel manager and a distributed IPTV metadata storage. The major actions are summarized to the following 5 actions. o Registering contents providers' IPTV channel information with the overlay and assigning a channel manager for the channel. o Registering IPTV metadata with the overlay. o Looking up a IPTV channel from metadata. o Looking up the Channel Manager. o Forming a direct connection to the Channel Manager. 2. Terminology 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]. The concepts used in this document are compatible with "Concepts and Terminology for Peer to Peer SIP" [I-D.ietf-p2psip-concepts] and the P2PSIP base protocol RELOAD[I-D.ietf-p2psip-base]. Channel : a media stream from a contents provider to Viewers. There may be some Relays between a Contents Provider and Viewers. Channel ID : a global unique ID which identifies a certain Channel. It may be a human readable ID. Hashed Channel ID : a result of hash function of Channel ID. To store channel information to the overlay, channel ID should be hashed. Contents Provider : a source entity which produces media for a Channel. Viewer : a entity which receives media from a Contents Provider or a Relay. Seokkap, et al. Expires August 21, 2009 [Page 6] Internet-Draft RELOAD IPTV Usage February 2009 Relay : a entity helps to deliver media from Contents Provider to Viewers. A Contents Provider or Viewer can be a Relay. Channel Manager : a entity manages a Channel. It keeps Contents Provider information and Viewer list. It controls media delivery network while forming a media delivery tree. A Viewer can be a relay in media delivery network according to Media Delivery Network Control Protocol. Channel Manager is similar to a tracker in BitTorrent. Application Server : an additional entity which work together with a channel manager to make a certain service. Media Delivery Network Control Protocol : a protocol which control media delivery tree. It makes a node to send media somewhere or to receive from somewhere. SIP(Session Initialization Protocol) can be a candidate of this protocol. Metadata : All descriptions and information about a certain channel. It contains title, category, language, credit, and so on. It may be used to find a certain channel. User : a person handles a certain agent. Agent : a entity helps an User. There are Contents Provider Agent and Viewer Agent. 3. Registering IPTV information If a Contents Provider wants to make its own IPTV channel, it MUST make a Channel ID, and describes this Channel. And, it MUST register this channel into the overlay. This document does not define the way to make a Channel ID. But, a Channel-ID MUST be a global unique ID. 3.1. Registering IPTV Channel information In ordinary centralized IPTV, a contents provider registers its channel information to an IPTV server. However, in distributed IPTV, a Contents Provider registers its channel information to the overlay. To register its channel information, a RELOAD peer stores IptvChanInfo structure with its channel ID. This uses IPTV-CHANINFO Kind-ID, which is formally defined in Section 5. All Peers in RELOAD SHOULD work as an IPTV server. The responsible peer of the channel ID SHOULD work as a Channel Manager. The Channel Seokkap, et al. Expires August 21, 2009 [Page 7] Internet-Draft RELOAD IPTV Usage February 2009 Manager manages all nodes which attend this channel. And, it controls these nodes to form a media delivery tree. For a simple example, if a channel ID is "diptv:bob_livetv_show" and the hashed channel ID is "1234", the responsible peer "1200" should store channel information and work as a Channel Manager. Other viewers can contact the channel manager using the Hashed Channel ID. The Contents provider or the responsible peer of a certain channel ID MAY choose another peer than the responsible peer as a Channel Manager. This draft does not define the method of assigning other channel manager. But, we MAY use random searching in the overlay. The contents of a IptvChanInfo structure are as follows: struct { opaque title<0..2^16-1>; opaque synopsis<0..2^16-1>; opaque genre<0..2^16-1>; opaque language<0..2^16-1>; opaque cast<0..2^16-1>; opaque group<0..2^16-1>; opaque credit<0..2^16-1>; opaque review<0..2^16-1>; opaque crid<0..2^16-1>; } ContentsDescription; struct { uint64 start_time; uint64 finish_time; opaque contents_provider_name<0..2^16-1>; opaque URL<0..2^16-1>; opaque logo<0..2^16-1>; } InstanceDescription; struct { opaque channel_id<0..2^16-1>; ContentsDescription contents_desc; InstanceDescription instance_desc; Destination contents_provider; Destination channel_manager; Destination application_server_list<0..2^16-1>; } IptvChanInfo; The contents of the IptvChanInfo PDU are: Seokkap, et al. Expires August 21, 2009 [Page 8] Internet-Draft RELOAD IPTV Usage February 2009 channel_id The identifier of the channel. A unhashed ID contents_desc Descriptions, category, types, and contents related information of a Channel instance_desc Start,finish time, and instance related information of a Channel contents_provider Content Provider's NodeID channel_manager Channel Manager's NodeID to attach application_server_list Additional application server Node ID list The contents descriptions and instance descriptions are inherited from [TVAF]. In order to prevent hijacking, registrations are subject to access control rule. Before a StoreReq is permitted, the storing peer MUST check that the certificate contains a Node-ID that is the same as the Contents Provider ID in the message. Note that this rule permits only a Contents Provider to register, modify, or delete this channel information. 3.2. Registering IPTV Metadata The other user does not know a registered channel ID. It should be possible to look up a certain channel with keywords. Additional information about the channel is metadata. The Channel Manager MAY register metadata about the channel with the overlay. To register metadata, a RELOAD peer stores IptvMetadata structure. IptvMetadata contains keyword and channel id as major information. This is used by IPTV-METADATA Kind-ID, which is formally defined in Section 6. Seokkap, et al. Expires August 21, 2009 [Page 9] Internet-Draft RELOAD IPTV Usage February 2009 The Channel Manager hashes each keyword to resource-IDs and stores these partial metadata within the overlay using StoreReq. All RELOAD peers MUST have storage for this metadata. The results of fetching a metadata are used to make a keyword matching list. Note that the Contents Provider MAY store metadata but some scenarios does not want to expose the Contents Provider to normal users. As a simple example above, if the title of a channel is "Bob's live talk show", the Channel Manager MAY make 4 words as title metadata keywords. It hashes each word and stores each title metadata keyword with the overlay. Each metadata will be stored in distributed peers. The contents of a IptvMetadata structure are as follows: enum { iptv_metakeyword_contdesc_title(1), iptv_metakeyword_contdesc_synopsys(2), iptv_metakeyword_contdesc_genre(3), iptv_metakeyword_contdesc_language(4), iptv_metakeyword_contdesc_cast(5), iptv_metakeyword_contdesc_group(6), iptv_metakeyword_contdesc_credit(7), iptv_metakeyword_contdesc_review(8), iptv_metakeyword_contdesc_crid(9), } IptvMetadataType; struct { IptvMetadataType type; opaque keyword<0..2^16-1>; opaque description<0..2^16-1>; opaque channel_id<0..2^16-1>; ResourceID hashed_channel_id; Destination .annel_manager; } IptvMetadata; The contents of the IptvMetadata PDU are: type the description type of the metadata keyword keyword partial keyword Seokkap, et al. Expires August 21, 2009 [Page 10] Internet-Draft RELOAD IPTV Usage February 2009 description full description. This description contains the keywords. channel_id the unhashed channel id hashed_channel_id the hashed channel_id to fetch more channel information channel_manager the channel_manager Node-Id which controls this channel The data model for the IPTV metadata Kind-ID is an array. Because Resource ID is derived from a keyword, it may cause a collision. But, the metadata record will be accumulated because the data model is array. In order to prevent hijacking, before a StoreReq is permitted, the storing peer MUST check if the certificate contains Node-ID is the same as the channel_manager Node-Id in the message. 4. Looking up IPTV information When a Viewer wishes to look up a certain channel with some keywords, she follows the following procedure. 1. A Viewer User inputs keywords per a description type. 2. The Viewer Agent hashes the inputted keywords and looks up IPTV metadata from the overlay. 3. The Viewer Agent shows the look-up result in order. The result is a list of channels. 4. The Viewer User chooses one item in the list. The Viewer Agent attaches the corresponding Channel Manager. 5. The Channel Manager controls the Contents Provider, Relays, and Viewers to deliver the media stream from the Contents Provider to Viewers. Consequently, the Contents Provider sends media to a Relay. Relay sends received media to Viewer Agent. Seokkap, et al. Expires August 21, 2009 [Page 11] Internet-Draft RELOAD IPTV Usage February 2009 4.1. Looking up IPTV Metadata A Viewer makes ResourceID with hashing the user inputted keyword and Description Type (IptvMetadataType). The Viewer sends FetchReq which contains a ResourceID and a Kind-ID. The Kind-ID in the FetchReq is IPTV-METADATA. The Viewer can get the result of searching a specific keyword with IptvMetadataType. The result contains the full description for specified metadata type and the Hashed Channel ID. The Viewer MAY get more information about this channel with sending FetchReq which contains a Hashed Channel ID as a Destination ID. 4.2. Looking up IPTV Channel information If a Viewer knows Channel ID, the Viewer can get a Hashed Channel ID with hashing a Channel ID. Also, a Viewer can get Hashed Channel ID through the metadata searching. A Viewer sends FetchReq which has the Hashed Channel ID as Destination ID. The responsible peer of the Hashed Channel ID responds with FetchAns. The FetchAns has Channel Manager Node-ID. 4.3. Forming a Direct Connection If a node knows Channel Manager Node-ID, the node can send AttachReq which has Channel Manager Node-ID as a Destination. The application field in this AttachReq MUST be a certain IPTV Media Delivery Network Control Protocol's port number. If a nodes support only ICE-lite, AttachLiteReq MUST be used instead of AttachReq. AttachReq contains requester's ICE candidates. AttachAns contains responder's ICE candidates. After exchanging ICE candidates, they perform ICE checking[I-D.ietf-mmusic-ice] and establish a connection for IPTV Media Delivery Network Control Protocol. 5. IPTV-CHANINFO Kind Definition The distributed IPTV channel information is provided using the IPTV- CHANINFO Kind-ID: o Kind ID - The Resource Name for the IPTV-CHANINFO is Channel ID. The data stored is a IptvChanInfo, which contains channel manager ID, channel description, and additional information. Seokkap, et al. Expires August 21, 2009 [Page 12] Internet-Draft RELOAD IPTV Usage February 2009 o Data Model - The data model for the IPTV-CHANINFO is single. A Channel has only one IPTV-CHANINFO. o Access Control - If certificate-based access control is used, stored data of Kind-ID IPTV-CHANINFO must be signed by certificate which contains Node-ID matching the Contents Provider Node-ID. 6. IPTV-METADATA Kind Definition The distributed IPTV metadata is provided using the IPTV-METADATA Kind-ID: o Kind ID - The Resource Name for the IPTV-METADATA is IptvMetadataType and keyword. The format of Resource name is : IptvMetadataType "+" Keyword The IptvMetadataType in Resource Name is a character string. For example, if the IptvMetadataType is iptv_metakeyword_contdesc_title and the keyword is "Bob", the resource name is "1+Bob". The stored data is a IptvMetadata, which contains one of description and Channel ID. o Data Model - The data model for the IPTV-METADATA is Array. There MAY be many records with the same Resource-ID. o Access Control - If certificate-based access control is being used, stored data of Kind-ID IPTV-METADATA must be signed by certificate which contains Node-ID matching the Channel Manager Node-ID. 7. Security Considerations TODO - fill in 8. IANA Considerations IANA SHALL add IPTV-CHANINFO and IPTV-METADATA into "RELOAD Data Kind-ID" Registry, which is defined in Section 14.2 Data Kind-ID in [I-D.ietf-p2psip-base]. The additional contents of the registry are: Seokkap, et al. Expires August 21, 2009 [Page 13] Internet-Draft RELOAD IPTV Usage February 2009 +--------------------+------------+----------+ | Kind | Kind-ID | RFC | +--------------------+------------+----------+ | IPTV-CHANINFO | 16 | RFC-AAAA | | IPTV-METADATA | 17 | RFC-AAAA | +--------------------+------------+----------+ 9. Acknowledgments TODO - fill in 10. References 10.1. Normative References [I-D.ietf-p2psip-base] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) Base Protocol", draft-ietf-p2psip-base- 01 (work in progress), December 2008. [I-D.ietf-p2psip-sip] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. Schulzrinne, "A SIP Usage for RELOAD", draft- ietf-p2psip-sip-00 (work in progress), October 2008 [I-D.ietf-mmusic-ice] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", draft-ietf-mmusic-ice-19 (work in progress), October 2007. 10.2. Informative References [I-D.ietf-p2psip-concepts] Bryan, D., Matthews, P., Shim, E., Willis, D., and S. Dawkins, "Concepts and Terminology for Peer to Peer SIP", draft-ietf-p2psip-concepts-02 (work in progress), July 2008. [TVAF] SP003v13, "Metadata", 2002, TV-Anytime Forum, http://www.tv- anytime.org/ Seokkap, et al. Expires August 21, 2009 [Page 14] Internet-Draft RELOAD IPTV Usage February 2009 Author's Addresses Seok-Kap Ko Soongsil University Sangdo-dong, Dongjak-Gu, Seoul Korea Phone: +82-2-820-0841 Email: softgear@dcn.ssu.ac.kr Young-Han Kim Soongsil University Sangdo-dong, Dongjak-Gu, Seoul Korea Phone: +82-2-814-0151 Email: younghak@ssu.ac.kr Byoung-Tak Lee ETRI HRC 1000-6 Oryong-dong, Buk-gu, Gwangju, 500-480 Korea Phone: +82-62-970-6624 Email: bytelee@etri.re.kr Seokkap, et al. Expires August 21, 2009 [Page 15]