1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
|
<pre>Internet Engineering Task Force (IETF) G. Bertrand, Ed.
Request for Comments: 6770 E. Stephan
Obsoletes: <a href="./rfc3570">3570</a> France Telecom - Orange
Category: Informational T. Burbridge
ISSN: 2070-1721 P. Eardley
BT
K. Ma
Azuki Systems, Inc.
G. Watson
Alcatel-Lucent (Velocix)
November 2012
<span class="h1">Use Cases for Content Delivery Network Interconnection</span>
Abstract
Content Delivery Networks (CDNs) are commonly used for improving the
End User experience of a content delivery service while keeping cost
at a reasonable level. This document focuses on use cases that
correspond to identified industry needs and that are expected to be
realized once open interfaces and protocols supporting the
interconnection of CDNs are specified and implemented. This document
can be used to motivate the definition of the requirements to be
supported by CDN Interconnection (CDNI) interfaces. It obsoletes <a href="./rfc3570">RFC</a>
<a href="./rfc3570">3570</a>.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc6770">http://www.rfc-editor.org/info/rfc6770</a>.
<span class="grey">Bertrand, et al. Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6770">RFC 6770</a> CDNI Use Cases November 2012</span>
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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. 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
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-1.1">1.1</a>. Terminology . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-1.2">1.2</a>. Abbreviations . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-1.3">1.3</a>. Rationale for CDN Interconnection . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2">2</a>. Footprint Extension Use Cases . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-2.1">2.1</a>. Geographic Extension . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-2.2">2.2</a>. Inter-Affiliates Interconnection . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-2.3">2.3</a>. ISP Handling of Third-Party Content . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-2.4">2.4</a>. Nomadic Users . . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-3">3</a>. Offload Use Cases . . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-3.1">3.1</a>. Overload Handling and Dimensioning . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-3.2">3.2</a>. Resiliency . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-3.2.1">3.2.1</a>. Failure of Content Delivery Resources . . . . . . . . <a href="#page-9">9</a>
<a href="#section-3.2.2">3.2.2</a>. Content Acquisition Resiliency . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-4">4</a>. Capability Use Cases . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-4.1">4.1</a>. Device and Network Technology Extension . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-4.2">4.2</a>. Technology and Vendor Interoperability . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-4.3">4.3</a>. QoE and QoS Improvement . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-5">5</a>. Enforcement of Content Delivery Policy . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-6">6</a>. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-7">7</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-8">8</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-8.1">8.1</a>. Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-8.2">8.2</a>. Informative References . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#appendix-A">Appendix A</a>. Content Service Providers' Delivery Policies . . . . <a href="#page-14">14</a>
<a href="#appendix-A.1">A.1</a>. Content Delivery Policy Enforcement . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#appendix-A.2">A.2</a>. Secure Access . . . . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#appendix-A.3">A.3</a>. Branding . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<span class="grey">Bertrand, et al. Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6770">RFC 6770</a> CDNI Use Cases November 2012</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Content Delivery Networks (CDNs) are commonly used for improving the
End User experience of a content delivery service while keeping cost
at a reasonable level. This document focuses on use cases that
correspond to identified industry needs and that are expected to be
realized once open interfaces and protocols supporting the
interconnection of CDNs are specified and implemented. The document
can be used to motivate the definition of the requirements (as
documented in [<a href="#ref-CDNI-REQ" title=""Content Distribution Network Interconnection (CDNI) Requirements"">CDNI-REQ</a>]) to be supported by the set of CDN
Interconnection (CDNI) interfaces defined in [<a href="./rfc6707" title=""Content Distribution Network Interconnection (CDNI) Problem Statement"">RFC6707</a>].
[<a id="ref-RFC3570">RFC3570</a>] describes slightly different terminologies and models for
"Content Internetworking (CDI)". This document obsoletes <a href="./rfc3570">RFC 3570</a> to
avoid confusion.
This document identifies the main motivations for a CDN Provider to
interconnect its CDN:
o CDN Footprint Extension Use Cases (<a href="#section-2">Section 2</a>)
o CDN Offload Use Cases (<a href="#section-3">Section 3</a>)
o CDN Capability Use Cases (<a href="#section-4">Section 4</a>)
Then, the document highlights the need for interoperability in order
to exchange and enforce content delivery policies (<a href="#section-5">Section 5</a>).
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Terminology</span>
In this document, the first letter of each CDNI-specific term is
capitalized. We adopt the terminology described in [<a href="./rfc6707" title=""Content Distribution Network Interconnection (CDNI) Problem Statement"">RFC6707</a>].
We extend this terminology with the following term:
Access CDN:
A CDN that includes Surrogates in the same administrative network as
the End User. Such a CDN can use accurate information on the End
User's network context to provide additional Content Delivery
Services to Content Service Providers.
<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>. Abbreviations</span>
o CDN: Content Delivery Network, also known as Content Distribution
Network
o CSP: Content Service Provider
<span class="grey">Bertrand, et al. Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6770">RFC 6770</a> CDNI Use Cases November 2012</span>
o dCDN: downstream CDN
o DNS: Domain Name System
o EU: End User
o ISP: Internet Service Provider
o NSP: Network Service Provider
o QoE: Quality of Experience
o QoS: Quality of Service
o uCDN: upstream CDN
o URL: Uniform Resource Locator
o WiFi: Wireless local area network (WLAN) based on IEEE 802.11
<span class="h3"><a class="selflink" id="section-1.3" href="#section-1.3">1.3</a>. Rationale for CDN Interconnection</span>
Content Delivery Networks (CDNs) are used to deliver content because
they can:
o improve the experience for the End User; for instance delivery has
lower latency (decreased round-trip-time and higher throughput
between the user and the delivery server) and better robustness
(ability to use multiple delivery servers),
o reduce the network operator's costs; for instance, lower delivery
cost (reduced bandwidth usage) for cacheable content,
o reduce the Content Service Provider's (CSP) internal
infrastructure costs, such as data center capacity, space, and
electricity consumption, as popular content is delivered
externally through the CDN rather than through the CSP's own
servers.
Indeed, many Network Service Providers (NSPs) and Enterprise Service
Providers are deploying or have deployed their own CDNs. Despite the
potential benefits of interconnecting CDNs, today each CDN is a
stand-alone network. The objective of CDN Interconnection is to
overcome this restriction; the interconnected CDNs should be able to
collectively behave as a single delivery infrastructure.
An example is depicted in Figure 1, where two CDN Providers establish
a CDN Interconnection. The Content Service Provider CSP-1 reaches an
<span class="grey">Bertrand, et al. Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6770">RFC 6770</a> CDNI Use Cases November 2012</span>
agreement with CDN Provider 'A' for the delivery of its content.
Independently, CDN Provider 'A' and CDN Provider 'B' agree to
interconnect their CDNs.
When a given User Agent requests content from CSP-1, CDN-A may
consider that delivery by CDN-B is appropriate, for instance, because
CDN-B is an Access CDN and the user is directly attached to it.
Through the CDN Interconnection arrangements put in place between
CDN-A and CDN-B (as a result of the CDN Interconnection agreement
established between CDN Provider 'A' and CDN Provider 'B'), CDN-A can
redirect the request to CDN-B and the content is actually delivered
to the User Agent by CDN-B.
The End User benefits from this arrangement through a better Quality
of Experience (QoE, see [<a href="./rfc6390" title=""Guidelines for Considering New Performance Metric Development"">RFC6390</a>]), because the content is delivered
from a nearby Surrogate (e.g., lower latency, bottlenecks avoided).
CDN Provider 'A' benefits because it does not need to deploy such an
extensive CDN, while CDN Provider 'B' may receive some compensation
for the delivery. CSP-1 benefits because it only needs to make one
business agreement and one technical arrangement with CDN Provider
'A', but its End Users get a service quality as though CSP-1 had also
gone to the trouble of making a business agreement and technical
arrangement with CDN Provider 'B'.
+-------+ +-------+
| CSP-1 | | CSP-2 |
+-------+ +-------+
| |
,--,--,--./ ,--,--,--.
,-' `-. ,-' `-.
(CDN Provider 'A')=====(CDN Provider 'B')
`-. (CDN-A) ,-' `-. (CDN-B) ,-'
`--'--'--' `--'--'--'
|
+----------+
| End User |
+----------+
=== CDN Interconnection
Figure 1
To extend the example, another Content Service Provider, CSP-2, may
also reach an agreement with CDN Provider 'A'. However, CSP-2 may
not want its content to be distributed by CDN Provider B; for
example, CSP-2 may not want to distribute its content in the area
where CDN Provider 'B' operates. This example illustrates that
policy considerations are an important part of CDNI.
<span class="grey">Bertrand, et al. Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6770">RFC 6770</a> CDNI Use Cases November 2012</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Footprint Extension Use Cases</span>
Footprint extension is expected to be a major use case for CDN
Interconnection.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Geographic Extension</span>
In this use case, the CDN Provider wants to extend the geographic
distribution that it can offer to its CSPs:
o without compromising the quality of delivery.
o without incurring additional transit and other network costs that
would result from serving content from geographically or
topologically remote Surrogates.
o without incurring the cost of deploying and operating Surrogates
and the associated CDN infrastructure that may not be justified in
the corresponding geographic region (e.g., because of relatively
low delivery volume, or conversely because of the high investments
that would be needed to satisfy the high volume).
If there are several CDN Providers that have a geographically limited
footprint (e.g., restricted to one country), or do not serve all End
Users in a geographic area, then interconnecting their CDNs enables
these CDN Providers to provide their services beyond their own
footprint.
As an example, suppose a French CSP wants to distribute its TV
programs to End Users located in France and various countries in
North Africa. It asks a French CDN Provider to deliver the content.
The French CDN Provider's network only covers France, so it makes an
agreement with another CDN Provider that covers North Africa.
Overall, from the CSP's perspective, the French CDN Provider provides
a CDN service for both France and North Africa.
In addition to video, this use case applies to other types of content
such as automatic software updates (browser updates, operating system
patches, virus database update, etc.).
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Inter-Affiliates Interconnection</span>
The previous section describes the case of geographic extension
between CDNs operated by different entities. A large CDN Provider
may have several subsidiaries that each operate their own CDN (which
may rely on different CDN technologies, see <a href="#section-4.2">Section 4.2</a>). In certain
<span class="grey">Bertrand, et al. Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6770">RFC 6770</a> CDNI Use Cases November 2012</span>
circumstances, the CDN Provider needs to make these CDNs interoperate
to provide consistent service to its customers on the whole
collective footprint.
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. ISP Handling of Third-Party Content</span>
Consider an ISP carrying to its subscribers a lot of content that
comes from a third-party CSP and that is injected into the ISP's
network by an Authoritative CDN Provider. There are mutual benefits
to the ISP (acting as an Access CDN), the Authoritative CDN, and the
CSP that would make a case for establishing a CDNI agreement. For
example:
o allowing the CSP to offer improved QoE and QoE services to
subscribers, for example, reduced content startup time or
increased video quality and resolution of adaptive streaming
content.
o allowing the Authoritative CDN to reduce hardware capacity and
footprint, by using the ISP caching and delivery capacity.
o allowing the ISP to reduce traffic load on some segments of the
network by caching inside of the ISP network.
o allowing the ISP to influence and/or control the traffic ingress
points.
o allowing the ISP to derive some incremental revenue for transport
of the traffic and to monetize QoE services.
<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>. Nomadic Users</span>
In this scenario, a CSP wishes to allow End Users who move between
access networks to continue to access their content. The motivation
of this case is to allow nomadic End Users to maintain access to
content with a consistent QoE across a range of devices and/or
geographic regions.
This use case covers situations like:
o End Users moving between different access networks, which may be
located within the same geographic region or different geographic
regions.
o End Users switching between different devices or delivery
technologies, as discussed in <a href="#section-4">Section 4</a>.
<span class="grey">Bertrand, et al. Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6770">RFC 6770</a> CDNI Use Cases November 2012</span>
Consider the following example, illustrated in Figure 2: End User A
has a subscription to a broadband service from ISP A, her "home ISP".
ISP A hosts CDN-A. Ordinarily, when End User A accesses content via
ISP A (her "home ISP"), the content is delivered from CDN-A, which in
this example is within ISP A's network.
However, while End User A is not connected to ISP A's network, for
example, because it is connected to a WiFi provider or mobile
network, End User A can also access the same content. In this case,
End User A may benefit from accessing the same content delivered by
an alternate CDN (CDN-B), in this case, hosted in the network of the
WiFi or mobile provider (ISP B), rather than from CDN-A in ISP A's
network.
+-------+
|Content|
+-------+
|
,--,--,--. ,--,--,--.
,-' ISP A `-. ,-' ISP B `-.
( (CDN-A) )=====( (CDN-B) )
`-. ,-' `-. ,-'
`--'--'--' `--'--'--'
| |
+------------+ +---------------+
+ EU A (home)| | EU A (nomadic)|
+------------+ +---------------+
=== CDN Interconnection
Figure 2
Though the content of CSP A is not accessible by typical End Users of
CDN-B, End User A is able to gain access to her "home" content (i.e.,
the content of CSP A) through the alternate CDN (CDN-B).
Depending on the CSP's content delivery policies (see <a href="#appendix-A.1">Appendix A.1</a>),
a user moving to a different geographic region may be subject to geo-
blocking content delivery restrictions. In this case, he/she may not
be allowed to access some pieces of content.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Offload Use Cases</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Overload Handling and Dimensioning</span>
A CDN is likely to be dimensioned to support an expected maximum
traffic load. However, unexpected spikes in content popularity
(flash crowd) may drive load beyond the expected peak. The prime
recurrent time peaks of content distribution may differ between two
<span class="grey">Bertrand, et al. Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6770">RFC 6770</a> CDNI Use Cases November 2012</span>
CDNs. Taking advantage of the different traffic peak times, a CDN
may interconnect with another CDN to increase its effective capacity
during the peak of traffic. This brings dimensioning savings to the
CDNs, as they can use each other's resources during their respective
peaks of activity.
Offload also applies to planned situations in which a CDN Provider
needs CDN capacity in a particular region during a short period of
time. For example, a CDN can offload traffic to another CDN for the
duration of a specific maintenance operation or for the distribution
of a special event, as in the scenario depicted in Figure 3. For
instance, consider a TV channel that is the distributor for a major
event, such as a celebrity's wedding or a major sport competition,
and this TV channel has contracted particular CDNs for the delivery.
The CDNs (CDN-A and CDN-B) that the TV channel uses for delivering
the content related to this event are likely to experience a flash
crowd during the event and will need to offload traffic, while other
CDNs (CDN-C) will support a more typical traffic load and be able to
handle the offloaded traffic.
In this use case, the Delivering CDN on which requests are offloaded
should be able to handle the offloaded requests. Therefore, the uCDN
might require information on the dCDNs to be aware of the amount of
traffic it can offload to each dCDN.
+------------+
| TV Channel |
+------------+
| \
,-,--,-. \ ,-,--,-. ,-,--,-.
,' `. ,' `. ,' CDN-C `.
( CDN-A ) ( CDN-B )==( offload )
`. ,' `. ,' `. ,'
`-'--'-' `-'--'-' `-'--'-'
=== CDN Interconnection
Figure 3
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Resiliency</span>
<span class="h4"><a class="selflink" id="section-3.2.1" href="#section-3.2.1">3.2.1</a>. Failure of Content Delivery Resources</span>
It is important for CDNs to be able to guarantee service continuity
during partial failures (e.g., failure of some Surrogates). In
partial failure scenarios, a CDN Provider has at least three options:
<span class="grey">Bertrand, et al. Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6770">RFC 6770</a> CDNI Use Cases November 2012</span>
1. if possible, use internal mechanisms to redirect traffic onto
surviving equipment,
2. depending on traffic management policies, forward some requests
to the CSP's origin servers, and/or
3. redirect some requests toward another CDN, which must be able to
serve the redirected requests.
The last option is a use case for CDNI.
<span class="h4"><a class="selflink" id="section-3.2.2" href="#section-3.2.2">3.2.2</a>. Content Acquisition Resiliency</span>
Source content acquisition may be handled in one of two ways:
o CSP origin, where a CDN acquires content directly from the CSP's
origin server, or
o CDN origin, where a downstream CDN acquires content from a
Surrogate within an upstream CDN.
The ability to support content acquisition resiliency is an important
use case for interconnected CDNs. When the content acquisition
source fails, the CDN might switch to another content acquisition
source. Similarly, when several content acquisition sources are
available, a CDN might balance the load between these multiple
sources.
Though other server and/or DNS load-balancing techniques may be
employed in the network, interconnected CDNs may have a better
understanding of origin-server availability, and be better equipped
to both distribute load between origin servers and attempt content
acquisition from alternate content sources when acquisition failures
occur. When normal content acquisition fails, a CDN may need to try
other content source options, for example:
o an upstream CDN may acquire content from an alternate CSP origin
server,
o a downstream CDN may acquire content from an alternate Surrogate
within an upstream CDN,
o a downstream CDN may acquire content from an alternate upstream
CDN, or
o a downstream CDN may acquire content directly from the CSP's
origin server.
<span class="grey">Bertrand, et al. Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc6770">RFC 6770</a> CDNI Use Cases November 2012</span>
Though content acquisition protocols are beyond the scope of CDNI,
the selection of content acquisition sources should be considered and
facilitated.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Capability Use Cases</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Device and Network Technology Extension</span>
In this use case, the CDN Provider may have the right geographic
footprint, but may wish to extend the supported range of devices and
User Agents or the supported range of delivery technologies. In this
case, a CDN Provider may interconnect with a CDN that offers services
that:
o the CDN Provider is not willing to provide, or
o its own CDN is not able to support.
The following examples illustrate this use case:
1. CDN-A cannot support a specific delivery protocol. For instance,
CDN-A may interconnect with CDN-B to serve a proportion of its
traffic that requires HTTPS [<a href="./rfc2818" title=""HTTP Over TLS"">RFC2818</a>]. CDN-A may use CDN-B's
footprint (which may overlap with its own) to deliver HTTPS
without needing to deploy its own infrastructure. This case
could also be true of other formats, delivery protocols (e.g.,
the Real Time Messaging Protocol (RTMP), the Real Time Streaming
Protocol (RTSP), etc.), and features (specific forms of
authorization such as tokens, per session encryption, etc.).
2. CDN-A has a footprint covering traditional fixed-line broadband
and wants to extend coverage to mobile devices. In this case,
CDN-A may contract and interconnect with CDN-B, who has both:
* a physical footprint inside the mobile network,
* the ability to deliver content over a protocol that is
required by specific mobile devices.
3. CDN-A only supports IPv4 within its infrastructure but wants to
deliver content over IPv6. CDN-B supports both IPv4 and IPv6
within its infrastructure. CDN-A interconnects with CDN-B to
serve out its content over native IPv6 connections.
These cases can apply to many CDN features that a given CDN Provider
may not be able to support or not be willing to invest in, and thus,
that the CDN Provider would delegate to another CDN.
<span class="grey">Bertrand, et al. Informational [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc6770">RFC 6770</a> CDNI Use Cases November 2012</span>
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Technology and Vendor Interoperability</span>
A CDN Provider may deploy a new CDN to run alongside its existing CDN
as a simple way of migrating its CDN service to a new technology. In
addition, a CDN Provider may have a multi-vendor strategy for its CDN
deployment. Finally, a CDN Provider may want to deploy a separate
CDN for a particular CSP or a specific network. In all these
circumstances, CDNI benefits the CDN Provider, as it simplifies or
automates some inter-CDN operations (e.g., migrating the request
routing function progressively).
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. QoE and QoS Improvement</span>
Some CSPs are willing to pay a premium for enhanced delivery of
content to their End Users. In some cases, even if the CDN Provider
could deliver the content to the End Users, it would not meet the
CSP's service-level requirements. As a result, the CDN Provider may
establish a CDN Interconnection agreement with another CDN Provider
that can provide the expected QoE to the End User, e.g., via an
Access CDN that is able to deliver content from Surrogates located
closer to the End User and with the required service level.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Enforcement of Content Delivery Policy</span>
An important aspect common to all the above use cases is that CSPs
typically want to enforce content delivery policies. A CSP may want
to define content delivery policies that specify when, how, and/or to
whom the CDN delivers content. These policies apply to all
interconnected CDNs (uCDNs and dCDNs) in the same or similar way that
a CSP can define content delivery policies for content delivered by a
single, non-interconnected CDN. <a href="#appendix-A">Appendix A</a> provides examples of CSP-
defined policies.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Acknowledgments</span>
The authors would like to thank Kent Leung, Francois Le Faucheur, Ben
Niven-Jenkins, and Scott Wainner for lively discussions, as well as
for their reviews and comments on the mailing list.
They also thank the contributors of the EU FP7 OCEAN and ETICS
projects for valuable inputs.
Finally, the authors acknowledge the work of the former CDI working
group. This document obsoletes [<a href="./rfc3570" title=""Content Internetworking (CDI) Scenarios"">RFC3570</a>] to avoid confusion.
<span class="grey">Bertrand, et al. Informational [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc6770">RFC 6770</a> CDNI Use Cases November 2012</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Security Considerations</span>
This document focuses on the motivational use cases for CDN
Interconnection and does not analyze the associated threats. Those
threats are discussed in [<a href="./rfc6707" title=""Content Distribution Network Interconnection (CDNI) Problem Statement"">RFC6707</a>]. <a href="#appendix-A.2">Appendix A.2</a> of this document
provides example security policies that CSPs might impose on CDNs to
mitigate the threats.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Normative References</span>
[<a id="ref-RFC6707">RFC6707</a>] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar,
"Content Distribution Network Interconnection (CDNI)
Problem Statement", <a href="./rfc6707">RFC 6707</a>, September 2012.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Informative References</span>
[<a id="ref-CDNI-REQ">CDNI-REQ</a>] Leung, K. and Y. Lee, "Content Distribution Network
Interconnection (CDNI) Requirements", Work in Progress,
June 2012.
[<a id="ref-RFC2818">RFC2818</a>] Rescorla, E., "HTTP Over TLS", <a href="./rfc2818">RFC 2818</a>, May 2000.
[<a id="ref-RFC3570">RFC3570</a>] Rzewski, P., Day, M., and D. Gilletti, "Content
Internetworking (CDI) Scenarios", <a href="./rfc3570">RFC 3570</a>, July 2003.
[<a id="ref-RFC6390">RFC6390</a>] Clark, A. and B. Claise, "Guidelines for Considering New
Performance Metric Development", <a href="https://www.rfc-editor.org/bcp/bcp170">BCP 170</a>, <a href="./rfc6390">RFC 6390</a>,
October 2011.
<span class="grey">Bertrand, et al. Informational [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc6770">RFC 6770</a> CDNI Use Cases November 2012</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Content Service Providers' Delivery Policies</span>
CSPs commonly apply different delivery policies to given sets of
content assets delivered through CDNs. Interconnected CDNs need to
support these policies. This appendix presents examples of CSPs'
delivery policies and their consequences on CDNI operations.
<span class="h3"><a class="selflink" id="appendix-A.1" href="#appendix-A.1">A.1</a>. Content Delivery Policy Enforcement</span>
The content distribution policies that a CSP attaches to a content
asset may depend on many criteria. For instance, distribution
policies for audiovisual content often combine constraints of varying
levels of complexity and sophistication, for example:
o temporal constraints (e.g., available for 24 hours, available 28
days after DVD release, etc.),
o user agent platform constraints (e.g., mobile device platforms,
desktop computer platforms, set-top-box platforms, etc.),
o resolution-based constraints (e.g., high definition vs. standard
definition encodings),
o user agent identification or authorization,
o access network constraints (e.g., per NSP), and
o IP geo-blocking constraints (e.g., for a given coverage area).
CSPs may use sophisticated policies in accordance with their business
model. However, the enforcement of those policies does not
necessarily require that the delivery network understand the policy
rationales or how policies apply to specific content assets. Content
delivery policies may be distilled into simple rules that can be
commonly enforced across all dCDNs. These rules may influence dCDN
delegation and Surrogate selection decisions, for instance, to ensure
that the specific rules (e.g., time-window, geo-blocking, pre-
authorization validation) can indeed be enforced by the Delivering
CDN. In turn, this can guarantee to the CSP that content delivery
policies are properly applied.
<span class="grey">Bertrand, et al. Informational [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc6770">RFC 6770</a> CDNI Use Cases November 2012</span>
+-----+
| CSP | Policies driven by business (e.g., available only
+-----+ in the UK and only from July 1st to September 1st)
\
\ Translate policies into
\simple rules (e.g., provide an authorization token)
\
V
+-----+
| CDN | Apply simple rules (e.g., check an
+-----+ authorization token and enforce geo-blocking)
\
\ Distribute simple rules
V
+-----+
| CDN | Apply simple rules
+-----+
Figure 4
<span class="h3"><a class="selflink" id="appendix-A.2" href="#appendix-A.2">A.2</a>. Secure Access</span>
Many protocols exist for delivering content to End Users. CSPs may
dictate a specific protocol or set of protocols that are acceptable
for delivery of their content, especially in the case where a secured
content transmission is required (e.g., must use HTTPS). CSPs may
also perform a per-request authentication/authorization decision and
then have the CDNs enforce that decision (e.g., must validate URL
signing, etc.).
<span class="h3"><a class="selflink" id="appendix-A.3" href="#appendix-A.3">A.3</a>. Branding</span>
Preserving the branding of the CSP throughout delivery is often
important to the CSP. CSPs may desire to offer content services
under their own name, even when the associated CDN service involves
other CDN Providers. For instance, a CSP may desire to ensure that
content is delivered with URIs appearing to the End Users under the
CSP's own domain name, even when the content delivery involves
separate CDN Providers. The CSP may wish to prevent the delivery of
its content by specific dCDNs that lack support for such branding
preservation features.
Analogous cases exist when the uCDN wants to offer CDN services under
its own branding even if dCDNs are involved, and so it restricts the
delivery delegation to a chain that preserves its brand visibility.
<span class="grey">Bertrand, et al. Informational [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc6770">RFC 6770</a> CDNI Use Cases November 2012</span>
Authors' Addresses
Gilles Bertrand (editor)
France Telecom - Orange
38-40 rue du General Leclerc
Issy les Moulineaux, 92130
FR
Phone: +33 1 45 29 89 46
EMail: gilles.bertrand@orange.com
Stephan Emile
France Telecom - Orange
2 avenue Pierre Marzin
Lannion F-22307
FR
EMail: emile.stephan@orange.com
Trevor Burbridge
BT
B54 Room 70, Adastral Park, Martlesham
Ipswich, IP5 3RE
UK
EMail: trevor.burbridge@bt.com
Philip Eardley
BT
B54 Room 77, Adastral Park, Martlesham
Ipswich, IP5 3RE
UK
EMail: philip.eardley@bt.com
Kevin J. Ma
Azuki Systems, Inc.
43 Nagog Park
Acton, MA 01720
USA
Phone: +1 978-844-5100
EMail: kevin.ma@azukisystems.com
Grant Watson
Alcatel-Lucent (Velocix)
3 Ely Road
Milton, Cambridge CB24 6AA
UK
EMail: gwatson@velocix.com
Bertrand, et al. Informational [Page 16]
</pre>
|
