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]