[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02                                                      
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]