P2PSIP WG Seok-Kap Ko Internet Draft Young-Han Kim Intended status: Standards Track Soongsil University Expires: April 24, 2010 Seung-Hun Oh Byung-Tak Lee ETRI Victor Pascual Avila Tekelec October 24, 2009 IPTV Usage for RELOAD draft-softgear-p2psip-iptv-02.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 April 24, 2010. 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Seokkap, et al. Expires April 24, 2010 [Page 1] Internet-Draft RELOAD IPTV Usage October 2009 Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document defines a P2P IPTV Usage for Resource Location And Discovery (RELOAD). The IPTV Usage provides the functionality of IPTV servers in a fully-distributed system using P2PSIP RELOAD. The IPTV Usage provides the metadata storage, channel peer list storage, and channel peer group storage using the P2PSIP overlay. This documents defines three kinds about these usages. Table of Contents 1. Introduction ................................................ 3 2. Terminology ................................................. 3 3. P2P IPTV Architectures ...................................... 4 3.1. Tracker based architecture ............................. 4 3.2. Server-controlled architecture .......................... 5 3.3. Full distributed architecture .......................... 6 4. Metadata storage ............................................ 7 4.1. Overview ............................................... 7 4.2. Registering MetaKeyword ................................ 8 4.3. Looking up MetaKeyword ................................. 9 4.4. IPTV-META-KEYWORD Kind Definitions ..................... 10 4.5. Registering MetaFullDesc .............................. 11 4.6. Looking up MetaFullDesc ............................... 12 4.7. IPTV-META-FULLDESC Kind Definitions .................... 12 5. Channel peer list storage .................................. 13 5.1. Overview .............................................. 13 5.2. Registering channel peer list ......................... 14 5.3. Looking up channel peer list .......................... 15 5.4. IPTV-CHAN-PEER-LIST Kind Definition .................... 15 6. Active storage & Channel peer group storage ................. 15 6.1. Active Storage & Overview ............................. 15 6.2. Registering channel peer group ......................... 16 6.3. Looking up channel peer group ......................... 17 6.4. IPTV-CHAN-PEER-GROUP Kind Definition ................... 18 7. Security Considerations .................................... 18 8. IANA Considerations ........................................ 18 9. Acknowledgments ............................................ 18 10. References ................................................ 19 10.1. Normative References ................................. 19 10.2. Informative References ............................... 19 Seokkap, et al. Expires April 24, 2010 [Page 2] Internet-Draft RELOAD IPTV Usage October 2009 1. Introduction RELOAD provides distributed storage and distributed service [I- D.ietf-p2psip-base]. RELOAD does not only support SIP based VoIP service[I-D.ietf-p2psip-sip] but also other services. This IPTV Usage of RELOAD allows a node to store or fetch various P2P IPTV related information within the overlay. Nowadays, Streaming service and User Create Contents are getting more popular. The number of streaming channel is growing up very quickly. They require huge storage and high bandwidth. It seems also impossible that central servers cover all streaming and clients. For economic reasons, P2P streaming must be used. There are already some P2P based streaming services. Some standardization groups have been starting to make a standard for P2P streaming. This document provides the method to use the RELOAD overlay as a distributed P2P IPTV server. The RELOAD overlay can store meta data about IPTV channel. And, The RELOAD overlay can store list of the peers which are attending P2P IPTV streaming. Although this document focuses on Live P2P IPTV service, one can use this method for VoD or another streaming service. 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 content provider to viewers. Channel ID : a globally 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. Content Provider : a source entity which produces media for channel to others. Seokkap, et al. Expires April 24, 2010 [Page 3] Internet-Draft RELOAD IPTV Usage October 2009 Viewer : an entity which receives media from other peers. A Viewer may/may not upload media stream to others. Client is an entity which does not upload media stream while it is downloading media. Metadata : All description and information about a certain channel. It includes 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 a User. A software which has user interface and communication protocols. 3. P2P IPTV Architectures 3.1. Tracker based architecture Tracker based P2P IPTV architecture is a simple and basic architecture. The following figure shows this type of architecture. .+--------+ | Server | +--------+ ^ | +----------+ | +------->| Tracker | (peer list) | | +----------+ | | all peer list | | +--------+ v v +-------------> | Peer A | +--------+ | +--------+ | Peer J |<--+ +--------+ +--------+ +-------------> | Peer B | | +--------+ | +--------+ +-------------> | Peer C | +--------+ There is the server which stores channel information. This server gives tracker information of a certain channel to new joining peer. Tracker information includes tracker's IP address. The new joining peer (Peer J in the figure) connects to the tracker and asks a peer list. Tracker stores all peer list. This peer list includes IP address and port number of all peers which attend to the same channel. Seokkap, et al. Expires April 24, 2010 [Page 4] Internet-Draft RELOAD IPTV Usage October 2009 The Content Provider of this channel is also included in this peer list. After the joining peer (Peer J) receives all peer list from the tracker, this peer checks which peer is the best peer in the peer list(Peer A,B,C in the figure). There are some methods to find the best peer among peers. For example, measuring RTT to each candidate peer is a simple method. Using (geographical) location information from IP address or the network coordinate[GNP] is one of useful methods. These methods consider peer's capabilities such as upload bandwidth. After Peer J finds the best peer(Peer A, for example) in the list, Peer J connects Peer A and asks Peer A to send media. After Peer J receives media stream from peer A, Peer J registers itself to the tracker. Peer J is added into the peer list in the tracker. The main feature of this architecture is that a tracker stores only a peer list for the channel. This peer list includes only coarse information about peer such as IP address and port. Instead that a tracker provides all peer list for a new joining peer, a tracker can give initial random peer list. A peer can use gossiping which selects other random peers and communicate with each other to get more peers. 3.2. Server-controlled architecture In contrast to the tracker based architecture, server-controlled P2P IPTV architecture uses a control server. This server stores all information about the channel. This information includes a peer list and virtual link information of the overlay. The following figure shows this architecture. . +----------------+ +------->| Control Server | (overlay topology) | +----------------+ |best candidate peer | +--------+ v +-------------> | Peer A | +--------+ | +--------+ | Peer J | --+ +--------+ +--------+ +-------------> | Peer B | +--------+ A new joining peer (Peer J) connects the control server. Peer J finds the channel from the server and asks the server for the peer list. The control server calculates virtual distances from Peer J to the existing peers in overlay topology and finds the better candidate peers for Peer J in the peer list. The virtual distance is a logical distance reflecting bandwidth and delay between two peers. In Seokkap, et al. Expires April 24, 2010 [Page 5] Internet-Draft RELOAD IPTV Usage October 2009 contrast to the tracker based architecture, the control server does not give all peer list to the joining peer (Peer J). Instead of all peer list, the control server gives small number of peer list which are the better candidates (Peer A,B, in the figure) for the joining peer. Peer J selects the best peer among the candidates(Peer A,B). If Peer J selects Peer A as the best peer, Peer J notifies the control server that Peer J selects to Peer A. The control server makes Peer A send the media to Peer J. The control server knows everything about this channel. i.e. The server knows who sends to who and who receives from who. 3.3. Full distributed architecture Full distributed architecture replaces the control server with DHT(distributed hash table). P2PSIP is one of DHT implementation [I- D.ietf-p2psip-base]. The following figure shows this architecture. . +----------------+ (meta data) +------->| DHT (P2PSIP) | (peer list) | +----------------+ | | +--------+ v +-------------> | Peer A | +--------+ | +--------+ | Peer J | --+ +--------+ +--------+ +-------------> | Peer B | +--------+ DHT stores meta data and peer list of channels in distributed manner. A streaming channel has many meta data which describes this channel. A user can find a certain channel by meta data searching. In the near future, thousands of IPTV steam channels will be expected to be emerging. Not only commercial content provider but also normal users, devices, sensors, and CCTVs will be contributors for lots of IPTV media stream channels. We need a realtime searching mechanism for global channels. This distributed meta data storage is one of realtime channel searching mechanism. Using P2PSIP event notification extension[I-D.ietf-p2psip-event] , we can wait for a specific content channel. DHT stores peer list for each channel. Similar to server controlled architecture, DHT provides the peer list and additional information to the joining peer. The joining peer can use additional information to select the best peer to connect. Seokkap, et al. Expires April 24, 2010 [Page 6] Internet-Draft RELOAD IPTV Usage October 2009 For example scenario, first, Peer J sends keywords into DHT to find a channel. DHT gives channel lists which has the matched metadata with keywords. Peer J selects one channel in the channel list. Peer J sends channel ID to DHT. DHT gives the peer list to Peer J. Peer J selects the best peer in the list. Peer J asks Peer A to send media. After that, Peer J registers its information into DHT as a peer in the channel. In mesh-full architectures or VoD services, DHT may stores chunk information[I-D.chunk-discovery]. DHT helps to find who have a certain chunk data in whole file or stream. However, chunk discovery and registration process may cause overlay overload. To avoid this problem, peers MAY exchange chunk map with each others. 4. Metadata storage 4.1. Overview In Metadata storage, simply speaking, the input to DHT is keyword and output is channel ID. User sends FetchReq message to DHT which includes a hashed keyword and description type(title, actor, or synopsis). The response, FetchAns, includes channel-ID and short description or title for a quick view. Contents Provider registers Metadata for each meaningful keyword to P2PSIP DHT using StoreReq message. The resource name is keyword and description type. The resource-ID is hashed value of the resource name. StoreReq includes channel-ID and short description (for example, title) for this channel. The responsible peer for this resource ID should store these metadata. User, especially Viewer, will search for a channel with keyword. Viewer should send FetchReq to DHT. As a results, Viewer can get a channel ID and short description. The Metadata storage in this draft supports to store a full description into DHT. The resource name of full description is Channel-ID. * Comment: The issue about large P2PSIP message has been discussed in IETF P2PSIP working group. Even if WG decided to use small size message only, this draft asks RELOAD to support as large message as about 1M bytes. Seokkap, et al. Expires April 24, 2010 [Page 7] Internet-Draft RELOAD IPTV Usage October 2009 To get notification of a specific channel registration, User MAY use P2PSIP event notification extension [I-D.ietf-p2psip-event]. This mechanism may be used for dynamic metadata where a meta data register changes metadata frequently[MyEdir]. If a Content Provider want to make own IPTV channel, it should make a Channel ID, and describes this channel. And, it should register this channel information into the DHT. This document does not define the way to make Channel ID. But, Channel ID MUST be globally unique. In ordinary centralized IPTV, a Content Provider registers its channel information to an IPTV server. However, in this draft, a Contents Provider MAY register its channel information to the DHT. To register its channel information, a RELOAD peer stores IptvMetaKeyword structure or IptvMetaFullDesc structure. This draft explains how to store meta data into a P2PSIP RELOAD overlay. 4.2. Registering MetaKeyword All Peers should work together to store metadata. A Content Provider can request to store keywords and Channel-ID into the overlay. This request is StoreReq that includes IptvMetaKeyword structure. Kind-ID for this storage is IPTV-META-KEYWORD. Formal definition of IPTV- META-KETWORD is described in section 4.4 in this draft. As a simple example, if the title of the channel is "Bob's live talk show", the Content Provider MAY make 4 words (Bob,live,talk,show) as title metadata keyword. It hashes each word and stores each title metadata keywords into the overlay. Each metadata will be stored in distributed other peers. The contents of the IptvMetaKeyword are as follows: Seokkap, et al. Expires April 24, 2010 [Page 8] Internet-Draft RELOAD IPTV Usage October 2009 enum { iptv_metatype_title(1), iptv_metatype_synopsys(2), iptv_metatype_genre(3), iptv_metatype_language(4), iptv_metatype_cast(5), iptv_metatype_group(6), iptv_metatype_credit(7), iptv_metatype_review(8), iptv_metatype_crid(9), } IptvMetaType; struct { IptvMetaType type; opaque keyword<0..2^16-1>; opaque short_description<0..2^16-1>; opaque channel_id<0..2^16-1>; } IptvMetaKeyword; The contents of the IptvMetaKeyword PDU are: type the description type of the metadata keyword. a number. keyword partial keyword. short_description short description about the content. This will be shown as a result of the keyword searching. Normally, this is a title of the content. channel_id the unhashed channel id 4.3. Looking up MetaKeyword When a Viewer wants to look up a certain channel with some keywords, the look-up process is going to be done in the following order. Seokkap, et al. Expires April 24, 2010 [Page 9] Internet-Draft RELOAD IPTV Usage October 2009 1. The user inputs keywords per each description type. 2. The Viewer Agent hashes the inputted keywords and looks up IPTV metadata from the overlay. 3. The Viewer Agent lists up the result of looking-up in order. The user can see the list of the channels which have keywords. This list shows short description of each channel. 4. The user can choose one among the channels on the list. A Viewer SHOULD make ResourceID by hashing the user inputted keyword and description type. The Viewer sends FetchReq to the overlay, which includes ResourceID and Kind-ID. Kind-ID in the FetchReq is IPTV- META-KEYWORD. The Viewer can get the result of searching a specific keyword with IptvMetaType. The result includes the short description of the channel and Channel-ID. After the user choose the channel, Viewer agent SHOULD look for Channel peer list. 4.4. IPTV-META-KEYWORD Kind Definitions The distributed IPTV metadata storage for keyword searching is provided using the IPTV-META-KEYWORD Kind-ID: o Kind ID - The Resource name for the IPTV-META-KEYWORD is IptvMetaType and keyword. The format of Resource name is : IptvMetaType "+" Keyword The IptvMetaType in Resource Name is a char string. For example, if the IptvMetaType is iptv_metatype_title and the keyword is "Bob", the resource name is "1+Bob". The data stored is a IptvMetaKeyword, which contains short description and Channel ID. o Data Model - The data model for the IPTV-META-KEYWORD is dictionary. There MAY be many records with the same Resource-ID. The dictionary key is the Channel-ID. A Peer can distinguish stored items with Channel-ID. The data structure for IPTV-META- KEYWORD is IptvMetaKeyword o Access Control - If certificate-based access control is being used, stored data of Kind-ID IPTV-META-KEYWORD must be signed by certificate which contains Channel-ID matching the Channel-ID in IptvMetaKeyword structure. Seokkap, et al. Expires April 24, 2010 [Page 10] Internet-Draft RELOAD IPTV Usage October 2009 4.5. Registering MetaFullDesc When a Content Provider wants to store the full description about his content, the Content Provider MAY use IptvMetaFullDesc structure to store the full description about the channel into the overlay. User also can get full description from the overlay before he watches it. A Content Provider sends StoreReq to the overlay. The Resource Name of this message is Channel-ID. The responsible peer of the hashed channel-ID stores the requested IptvMetaFullDesc data structure. Kind ID of this StoreReq is IPTV-META-FULLDESC. The contents of the IptvMetaFullDesc 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>; opaque short_description<0..2^16-1>; ContentsDescription contents_desc; InstanceDescription instance_desc; } IptvMetaFullDesc; The content of the IptvMetaFullDesc PDU are: Seokkap, et al. Expires April 24, 2010 [Page 11] Internet-Draft RELOAD IPTV Usage October 2009 channel_id the identifier of the channel. Unhashed ID short_description short description about the content. Normally, this is a title of the content. contents_desc Descriptions and other metadata for this channel instance_desc Start,finish time, and other information of this channel The contents descriptions and instance descriptions are inherited from [TVAF]. If a user needs more information, he can use additional URL in InstanceDescription. * Comment : This length of element in IptvMetaFullDesc is not fixed in this version of draft. The total size of RELOAD message SHOULD be smaller than 16K bytes. This limitation will be acceptable for IptvMetaFullDesc. 4.6. Looking up MetaFullDesc When a Viewer knows Channel-ID and he want to get more description about this channel, he SHOULD send FetchReq to the overlay which Kind ID is IPTV-META-FULLDESC. The viewer can receive the full description about the channel in FetchAns from the overlay. The FetchAns SHOULD include IptvMetaFullDesc as a result. 4.7. IPTV-META-FULLDESC Kind Definitions The distributed IPTV metadata storage for the full description is provided using the IPTV-META-FULLDESC Kind-ID: o Kind ID - The Resource name for the IPTV-META-FULLDESC is Channel ID. o Data Model - The data model for the IPTV-META-FULLDESC is dictionary. There MAY be many records with the same Resource-ID. The dictionary key is the Channel-ID. A Peer can distinguish stored items with Channel-ID. The data structure for IPTV-META- FULLDESC is IptvMetaFullDesc Seokkap, et al. Expires April 24, 2010 [Page 12] Internet-Draft RELOAD IPTV Usage October 2009 o Access Control - If certificate-based access control is being used, stored data of Kind-ID IPTV-META-FULLDESC must be signed by certificate which contains Channel-ID matching the Channel-ID in IptvMetaFullDesc structure. 5. Channel peer list storage 5.1. Overview P2PSIP DHT can store peer list for a channel. The responsible peer of a certain channel ID stores all peers who are sending, relaying, or receiving this channel. This is very similar to Tracker based architecture that is described in Section 3.1. The Content Provider registers the Channel-ID and its Peer ID to the overlay. If a peer can provide media to other peer, this peer registers its Peer ID to the overlay. A peer which want to watch the channel receives peer list from the overlay. This list consists of a Contents Provider and all peers of the channel. After the peer gets peer list, peer chooses and connects best peers using a specific protocol such as PPSP[PPSP]. The following figure shows the overview of Channel peer list storage. Peer A Peer B Peer C (1111) Overlay Peers (2222) (3333) | | | | |StoreReq(Ch#9)--> | | | | <-------StoreAns | | | | | | | | | <--FetchReq(Ch#9)| | | | FetchAns(1111)-->| | |<--------------Attach--------------->| | |<==== Media Signaling/Transport ====>| | | | <--StoreReq(Ch#9)| | | | StoreAns-------->| | | | | | | | <--------------------FetchReq(Ch#9)| | | FetchAns(1111,2222)--------------->| | | |<---Attach------>| | | |<== Media S/T ==>| |<-----------------------------------Attach------------>| |<==================Media Signaling/Transport==========>| | | | | | | <--------------------StoreReq(Ch#9)| | | StoreAns ------------------------->| | | | | Seokkap, et al. Expires April 24, 2010 [Page 13] Internet-Draft RELOAD IPTV Usage October 2009 Peer A is a Content Provider. Peer A sends StoreReq to register new channel and its Peer ID. This StoreReq includes Channel ID (Ch#9) and A's Peer ID 1111. The resource name of this is Channel ID. If Peer B wants to watch Ch#9 channel, Peer B sends FetchReq into the overlay. The overlay replies with FetchAns. This FetchAns includes the peer list. The peer list includes Peer ID 1111 now. Peer B sends AttachReq to Peer ID 1111. This message has Peer B's ICE candidates [I-D.ietf-mmusic-ice]. This message will be arrived at Peer A. Peer A replies with AttachAns message that includes Peer A's ICE candidates. After that, Peer A and Peer B will perform ICE check and make a connection. Peer B may ask Peer A to send media using a certain media signaling protocol. This protocol is not P2PSIP protocol. This protocol can be PPSP or SIP. After Peer B can relay this channel, Peer B sends StoreReq to register Peer B's Peer ID into the peer list for Ch#9 Channel. Peer C also does the same process to Peer B. The response, FetchAns, has two peer IDs that are 1111 and 2222. Peer C attaches Peer B and Peer A. Peer C may choose the best peer between Peer A and Peer B using a certain media signaling protocol. Peer C can get more information about peers by communicating with other peers. After Peer C is ready to relay the media to another peer, Peer C register its Peer ID 3333 into the peer list for this Ch#9 channel by sending StoreReq. 5.2. Registering channel peer list To register a channel peer ID, StoreReq message SHOULD include IptvChanPeerList structure. Normally, StoreReq include only one Peer ID in IptvChanPeerList structure. But, it is possible to use more than one Peer ID in IptvChanPeerList in StoreReq. The Kind ID of this storing data is IPTV-CHAN-PEER-LIST. The contents of IptvChanPeer structure are defined as follows: struct { Destination peer_id opaque location_info<0..2^16-1>; } IptvPeerInfo; struct { uint32 peer_list_length; IptvPeerInfo peer_list[peer_list_length]; } IptvChanPeer; The contents of the IptvChanPeer PDU are: Seokkap, et al. Expires April 24, 2010 [Page 14] Internet-Draft RELOAD IPTV Usage October 2009 peer_id - the identifier of peers of this channel. location_info - this peer's virtual position. peer can get this position from network coordinate system[GNP], ISP(AS) number, or IP address based mapping. ISP number can be worked with ALTO service[RFC5693]. Peer MAY user this location information to select the best peer. * Comment : The format of location_info is not fixed yet. peer_list_length - the number of the peers in the list. peer_list - the list of IptvPeerInfo. 5.3. Looking up channel peer list To get channel peer list of a channel, FetchAns message SHOULD include IptvChanPeerList structure. The responsible peer replies with all peer list. 5.4. IPTV-CHAN-PEER-LIST Kind Definition The distributed IPTV channel peer list storage is provided using the IPTV-CHAN-PEER-LIST Kind-ID: o Kind ID - The Resource name for the IPTV-CHAN-PEER-LIST is Channel ID. o Data Model - The data model for the IPTV-CHAN-PEER-LIST is dictionary. The dictionary key is the Peer-ID. o Access Control - If certificate-based access control is being used, stored data of Kind-ID IPTV-CHAN-PEER-LIST must be signed by certificate which contains Peer-ID matching the Peer-ID in IptvChanPeerList structure. 6. Active storage & Channel peer group storage 6.1. Active Storage & Overview The existing P2PSIP RELOAD supports passive storage only. The responsible peer SHOULD store a requested data without any change. The response also SHOULD be the same to what was stored. The responsible peer SHOULD NOT re-arrange, modify, or select the stored Seokkap, et al. Expires April 24, 2010 [Page 15] Internet-Draft RELOAD IPTV Usage October 2009 data. The responsible peer works passively. For redundancy, the stored data in the redundancy responsible peer (the successor of the responsible peer) SHOULD be synchronized to it in the main responsible peer. The responsible peer uses the same StoreReq that it received from the requesting peer. That's why P2PSIP RELOAD is passive storage. To make the responsible peer more active, this document suggests an active storage. In the active storage, the responsible peer has some active logic. It can re-arrange, modify, or select the stored data. It can store the requested data into another peer. The channel peer list storage which is explained in Section 5 is not scalable. It is possible that there is lots of peer in a channel. Under the flash crowd, the number of peer can be more than a million. It is impossible for one peer to store all peer list. Moreover, RELOAD message cannot carry this huge data. If the responsible peer of the channel has active logic, it can store the data in another distributed manner. The responsible peer form peer groups and stores grouped peer list into another peers. This grouping logic SHOULD be the same to the redundancy responsible peer's. This responsible peer keeps information about groups, which information MAY includes group ID and the number of peer in a group. This document provides virtual network coordinate based grouping strategy. Every peer can get its virtual position using a network coordination system or an IP address mapping. Grouping is performed using peer's location, the number of peer in group, and the number of group. This grouping can be performed hierarchically. We can call a intermediate responsible peer a group manager. A group manager can reassign groups with StoreReq(IPTV-CHAN-PEER-GROUP). * Comment : The exact grouping strategy is to be defined. 6.2. Registering channel peer group After the responsible peer of the Channel ID receives a StoreReq with IPTV-CHAN-PEER-LIST, it assigns this requesting peer to a group. The responsible peer sends a StoreReq with IPTV-CHAN-PEER-GROUP to the overlay. The Resource name of this message is Channel ID, group level, and group ID. This message uses IptvChanPeerGroup structure. The contents of a IptvChanPeerGroup are as follows: Seokkap, et al. Expires April 24, 2010 [Page 16] Internet-Draft RELOAD IPTV Usage October 2009 struct { uint32 level; uint32 group_id; uint32 peer_list_length; IptvPeerInfo peer_list[peer_list_length]; } IptvChanPeerGroup; level - grouping level. This document supports hierarchical grouping. The first level is 1. group_id - group id in this level. peer info is stored in this group. peer_list_length - the number of the peers in the list. peer_list - the list of IptvPeerInfo. The following figure shows an example of Channel peer group storage. Peer D Peer X Peer Y (4444) | | | | | | StoreReq(Ch#9,4444) --> | | | +--------------+ | | | assign group | | | +--------------+ | | | StoreReq(Ch#9,L1,G3,4444)-> | | | | Peer D is new peer. Peer X is the responsible peer of this channel. After Peer X receives Peer D's StoreReq, Peer X decides to assign Peer D to group#3 on group level 1. And, Peer X sends StoreReq with IPTV-CHAN-PEER-GROUP to Peer Y. Peer Y is the responsible peer of Channel-ID plus level plus group ID. Peer Y stores the peer information into this group. 6.3. Looking up channel peer group The responsible peer of the Channel ID receives FetchReq with IPTV- CHAN-PEER-LIST. The response, FetchAns, uses IptvChanPeerGroup. This response SHOULD include all peer information list or a part of all peer information in the group. The responsible peer of Channel ID MAY give the requesting peer initial peer list instead of whole peer list in the group. Seokkap, et al. Expires April 24, 2010 [Page 17] Internet-Draft RELOAD IPTV Usage October 2009 6.4. IPTV-CHAN-PEER-GROUP Kind Definition The distributed IPTV channel peer group storage is provided using the IPTV-CHAN-PEER-GROUP Kind-ID: o Kind ID - The format of Resource name for the IPTV-CHAN-PEER-GROUP is : Channel ID '+' grouping level '+' group ID o Data Model - The data model for the IPTV-CHAN-PEER-GROUP is dictionary. The dictionary key is the Peer-ID. o Access Control - If certificate-based access control is being used, stored data of Kind-ID IPTV-CHAN-PEER-GROUP must be signed by certificate which contains Peer-ID matching the Peer-ID in IptvChanPeerGroup structure. 7. Security Considerations TODO - fill in 8. IANA Considerations IANA SHALL add IPTV-META-KEYWORD, IPTV-META-FULLDESC, IPTV-CHAN-PEER- LIST, and IPTV-CHAN-PEER-GROUP into "RELOAD Data Kind-ID" Registry. The additional contents of the registry are: +---------------------+------------+----------+ | Kind | Kind-ID | RFC | +---------------------+------------+----------+ | IPTV-META-KEYWORD | 16 | RFC-AAAA | | IPTV-META-FULLDESC | 17 | RFC-AAAA | | IPTV-CHAN-PEER-LIST | 18 | RFC-AAAA | | IPTV-CHAN-PEER-GROUP| 19 | RFC-AAAA | +---------------------+------------+----------+ 9. Acknowledgments TODO - fill in Seokkap, et al. Expires April 24, 2010 [Page 18] Internet-Draft RELOAD IPTV Usage October 2009 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- 02 (work in progress), March 2009. [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-01 (work in progress), March 2009. [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. [I-D.chunk-discovery] N. Zong, "Chunk Discovery for P2P Streaming", draft-zong-ppsp-chunk-discovery-00, June 2009. 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 (expired), July 2008. [I-D.ietf-p2psip-event] Jun W., Zhifeng C., Yu M., Jiong S., "P2PSIP Event Notification Extension", draft-wang-p2psip-event- notification-extension-01, July 2009. [TVAF] SP003v13, "Metadata", 2002, TV-Anytime Forum, http://www.tv- anytime.org/ [RFC5693] J. Seedorf, E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", October 2009. [PPSP] Zhang, Y., Zong, N., Camarillo, G., Seng, J., and R. Yang, "Problem Statement of P2P Streaming Protocol (PPSP)", IETF PPSP BoF, May 2009. [GNP] T.S.E. Ng, H. Zhang, "Predicting Internet network distance with Coordinates-Based Approaches", In Proceedings of IEEE Infocom, page 170-179, 2002. Seokkap, et al. Expires April 24, 2010 [Page 19] Internet-Draft RELOAD IPTV Usage October 2009 [MyEdir] N. Papaoulakis, N. Doulamis, C. Patrikakis, E. Protonotarios, J. Soldatos, "Real-Time Context-Aware and Personalized Media Streaming Environments for Large Scale Broadcasting Applications : My-e-Director 2012", ISCE 2008, 2008. Author's Addresses Seok-Kap Ko ETRI 1000-6 Oryong-dong, Buk-gu, Gwangju, 500-480, Korea Phone: +82-62-970-6677 Email: softgear@etri.re.kr Young-Han Kim Soongsil University Sangdo-dong, Dongjak-Gu, Seoul Korea Phone: +82-2-814-0151 Email: younghak@ssu.ac.kr Seung-Hun Oh ETRI 1000-6 Oryong-dong, Buk-gu, Gwangju, 500-480, Korea Phone: +82-62-970-6672 Email: osh93@etri.re.kr Byung-Tak Lee ETRI 1000-6 Oryong-dong, Buk-gu, Gwangju, 500-480, Korea Phone: +82-62-970-6624 Email: bytelee@etri.re.kr Victor Pascual Avila Tekelec Am Borsigturm 11, Berlin Germany Email: victor@iptel.org Seokkap, et al. Expires April 24, 2010 [Page 20]