Introduction of MTN
draft-wu-ppsp-mtn-introduction-00

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 January 7, 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). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Abstract

This draft briefly introduces MTN, the Median Telecom Network built by China Telecom to support streaming and file download services with peer to peer technologies.

Table of Contents

1.  Introduction
2.  Terminology
    2.1.  MTN
    2.2.  Center node
    2.3.  Area node
    2.4.  Static node
    2.5.  User node
3.  MTN architecture
4.  Key components
    4.1.  Content storage and delivery system
    4.2.  Resource management and dispatch system
    4.3.  Content management system
5.  Deployment
6.  Performance evaluations
7.  Security considerations
8.  References
    8.1.  Normative References
    8.2.  Informative References
§  Authors' Addresses

1.  Introduction

MTN, the abbreviation of media telecom network, is a service network built by China Telecom to provide media services in peer to peer form. As far as we know, PPLive has constructed a platform for its linear TV and then another different one for VOD because of the lack of scalability of the first platform, which weighs both CAPEXP and OEXP. On the contrary, MTN provides linear streaming, VOD, and file download on the same platform. Our aim is to support multiple media services over one single platform with carrier's grade manageability and operability. What's more, MTN is designed for both IPv4 and IPv6 to be compatible with the evolution of NGN. The concept of MTN was proposed in 2004 and we constructed a trial platform in 2008. Now MTN is working as a commercial platform to support P2P services.

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 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

2.1.  MTN

MTN is a distributed, manageable and operable platform which can effectively support a wide range of media services such as linear TV, VOD, file download and so on.

2.2.  Center node

Center node is the higher index server containing the content routing information of the whole MTN, which responds to inquiries from area nodes.

2.3.  Area node

Area node is the lower index server with the knowledge of the content routing information of its own responsible region, which receives requests from user nodes of its area, replies to user nodes or forwards the requests to center node, and supplies center node with its area routing information for aggregation.

2.4.  Static node

Static node refers to a special server deployed by carriers to offer better performance experiences, which acts as either a supplement content seed or a relay, or both.

2.5.  User node

User node refers to electronic terminal used to consume the services by users, e.g. PCs, mobile terminals, etc.

3.  MTN architecture

MTN uses the distributed-transport and central-control design along with integrated services supporting platform and carrier's existing BSS/OSS to achieve the goal of manageability and operability. To make it clear, we divided the architecture into several sub-layers as follows:

+-----------------------------------------------------------------+
|   Operation  Supporting Sub-Layer                               |
| +-----------------------------------------------------------+   |
| |   +--------+ +--------+ +----------+ +-------------+      |   |
| |   |Users & | |Billings| |Statistics| |Terminals &  |      |   |
| |   |CPs mgmt| |        | |          | |Networks mgmt|      |   |
| |   +--------+ +--------+ +----------+ +-------------+      |   |
| +-----------------------------------------------------------+   |
|  Service Applying Sub-Layer                                     |
| +-------------------------------------------------------------+ |
| | +---------+ +---+ +--------------+ +----------------------+ | |
| | |Linear TV| |VOD| |File Downloads| |Extending Applications| | |
| | +---------+ +---+ +--------------+ +----------------------+ | |
| | +--------------------------------+ +----------------------+ | |
| | |Digital Right Management System | |                      | | |
| | +--------------------------------+ |Extending Applications| | |
| | +--------------------------------+ |Supportive Systems    | | |
| | | Content Management System      | |                      | | |
| | +--------------------------------+ +----------------------+ | |
| | +---------------------------------------------------------+ | |
| | |       Information Publication System                    | | |
| | +---------------------------------------------------------+ | |
| +-------------------------------------------------------------+ |
|  Service Controlling Sub-Layer                                  |
| +-------------------------------------------------------------+ |
| |       Resource Management and Dispatch System               | |
| |           ( Center Node & Area Nodes )                      | |
| +-------------------------------------------------------------+ |
|  Content Switching Sub-Layer                                    |
| +-------------------------------------------------------------+ |
| |       Content Storage and Delivery System                   | |
| | +--------------+  +--------------+   +--------------------+ | |
| | |  User Nodes  |  | Static Nodes |   | Content Repository | | |
| | +--------------+  +--------------+   +--------------------+ | |
| +-------------------------------------------------------------+ |
|  Network Carrying Sub-Layer                                     |
|  +------------------------------------------------------------+ |
|  | +-------------------------------------------------------+  | |
|  | |          ChinaNet Internet    or    CN2 Network       |  | |
|  | +-------------------------------------------------------+  | |
|  |    +-----------+      +-----------+     +------------+     | |
|  |    | DSL Access|      | LAN Access|     | WLAN Access|     | |
|  |    +-----------+      +-----------+     +------------+     | |
|  +------------------------------------------------------------+ |
+-----------------------------------------------------------------+

The bottom in the hierarchy is the carrier's network infrastructures, which consist of various access networks and the backbone networks. As for China Telecom, it now has two distinct backbone networks: ChinaNet and China Telecom Next Generation Carrying Network (CN2), and users can access them in different ways.

The second is content switching sub-layer, which has content storage and delivery system composed of user nodes, static nodes and content repository. The major streaming data flows are occurring among these three types of entities.

The third is service controlling sub-layer, which has the instances of center nodes and area nodes. Its main function is to collect and aggregate content routing information and respond the indexing queries.

The forth is service applying sub-layer, which contains the application-specific function components, e.g. digital right management, content management system, etc.

Atop is the conventional operation supporting sub-layer, which usually has User and CP management, billings, statistics, terminal and P2P network management, and so on.

4.  Key components

The draft doesn't intend to cover all aspects of MTN, instead it focuses on several essential components, which we think SHOULD include the content storage and delivery system, resource management and dispatch system, and content management system.

