IETF cdni ZP.Zhou
Internet-Draft Huawei Technologies, Inc.
Intended status: Informational Aug 17, 2011
Expires: February 18, 2012
CDNI use case
draft-zhou-cdni-use-case-01
Abstract
Industry needs the CDN interconnection to provide the CDN service
that may cover a wider geographical area and a better service
quality. In the real pragmatic operation, the relationship between
two CDNs should concern many factors(for instance, CDN or CP may
select the downstream CDN based on some principals or conditions or
service authorizations), hence the CDN interconnection is defacto a
sort of constrained interconnection. This document will give the use
cases to indicate the models of how the CDN interconnection may be
used and the associated examples for the use cases will be listed
subsequently.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on February 18, 2012.
Copyright Notice
Copyright (c) 2011 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
ZP.Zhou Expires February 18, 2012 [Page 1]
Internet-Draft CDNI use case Aug 2011
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Architecture for CDN-I Service . . . . . . . . . . . . . . . . 3
4. Operating Requirements on CDN Interconnection . . . . . . . . 3
5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. CDN authorization . . . . . . . . . . . . . . . . . . . . 5
5.2. Constraint for Content . . . . . . . . . . . . . . . . . . 6
5.3. Content Adaptation . . . . . . . . . . . . . . . . . . . . 6
5.4. Content Priority . . . . . . . . . . . . . . . . . . . . . 7
6. Application Example . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
10. Normative References . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
ZP.Zhou Expires February 18, 2012 [Page 2]
Internet-Draft CDNI use case Aug 2011
1. Introduction
[I- D.bertrand-cdni-use-cases] has provided some basic use cases for
CDN Interconnection. While it has not talked about how CDN-A may
interconnect CDN-B as its downstream CDN(e.g. How the downstream CDN
is selected; what operation rule(business rule) should be taken into
account on service of CDN interconnection).
This draft gives some use cases concerning the operation of multiple
CDN federation and as a result some examples are provides.
2. Terminology
Roughly, this document may refer the terminology defined in section
1.1 of [I-D.jenkins-cdni-problem-statement] and [I-D.bertrand-cdni-
use-cases].
3. Architecture for CDN-I Service
Following, a general service architecture of CDN interconnection is
listed as Figure 1:
+-------+ +-------+ +-------+ +-------+
| CSP |-------| CDN-A |------| CDN-B |------| UE |
+-------+ | +-------+ +-------+ +-------+
| \______________/ |
| / \ |
| +-------+ +-------+ |
|___| CDN-C |______| CDN-D |__________|
+-------+ +-------+
Figure 1. Typical Architecture for CDN interconnection
This is just a typical architecture of CDN interconnection. The CSP
may connect multiple CDNs and a upstream CDN may connect multiple
downstream CDNs(such as CDN-A may connect either CDN-B or CDN-D;
similarly to CDN-C)
This figure is used for the following discussion of use cases while
in reality it may be possible that the CSP only select one delegate
CDN or a upstream CDN may only have one downstream CDN.
4. Operating Requirements on CDN Interconnection
In the real operation, some basic requirements of CDN-I service based
ZP.Zhou Expires February 18, 2012 [Page 3]
Internet-Draft CDNI use case Aug 2011
on service operating should be abided, including:
Authorization area for CDN provider: the CDN provider may only
provide CDN service in a specific area, such as CDN-A may only serve
in Beijing and CDN-B may only serve in Shanghai. Such authorization
may be determined by CSP or by upstream CDN for the downstream CDN.
And such authorization is because of the business model(for example
to protect the business of authorized CDN service provider).
Therefore the associated policy should be supported in the CDN
interconnection.
Constraint of service by content: the access area or access period of
specific content may be constrained in content service. For example
the movie in a Chinese video website may only be accessed by the
terminals located in China mainland and if being overseas the request
for the movie service will be rejected. The rule in this use case
comes from the content rights operation and should be conducted by
the CDN service provider.
Content adaptation: the format of content service may be converted
according to the terminal's capability or consumer's application.
For example, convert multicast (or unicast) RTP streams to HTTP
streaming and then deliver the adaptive stream to terminals( refer to
MCD CDN-I use case and requirement). As for implementation of CDN
service, it is optimum maintaining and delivering one format of
content within CDN system(including CDN to CDN) while providing the
adaptive streaming service on the interface between CDN and
terminals. The content adaptation may be deployed on a node of the
CDN or CDN-I system as a functionality.
Content priority: towards the content service, one way to provide the
differ-service of content delivery is to set priority for the
content. Such priority mechanism may be supported and extended
between CDNs. The downstream CDN may inherit the content priority
from CSP or upstream CDN or the priority may even be updated at the
downstream CDN depending on the service.
Totally the requirements above are usual rules of content service
operating and are also applicable for CDN-I use cases.
5. Use Cases
In this section, three Use Cases to realize the requirements are
described along with examples.
ZP.Zhou Expires February 18, 2012 [Page 4]
Internet-Draft CDNI use case Aug 2011
5.1. CDN authorization
In this use case, the CP may make a list of pairs of CDN and its
authorized service area. For example:
_____________________________
| CDN Provider | Service Area |
|______________|______________|
| CDN-A | Beijing |
|______________|______________|
| CDN-B | Shanghai |
|______________|______________|
| CDN-C | Guangdong |
|______________|______________|
| .... | .... |
|______________|______________|
| CDN-Z | Tianjing |
|______________|______________|
| CDN-HK | Hongkong |
|______________|______________|
Figure 2: Example List of CDN Authorization Areas
The list of CDN authorization areas may be created by the CP and be
kept by all CDNs. When delivering content, CDN may refer to this
list to determine with which CDN it has to connect. Here gives two
sub-cases:
Sub-Case one: for the unicast service, when the CP receives a content
request from a UE located in Beijing, CP will redirect that request
to CDN-A. CDN-A then will check whether the requested content is
available locally. If yes, then provide the content to the
requesting UE, else if the content at that time is only stored in
Tianjing and Guangdong, CDN-A will contact CDN-Z or CDN-C getting
that content and at last issue that content to the UE.
Sub-Case two: for the broadcast service, the content broadcast route
may be designed based on the geographical relationship of each area.
For example Tianjing is very near to Beijing. If the CP is also
located in Beijing, for the content broadcast, the content may be
delivered from CP to CDN-A first and CDN-A will then forward the
content to CDN-Z. In the same way, the content to CDN-HK may be
forwarded from CDN-C since Hongkong is near to Guangdong. To design
such transport route should consider the transport efficiency,
neither overlap nor neglect an area.
Further, if concern there are possibly multiple CDNs in an area, for
example CDN-Ax and CDN-Ay both serve in Beijing, there should be an
entity coordinating these two CDNs(CDN-Ax and CDN-Ay) and contacting
ZP.Zhou Expires February 18, 2012 [Page 5]
Internet-Draft CDNI use case Aug 2011
other CDNs outside of Beijing. Or probably each CDN in the same area
is responsible for different services, e.g. CDN-Ax serves for Mobile
request and CDN-Bx serves for request of IPTV service.
The arrangement above may be seen as a typical deployment policy( may
be beneficial for both efficiency and business cooperation). The
core issue is to keep all CDNs complying with the same policy.
5.2. Constraint for Content
The arrangement of content publishing/content service is another
typical policy controlled by CP. For example, the rights of
OlympicGame in 2008 for live broadcast in China Mainland was
purchased by CCTV and all related content may only be accessed in
China Mainland. Hereby a terminal from outside Mainland of China
such as Hongkong is prohibited to access the live Olympic broadcast
or video on demand issued from CCTV during Olympic period(Hongkong
users may access Olympic content from another content provider
locally in Hongkong). Hence for all the CDNs within China during
Olympic period, the content forward should abide this constriction.
If broadcast both Movie-A and OlympicGame B, CDN-C should deliver
content of Movie-A to CDN-HK but should not deliver content of
OlympicGame B to CDN-HK.
________________________________________________
| Content Name | Service Area | Service Period |
|______________|______________|__________________|
| Movie-A | China | 2009.01--2009.12 |
|______________|______________|__________________|
|OlympicGame B |China Mainland| 2008.08--2008.10 |
|______________|______________|__________________|
Figure 3: Example List of Constraint for Content
When the service period expires, the CDNs should remove the related
content.
This constraint in fact has controlled the broadcast service as a
limited broadcast. This is another typical use case of broadcast or
multicast over CDN interconnection.
5.3. Content Adaptation
To support the diversity of terminals and the fluctuant network band
width, adaptation measures may be conducted for the content services.
While for the CDN operator, it is better only to maintain
minimum(only one) content format(s). So, one solution is to
transform the content format prior to delivery. It means the content
forwarded between CDNs may be RTP streams of best quality( e.g. HD
ZP.Zhou Expires February 18, 2012 [Page 6]
Internet-Draft CDNI use case Aug 2011
video and Hi-Fi audio) while the RTP stream may be transformed to
adaptive streaming to serve for user. One possible realization is
that the delivering CDN which is nearest to the UE performs such
delivery format adaptation according to the UE's capabilities. The
adaptation may include, but is not limited to, conversion to adaptive
streaming, the transport format conversion, codec type conversion,
content encapsulation conversion and content metadata conversion
(e.g. content description, program information, etc). For example,
content is delivered from Content Provider through CDN-A to CDN-B in
the form of normal RTP streams. The delivering CDN, i.e. CDN-B,
determines that a UE requires the content to be delivered using
adaptive HTTP streaming, CDN-B now transforms the RTP streams to an
adaptive HTTP stream that can be delivered to the UE. See as figure
4:
+-------+ RTP Streams +-------+ RTP Streams +-------+
| CSP |------------>| CDN-A |------------>| CDN-B |
+-------+ +-------+ +-------+
|Converted to
|HTTP Streaming
| +-------+
-------------->| UE |
+-------+
Figure 4. Example of Content Adaptation
This use case is applicable for either broadcast or unicast service;
for either live Broadcast or VOD service. The content may be
transformed and stored as different files with different formats/
rates. According to the UE capability(media resolution, media types,
bandwidth, etc), the content request will be forwarded to specific
content link of different content files/live broadcast sources.
5.4. Content Priority
For the differ-service of content delivery, one way is to set
priority for the content. For example the content for more users may
be set a high priority and will be served first.
For example, when CDN-A receives two tasks to deliver two contents to
its downstream CDNs, CDN-A will check the priority of these two
contents. Since content-A is a live broadcast of football game to
millions of audiences and has been set a very high priority, CDN-A
will handle the task of content-A with high priority.
In general, the content should be set a priority before it is
delivered. The content priority may be set by CSP, Upstream CDN or
the UE( the user) and the priority may be set whether it may be
ZP.Zhou Expires February 18, 2012 [Page 7]
Internet-Draft CDNI use case Aug 2011
updated or not in terms of service implementation. For instance, the
user may set his subscribed content with a high priority with high
price and may change the priority sometimes, but the user may not set
the priority of some contents such as the advertisement content.
With the content priority, the CDN may also provide a VAS for the
user. If the user has subscribed two contents and when there is a
time conflict of these two content services, CDN will automatically
deliver the content service with high priority to the UE. One
example is, the user has subscribed two broadcast content services:
the News program from 6 to 10 o'clock and a football game from 7
o'clock but the football game is set a higher priority. At 6
o'clock, the CDN starts to deliver News content to UE and when time
arrives at 7 o'clock, the CDN will automatically stop the News
content delivery but start to deliver the content of football game.
Accordingly, the UE will alter to play the football game from the
News. When the football game finishes at 10 after 9 o'clock, the CDN
will automatically deliver again the News to the UE.
This use case is applicable for either broadcast or unicast service;
for either live Broadcast or VOD service. The core requirement is
the mechanism of priority management(e.g. set, exchange, update).
6. Application Example
Taking TISPAN CDN architecture as example in this section, a full
implementary instance for broadcast service performing the operating
requirements is given as below:
+------------+ +-------------+
| ALF/CDN-A |--------- | ALF /CDN-Z |
+------------+ +-------------+
| |
| |
+-------+ 1) +-----------+ 4) +-----------+
| CSP |-------|CDNCF/CDN-A|-----------|CDNCF/CDN-Z|
+-------+ +-----------+ +-----------+
| \ 2)| 5)|
| 3)\ +-------------+ 6) +-------------+
| \___ |CLUSTER/CDN-A|-------- |CLUSTER/CDN-Z|
7)| +-------------+ +-------------+
| |
+-------+ 8) |
| UE |-------------------------------------
+-------+
Figure 5: Example of Broadcast Service via CDN Interconnection
ZP.Zhou Expires February 18, 2012 [Page 8]
Internet-Draft CDNI use case Aug 2011
Execution steps for this procedure may be as following:
step 1: CSP informs to broadcast the content.
step 2: CDNCF in CDN-A informs its clusters to receive/get the
content( sports game with HD video format).
step 3: Cluster in CDN-A receives/gets the content from CSP.
step 4: CDNCF in CDN-A informs another CDNCF in CDN-Z to receive/get
the content from the cluster in CDN-A.
step 5: CDNCF in CDN-Z informs its clusters to receive/get the
content from CDN-A.
step 6: cluster in CDN-Z receives/gets the content from cluster in
CDN-A.
step 7: A UE in Tianjing subscribes the broadcast service. Through a
general CDN procedure, the UE is informed the address of cluster
under CDN-Z where UE may receive the broadcast content.
Additionally, CDN-Z may provide HTTP adaptive streaming and the
content received from CDN-A is transformed in adaptive streaming for
the UE.
step 8: UE receives the broadcast service from CDN-Z.
7. Security Considerations
The involved service information should be guaranteed unchanged.
More detail may be provided later.
8. IANA Considerations
This document requires no actions from IANA.
9. Acknowledgements
Many thanks to all the members of Huawei Software CDN project team
and all the friends met in the CDN standard meetings.
10. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
ZP.Zhou Expires February 18, 2012 [Page 9]
Internet-Draft CDNI use case Aug 2011
Requirement Levels", BCP 14, RFC 2119, March 1997.
[TISPAN] ETSI TISPAN, "CDN Architecture(ETSI TS 182 019)".
[MCD] ETSI MCD, "Media CDN Interconnection, use cases and
requirements(ETSI TS 102 990)".
[IETF-CDNI-usecase]
IETF CDNI, "[Draft-bertrand-cdni-use-cases]".
[IETF-CDNI-problem-statement]
IETF CDNI, "[Draft-jenkins-cdni-problem-statement]".
Author's Address
Zhipeng Zhou
Huawei Technologies, Inc.
No.101, Software Avenue, Yuhuatai District
Nanjing 210012
P.R.China
Phone: +86-25-56620690
Email: zhouzhipeng@huawei.com
ZP.Zhou Expires February 18, 2012 [Page 10]