One document matched: draft-wu-ppsp-mtn-introduction-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3261 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY RFC0792 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0792.xml">
<!ENTITY RFC4330 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4330.xml">
<!ENTITY RFC4981 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4981.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY I-D.ietf-p2psip-sip SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-p2psip-sip.xml">
<!ENTITY I-D.ietf-p2psip-base SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-p2psip-base.xml">
<!ENTITY I-D.song-p2psip-security-eval SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.song-p2psip-security-eval.xml">
<!ENTITY I-D.bryan-p2psip-app-scenarios SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bryan-p2psip-app-scenarios.xml">
<!ENTITY I-D.bryan-p2psip-requirements SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bryan-p2psip-requirements.xml">
<!ENTITY I-D.zheng-p2psip-diagnose SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.zheng-p2psip-diagnose.xml">
<!ENTITY I-D.matuszewski-p2psip-security-requirements SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.matuszewski-p2psip-security-requirements.xml">
<!ENTITY I-D.baset-p2psip-p2pp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.baset-p2psip-p2pp.xml">
<!ENTITY I-D.ietf-mmusic-ice SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mmusic-ice.xml">
<!ENTITY I-D.ietf-behave-rfc3489bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-behave-rfc3489bis.xml">
<!ENTITY I-D.ietf-p2psip-concepts SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-p2psip-concepts.xml">
]>
<rfc category="info" docName="draft-wu-ppsp-mtn-introduction-00"
ipr="trust200902" submissionType="IETF" updates="" xml:lang="">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="no"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<front>
<title abbrev="Introduction of MTN">Introduction of MTN</title>
<author fullname="Wu Juan" initials="J." surname="Wu">
<organization>China Telecom</organization>
<address>
<postal>
<street>109 West Zhongshan Ave, Tianhe District</street>
<city>Guangzhou</city>
<region>Guangdong Province</region>
<code>510630</code>
<country>P.R.China</country>
</postal>
<phone>+86-20-38639132</phone>
<facsimile>+86-20-38639457</facsimile>
<email>wuj@gsta.com</email>
</address>
</author>
<author fullname="Long Bin" initials="B." surname="Long">
<organization>China Telecom</organization>
<address>
<postal>
<street>109 West Zhongshan Ave, Tianhe District</street>
<city>Guangzhou</city>
<region>Guangdong Province</region>
<code>510630</code>
<country>P.R.China</country>
</postal>
<phone>+86-20-38639453</phone>
<facsimile>+86-20-38639457</facsimile>
<email>longbin@gsta.com</email>
</address>
</author>
<author fullname="Pang Tao" initials="T." surname="Pang">
<organization>China Telecom</organization>
<address>
<postal>
<street>109 West Zhongshan Ave, Tianhe District</street>
<city>Guangzhou</city>
<region>Guangdong Province</region>
<code>510630</code>
<country>P.R.China</country>
</postal>
<phone>+86-20-38639769</phone>
<facsimile>+86-20-38639457</facsimile>
<email>pangt@gsta.com</email>
</address>
</author>
<author fullname="Huang Hai" initials="H." surname="Huang">
<organization>China Telecom</organization>
<address>
<postal>
<street>109 West Zhongshan Ave, Tianhe District</street>
<city>Guangzhou</city>
<region>Guangdong Province</region>
<code>510630</code>
<country>P.R.China</country>
</postal>
<phone>+86-20-38639582</phone>
<facsimile>+86-20-38639457</facsimile>
<email>Huanghai@gsta.com</email>
</address>
</author>
<date day="6" month="July" year="2009" />
<area>Real-time Applications and Infrastructure</area>
<workgroup>PPSP</workgroup>
<keyword>MTN</keyword>
<keyword>P2P</keyword>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>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.</t>
</section>
<section title="Terminology" toc="default">
<t>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 <xref
target="RFC2119"></xref>.</t>
<section title="MTN">
<t>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.</t>
</section>
<section title="Center node">
<t>Center node is the higher index server containing the content routing information of the whole MTN, which responds to inquiries from area nodes.</t>
</section>
<section title="Area node">
<t>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.</t>
</section>
<section title="Static node">
<t>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.</t>
</section>
<section title="User node">
<t>User node refers to electronic terminal used to consume the services by users, e.g. PCs, mobile terminals, etc.</t>
</section>
</section>
<section title="MTN architecture">
<t>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:
<figure
align="left">
<artwork>
+-----------------------------------------------------------------+
| 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| | |
| | +-----------+ +-----------+ +------------+ | |
| +------------------------------------------------------------+ |
+-----------------------------------------------------------------+
</artwork>
</figure></t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>The forth is service applying sub-layer, which contains the application-specific function components, e.g. digital right management, content management system, etc.</t>
<t>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.</t>
</section>
<section title="Key components" toc="default">
<t>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.</t>
<section title="Content storage and delivery system">
<t>For the purpose of P2P share, the content storage needs special treatment, so we elaborate on the mechanism used in our design.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Resource management and dispatch system">
<t>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.</t>
<t>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.</t>
<t>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:<figure align="left"><artwork>
+------------+------------+---------+----------+-------------+
|content ID | shared tag | DRM Tag | Reserved | upload count|
+----------------------------+-------------------------------+
| segment count | content length |
+----------------------------+-------------------------------+
| created date | modified date |
+----------------------------+-------------------------------+
| first segment ID | first segment pointer |
+----------------------------+-------------------------------+
</artwork></figure></t>
<t><list>
<t>content ID: the 40-bits field is the unique identifier of content in MTN.</t>
<t>shared tag: the 1-bit field specifies whether the content can be shared, the value of '0'forbids sharing while '1'permits.</t>
<t>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.</t>
<t>Reserved: the 5-bits field is preserved for future use.</t>
<t>Upload count£ºthe 16-bits field specifies the number of segments that have been uploaded.</t>
<t>Segment count: the 32-bits field specifies the number of segments the node has.</t>
<t>Content length: the 32-bits field specifies the size of content in the unit of byte.</t>
<t>Created date: the 32-bits field specifies the time when the indexing information is created.</t>
<t>Modified date: the 32-bits field specifies the latest update time of indexing information.</t>
<t>First segment ID: the 32-bits field specifies the smallest ID of segments of the content it has.</t>
<t>First segment index: the 32-bits field specifies the pointer to the exact storage information of the first segment, which has the following format:<figure align="left"><artwork>
+-----------+---------------+---------------+--------------+
|segment ID | area sequence | data position | next pointer |
+-----------+---------------+---------------+--------------+
</artwork></figure></t>
</list></t>
<t><list>
<t>Segment ID: the 32-bits field specifies the identifier of the segment.</t>
<t>Area sequence: the 16-bits field specifies which area of storage the segment resides in.</t>
<t>Data pointer: the 32-bits field specifies the exact position of the segment in the area.</t>
<t>Next index: the 32-bits field points to a same format index for the next greater segment on the storage.</t>
</list></t>
</section>
<section title="Content management system">
<t>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:<list
hangIndent ="3" style="empty">
<t>Content type, e.g. audio, video, game, etc.</t>
<t>File type, e.g. .exe, word, etc</t>
<t>Content status, which indicates whether the content is available.</t>
<t>Service type, e.g. download, online play, etc.</t>
If the content is a music or movie, supplement information SHOULD also be recorded such as authors, issuers and so on.</list></t>
</section>
</section>
<section title="Deployment">
<t>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.</t>
</section>
<section title="Performance evaluations">
<t>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.</t>
</section>
<section title="Security considerations">
<t>In MTN, the following security issues have been addressed:<list>
<t>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.</t>
<t>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.</t>
<t>Communication securities: the route queries and responses could be encrypted as needed.</t>
</list></t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
</references>
<references title="Informative References ">
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:42:45 |