One document matched: draft-zhou-cdni-use-case-00.txt
IETF cdni Zhou
Internet-Draft Huawei Technologies, Inc.
Intended status: Informational Jul 04, 2011
Expires: January 5, 2012
CDNI use case
draft-zhou-cdni-use-case-00
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 January 5, 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
Zhou Expires January 5, 2012 [Page 1]
Internet-Draft CDNI use case Jul 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 . . . . . . . . . . . . . . . . . . . . . 4
5.2. Constraint for Content . . . . . . . . . . . . . . . . . . 6
5.3. Content Adaptation . . . . . . . . . . . . . . . . . . . . 6
6. Application Example . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
10. Normative References . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Zhou Expires January 5, 2012 [Page 2]
Internet-Draft CDNI use case Jul 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
Zhou Expires January 5, 2012 [Page 3]
Internet-Draft CDNI use case Jul 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 fromat of content service may be converted
according to the terminal's capability or consumer's application.
For example converting multicast (or unicast) RTP streams to HTTP
streaming and then delivering the adaptive stream to terminals( refer
to MCD CDN-I use case and requirement). For implementation of CDN
service, it is optimum maintaining and delivering one format of
content within CDN system 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.
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.
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:
Zhou Expires January 5, 2012 [Page 4]
Internet-Draft CDNI use case Jul 2011
_____________________________
| 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
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.
Zhou Expires January 5, 2012 [Page 5]
Internet-Draft CDNI use case Jul 2011
The arrangement above may be seen as a typical deployment policy( may
be benefical for both efficienty 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
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
Zhou Expires January 5, 2012 [Page 6]
Internet-Draft CDNI use case Jul 2011
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, 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 broadcase or unicast service.
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
Zhou Expires January 5, 2012 [Page 7]
Internet-Draft CDNI use case Jul 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
Zhou Expires January 5, 2012 [Page 8]
Internet-Draft CDNI use case Jul 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]
IETF CDNI, "[Draft-bertrand-cdni-use-cases]".
Author's Address
Zhipeng Zhou
Huawei Technologies, Inc.
No.101, Software Avenue,Yuhuatai District
Nanjing 210012
P.R.China
Phone: +86-25-56620690
Email: zhouzp@huawei.com
Zhou Expires January 5, 2012 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-24 02:49:37 |