4.1.  Content storage and delivery system

For the purpose of P2P share, the content storage needs special treatment, so we elaborate on the mechanism used in our design.

The contents are stored in the unit of segment, whose size is 2M bytes. If the length of content is not multiple of 2M bytes, the last segment can be less than 2M bytes with an ending symbol appended. The storage disks of user nodes, static nodes and content repository are divided into areas of 512M bytes size and the areas are numbered.

After getting the peer list from area node or center node, user node begins the process of content request and delivery. A user node could build connections with at most 20 peers, and SHOULD NOT ask for content from more than 10 peers. A peer could simultaneously upload content to no more than 4 user nodes.

Before content delivery starts, the receiver assigns a space of size 256K byte in memory. The content is delivered in the unit of 64K byte, and is first placed in the designated memory space. It will be rewrite to the corresponding segment of 2M bytes in disk once the 256K memory is full. As soon as a new segment has been downloaded, the receiver will update its indexing information in its area node and center node.

4.2.  Resource management and dispatch system

Resource management and dispatch system consists of one center node and various number of area nodes, which in turn compose of a two-layer hierarchy with the center node in the higher. In MTN, each area node manages a certain number of user nodes and static nodes, which are usually geographically proximate and MAY change dynamically. With the constant join, leave, failure of user nodes, an area MAY be split into two when there are too many nodes or two sparse areas could be merged into one, all partition and merger operations are under the control of center node. MTN has adopted a sophisticated method to implement such an adaptive management.

The routing computing is simple: user node sends requests to the corresponding area node, which will first looks up in its own indexing database. If there are enough seeds, the area node returns a list of peers based on the principle of traffic localization; else if the area node cannot find REQUIRED number of peers, it forwards the query to center node, which will pick another area node based on both load balance and traffic optimization to handle the requests. Center node will reply to the origin user node directly after all the computing.

The indexing information in MTN is stored using link data structure, with the tiny change that the first entity of link uses a different format which is specified as follows:

+------------+------------+---------+----------+-------------+
|content ID  | shared tag | DRM Tag | Reserved | upload count|
+----------------------------+-------------------------------+
|     segment count          |    content length             |
+----------------------------+-------------------------------+
|     created date           |    modified date              |
+----------------------------+-------------------------------+
|     first segment ID       |    first segment pointer      |
+----------------------------+-------------------------------+

content ID: the 40-bits field is the unique identifier of content in MTN.

shared tag: the 1-bit field specifies whether the content can be shared, the value of '0'forbids sharing while '1'permits.

DRM tag: the 2-bits field specifies whether the content has been encrypted, the value of '00'means no encryption, '01'denotes it has been encrypted by carriers, '10'encrypted by content providers, '11'is reserved.

Reserved: the 5-bits field is preserved for future use.

Upload count£ºthe 16-bits field specifies the number of segments that have been uploaded.

Segment count: the 32-bits field specifies the number of segments the node has.

Content length: the 32-bits field specifies the size of content in the unit of byte.

Created date: the 32-bits field specifies the time when the indexing information is created.

Modified date: the 32-bits field specifies the latest update time of indexing information.

First segment ID: the 32-bits field specifies the smallest ID of segments of the content it has.

First segment index: the 32-bits field specifies the pointer to the exact storage information of the first segment, which has the following format:

+-----------+---------------+---------------+--------------+
|segment ID | area sequence | data position | next pointer |
+-----------+---------------+---------------+--------------+

Segment ID: the 32-bits field specifies the identifier of the segment.

Area sequence: the 16-bits field specifies which area of storage the segment resides in.

Data pointer: the 32-bits field specifies the exact position of the segment in the area.

Next index: the 32-bits field points to a same format index for the next greater segment on the storage.

4.3.  Content management system

Content management system is responsible for the upload, edition, deletion, storage and other related operation of contents.When a specific content is uploaded, an ID of 40 bits length which is unique in the scope of MTN will be assigned. The following metadata SHOULD also be provided along with the content:

Content type, e.g. audio, video, game, etc.

File type, e.g. .exe, word, etc

Content status, which indicates whether the content is available.

Service type, e.g. download, online play, etc.

5.  Deployment

The deployment of MTN adopted a three-layer hierarchy corresponding to the administration regionalism of China: country, province and individual. The center node and the center content repository are placed at the country level, while area nodes and provincial content repositories are installed at the province level. A note is that one province usually has only one content vault but various number of area nodes according to the number of its subscribers. The lowest level contains user nodes and static nodes. The deployment of static nodes by carriers is to provide faster and more stable seeds for users and they could also function as relays as needed.

6.  Performance evaluations

We evaluate the performance of MTN in two ways: large-scale simulation based on PDNS and the field trial and test. Both results indicate MTN could provide traffic localization and service of quality as well as or better than PPLive, PPStream and BitTorren.

7.  Security considerations

In MTN, the following security issues have been addressed:

authentication and authorization: on one hand, the terminal users MUST first register with the carrier and provide usernames and passwords to enter the MTN through a client software provided by the carrier. Once given the admission, users could consumer the services authorized to them. On the other hand, the content provider MUST also be authenticated and authorized to upload contents.

Content securities: all contents in MTN MUST be creditable and legal and their copyrights can be protected. MTN has its own DRM mechanism and external DRMs could also be applied through specific interfaces, contents MAY be encrypted by content providers or carrier. Once contents have been uploaded by content providers, they will be artificially censored before being published. The contents downloaded by users can be verified against correctness and integrity.

Communication securities: the route queries and responses could be encrypted as needed.

8.  References

8.1. Normative References

8.2. Informative References

Authors' Addresses