Content Delivery Network

Transcription

Content Delivery Network
Overview
May 25, 2010
© 2010 Level 3 Communications, LLC. All Rights Reserved.VenueNet, vyvxInView and First Video are registered service marks of Level 3 Communications,
LLC and/or one of its affiliates in the United States and/or other countries. Level 3 and the Level 3 logo are service marks of Level 3 Communications, LLC
and/or one of its affiliates in the United States and/or other countries with respect to Level 3's VyVx service offerings. Level 3 services are provided by wholly
owned subsidiaries of Level 3 Communications, Inc. Any other service, product or company names recited herein are the trademarks or service marks of their
respective owners.
Confidential & Proprietary – Subject to NDA
Notices
Copyright © 2008 – 2010, Level 3 Communications
All rights reserved. No part of this publication may be reproduced, transmitted, distributed, transcribed, stored in a retrie val system, or
translated into any language, in any form or by any means, electronic, mechanical, or otherwise, without prior written permission from Level 3
Communications.
The technology described herein may be protected by one or more of the following U.S. Patents: 5,978,791, 6,185,598, 6,415,280, 6,275,470,
6,130,890. Additional patents pending worldwide.
Published in the United States of America.
THIS DOCUMENTATION CONSTITUTES PROPRIETARY, CONFIDENTIAL INFORMATION OF LEVEL 3 COMMUNICATIONS, AND MAY NOT BE
DISCLOSED OR USED EXCEPT AS MAY BE PROVIDED IN THE TERMS AND CONDITIONS OF THE LICENSE OR OTHER AGREEMENT
PURSUANT TO WHICH YOU HAVE BEEN AUTHORIZED TO USE THE FOOTPRINT PRODUCT OR TO REVIEW THIS DOCUMENT.
The Level 3 Communications logo and other marks designated with ® are registered service marks, and those designated with SM are service marks
of Level 3 Communications, Inc. and/or its affiliates in the United States and/or other countries. The Level 3 Enhanced Services logo is a service
mark of Level 3 Enhanced Services, LLC in the United States and/or other countries. These marks may be used publicly only with prior permission
of Level 3. Fair use of Level 3‘s marks in advertising and promotion of Level 3 services requires proper acknowledgment. All other trademarks and
service marks referenced in this Site are the property of their respective owners.
All other product and company names mentioned herein may be the trademarks or registered trademarks of their respective owners.
Level 3 Communications
Level 3 Communications, Inc.
1025 Eldorado Boulevard
Broomfield, Colorado 80021
720-888-1000
DOCUMENT revision: 1.0 Edition Date: 5/1/10
© 2010 Level 3 Communications, LLC. All Rights Reserved.
Page 2
Table of Contents
Notices .............................................................................................................................................................................. 2
Table of Contents ............................................................................................................................................................. 3
List of Figures ................................................................................................................................................................... 6
CDN Overview .................................................................................................................................................................. 7
Value-Add Capabilities ................................................................................................................................................. 8
Major Services Overview ................................................................................................................................................ 10
Streaming Overview ................................................................................................................................................... 10
Caching Services Overview ....................................................................................................................................... 11
Intelligent Traffic Management (ITM) Overview ......................................................................................................... 12
Origin Storage Overview ............................................................................................................................................ 16
Major Services Operations ............................................................................................................................................. 18
On-Demand Streaming Operations ............................................................................................................................ 18
Live Streaming Operations ......................................................................................................................................... 20
Caching Operations .................................................................................................................................................... 28
Origin Storage Operations.......................................................................................................................................... 35
Content Freshness Features .......................................................................................................................................... 36
Methods of Freshness Control ................................................................................................................................... 36
Refreshing Content in Cache ..................................................................................................................................... 36
Expiration Policies ...................................................................................................................................................... 36
Cache-Control-Header-Override Mode (CCHOMode) ............................................................................................... 37
Background Refresh (BRefresh) ................................................................................................................................ 39
How Content Freshness Works with BRefresh and CCHOMode .............................................................................. 39
ETAG and If-None-Match Support ............................................................................................................................. 40
Query-String-Handling Mode (QSHMode) ................................................................................................................. 40
On-Demand Invalidation............................................................................................................................................. 41
Security Features ............................................................................................................................................................ 45
Overview..................................................................................................................................................................... 45
Proxy Authentication .................................................................................................................................................. 45
Edge Authentication ................................................................................................................................................... 48
Origin Server Security Features ................................................................................................................................. 54
SWF Verification ......................................................................................................................................................... 54
Order of Authentication Checks ................................................................................................................................. 56
Secure Protocols ........................................................................................................................................................ 56
Request and Response Inspection and Manipulation .................................................................................................... 58
HTTP Header Manipulation ........................................................................................................................................ 58
HTTP Status Code Manipulation ................................................................................................................................ 58
Response Body Manipulation .................................................................................................................................... 58
Redirect on Error ........................................................................................................................................................ 58
Page 3
Advanced Path Rewriting ........................................................................................................................................... 59
Override Vary Header ................................................................................................................................................ 59
Alternative Range Headers (URL-based Range Requests) ...................................................................................... 59
X-Forwarded-For Manipulation .................................................................................................................................. 60
Geographic Intelligence.............................................................................................................................................. 60
Performance Features .................................................................................................................................................... 61
Compressed Content Encoding ................................................................................................................................. 61
Foreground/Background Traffic ................................................................................................................................. 62
Extended Library Support (CDXL) ............................................................................................................................. 63
Follow Redirect ........................................................................................................................................................... 66
Large File Delivery ..................................................................................................................................................... 67
China In-Country Delivery .......................................................................................................................................... 67
Streaming Features ........................................................................................................................................................ 68
Dynamic Streaming .................................................................................................................................................... 68
Smooth Streaming...................................................................................................................................................... 68
QuickTime X (iPhone) HTTP Streaming .................................................................................................................... 68
Flash Scrubbing ......................................................................................................................................................... 68
Supported Flash Streaming Protocols ....................................................................................................................... 70
FCSubscribe Support ................................................................................................................................................. 70
Vyvx Broadcast Services ................................................................................................................................................ 71
Level 3 Vyvx Broadcast Services ............................................................................................................................... 71
Terrestrial Service Offerings ...................................................................................................................................... 71
Teleport and Satellite Service Offerings..................................................................................................................... 71
Live Encoding Services .................................................................................................................................................. 72
Key features ............................................................................................................................................................... 72
Management Services .................................................................................................................................................... 74
Level 3 Media Portal................................................................................................................................................... 74
Logging ....................................................................................................................................................................... 75
Download Receipts (Remote Logging) ...................................................................................................................... 76
Professional Services ..................................................................................................................................................... 77
Event Management Services ..................................................................................................................................... 77
Integration Services .................................................................................................................................................... 77
Appendix A:
Using ASX Files .................................................................................................................................... 79
Appendix B:
Firewall Port Access ............................................................................................................................. 80
Appendix C:
Protocol Rollover .................................................................................................................................. 81
Appendix D:
Legacy Flex Token Support .................................................................................................................. 83
Appendix E:
Perl Self-Generated Token Code Sample for Standard Token ............................................................ 84
Appendix F:
Perl Self-Generated Token Code Sample for Standard Token ............................................................ 86
Appendix G:
Flex Token Format ............................................................................................................................... 88
Appendix H:
Standard Token Format........................................................................................................................ 93
Page 4
Appendix I:
Jeroen Wijering (JW) FLV Media Player .............................................................................................. 95
Page 5
List of Figures
Figure 1: Level 3 CDN Services ................................................................................................................... 7
Figure 2: CDN Overview .............................................................................................................................. 8
Figure 3: Example of ITM Routing of Traffic ............................................................................................... 13
Figure 4: ITM Request Flow ....................................................................................................................... 14
Figure 5: Origin Storage Overview ............................................................................................................. 16
Figure 6: How On-Demand Streaming Works ............................................................................................ 18
Figure 7: Windows Media – Live "Pull" Workflow ....................................................................................... 20
Figure 8: One Possible Set Up for Live Flash Media (Multipoint Publishing) .............................................. 21
Figure 9: Flash Media – Live ―Push‖ Workflow ........................................................................................... 22
Figure 10: Extended Aliases ...................................................................................................................... 30
Figure 11: Request Processing – ―5 R‘s‖ Overview .................................................................................... 31
Figure 12: DNS Rendezvous Steps ........................................................................................................... 32
Figure 13: HTTP Cache Control Headers .................................................................................................. 37
Figure 14: Cache-Control Header Directives .............................................................................................. 37
Figure 15: Invalidation Meta-Characters .................................................................................................... 42
Figure 16: Proxy Authentication Using HEAD Requests ............................................................................ 46
Figure 17: Proxy Auth with Alternative Authentication Server..................................................................... 47
Figure 18: How Token Authentication works in Level 3‘s CDN ................................................................... 49
Figure 19: Standard Token Parameters ..................................................................................................... 50
Figure 20: Geo Intelligence Explanation .................................................................................................... 53
Figure 21: SWF Verification Flow ............................................................................................................... 55
Figure 22: Footprint/Secure ....................................................................................................................... 57
Figure 23: Scenario: Content Served from Edge (―Popular‖ Scenario) ....................................................... 64
Figure 24: Object Popularity and Thresholds ............................................................................................. 66
Figure 25: Flash Scrubbing ........................................................................................................................ 70
Figure 26: Broadcast Encoding to Streaming ............................................................................................. 72
Figure 27: Portal Dashboard ...................................................................................................................... 74
Figure 28: Log Processing ......................................................................................................................... 75
Figure 29: Comparison of Flex and Standard Tokens ................................................................................ 83
Figure 30: Excerpt from JW Setup Wizard ................................................................................................. 95
Figure 31: Output of JW Setup Wizard ....................................................................................................... 96
Page 6
CDN Overview
Level 3 is changing the business of content delivery as the first carrier to combine the advantages of an
industry-leading Internet backbone with a sophisticated and proven Content Delivery Network (CDN)
platform. This unique combination allows Level 3 to connect our customers with the benefits of our highperformance, highly scalable service – and deliver those services in a simplistic way. Our full suite of CDN
service offerings also allows our users the unique flexibility of supporting delivery at every step in the
content lifecycle, from ingest at the point of generation to delivery to end users.
The Level 3 CDN is powered by patented content delivery technology. It has extensive capabilities
developed by deploying and operating the world‘s first content delivery network. Our CDN services
leverage both the Level 3 IP transport network and our global peering relationships. This allows us to
distribute online content easily, rapidly, and reliably to end users from an international network of servers
located in strategic locations at the edge of the Internet near them.
Level 3‘s full suite of scalable CDN services gives you access to the customizable services you need from
a single, trusted provider. Level 3 offers more than a one-size-fits-all solution. By leveraging our CDN
services and industry-leading IP backbone, you can avoid costly capital investments and take advantage of
cost efficiencies. We can connect you with an end-to-end content delivery solution that supports your
unique business needs from content creation to consumption.
Vyvx
Content
Provider
g
din
co
En
End Users
Level 3 Caching and
Streaming CDN
Level 3
Storage
Level 3
Storage
Mobile
End Users
Customer
Origin
End Users
Figure 1: Level 3 CDN Services
Why choose the Level 3 Content Delivery Network?
•
Proactive Scalability Designed for Reduced Delivery Costs: Our CDN services proactively scale
edgeserver resources to meet real-time usage demands. This flexible capacity model is engineered to
enable greater operational cost-efficiencies and improve website and video delivery performance
Page 7
•
Flexible Portfolio: Since we have a comprehensive portfolio of CDN services, we can focus on meeting
your needs, not pushing just a single offering. In addition, we give you the flexibility to change your
network services as your needs grow
•
Targeted Solutions: We offer unique solutions that leverage caching, streaming, and storage to address
the needs of distinct segments. These solutions enable you to comfortably rely on us to deliver your
entire library, including popular and long-tail content, as well as flash traffic events
•
Network Performance that can help drive content monetization: Utilizing the global reach and
connectivity of an industry-leading IP backbone, your end users can receive the high-quality web
experience they expect. This can help improve customer loyalty, enhance brand equity, and drive the
monetization of your online assets
CDN Top Level Architecture
CDXL
Client
Edgeservers
Origin Storage or
Customer Origin
Parent Cache
Figure 2: CDN Overview
Value-Add Capabilities
The Caching and Streaming platform includes several critical features including the following:
•
Security: Features such as token-based authentication, download receipts, and referrer and IP blocking
allow customers to secure their content before it is delivered
•
Secure Delivery: This approach offloads computationally intensive processes of securing content with
SSL certificates to the CDN. Objects are transferred from the customer origin server and delivered,
encrypted, to end users. This prevents the display of ―page contains both secured and unsecured
items‖ pop-up for end-users. For FMS streaming, Level 3 supports RTMPE streaming of encrypted
assets
Page 8
•
Targeted Delivery: Delivery support can be targeted based on country, metro and/or network settings of
the end-user
Page 9
Major Services Overview
Streaming Overview
The Level 3SM Media Delivery Platform delivers audio and video content from an expansive global network
with edge delivery. It includes the expertise, technology, and applications required to support end-to-end
delivery for both live and on-demand streaming as well as ―always on‖ simulcasts.
Level 3® Streaming supports the major formats of today. It is an authorized premier partner for Adobe
Flash®, Apple QuickTime®, Microsoft Silverlight®, and Microsoft Windows Media. We also provide
optimized delivery of the HD-quality, adaptive streaming technology from Move Networks.
Both native and HTTP streaming formats are supported.
Through its integration with Level 3SM Vyvx® signal acquisition and web encoding solutions, the streaming
platform provides a simplified, single source offering for delivery of all types. That delivery includes full
reliability through a 100 percent uptime SLA and no single points of failure.
Streaming Types Supported
The Level 3 Media Delivery Platform includes two primary forms of streaming delivery:
•
Level 3® Live Online Broadcast Streaming: Delivers high-quality award shows, sporting events or
television broadcasts in event or continuous, always-on environments. Primary product components
include video delivery via Flash, Smooth Streaming, Windows Media, QuickTime (HTTP), or Move as
well as token authentication, geo intelligence, and reporting and management from the Level 3SM Media
Portal
•
Level 3® Video On-Demand Streaming: Delivers the pre-recorded playback of content including digital
music, music videos, movie and game trailers, and television programs
Multiple Service Options
•
Live Event: A single live event with SD and HD streaming quality
•
Live Event Series: A series of live events with multiple days or sessions
•
Always Live: Continuous streaming of an ongoing broadcast
•
On-Demand : Pre-recorded content, streamed and available online any time
Page 10
Caching Services Overview
The Level 3® Caching and Download Services are built to handle audiences of any size. The Level 3
Caching and Download platform supports multiple, common standards-based models for delivering
content. With extensive, global reach and capacity, the platform supports thousands of servers and
individual customers.
The Level 3 Caching and Download platform guarantees high quality performance and reliability with third
party SLA monitoring. The large suite of cacheability features ensures a high origin offload. For maximum
customer datacenter offload, customers can use Level 3SM Origin Storage.
Supported Caching Services
Object Delivery
Deliver popular file content, such as video, games, multimedia, patches, and file downloads to large
audiences. Objects can be tagged for control over delivery, authentication, and content freshness.
Wholesite Delivery
Level 3® Wholesite Delivery delivers entire pages as well as each page element, including HTML, CSS,
JavaScript, images, collateral downloads, etc. The result is high-performance delivery of the whole website,
and maximum protection against flash crowds. No modifications to the origin server are required, and the
service can be implemented without rewriting HTML.
Level 3® Electronic Software Delivery
Software downloads are a subcategory of object delivery for the purposes of sending software drivers,
executables, documentation, for example, to end users. Level 3 supports byte range requests to allow
large files to be requested efficiently.
Page 11
Intelligent Traffic Management (ITM) Overview
The Level 3 Communications Intelligent Traffic Management (ITM) is a powerful DNS-based service that
enables companies to route wide-area traffic transparently to any publicly accessible IP application,
website, or CDN. Routing decisions are made based on an ITM policy (that leverages network data)
configured by customers for optimal performance and availability. ITM is a flexible, easy to use service with
automatic failover, global load balancing, and geo-intelligence capabilities built-in to the platform. The
implementation of ITM is simple and it is controlled by the Level 3 CDN Media Portal for access and
security.
The service seamlessly interfaces with existing local and global load-balancing solutions, allowing
customers to reduce the cost of deploying, operating, and maintaining their own Internet traffic
management systems.
ITM allows you to maximize your online reliability and performance, as seen by end users, regardless of
whether your current Internet presence consists of a single server or a dozen globally distributed data
centers, each housing multiple machines behind a virtual IP address.
Directing Traffic with ITM
With ITM, customers can configure a static ―traffic distribution‖ policy by specifying the percentage of traffic
to be directed to each group of application servers. If needed, ―overflow‖ policies can be defined to handle
spillover traffic or all traffic in the event of total application failure—all managed from Level 3‘s easy-to-use,
secure portal for near-instant implementation.
Additionally, users can specify precisely how end-user traffic is directed to applications (HTTP, FTP, etc.)
at your data centers and servers. ITM can send a given percentage of traffic to each of your servers (for
global load balancing), send end users to the best server for that end user (avoiding unreliable or
unreachable servers), and gracefully send traffic to secondary servers or a third party content delivery
network (such as the Level 3 CDN) during overwhelming flash crowds. All of these abilities are easily and
swiftly configured through a secure, web interface and no hardware is required at your sites - you simply
subscribe to the ITM service.
Typical DNS configurations provide a static set of five or fewer authoritative name servers returning, for
example, two IP addresses in round-robin fashion for your two web servers. ITM provides more reliable
and lower latency name resolution than these standard configurations because ITM has many more name
servers. The loss of connectivity to any one name server affects fewer end users, and ITM name servers
are closer, in a network proximity sense, to end users because of their redundant, global presence –
providing better service to end-user at any given time.
Page 12
End User
End User
End User
End User
ITM Server
ITM Server
ITM Server
Europe Traffic
US Traffic
50%
application
NY
30%
20%
application
LA
80%
application
DC
application
UK
overflow
20%
application
FR
overflow
Level 3 CDN
Figure 3: Example of ITM Routing of Traffic
Typical Flow of a Client URL Request
When the client's browser makes a request for a resource, the following sequence of events occurs:
1. The browser first queries its DNS resolver for a subscriber domain name.
2. The DNS resolver queries a nearby ITM name server for the domain name.
3. The ITM name server follows the subscriber‘s specified policies to return the appropriate subscriber
IP address to the end user‘s DNS resolver.
4. The DNS resolver passes the information on to the browser.
5. The end user communicates with the best subscriber server, according to the customer-selected
policies.
Page 13
Figure 4: ITM Request Flow
Available ITM Configuration Options
Automatic Failover Configuration
ITM name resolution decisions are based on the availability of the customer server, as determined
independently by the global network of ITM name servers. If any of these servers are unavailable, ITM
does not return their associated IP address until the server starts responding again. Meanwhile, traffic is
sent to the designated alternate servers.
GeoIntelligence Configuration
ITM name resolution decisions are based on the IP address of the end user's resolver. The mapping, from
IP address to geographic region, allows rules based on the continent, country, US state, or time zone of the
resolver IP address.
For example, traffic can be split between customer datacenters in North America and Europe, based on the
location of the end user. If the end user‘s IP address is within North America, the request may be directed
to the North America origin servers (San Jose, for example); otherwise, the request is directed to European
origin servers (London, for example).
Page 14
Global Load Balancing Configuration
ITM name resolution decisions are based on customer-specified ratios of traffic sent to each server.
Typically the ratios are chosen to reflect the capacity at each server.
For example, if a server in San Francisco can handle twice the traffic of the San Jose server, ITM can
direct two-thirds of the traffic to San Francisco.
ITM can dynamically update the ratio by polling the server‘s load at a set location.
Customizable Configuration
More complex traffic management schemes can be implemented as well. See your sales engineer for a
more in-depth discussion.
Page 15
Origin Storage Overview
Level 3 Origin Storage service is the secure and affordable storage and management solution for your
Internet content. And because our storage solution is connected directly to our Content Delivery Network
(CDN), you have peace of mind that your content is delivered to your end-users when they request it. We
have designed our storage systems to provide the highest level of protection for your content and
availability for Level 3 HTTP Delivery or Level 3 Streaming services.
Features
•
Origin Offload: Upload content to Level 3‘s Origin Storage which then feeds the CDN edge delivery
network without overloading the customer‘s infrastructure. This option is particularly useful for
customers with a set of popular content and an interest in outsourcing their origin infrastructure. By
combining multiple, geographically diverse locations with redundant high-speed connectivity to our
industry-leading CDN, latency is minimized
•
In-Depth Reporting: The Level 3 Portal provides access to view daily storage usage and peak storage
amounts over time. Depending on the configuration of the customer, the portal can also provide storage
usage for ―child accounts‖ so that usage for these accounts can be tracked and billed appropriately
End
User
Customer
ITM
F1
Content
Delivery
Level3
Edgeserver
Content Management:
myco.ingest.level3.com
Level3
Parent
Servers
Level3
Parent
Servers
Content Replication
(Primary to Secondary)
F1
Level3 ―Primary‖
Origin Storage
F1
Level 3 ―Secondary‖
Origin Storage
Figure 5: Origin Storage Overview
Value Add Capabilities
The Origin Storage platform is built on several important features including the following:
•
Engineered for Security and Fault Tolerance: Highly-Availability Hardware, redundant storage servers
in every location, RAID, mirroring, redundant network interfaces and paths to the Internet, multiple
Page 16
power supplies for every piece of hardware, spare disks at every location and the latest firewall
technology all combine to provide a 100 percent SLA guarantees on content protection
•
Massively Scalable Storage Capacity: Over 1 PB of global storage provides the scalability necessary
for the largest content libraries today. Level 3 has Origin Storage space ready when you need it
•
Flexible Asset Management: Standard methods of content upload and management include FTP,
Secure FTP, FTP-S, SCP, and RSYNC command sets
•
Origin Offload with Global Coverage: Our Origin Storage super nodes are strategically positioned
around the world and directly attached to dedicated serving clusters and the Level 3 Network through
high-speed connections
•
High Availability Content: Content is automatically copied and stored in multiple locations. As soon as a
piece of content is uploaded to a single location, it is available to the CDN
Page 17
Major Services Operations
On-Demand Streaming Operations
Overview
Level 3‘s On-Demand streaming platform also enables content to be pulled into its CDN network from
Level 3‘s own internal Origin Storage Platform, as well as any external origin storage sources.
Level 3‘s CDN actively pulls the content into its content delivery platform from an origin storage source
(such as an HTTP or HTTPS Web server) when content requests are made.
1. The end user requests an On-Demand streaming asset via a customer-specific hostname. End users
are directed to the best performing edgeserver on the Level 3 Network for that particular user.
2. The edgeserver determines if it has the content; if it does, it immediately streams the content. If the
Level 3 edgeserver does not have the asset requested, the server fetches the content from either the
customer‘s web server or the Level 3 Origin Storage repository and populates the edge cache.
3. The Level 3 edgeserver streams the content.
End User
Request
HTTP Get Request
Get http://origin.example.com/video.wmv
3
Customer
Web Server
1
2
HTTP Get from Origin Storage
Get http://example.level3.com/video.wmv
Level3
Streaming
Network
Level 3
Origin
Storage
Figure 6: How On-Demand Streaming Works
Delivering Content thru the On-Demand Streaming platform
Delivering on-demand content through Level 3‘s CDN requires that end users be provided with the URI
path that leads them to the Level 3 edgeservers.
Creating URLs for On-Demand Streams
On-Demand stream links can be created using a simple construct:
Protocol://Hostname/Level 3_SubscriberID/ContentLocation/Filename
Page 18
Protocol is the protocol used in delivering content, which is typically associated with the format type of
the content, such as: (1) mms and rtsp for Windows Media; and (2) rtmp, rtmpe, and rtmpt for Flash.
Hostname can be an external or generated from a Level 3 sub-domain (e.g., f35.c.footprint.net).
Level 3 assigns two separate hostnames to direct the end user to the best performing edgeserver on the
Level 3 Network for that particular user.
Level 3_SusbcriberID is a unique billing identifier provided by Level 3 and used for reporting and
billing purposes.
ContentLocation is location where the file is located on a customer HTTP web server and must be used
in the constructed streaming URI as it tells the edgeserver which folder to retrieve the content file from. If
the content is located in the root directory, there should not be any path in the streaming URL.
Filename is the name of the streaming asset that is to be played.
Since any Hostname and ContentLocation can be embedded to access content from an external
source, Level 3 may not have the content in its local storage, so a path is needed to get to the content from
the external source.
It‘s not necessary to embed the origin Hostname in the URL as that information is contained in Level 3‘s
streaming configuration. If the edgeserver does not have the content, Level 3 fetches the content from the
external origin web server using the DirectoryPath provided in the end-user URL.
Windows example
rtsp://xyzmedia.fplive.net/xyzmedia/sampleVideo.wmv
Adobe Flash example
rtmp://xyzmedia.f35.c.footprint.net/xyzmedia/rtmp/sampleVideo.flv
rtmpe://xyzmedia.f35.c.footprint.net/xyzmedia/rtmpe/sampleVideo.flv
NOTE: For Flash On-Demand content, /rtmp and /rtmpe folders should be created within the directory
from where the content files are being managed from, as implied above.
A vanity Hostname can be used (e.g., video.example.com) via a CNAME delegation:
rtsp://video.example.com/xyzmedia/sampleVideo.wmv
And it might forward to:
http://origin.example.com/xyzmedia/sampleVideo.wmv
See the Streaming Features section for more details.
Removing Content from the On-Demand Streaming Platform
Deleting files from the cache can be accomplished by:
•
Applying cache control headers as a means to control when content should be expired off of the
streaming platform. The edgeservers honor cache control header values as long as they are delineated
in seconds. If no cache control header values are present, Level 3 applies a cache control header of 1
week
•
Submitting a request through Level 3‘s Media Portal to invalidate the CDN of particular content
•
Submitting a request to Level 3‘s customer support team to delete particular content files from the
platform
Page 19
Live Streaming Operations
Getting Live broadcasts into the Live Streaming Platform
Level 3‘s Live Streaming platform provides support for both Microsoft‘s Windows Media and Adobe Flash
formats. Although Level 3 can provide signal acquisition and encoding services through Level 3 Vyvx
services as part of a larger holistic solution, the scope of this chapter deals strictly with the CDN live
streaming services capability.
Windows Media
Currently, Live WMS signal acquisition is done only via a pull model from encoders that output live streams
supporting the Windows Media format and protocols. This necessitates Level 3 having direct access to the
WME machine over the Internet. This includes access through any firewall to actively pull the live stream
onto Level 3‘s CDN.
In order to foster a secured environment, Level 3 can provide the IP addresses of its publishing points in
order to restrict access.
How a “pull” of Windows Media live stream works in Level 3’s CDN
Level 3 Secondary
Publishing Point
End User
Request
Customer
Encoder
Backup
Stream
1
4
2
3
Edgeserver subscribes to live feed
Level3 CDN
Level 3 Primary
Publishing Point
Figure 7: Windows Media – Live "Pull" Workflow
1. Level 3 Acquires Live Signal Feed. Level 3 must initiate the live stream pull from the Windows
Media Encoder via a publicly accessible IP address by way of a primary Publishing Point server. In
the case where a backup stream is used, Level 3 also pulls the stream from an alternate location.
Level 3 strongly recommends the use of a backup encoder and stream source to mitigate possible
issues with the signal acquisition. Level 3 provides a streaming link where end users are able to
access the stream through the CDN.
2. End User Requests Live Stream. When an end user clicks on the Level 3 stream link, the end user
is directed to the best performing Level 3 edgeserver for that particular end user to receive that
stream.
Page 20
3. Level 3 Streaming Server Subscribes to Live Feed. If the Level 3 edgeserver is not already
subscribed to the live feed, it reaches out to the Level 3 Primary and/or Secondary Publishing Point.
4. Deliver Live Stream. Once the edgeserver has subscribed to the live feed, the edgeserver delivers
the stream to the end user via the requested stream protocol. The streaming server automatically
cycles through the various protocols until it is able to negotiate a protocol acceptable to the client.
Adobe Flash
Live FMS signal acquisition can be done via:
•
―Pull‖ model in which a live Flash stream is pulled onto Level 3‘s publishing points from an external
Flash Media Server
•
―Push‖ model in which live Flash streams are push to Level 3‘s publishing points from external
encoders that output live streams supporting the Flash media format and protocols
“Pull” of a Flash live stream (Multipoint Publishing)
Pulling live FMS streams onto Level 3‘s edgeservers from external Flash Media Servers is also known as
Multipoint Publishing. Under this scenario, the Flash Media Server is used as a local Flash Publishing
Point.
For this ―pull‖ model, Level 3 must have direct access to the external Flash Media Server over the Internet.
This includes access through any firewall to actively pull the live stream onto Level 3‘s CDN.
While specific server-side code cannot be deployed onto the Level 3‘s Flash Media Servers nor data
messages injected into an outbound stream, Multipoint Publishing enables custom information to be
inserted into a live Flash data feed, such as ads, tracking beacons, or SWF interactivity.
How a “pull” of live Flash streams works in Level 3’s CDN
Customer
or Level3
Backup
Flash
Media
Encoder
1
2
Level 3
Secondary
Publishing
Point
End User
Request
Customer
or Level3
Flash
Media
Encoder
Backup
Stream
5
3
4
Level3 CDN
2
Level3
Publishing
Point
Figure 8: One Possible Set Up for Live Flash Media (Multipoint Publishing)
Page 21
1. Live feeds are encoded to Flash format. The live signal feed is encoded by a Flash-based encoder
and then directed to Flash Media Servers outside of Level 3‘s CDN. It is highly recommended for
customers that a backup encoder also be used.
2. Level 3 Acquires the Live Stream. Level 3‘s Publishing Point Servers acquire the live Flash stream
by initiating a pull from the external Flash Media Servers. Where there is a primary and a backup
feed, Level 3 uses disparate server locations to ensure diversity. Level 3 provides a URL that can be
embedded into a SWF file from which end users retrieve the live stream feed from the Level 3‘s CDN.
3. End User Requests Live Flash Stream. End users are directed to the closest available Level 3
edge Flash streaming server by way of the Level 3 provided stream link.
4. Level 3 Flash Server Subscribes to Live Feed. The Level 3 edgeserver subscribes to the Level 3
FMS Publishing Point server used to acquire the live signal feed. If the edgeserver is already
subscribed to the live feed, it does not have to re-subscribe to the live feed.
5. Deliver the Live Flash Stream. Once Level 3‘s Flash edgeservers receive enough information to fill
its buffer, it in turn begins playback to the end user through the Flash player on their computer.
“Push” of a Flash live stream (Encoder Publishing)
Level 3 supports the ability to ―push‖ live streams from a Flash based encoder directly to Level 3 Flash
Media Servers (Publishing Points) without the need for external/intermediate Flash Media Servers. In this
―push‖ model – metadata can only be injected in the live Flash streams via the encoder.
How a “push” of Flash live streams works in Level 3’s CDN
Figure 9: Flash Media – Live “Push” Workflow
Page 22
1. The encoded live stream is pushed to Level 3’s Flash Publishing Point. The encoded live stream
is pushed from the Flash encoder to a Level 3 Flash Publishing Point. Level 3 provides a URL that
can be embedded into the Flash player distributed to end users.
2. End User Requests Live Flash Stream. End users are directed to the closest available Level 3
edge Flash streaming server by way of the provided Level 3 stream link.
3. Level 3 Flash Server Subscribes to Live Feed. The Level 3 edge Flash Media Server subscribes to
the Level 3 FMS Publishing Point server used to acquire the live signal feed. If the edgeserver is
already subscribed to the live feed, it does not have to re-subscribe to the live feed.
4. Deliver the Live Flash Stream. Once the Level 3 Flash edgeserver receives enough information to
fill its buffer, it in turn begins playback to the end user within the Flash player on their computer.
Delivering Live broadcasts through the Live Streaming platform
Delivering live streams through Level 3‘s CDN requires that end users be provided with the URI path that
leads them to the Level 3 media servers.
Creating URL’s for Live Streams
Live stream links can be created using a simple construct as follows:
Protocol://Hostname/Level 3_SubscriberID/StreamFolder/StreamName
NOTE: For Flash Live streams, /rtmp and /rtmpe folders should be created within the directory from
where these lives streams are being managed from, as indicated above.
the content, such as: (1) mms and rtsp for Windows Media; (2) rtmp and rtmpe for Flash; and (3) http
for QuickTime and MS-Siliverlight, and so forth.
Hostname can be an external or Level 3 generated sub-domain from the f35.c.footprint.net
domain. When using both Windows Media and Flash, Level 3 will assigns two separate hostnames, which
are used to direct end user to the closest streaming media server from which to be served content.
billing purposes.
StreamFolder is the name of the folder from which live streams are managed.
StreamName is the name of the stream carrying a specific live feed. StreamName is typically bound to a
specific (ingress) Publishing Point.
Windows example
mms://xyzmedia.fplive.net/xyzmedia/liveStreams/livestream01
Adobe Flash example
rtmp://xyzmedia.f35.c.footprint.net/xyzmedia/rtmp/liveStreams/livestream02
rtmpe://xyzmedia.f35.c.footprint.net/xyzmedia/rtmpe/liveStreams/livestream03
Using URLs for On-Demand and Live Streaming
The following description provides an outline of the different popular media technologies that can be used
to integrate streaming links within the context of a web (portal) site.
Windows Media – Stand Alone Player
Windows Media Player can directly play back Level 3 streaming links. Most often, this is achieved using an
Advanced Stream Redirector (ASX) file. See Appendix A: for more details on ASX files.
Page 23
Using ASX files provides some flexibility in terms of the end user experience. Not only can the media file
and location be specified, but also delayed start/end times can be defined as well as the creation of library
play lists and banner links.
What is the end user experience like?
When an end user clicks on an ASX file, it triggers the browser to launch the media player associated with
the file extension type. Most often, this is the Windows Media Player. When the stream link is played back
with the external media player, end users are not bound to a specific Web page; however, the ability to
customize the player experience/appearance is no longer available.
Windows Media – Embedding Links
Another popular option for using streaming links is to directly embed the mms or rtsp link into an HTML
Web page. Using this method of playback requires that end users‘ web browsers be provided with helper
code so that the web browser knows what type of media player should be used to play back the file.
What is the end user experience like?
When an end user clicks on an embedded stream link, the end user‘s browser launches a browser helper
object that launches an embedded Windows Media Player. Some implementations prefer using embedded
streaming links as it necessitates the end user to stay on a designated web page in order to continue to
view the asset. If the end user navigates away from the web page, the stream stops playing, unlike a
stream link that is played directly in an external player. Other reasons to embed a stream link are to gain
greater control of the end user experience (such as customizing the player skin) and control over what
Media Player attributes are available to the end user.
Adobe Flash
Adobe‘s Flash Media Server works much like other media services, allowing a user to connect and play a
video. One key difference is how the end user connects. With services like Windows Media, a player is
usually available on the end user's computer (i.e., Windows Media Player); however, for Flash a default
player does not exist. To solve this deficiency, companies delivering Flash content to their end users
usually provide a player embedded in a web page. This typically requires end users to download a Flash
plug-in to allow their web browser to play Flash files, such as content files with the .FLV or .SWF extension.
The Adobe's site contains a useful Flash video guide:
http://www.adobe.com/devnet/flash/articles/video_guide_02.html
While Level 3 currently does not provide a default Flash player, several stand-alone players on the market
can be utilized to test Flash streams, such as Applian Technologies‘ Applian FLV Player (or the GNU
Gnash project (. Level 3 makes no warranties and no endorsement on any specific FLV player technology.
Adobe Flash Helper Directives – Format Type
Level 3‘s Flash Media service assumes that a streamed Flash file is in some form of an .flv file;
therefore, it is not necessary to specify the .flv format type in the stream path if the asset is an .flv file
type.
However, depending on how a Flash player is developed, the .flv file extension may need to be denoted,
but the streaming URL does not need to include an .flv helper directive.
When dealing with H.264 encoded (.mp4 and its variants) or .mp3 content, it is necessary tell the Flash
Media Server that it is dealing with a content item other than an .flv supported file. Thus, it is necessary
to insert a helper file in the URI path immediately before the file asset name.
In the case of Multipoint Publishing for Live streaming, the helper file is not considered part of the origin
path and is extrapolated at the edge Flash Media Server before any backhand pass to an encoder or a
Flash Media Server, so it is not necessary to modify the actual file asset name or directory structure.
The helper directives are expressed in any one of the following supported file formats: .flv, .mp3, or
.mp4.
Page 24
Again, the default format if unspecified is .flv so it‘s not necessary to include the .flv file extension in
the URI path.
Below are examples of the application of the helper directive inserted before the file name for the streaming
URL submitted into the SWF container:
On-Demand Streaming Examples
rtmp://xyzmedia.f35.c.footprint.net/xyzmedia/rtmp/mp4:sampleSDvideo.mov
rtmp//xyzmedia.f35.c.footprint.net/xyzmedia/rtmp/mp4:sampleHDvideo.mp4
rtmpe://xyzmedia.f35.c.footprint.net/xyzmedia/rtmpe/mp3:sampleAudio.mp3
Live Streaming Examples
rtmp://xyzmedia.f35.c.footprint.net/xyzmedia/liveStreams/mp4:sampleSDFeed.mov
rtmp://xyzmedia.f35.c.footprint.net/xyzmedia/liveStreams/mp4:sampleHDFeed.mp4
rtmp://xyzmedia.f35.c.footprint.net/xyzmedia/liveStreams/mp3:sampleAudio.mp3
It is a best practice to have the file extension and file type directive in the URL. This is to ensure the CDN
platform knows which asset to retrieve from the publishing point server for streaming assets with the same
name.
The request to the publishing point makes use the of file extension listed in the URL. If there is a format
type directive listed but no file extension, the edge Flash Media Server assumes that the file extension is
that of the helper directive in the URL path. If the format type directive is not present and your content is
H.264 encoded or .mp3 encoded, the file may fail to play.
Typically, the flash streaming file would be embedded within an Action Script. Below is a basic sample
Action Script illustrating how the Level 3 On-Demand Flash stream links would be incorporated into a Flash
player.
1.
2.
3.
4.
5.
var nc:NetConnection = new NetConnection();
nc.connect("rtmp://xyzmedia.f35.c.footprint.net/xyzmedia/liveStreams");
var ns:NetStream = new NetStream(nc);
myVideo.attachVideo(ns);
ns.play("liveStreamName.flv");
Using an embedded Flash player
Another common way to leverage a Flash stream is through an embedded player within an HTML page.
Calling the external RTMP stream can be accomplished by leveraging the flashvars parameter where
the RTMP link is passed in as a parameter to the SWF player.
The following describes how to incorporate a Level 3 Flash streaming link into an embedded player using
an embedded object call.
Calling an external stream object into an embedded object call requires three key elements:
1. SWF player
2. Location of live .flv file
3. The .flv live stream file name
SWF Player
Level 3 does not provide a Flash player. The customer must provide their own flash player/container. As
the SWF player is an HTTP binary, the delivery of the player is not inherently included in the Level 3 Flash
streaming service. If you need assistance in obtaining a Flash player, please contact your Level 3 Sales
Engineer. The player can be delivered via the Level 3 caching service under a separate contract. To call
the player, the source path must be provided. The URL may be a relative link to the base page, or it may
be the fully qualified URL.
Page 25
Location of the FLV File
The .flv file location is the RTMP link that is comprised of the Level 3 streaming hostname as well as any
directory path information leading up to the file. It is not necessary to include the trailing slash in the path
parameters. Most SFW players automatically add the trailing slash.
FLV File Name
The .flv file name is the name of the asset that is to be called by the player. The file name should not
include the .flv extension name.
Sample Embedded Flash Player Code
<html>
<head></head>
<title>Level 3 RTMP Streaming Test</title>
<body>
<embed src="http://www.jeroenwijering.com/embed/mediaplayer.swf"
width="320"
height="260"
allowscriptaccess="always"
allowfullscreen="true"
flashvars="height=260&width=320&file=rtmp://xyzmedia.f35.c.footprint.net/xyzmed
ia/liveStreams&id=liveStreamName"/>
</body>
</html>
In the example above, the three critical components are as follows:
src (Flash Player):
http://www.jeroenwijering.com/embed/mediaplayer.swf
file (Location):
rtmp://xyzmedia.f35.c.footprint.net/xyzmedia/liveStreams
id:
liveStreamName
The sample embedded Flash code above referencing the JW FLV Media Player is only for demonstration
purposes and is neither an endorsement nor should be considered a commercial license to use the Jeroen
Wijering player. See Jeroen Wijering (JW) FLV Media Player.
Vanity Streaming Hostnames
Through ITM and BDS (see below), Level 3 uses DNS to provide global load-balancing across the CDN.
These DNS-based systems make real-time decisions on which available streaming server is the best for a
particular end user, including the Level 3 streaming hostnames. Because of the DNS CNAME abstraction
from using actual IP addresses, Level 3 can efficiency add and remove streaming servers into the platform
without the customer having to make any modifications to their streaming links.
Some customers may want to obfuscate Level 3‘s delivering their streams. In such instances, customers
can create their own vanity streaming hostnames and then CNAME that customer hostname to the Level 3
provided hostname. For example:
video.example.com CNAME 1d examplewms.fplive.net
When using a vanity hostname, the customer still needs to use the Content_Location directory path
when constructing their URIs; however, the double CNAME effectively hides Level 3‘s delivery of the
streams. The media player only displays the customer‘s vanity hostname and not display the CNAMEd
hostname to *.fplive.net back to the media player.
Page 26
NOTE: if an end user were to query the vanity hostname using DIG, the fplive.net domain is returned in the
answer as the name server chases the CNAME in order to return an answer to the end user. Level 3
recommends that customers using their own vanity hostnames use a TTL in their DNS entry of at least 1
day to minimize DNS lookup times for the end user.
Page 27
Caching Operations
Caching Basics and Terminology
In order to put a website, application, or object-delivering hostname on the Level 3 network, a customer
should have:
1. A Supername – The Supername is a special designated customer hostname that the customer uses
to direct traffic to the Level 3 CDN, e.g., cdn.example.com, www.example.com.
2. An origin server – The origin server refers to the web servers which host content to be delivered
through the CDN. The customer can use his own servers or use Level 3 Origin Storage. Resources
are retrieved from the origin using an on-demand pull mechanism by the edgeservers to fill the cache
and respond to requests. In order to contact the origin, the CDN needs to know the origin hostname,
port, and protocol, e.g., HTTP.
3. A customer account and configuration – The CDN uses the configuration to determine how to
deliver the content, how long content is fresh, which origin server to use, etc. Registering the
Supername in the system allows the CDN to accept end user requests for content.
The customer account must include at least one CDN Property configured on the network. The property is
the specific identifier within the Level 3 CDN network. Each property has a unique identifier (Property ID)
and specifies:
•
The hostname of the origin (fully-qualified domain name)
•
The port number used by the origin
•
The Host: header value to use when contacting the origin
•
The protocol used by the origin (HTTP, HTTPS, or FTP)
•
The Supername(s) used to retrieve the content from the CDN
The property is the basic building block for content delivery policy. Content is stored in cache on a per
property basis.
It is possible to have multiple properties defined for each origin. Doing so allows the same content from the
same physical origin servers to be served in different ways, using different configuration settings, and
allows real-time reports of bandwidth served on behalf of the origin server to be reported on a more
granular level.
Configuring Customer Hostnames
The Level 3 CDN works through DNS to direct end user requests for customer properties onto its CDN.
The CDN uses a method, DNS Rendezvous, to direct these requests to the best content server in the
Level 3 CDN network through the use of previously created domain name server (DNS) entries. To provide
the optimal response to each end user, DNS Rendezvous uses the Best Distributor Selection (BDS)
algorithm to select the best-performing edgeserver for delivery of the customer's content to that specific
end user. The Level 3 name server that receives the DNS query weighs in factors such as relative load on
the CDN servers, network distance, and overall state of the Internet to determine the best edgeserver to
serve a client's request.
To implement this, typically, a CDN Supername is configured in a customer's DNS as a CNAME record
pointing to a canonical name assigned to the customer in the *.c.footprint.net namespace controlled by
Level 3 name servers. This canonical name is typically referred to simply as the "CNAME‖. The standard
CNAME format is cdn.<customer-name>.com.c.footprint.net. (Other Level 3 subdomains and domains may
be used for different services.) This might appear in a dig or nslookup as:
cdn.example.com.
86400 IN
CNAME cdn.example.com.c.footprint.net.
Page 28
During normal operations, the use of the CNAME is completely transparent to the end user. The browser
only has to use the Supername because the CNAME is hidden.
Each Supername must be registered on the network with the appropriate origin server, which enables it to
deliver traffic, even if it just points to an existing CNAME. If a customer were to CNAME one of their
hostnames to Level 3 (directly or indirectly) without the appropriate configuration, the Level 3 CDN would
not be able to deliver the traffic. The CDN is not able to recognize the value of the Host: header on an
incoming request as a valid Supername, resulting in a 404 error being sent to the end user.
A Supername uniquely identifies a property; however, a property may have multiple CDN Supernames
associated with it. When a property has multiple Supernames, one of them carries special meaning and is
being referred to as the Primary Alias. All other Supernames are referred to as Secondary Aliases. The
most important function of the Primary Alias is being part of the cache key – i.e. resources are stored in
cache under the Primary Alias, this prevents double caching. Also, the Primary Alias is used to represent
the property in the Media Portal. Customers may select which Supername they want to see as their
Primary Alias when the property is being configured. It is not recommended to change the Primary Alias
after a property starts delivering production traffic. Any changes to the Primary Alias have the same effect
as an invalidation for all cached content for the property because the cache key is built from the Primary
Alias.
Extended Aliases
There are 2 different styles of CDN Supernames:
1. The Simple Alias style Supername is just a FQDN, i.e., a hostname, such as "cdn.example.com".
2. The Extended Alias style Supername is a hostname followed by the first directory element of the
path of a URL, such as "cdn.example.com/dir".
With the Extended Alias style, the entire string "cdn.example.com/dir" is used to lookup the Property and
therefore must be unique across the network. Both Primary and Secondary Aliases can use the Extended
Alias style. The benefits of Extended Aliases include:
•
Facilitation of content retrieval from more than one origin server using the same client-facing hostname.
This lets web publishers bypass sandbox security issues with Java and Flash applets that would
normally be restricted to a single hostname. By using Extended Aliases, such applications may retrieve
data from as many origin servers as required
•
Allowing multiple organizations, departments, or reseller end-customers to utilize the same domain
name but define multiple properties and potentially different CDN configuration profiles (such as
different expiration policies) with a single CNAME record in their DNS. This saves time and simplifies
integration
•
Subdividing a site‘s content, so that different divisions, which all post content on the same server, can
be considered individual origin servers and provided individual traffic reports
When performing a cache fill, the first directory element (part of the Extended Alias) is removed from the
incoming URI path on the request before contacting the origin server. Similarly, the URL is logged and
reported without that element, for example:
Given the Extended Alias: "cdn.example.com/abc"
The request to the CDN would be: http://cdn.example.com/abc/logo.gif
The corresponding request to the origin would be: http://origin.example.com/logo.gif
In order to issue an invalidation, the customer must remember to remove the first directory element (now
part of the Extended Alias) from the path and invalidate using the same path used to fill the resource in
cache.
Extended Aliases Example
The following example illustrates how extended aliases work.
Page 29
End User
Requests
cdn.example.com CNAME cdn.example.com.c.footprint.net
cdn.example.com/pix/image.jpg
Configuration Set 1
Primary Alias (Supername) = cdn.example.com
Origin Hostname = origin.example.com
Edge Request: http://cdn.example.com/pix/image.jpg
Origin Request: http://origin.example.com/pix/image.jpg
cdn.example.com/dept1/image.jpg
Configuration Set 2
Primary Alias (Supername) = abc.example.com
Extended Alias = cdn.example.com/dept1/
Origin Hostname = origin.example.com
Max-Age: 5 minutes
Edge Request: http://cdn.example.com/dept1/image.jpg
Origin Request: http://origin.example.com/image.jpg
cdn.example.com/dept1/image.jpg
Configuration Set 3
Primary Alias (Supername) = xyz.example.com
Extended Alias = cdn.example.com/dept2/
Origin Hostname = origin2.example.com
Edge Request: http://cdn.example.com/dept2/image.jpg
Origin Request: http://origin2.example.com/image.jpg
origin2.example.com origin.example.com
Figure 10: Extended Aliases
Here are some examples of the use of Extended Aliases:
1. A request is received for the resource http://cdn.example.com/pix/image.jpg. The request‘s Host:
header matches the supername, and the directory ―pix” is not an extended alias in any Configuration
Set. Therefore, the edgeserver applies Configuration Set 1.
2. The end user makes a similar request to the one above, but the path includes the directory ―dept1‖.
Since ―cdn.example.com/dept1/” has been defined as an Extended Alias for Configuration Set 2, the
request is sent to the origin defined for this Configuration without the ―/dept1/‖ directory in the path.
However, since the Configuration Set definition specifies a Max-age, or Time-To-Live in cache of five
minutes before being considered expired, the edgeserver uses this setting for the resource when it is
cached. Since the Extended Alias was used, the Configuration Set primary alias, or supername, could
be any valid hostname (in this case abc.example.com).
3. The end user makes a similar request to the one above, but the path includes the directory ―dept2‖.
Since ―cdn.example.com/dept2/” has been defined as an Extended Alias for Configuration Set 3, the
request for ―cdn.example.com/dept2/image.jpg” is sent to the host ―origin2.example.com”. Again, any
valid hostname could be used as the Primary Alias (xyz.example.com in this case).
How Caching Service Works
The ―5 R‘s‖ provide an easy-to-remember flow of the CDN processing required to fulfill a client request and
are used here to help visualize the procedure.
Page 30
Figure 11: Request Processing – “5 R’s” Overview
The steps are detailed below and include determination of the optimal Content Delivery Server, routing of
the client request to that cache, application of caching and security rules, retrieval of the resource if not
cached, and ultimate delivery to the requestor.
Rendezvous
Request
Rules
Retrieval
Response
Client
Rendezvous
Suppose a client wants to download a resource http://cdn.example.com/images/logo.gif:
Page 31
1
Request to resolve
cdn.example.com
BDS Server resolves
cdn.example.com.c.footprint.net
2
Level 3 Caching and
Streaming CDN
Customer Origin Server
www.example.com
Figure 12: DNS Rendezvous Steps
1. The browser requests the resource using CDN Supername cdn.example.com. During
implementation, the Supername has been setup in customer‘s DNS to direct requests to Level 3 CDN
and points to cdn.example.com.c.footprint.net. The Level 3 name servers resolve that CNAME and
return the IP address of the most optimal CDN cluster to handle the request.
2. The browser sends the request to the selected CDN cluster where it is assigned to an available
server.
Rendezvous
Request
Rules
Retrieval
Response
Client
Request
When a request is received at the CDN cluster, it is assigned to an appropriate server with available
capacity.
In order to determine the appropriate processing options, the CDN server examines the value of the Host:
header "cdn.example.com" on incoming request and determine if it matches a registered Supername that
belongs to an active CDN Property. If a direct match cannot be found, the edgeserver proceeds to check if
the hostname plus top-level folder combination matches a known Extended Alias style Supername. If no
match is found, the edgeserver returns a 404 (Not Found) HTTP status code to the end user.
Page 32
Rendezvous
Request
Rules
Retrieval
Response
Client
Configuration Rules
Once the Property is found, the edgeserver determines if a usable copy of the resource is present in cache
and identifies configured caching and security features. Caching options may be assigned for groups or
types of resources, as well as by resource name. Access control may additionally be based upon
characteristics like the IP address or country from which the request was received, or value of the HTTP
Referer: or an arbitrary request header.
Among the most powerful of the CDN functions is the Level 3 RuleBase. This facility provides resourcelevel specification of processing, caching, expiration, header manipulation, security, delivery, and logging
options.
Options are assigned by matching the resource requested against filters specified for RuleBase flags.
Flags are the configuration settings, which control various forms of special resource handling modes.
The combination of one or more flags with one or more filters comprises a Rule, which applies the value or
attribute of the flag to resources matching the filter. The rules are processed when resource gets filled and
revalidated.
The list of available RuleBase filters includes Property ID filter, path filters, MIME type filter, HTTP header
filters, etc. Certain rules can only be applied after response from the Origin Server is received (for example,
MIME type or HTTP Status matching rules). For that reason the RuleBase is divided into two parts:
Request RuleBase and Response RuleBase
First, CDN server evaluates URI path and HTTP headers from the request and applies the Request portion
of the RuleBase, then Retrieval processing is initiated. When a cache-fill is completed, the Response
RuleBase is applied.
Rendezvous
Request
Rules
Retrieval
Response
Client
Retrieval
Prior to contacting the origin, the edgeserver checks if a usable copy of the resource is available from a
nearby peer. Local peering is automatically implemented for all caching configurations. This enables filling
cached object requests from other CDN servers, which leads to increased cache hit rates and enhanced
performance. Cache Hierarchy (Tiered Distribution) is optional and highly dependent upon customer
requirements.
If the resource is not cached and not available from a peer cache, the complete URL, including any query
string and all HTTP request headers received from the client are forwarded to the origin server using the
hostname, port, protocol and other attributes specified in the Property definition. Additionally, request
headers may be added to the cache fill request via RuleBase.
If Pre-Authentication is enabled for the Property, successful validation from an Alternative Authentication
Server is required before the cache fill request is sent to the origin server.
Page 33
Rendezvous
Request
Rules
Retrieval
Response
Client
Response
The edgeserver response to a client request contains the object, if available and authorized, and a status
code indicating success, redirection, or the nature of a failure. Normally, the HTTP status code received
from the origin server is passed on to the end user; however, it is possible to for the CDN server to
generate a different status code to indicate successful delivery from cache, an error generated by a
RuleBase flag, or failure of CDN-based authentication, including Geographic Blocking, Referer: Blocking,
URL Token Authentication, or Arbitrary Header Blocking.
Optionally, arbitrary response headers may be added or customer-specified status codes may be issued
for successful resource deliveries or access denials.
Downstream cache control headers may also be set or altered by utilizing the CCHOMode feature. (See
the Cache-Control-Header-Override Mode (CCHOMode) section.)
Page 34
Origin Storage Operations
Uploading Content and Removing Content
Each customer is assigned a primary upload site, either in North America (Los Angeles and New York) or
in European (London and Frankfurt). This site serves as the upload location and the primary serving origin
to the CDN for that customer‘s content. Generally speaking, this location is chosen by the integration team
and the customer, based on the geographic location of the customer‘s content library.
Once content is uploaded to a Level 3 Origin Storage site, it is automatically replicated to the other site
within that region – that is, between New York and Los Angeles, or between Frankfurt and London. Content
is not automatically replicated between the regions, however. For customers that require their content to be
stored in both Level 3 regions, customers upload their content into one location in each region.
As stated above, to achieve added redundancy and performance, all content is replicated automatically to
the secondary site in a particular region. If a specific piece of content is not available at a CDN edge
location (the content is not already cached), then the request for that particular piece of content is
requested from one of the Origin Storage locations. Should the content not be available at the primary
origin location, the request is redirected by ITM to the secondary Level 3 origin location within the region
before redirecting requests back to the customer‘s origin, depending on the customer‘s specific
configuration.
Several different methods of uploading files to Origin Storage are supported:
•
FTP / FTPS – These are interactive TCP-based FTP protocol sessions connecting over ports 20 and 21
for both FTP and FTPS (over SSL). The use of passive FTP is also supported
•
SFTP – this allows customers to place content using non-interactive SSH-based encryption.
Connections are established by placing a shared-key on the Level 3 OSP generated by the customer or
by password-based authentication. This rides over port 22 in a non-interactive mode (for customers)
•
SCP – this mechanism also uses traditional SSH-based file transfer. This is also non-interactive and
uses key pairs or password-based authentication
•
Rsync – customers can also choose to ingest and synchronize their libraries with the OSP by using an
rsync client and connecting on periodic intervals to push any new or changed files. The underlying
transport protocol is SSH-based and uses both key pair and password-based authentication
Content can be removed from Origin Storage via the same methods available for upload, i.e., FTP, SFTP,
SCP, Rsync. The customer still needs to change or remove any links in their basepages to the content.
Using Origin Storage as Content Origin
When a property‘s configuration rules are set up, instead of using a customer hostname for the origin, the
Origin Storage hostname should be substituted. As with customer origins, access to Origin Storage can be
designated as HTTP or HTTPS only. The Origin Storage uses Level 3‘s midgress servers and edgeservers
to deliver the content – end users never access files from Origin Storage directly.
End users are restricted from listing storage directories.
Page 35
Content Freshness Features
Methods of Freshness Control
Level 3 CDN was explicitly designed to allow customers the option of controlling and maintaining content
freshness without sacrificing end-user performance. Customers can consistently deliver the most accurate
and up-to-date content quickly to their end users. Depending on their business needs, customers can
update content within the Level 3 CDN network on-demand or at regularly scheduled intervals.
Level 3 CDN offers customers two basic mechanisms to control content freshness:
•
Expiration Policy – determines how long the resource in cache is considered fresh and can be served
without revalidation with the origin server
•
On-Demand Invalidation – provides a real-time method of expiring the resource in cache
These mechanisms are not mutually exclusive. They provide complementary ways for the CDN to serve
continually fresh content by triggering fills for fresh content when required. As a standard practice, CDN
customers often use an expiration policy as a default method of content freshness control while using ondemand invalidation as an occasional override, for example.
Refreshing Content in Cache
The process for updating content within a cache occurs when a request for a stale resource (i.e.,
invalidated or past expiration) arrives at a Level 3 edgeserver. Then, a GET If-Modified-Since (GIMS)
request for the resource is sent to the customer‘s origin server or to a cache peer or parent, in order to
revalidate content.
If the resource has not changed, a 304 (Not Modified) response is returned, and the content is again
marked as fresh. If the resource has changed, the modified resource is returned in a 200 (OK) response.
The new resource replaces the stale resource at the CDN server and is served to the customer's end user.
Note: If the resource in cache does not have a valid Last-Modified: header supplied by the origin
server, then an unconditional GET request is used for revalidation, which causes the resource to be
reloaded in cache.
Level 3 CDN also has a Background Refresh feature (also known as BRefresh Mode). This mode allows
the existing stale content to be served while triggering an asynchronous revalidation back to the origin
server. (There is a limit on how stale the content can be with this mode enabled.)
If a refresh attempt fails because of a failure to contact the origin server, the old stale content is served for
a short period of time before a further refresh attempt. This is independent of Background-Refresh mode.
Expiration Policies
Expiration policies can be established and controlled either at the customer‘s origin server or within the
CDN itself.
Level 3 CDN recognizes standard HTTP cache control headers which can be added to the header of any
resource served by a standard HTTP server (e.g., Apache, Netscape, and IIS). When a customer knows
that specific content is likely to change at regularly scheduled intervals, cache control headers should be
used to expire content within the Level 3 CDN. Origin server policies can also be used if content is known
to get updated at a certain time.
The Level 3 CDN also provides a Cache Control Header Override Mode (CCHOMode) that enables a
resource to be cached for the configurable period of time, regardless of HTTP cache control headers set by
the origin server.
Page 36
HTTP Cache Control Headers
The HTTP cache control headers that affect content freshness are:
Header
Value
Cache-Control:
Specifies directives that must be obeyed by the cache, including assigned TTL values
Expires:
Date and time after which the resource is no longer considered fresh
Last Modified:
The date and time the resource was last modified at the origin server
Figure 13: HTTP Cache Control Headers
The following is a list of attributes of the Cache-Control: header most commonly used:
Directive
Meaning
max-age
In seconds, the Time-To-Live (TTL) assigned to the resource in cache. The resource is considered cacheable
and TTL determines amount of time the resource can be served straight out of cache after the time it was
retrieved from the origin server.
no-cache
A cache must not use the response to satisfy a subsequent request without successful revalidation with the
origin server. The resource is considered cacheable, but must be revalidated on every request.
no-store
A cache must not store the response. The resource is considered non-cacheable.
public
The response may be cached by any cache. The resource is considered cacheable.
private
The response must not be cached by a shared cache, such as Level 3 CDN.
Figure 14: Cache-Control Header Directives
Note: Level 3 CDN does not support the use of Meta tags within HTML resources.
Cache-Control-Header-Override Mode (CCHOMode)
The Cache Control Header Override Mode (CCHOMode) feature allows the Level 3 CDN to override cache
control headers that otherwise would cause resources to be uncacheable and gives customers control over
their content in Level 3 caches.
A key component of the CDN‘s performance improvement is due to the storage and delivery of customer
content in cache at the edge of the network. When browsers request already cached content, the content
can be served immediately. An edgeserver that does not have the requested resource in its cache may find
it cached at a peer, so there is often no need to retrieve content from an origin server before it can be
served.
By default, the CDN honors the expiration policy set by the origin server. This means retention of customer
content in CDN caches can be made difficult or impossible by resource headers like Cache-Control:,
Expires:, and Pragma: no-cache, which lower resource cache lifetimes or cause resources not to be
cached at all. Some customers may have cache control headers set to short durations to prevent retention
of stale resource versions at ISP caches over which they have no control.
CCHOMode is especially useful during test and evaluation when new customers cannot easily set, remove,
or modify cache control headers on the resources. Enabling this mode during trials permits more realistic
assessments of Level 3 CDN performance improvements than otherwise would be possible. This mode
can also be used in a production environment to ensure resources served by the CDN are always
cacheable.
CCHOMode can be applied to individual resources or groups of resources using pattern matching. This
feature defines the expiration criteria for resources and overrides any existing cache control headers set by
the origin server – this is referred to as Internal Expiration Policy, utilized strictly within Level 3 CDN.
Optionally, new cache control headers may be set or existing headers altered when the resource is served
to a client – this is known as the External Expiration Policy – which should be honored by a browser or
down-stream cache.
The Internal Expiration Policy and External Expiration Policy can be configured separately.
Page 37
CCHOMode Usage
CCHOMode is specified with a Time-To-Live (TTL) time unit (seconds, minutes, hours, days, weeks, or a
year) or may indicate that the resource is not to be cached (―no-store‖).
For internal specifications, a positive number acts as if a max-age value had been supplied in a CacheControl: header and determines the TTL applied to the resource in cache.
For optional external specifications, when set to a positive value, a Cache-Control: max-age and/or an
Expires: header is added to the resource with header values set appropriately, given the Date: when
the resource was served from the cache and the TTL value. When zero, both a Cache-Control: nocache and a Pragma: no-cache (for compatibility) header is added when the resource is served from
cache, putting, in effect, an explicit no-cache policy at the end user.
The following table explains the various options available with CCHOMode and the corresponding effects
on caching the object at the edgeserver (the Internal Policy) and the expiration policies the edgeserver
sends to the end user (the External Policy). The Internal Policy specifies the internal caching policy, i.e.,
how the edgeserver should deal with the resource. The External Policy specifies the external caching
policy, i.e., the caching policy on the resource when it is delivered to downstream caches/clients.
CCHOMode Value
Internal Policy
External Policy
true or on
Ignore cache control headers supplied by the origin
server and apply internal expiration policy which
defaults to 1 year
N/A. Only applies to Internal Policy.
false or off
Honor cache control headers supplied by the origin
server. This is the default behavior
N/A. Only applies to Internal Policy.
positive number
Set internal TTL value to # of seconds, minutes,
hours, days, weeks, or 1 year. Default is seconds.
Set external TTL value to # of seconds, minutes,
hours, days, weeks, or 1 year. Default is seconds.
A positive number acts as if a max-age value was
supplied by the origin server in a CacheControl: header
Cache-Control: max-age and/or an Expires:
header added when the resource is served to the
client
Sets an external policy without setting the internal
expiration policy
Sets an external policy without setting the internal
expiration policy
The resource is cached, but the next request will
trigger revalidation with the origin server
Cache-Control: no-cache and Pragma: nocache headers added when the resource is served
to the client
Prevents the resource from being cached by the
CDN as if the origin server set a CacheControl: no-store header
Cache-Control: no-store and Pragma: nocache headers added when the resource is
served to the client
#<s,m,h,d,w,y>
negative # or
as-is
no-cache or
0
no-store
Note: External actions are not performed if the resource had a cache control policy served from the origin
server unless an optional ―force‖ attribute is specified. When set, cache headers received from the origin
server are stripped off and replaced with any headers added by the external CCHOMode.
Cache Control Header Precedence
By default, if no CCHOMode is in effect, the edgeserver honors standard HTTP cache control headers
supplied by the origin server. If multiple cache control headers are present, internal expiration policy is
determined by the max-age directive in the Cache-Control: header which takes precedence over any
Expires: and Pragma: no-cache headers. This means Expires: header is only considered if there is
no valid Cache-Control: max-age header.
The cache control headers are stored with the resource in cache and updated when the resource is
revalidated with the origin server. If a Cache-Control: header and/or CCHOMode are in effect, the value
Page 38
of the Expires: header is set or altered to specify the expiration policy based on the date and time that
the resource was filled.
If both Cache-Control: max-age and Expires: are present on the resource in cache, neither is
altered when the resource is served to the client; however, it is possible to adjust the headers based on the
time of the request if the cache-control-policy specifies which cache control header value takes
precedence. The cache-control-policy is configurable on per property basis.
•
When set to ―expires‖, the value of max-age in the Cache-Control: header is modified when served,
so that, when added to the Date: header value, it matches the value of the Expires: header
•
When set to ―max-age‖, the value of the Expires: header is modified when served so that it matches
the value of the Date: header + max-age from the Cache-Control header
•
When set to 'off' (the default), neither is altered when the resource is served to the client
If no Expires: header was supplied by the origin server, then an Expires: header is always generated
by the CDN whenever a Cache-Control: max-age header is present, but the inverse is not true—i.e.,
the presence of an Expires: header does not lead to creation of a Cache-Control: max-age. As
such, any response with only an Expires: header is not affected regardless of the cache-control-policy
setting.
Background Refresh (BRefresh)
Once an edgeserver caches a resource, it serves that object from the cache until it becomes stale. When
the object is stale, it has to be revalidated with the origin server before the edgeserver can deliver it to the
client.
The edgeserver makes a request to the origin server for the resource. If the resource version is still valid,
the origin server returns a 304 (Not Modified) response with new TTL information. On the other hand, if the
resource version has been superseded, the origin server sends the new version of the file.
The resource revalidation process imposes a certain amount of latency on clients who must wait for this
update to complete. Under ideal circumstances, revalidation may take a few milliseconds, but this time can
dramatically increase if the origin server is unreachable, in which case multiple-second timeouts may need
to expire before the refresh attempt is abandoned.
Background Refresh (BRefresh) mode provides an alternative resource revalidation method for the Level 3
CDN. If this mode is enabled for a stale resource, the currently cached version is served immediately, while
a revalidation of the resource is launched asynchronously in the background, thereby removing the latency
traditionally involved with revalidation. There is a limit on how stale the content can be with this mode
enabled. By default, content that has been stale for more than four (4) hours is not subject to the
Background Refresh policy; however, this setting can be overridden in the customer configuration.
BRefresh mode is recommended for frequently changing resources with short TTLs and slow origin
servers.
BRefresh mode can be applied to individual resources or groups of resources using pattern-matching
designations. The interval of time during which the content is subject to BRefresh, the background-refreshstale-limit, is configurable on per property basis—its value is specified in seconds.
How Content Freshness Works with BRefresh and
CCHOMode
When a request is received, the edgeserver determines if a fresh copy of the resource is in the cache. If so,
the user will be authenticated (if required), and the resource delivered.
If the resource is in cache but is no longer considered fresh (invalidated or past expiration), the edgeserver
checks if the resource is configured for Background Refresh. If it is and the acceptable interval for service
Page 39
has not passed, the user is authenticated (if required), the resource is served, and the background cache
fill initiated. If the interval has expired and a cache fill is in progress, the request will wait for the cache fill to
complete.
If Background Refresh is not configured for the resource or the background-refresh-stale-limit has expired,
the request is handled normally. That is:
•
The edgeserver queries available peers to determine if they have a fresh copy. If a current copy is
resident in a peer cache, it is delivered to the requesting edgeserver, cached for subsequent requests,
and delivered to the end user
•
If the resource requires authentication, the peer sends a revalidation request to the authentication
server to determine if the user is authorized before returning it to the requesting CDN server
•
If a usable copy is not available from a peer server, a GET If-Modified-Since (GIMS) request is sent to
the origin server. If the user is authorized to receive the resource, a new copy is returned with a 200
(OK) response
•
Should authentication fail for any reason, the unsuccessful request returns a 401 (Unauthorized) or a
302 (Redirect), usually to a customized error page
Note: If no Last-Modified: header was supplied by the origin when resource was loaded into cache, an
unconditional GET request rather than the GIMS request is sent to the origin server.
Upon completion of a cache fill, the edgeserver determines if CCHOMode is indicated for the resource. If
so, internal and external expiration are set accordingly. If not, any cache headers presented by the origin
server will determine expiration criteria. If no cache control headers were supplied by the origin server, the
resource is considered cacheable for one year from the time it is loaded into cache.
ETAG and If-None-Match Support
The ETag: is a standard HTTP response header that provides the current value of the entity tag for the
resource. If the origin server supplies this header, the edgeserver stores it with the resource in cache and
return it to the client when delivering the resource. The client could then use the value of this header to
issue a conditional request to the Level 3 CDN. If the client has one or more entities previously obtained for
a given resource, it can verify that none of those entities is current by including a list of their associated
entity tags in If-None-Match: header.
The Level 3 CDN recognizes the If-None-Match: header. Upon receipt of a conditional request with an
If-None-Match: header, the edgeserver compares the value of the ETag: header on the resource in
cache to the entity tags provided in the If-None-Match: header on the request, and, if any entities at the
client are current, the edgeserver responds with a 304 (Not Modified) HTTP status code.
Entity tags are also used by the Level 3 CDN when managing variant responses—revalidation requests for
such resources always include an If-None-Match: header. For resources that do not vary, an IfNone-Match: header will not be included unless If-None-Match support is configured for the property in
which case refresh requests (revalidations) for a resource with a known ETag: will also include an IfNone-Match: header.
Query-String-Handling Mode (QSHMode)
By default, resources are cached within the Level 3 CDN using their complete URL including the entire
query string as the cache key. There may be elements of the query string that make it unique for each end
user, such as parameters used for authentication or session tracking, even though the resource is identical
for those end users. In those cases, every user‘s request will result in a cache miss, causing sub-optimal
performance as each user request for the resources will have to go to the origin server. In order to serve
such users from the cached copies, the query string portion of the cache key can be altered to remove the
name-value pairs from the query string, thus making the cache key the same for the same resource.
Page 40
Query String Handling Mode (QSHMode) is a feature that allows some or all of the name-value pairs of the
URL query string to be excluded from the cache key to ensure the cacheability of resources that are only
unique due to query string parameters but where the associated content is actually identical.
For example, consider the URL:
http://cdn.example.com/image101.jpg?username=john_doe&userid=12345&type=7
Indicating that QSHMode should eliminate the ―username=‖ and ―userid=‖ parameters from the cache key
would allow the edgeserver to access the same cached resource, regardless of the user-specific data,
under the resulting cache key:
http://cdn.example.com/image101.jpg?type=7
QSHMode may be applied to customer resources in either Selective or Full mode:
•
Selective Mode indicates which query string parameters should be used and which should be ignored.
Parameters selected may be specified by either an inclusion list or an exclusion list. Inclusion means
―only use these parameters‖ while exclusion denotes ―suppress these parameters‖. This option is very
flexible in what it can do but can only be specified at the property level, so that it applies to all resources
on a particular property.
•
Full Mode indicates that all query string parameters should be excluded from the cache key and may
be set at the resource level. A match suppresses the entire query string from cache processing and
overrides any Selective Mode specifications.
Regardless of which style is used, the log file entries contain the entire URL as presented by the end user.
Also, any cache fills and refresh or revalidation (including authentication revalidations) attempts will use the
entire URL, including the full query string.
On-Demand Invalidation
Purpose of Invalidations
The term Invalidation refers to the CDN‘s on-demand content expiration system.
Normally, edgeservers retain content for no longer than the amount of time specified in certain HTTP
headers, primarily the Cache-Control: and Expires: headers. These headers indicate that a resource
is expected to change by a certain time, specified either as an absolute time or as a delta from the time the
resource is filled by the cache. When the specified time has arrived, the content in the cache becomes
stale, and the next request for it causes the edgeserver to revalidate the content with the origin server. This
process is often referred to as Passive Invalidation.
If the resource changes sooner than expected, an invalidation request can be initiated with the Level 3
CDN system. As such, this process is often referred to as Active Invalidation.
The result of an Active Invalidation is typically the same as a Passive Invalidation. The resource is still in
the cache, and the next request for it triggers a revalidation of the resource back to the origin server or to a
peer (if the peer is known to have fresh content).
These revalidation requests are made in the form of a GIMS (GET with an If-Modified-Since:
header) request. The date provided in the If-Modified-Since: header is the value of the LastModified: header received on the response that filled the resource into the cache.
If the resource has changed since that time, the new version of it is stored in the cache – if it has not
changed, the origin server should be able to respond with a 304 (Not Modified) response, providing an
updated cache expiration policy.
The Active Invalidation system also provides a way to ―force‖ the reload of a resource. This is useful when
the Last-Modified: header generated by the origin server is unreliable and its value has not changed
(or has gone backwards in time). In the case of a forced invalidation, the revalidation request made to the
origin server is an unconditional GET as opposed to the conditional GIMS.
Page 41
Invalidation Request Format
The invalidation request specifies the URL or URLs that should be invalidated across the Level 3 CDN
network. It is specified as a combination of property and path.
The path in an invalidation request is the URI path of the resource on the origin server. This is often the
same as the path to the resource on Level 3 CDN unless the CDN Supername is using an Extended Alias
(i.e., contains a directory path element) or Alternative Webroot is used (e.g., CDN is configured to fill cache
from a designated subdirectory below the actual webroot).
A path can be specified as either a complete path (in an abspath style), or it can make use of one or more
wildcard specifications. For instance, an invalidation request can specify all the content in a certain
subdirectory, or all resources with a common extension.
The meta-language used to describe the path is a shell-glob like regular expression. This means that
wildcards can be specified using ―*‖, to mean match zero or more characters (this is used for a request to
invalidate all resources with a common extension as well as all the content of a directory tree), or some
special characters such as ―+‖ (meaning one or more characters, except for the directory separator).
The complete set of supported meta-characters available is outlined in the following table:
Meta
Character
Matches
*
Zero or more characters
+
One or more, non-directory separator characters
?
Any single character including the directory separator
.
Matches the "." (period) character only
\
Matches the directory separator
/
The directory separator character
{n,m}
Matches between "n" and "m" characters, where "n" and "m" are integer values
[a,x-y]
Matches any single character in the set provided. Comma (‗,‘) characters are used to separate individual
characters in the set; hyphens (‗-‘) are used to specify ranges (from the ASCII character set)
[^a,x-y]
Matches any single character not in the defined set
Figure 15: Invalidation Meta-Characters
If the URL is submitted with a query string, then the system attempts to match the entire URL including the
query string, through the QSHMode mechanism. If the URL is submitted without a query string, then the
query string is ignored for the purposes of that invalidation.
Submitting Invalidation Requests
Customers can submit their invalidation requests in two different ways:
1. Media Portal-based Invalidation – The portal‘s web-based tool is used for listing properties,
entering invalidation paths, and tracking the status of the invalidations. Media Portal Invalidations are
also accessible through the Media Portal API. (See the Media Portal Online Help for more details
about the API.)
2. Command Line-based Invalidation – The command line interface allows customers to bypass the
Media Portal and inject the invalidations directly into the system using any HTTPS-capable tool (such
as CURL or WGET). Requests can be made using the simple GET method.
Command Line-based Invalidation Usage
To issue a command line-based invalidation, the submit.cgi script is requested providing the account name,
password, and URL pattern to be invalidated. The syntax is as follows:
Page 42
Request: = “https://www.admin.footprint.net/invalidate/submit.cgi?”
“Account=” <account> “&Password=” <password>
“&URL=” <URL> “&ID=” <ID>
Note that the argument names (and values) are case-sensitive.
The <account> and <password> values are assigned by either Level 3‘s CDN Activation or CDN Support
teams upon request to enable access to the Command Line-based invalidation feature. They are not the
same as the Media Portal login and password.
The <URL> can be absolute or abspath. In addition, the value of <URL> in the Command Line style cannot
contain any characters marked as ―unsafe‖ or ―reserved‖ in RFC1738, and so those must be encoded (as
specified in RFC1738). Most obviously, any ―&‖ (ampersand) characters is interpreted as the end of the
URL argument to the submit.cgi process, rather than as part of the URL. Also, any ―%‖ (percent) characters
introduced by a previous encoding will need to be themselves encoded as ―%25‖.
When using the abspath style, the ―ID=‖ attribute must also be set. Its value is the Property ID. CDN
Support can provide the list of Property IDs associated with the account.
Note: This additional encoding step is not required for Media Portal-based submission system where the
URL entered should match the URL path to the resource on the origin server.
If the resource to be invalidated belongs to a property that has a unique hostname, then the absolute style
reliably invalidates its content. However, if there are multiple properties that share the same hostname,
then the specific Property ID should be used to direct the invalidation against the required property.
Invalidation Recommendations
Level 3 CDN provides a number of mechanisms to ensure that customers maintain control over the
freshness of the content served through the CDN. As can be seen in this section, Level 3 offers an
extensive set of configurable features and functions for freshness control. To achieve best results, OnDemand Invalidation should be used in conjunction with other methods. Below is a list of the mechanisms
and the order of precedence in which they should be used:
1. Origin Server Policies – Expiration policies set at the origin server are typically respected by the
CDN, unless otherwise overridden by CCHOMode. Specific configuration of individual HTTP servers
may vary (and are beyond the scope of this document), but most modern, compliant servers should
offer the ability to set Expires: and Cache-Control: (max-age, no-cache, no-store, mustrevalidate, etc) headers with varying degrees of flexibility and granularity. These headers cause
the CDN caches to expire content according to the policies established at the customer‘s origin,
unless explicitly overridden. This is the customer‘s first, best option for explicitly controlling the
freshness of content as it is under the customer‘s direct control.
2. CDN Specific Policies – Expiration policies set in the CDN configuration via CCHOMode which
override or replace policies established at the origin server. Use this mechanism when it is not
technically possible to establish policies at the origin or when different policies are required for the
CDN than for downstream (browser/proxy) caches. The CDN utilizes the internal expiration policies
and proxy the origin-established policies to downstream clients/proxies.
3. File Renaming – In general, new, unique assets should be given unique naming conventions where
possible via direct path/filename naming conventions or via query string tokens or other identifiers in
the URL. Unique naming allows the CDN to cache fresh versions of a resource and lets old versions
expire naturally. This is not always possible via Content Management or publishing tools or
processes, but, where it is an option, it is preferable to other methods.
4. Active Invalidation – Using the Level 3 Invalidation Facility to expire content in near real time. This
method provides an ―override‖ when other methods have been used but content requires real-time
replacement outside of defined expiration policy.
Invalidation System Limitations
The Invalidation System consumes resources on the CDN infrastructure. It takes time (CPU, network, etc)
Page 43
to process the various invalidation messages, propagate them across thousands of distributed servers,
provide completion feedback, and many other mechanisms within the system to attempt to guarantee that
invalidation messages are not lost or skipped. As such, there are a finite number of Invalidation Events that
can be processed by the system as a whole.
Invalidation Usage Guidelines
Invalidation should not be a primary method of content freshness control. Use invalidation only in
conjunction with other means or when other methods are absolutely not available (a rare condition).
Use cache control directives at the origin that accommodate the typical, expected interval of updating. In
case of an unexpected event, use invalidations for the specific content being changed. Do not use
programmatic invalidations every few minutes ―just in case‖ as an alternative to expiration policies. Even
the most dynamic of real-time applications can be very tightly controlled using sub-minute expiration
policies when needed. It is preferable to have an overly aggressive expiration policy than to become overly
dependent on invalidations.
Consider the true need for ―real-time‖ expiration. Do monetary, brand perception or legal necessity require
replacing content, or will a few extra minutes to allow the content to age out make a material difference?
For automated, scripted use of the Invalidation API, the following guidelines apply:
•
Batch Requests – Use the list-based or file-based form of the interface to submit multiple URLs as a
batch. Submit as many URL‘s as possible in as few batches as possible
•
Use fully qualified URLs – Minimize the use of wildcarding. Reserve wildcarding for the GUI-based
interface. Where programmatic access to Invalidations is used, Level 3 would expect that explicit lists of
URLs can be constructed by the invoking application
•
Limit the Invalidation Request Rate – Set it to less than ten (10) per minute. Queue submissions on the
client/script side of the interface if the quantity of invalidations would exceed this rate
Level 3 reserves the right to limit, throttle, de-prioritize, or potentially restrict access to the Invalidation
System for a specific customer if that customer‘s usage patterns place an undue burden on the system.
Should this be the case, Level 3 Sales Engineers and CDN Support personnel will work with that customer
to find a solution that complies with the above guidelines while meeting the needs of the particular
application in question. However, in some cases, creating an appropriate caching/freshness policy might
require changes on the customer‘s side. Level 3 cannot guarantee the use of invalidations as a primary
means of freshness control for every application.
Page 44
Security Features
Overview
Customers may need to restrict the delivery of resources to end-users by verifying that only authorized
users receive that content. The verification may ensure that only known users, direct affiliates, or those that
have paid for the content are allowed to download it. In addition, there may be export restrictions that would
restrict access from specific countries or requirements to prevent the reuse or modification of URLs.
The Level 3 CDN offers a wide range of content security features that allow customers to protect their
content from unauthorized access. Content stored within the CDN may be flagged as using one of a set of
authentication modes, each of which cause some form of authentication revalidation to be performed for
subsequent requests.
Authentication modes can be broken into two groups:
•
Proxy Authentication – Requires that a validation request is sent to a customer‘s authentication
server
•
Edge Authentication – Uses knowledge present within the CDN itself to determine whether a client is
authorized
When a request for a protected resource is received, the edgeserver performs the appropriate
authentication processing and uses the result to determine the response returned to the client.
Typically, there are three types of responses—where the user is:
•
Authenticated and receives the resource with (200) OK response
•
Not authenticated and receives an Unauthorized (401) response
•
Not authenticated and receives a Redirect (302) to a specified page, often showing an error or asking
the end-user to provide the proper credentials
If the requested resource is not in cache, or if it is no longer considered fresh, a cache-fill will need to be
performed. Depending on the authentication mode in use, this may occur after the user has been
authorized or the authentication may occur as part of the cache-fill.
For authentication modes that include some form of authentication credential within the query string portion
of the URL, the credentials make the URL unique. This has adverse affects on the cacheability of the
content, and QSHMode should be used so that the content may be effectively cached.
Proxy Authentication
Proxy Authentication relies on a customer-operated authentication server and provides a more flexible
solution compare to Edge Authentication but at the cost of the latency added by the extra step of the
validation request. As with regular cache fills, all HTTP headers presented by the end-user are provided to
the authentication server so that it can make the authorization determination. The client IP address is
passed along in the X-Forwarded-For: header.
The types of Proxy Authentication are:
•
Cookie-based – authentication information is attached to the request in a cookie
•
authentication – authentication information is the user-supplied name/password combination
•
string-based – authentication information is embedded in the query string portion of the URL
(note: QSHMode should be used so that the content may be effectively cached)
Restricted resources resident in cache must be revalidated when requested. The revalidation methods are:
Page 45
•
HEAD method – A lightweight (HEAD) request is sent to the authentication server along with all
headers. This is the most common method of revalidation often referred to as Traditional Authentication
•
GIMS method – A GET If-Modified-Since request is sent to the origin server along with all headers. If
the version at the origin server is more current than the one in cache and the request is authenticated, it
will be returned. If a Last-Modified date is not available, the request is changed to an unconditional GET
The following diagram illustrates how Proxy Authentication works using the HEAD method for revalidation:
End User
Request
4
Response header is
returned to the
edgeserver:
200 = Ok to serve
401 = Don‘t serve
302 = redirect
Edgeserver can return
origin response code
or apply configuration
rules to alter the
response
3
1
Cookie info,
query string, or a
custom client
that generates
custom request
headers
Level3
Edgeserver
Origin
Server
2
Edgeserver sends
Head request and any
required end user
information
Figure 16: Proxy Authentication Using HEAD Requests
The numbered sequence defines the numbered actions in the diagram:
1. End-user requests a protected resource from Level 3 CDN. This request may include cookies, query
string, and/or custom HTTP headers generated by custom client.
2. Level 3 CDN server sends HEAD request with any required end-user information to the Origin Server.
3. Origin Server processes the request, makes it authorization decision and responds with HTTP status
code telling Level 3 CDN what action to take:
•
200 – OK to serve
•
401 – Do not serve
•
302 – Redirect
4. If authentication succeeded, the Level 3 CDN delivers the resource to the end-user with a 200 OK
status code. If not, the Level 3 CDN denies access with an appropriate HTTP status code (401/302)
received from the Origin Server.
Page 46
Alternative Authentication Server Option
By default, revalidation requests are sent to the origin server from which the content is retrieved; however,
this behavior can be modified to forward revalidation requests to a different location, referred to as an
Alternative Authentication Server. This may reduce the resource requirements at the origin server or
facilitate distributed administration of security policies.
Additionally, a property may be designated to use Pre-Authentication option. Pre-Authentication causes
requests to be validated at the Alternative Authentication Server before a cache-fill request is sent to the
origin server. Pre-Authentication allows the authentication server to be the sole owner of the authentication
knowledge – the origin server just has to serve the content to the CDN.
Depending on the requirements of the application receiving the authentication request at the Alternative
Authentication Server, the system can format the request in several different ways.
•
The request can be directed to a generic hostname or to a specific ―script‖ URL
•
The system can control whether the URL originally requested is appended to the end of the
authentication request or included as a separate HTTP request header
Data transmitted to and from an Alternative Authentication Server may be protected by selection of the
Secure Authentication option, which causes HTTPS to be used for all such traffic.
The following diagram illustrates how Proxy Authentication model works with Alternative Authentication
Server assuming Pre-Authentication option is enabled:
5
End User
Request
6
Origin
Content
Server
Once the user request
is authenticated, the
edgeserver can
request content, if
needed, from the
origin server
Edgeserver can return
origin response code
or apply configuration
rules to alter the
response
4
3
Response header is
returned to the
edgeserver:
200 = Ok to serve
401 = Don‘t serve
302 = redirect
1
Cookie info,
query string, or a
custom client
that generates
custom request
headers
Level3
Edgeserver
2
Origin
Auth
Server
Edgeserver sends
Head request and any
required end user
information
Figure 17: Proxy Auth with Alternative Authentication Server
Page 47
The numbered sequence defines the numbered actions in the diagram:
1. The end-user requests a protected resource from the Level 3 CDN. This request may include
cookies, a query string, and/or custom HTTP headers generated by custom client.
2. The edgeserver sends a HEAD request with any required end-user information to the Alternative
Authentication Server.
3. The Alternative Authentication Server processes the request, makes an authorization decision and
responds with HTTP status code telling Level 3 CDN what action to take:
•
200 – OK to serve
•
401 – Do not serve
•
302 – Redirect
4. If authentication succeeded, the Level 3 CDN may request the resource from the Origin Server.
5. The origin server returns current copy of the resource to Level 3 CDN.
6. The edgeserver delivers the resource to the end-user with a 200 OK status code. If authentication
failed, the edgeserver denies access with the appropriate HTTP status code (401/302) received from
the Alternative Authentication Server.
Further details regarding Proxy Authentication are available in the CDN Asset Security Technical Brief.
Edge Authentication
The second group of authentication modes can make the authentication determination without the need to
contact an authentication server. They include:
•
URL Token Authentication – Secure content with embedded encrypted tokens in the query string of
the URL
•
Geographic Intelligence / GeoBlocking – Restrict requests by country of origin with Basic
GeoIntelligence or more granular geographic restrictions with Premium GeoIntelligence
•
Referrer Blocking – Restrict requests to a known set of referrers. Headers other than Referer: may
also be utilized for similar types of restriction
•
IP/CIDR Blocking – Deny requests from designated IP addresses or Classless Inter-Domain Routing
Blocks (CIDR)
Detailed descriptions of each of these modes can be found in the sections that follow.
URL-based Token Authentication
URL Token Authentication allows a customer to encode information into a URL, including tokens that
provide special instruction to the CDN. This encoded information can then be secured from tampering by
appending a security token to the URL that gives the CDN the ability to verify that nothing in the URL has
been changed between the time the URL was published and the time the request is received by the CDN.
This feature allows the CDN to inspect a set of name-value pairs within the query string element of the
URL, using them as valid starting and ending times. The CDN ensures that requests are valid only during
the validity window defined by the start and end times. Requests outside of the validity window are rejected
using a customer-configurable response code.
The URL is ―authenticated‖ through the use of hash encoding of the URL itself. The customer and Level 3
coordinate on which elements of the URL are meaningful and on a shared-secret key. This feature
assumes that the customer has implemented code at their origin server that computes a hash value based
on the URL (path and designated query string elements) using the shared secret and a common algorithm
(MD5 or HMAC-SHA1 hashing, depending on the token type chosen) and appends the generated hash
value to the end of the URL prior to publication. This allows the CDN (upon receipt of a request) to
compute the same hash using the same components of the URL, the pre-shared secret, and the same
Page 48
hashing algorithm. The resulting hash code is compared to the hash code on the incoming request. If they
match, the CDN is assured that the URL has not been tampered with (the algorithm assures that any
change – even a single character – results in a completely different hash code) and that the embedded
validity tokens are authentic as published.
Level 3‘s Token Authentication can be applied against a list of specific content files or against a folder of
content files on the server-side.
How Token Authentication works in Level 3’s CDN
1. The end user requests a protected resource.
2. The customer origin generates the resource URL with the token attached and returns the resource
URL with the token attached to the end user.
3. The end user requests the resource URL with the attached token from the Level 3 edgeserver.
4. The edgeserver validates the token and processes the business rules. It returns the resource if
authorized, else it denies or redirects the request
1
2
Customer
Web Server
URLs w/
End User
Request
TOKEN
3
TOKEN
4
Level3 CDN
Figure 18: How Token Authentication works in Level 3’s CDN
Standard Token Parameters
The Standard Token is the token format to be used in all new implementations. Each can be used with both
streaming and with caching services. (Level 3 also supports the Flex Token as a legacy implementation.
See Appendix D: Legacy Flex Token Support. It also can support both streaming and caching.)
Page 49
Feature/Parameter
Standard Token Usage/Definition/Value
Hash Algorithm
HMAC-SHA1
Hash Contents
Take the full URL and remove the protocol, hostname, and unneeded query string
parameters
Add any desired arbitrary or time validity tokens
Time Format
yyyymmddHHMMSS in GMT or in epoch-seconds
SaltValue/SecretKey
ASCII character string of up to 64 bytes
No Reserved characters
Secret Table
Yes, up to 10 active secrets with Validity Times for the secrets
Hash / Token Length in URL
20 characters / 21 characters
First character designates secret number used, then first 20 characters of calculated
hash
Token Query String Parameter Name
Configurable, for example ―hash=‖
Base64 Encoded
No
Start/End parameter names
Configurable, for example ―stime=‖ and ―etime=‖
If there is no End Time value present, the edgeserver assumes that the token value never
expires and always serves the object. If there is no Start Time, the object is considered
valid until the End Time value.
Figure 19: Standard Token Parameters
An Example for Constructing the Token for On-Demand Flash Streaming
Start with a URL in the following format
Protocol://Hostname/ContentLocation/Resource?QueryString
the content, such as: (1) mms and rtsp for Windows Media; and (2) rtmp and rtmpe for Flash.
Hostname can be an external or Level 3-generated sub-domain from the f35.c.footprint.net
domain.
ContentLocation is the path to the resources being protected.
Resource is the desired resource to be protected or the folder to be protected.
Here is the URL to be protected with a token for this example. It is assumed that forced adding of filename
extensions is turned off. (See below.)
rtmp://xyzmedia.f35.c.footprint.net/xyzmedia/liveStreams/testStream?
CustomerID=1234&NotUsed=ThisOne
Steps to generate the protected URL.
1. Remove the protocol (e.g., rtmp://) and hostname.
/xyzmedia/liveStreams/testStream?CustomerID=1234&NotUsed=ThisOne
2. Remove any name-value pairs from the query string that are to be left out of the hash. Leave in any
name-value pairs from the query string that should be protected by the hash function. In this
example, ―CustomerID‖ is a customer variable that should be protected by the hash, and ―NotUsed‖
is a customer variable that does not need to be protected by the hash. This is set in the property
configuration to ensure that the edgeserver protects and ignores the proper variables from the
query string.
/xyzmedia/liveStreams/testStream?CustomerID=1234
Page 50
3. Add a designated name-value pair for the start time of the token validity window to the query string.
(Start and Stop times are in UTC/GMT format, for example: yyyymmddHHMMSS). In this example,
―stime‖ was used as the start time variable name and set in the property configuration.
/xyzmedia/liveStreams/testStream?CustomerID=1234&stime=20080101120000
4. Add a designated name-value pair for the end time of the token validity window to the query string.
(Start and Stop times are in UTC/GMT format, for example: yyyymmddHHMMSS). In this example,
―etime‖ was used as the end time variable name and set in the property configuration.
/xyzmedia/liveStreams/testStream?CustomerID=1234&stime=20080101120000&
etime=20101231235900
5. Choose the secret number from the Secret Table. Up to ten (10) pre-configured secrets are
available at one time. In this example, Secret #0 was chosen which is ―SecretWord‖ (without the
quotations).
6. Use the HMAC-SHA1 Hash algorithm on the text message from Step 4 using the secret from Step 5
to produce the hash digest. The first 20 characters are used from the result.
dc0f6611f819bc2a632c
7. Take the hash digest and prepend the secret number from Step 5.
0dc0f6611f819bc2a632c
8. Take the original URL (including any desired name-value pairs that were left out of the hash) plus
the token validity start and end time name-value pairs and add a designated name-value pair with
the token from Step 7. In this case, ―hash‖ was chosen as the token variable name and set in the
property configuration.
rtmp://xyzmedia.f35.c.footprint.net/xyzmedia/liveStreams/testStream?Customer
ID=1234&NotUsed=ThisOne&stime=20080101120000&etime=20101231235900&hash=0dc0f
6611f819bc2a632c
Self-Generated Tokens
Tokens can be self-generated using code samples provided by Level 3. See Appendix D: for sample Perl
code that demonstrates how to add the Standard Token to a URL. (See Appendix F: for sample Perl
code that demonstrates how to add the Flex Token to a URL.) Customers in need of the Java, ASP, or
C++ Token Generator Script should contact their Level 3 Activation Engineer. They are not intended to
be used as-is, but rather to generate example URLs, and to serve as an example to guide an
implementation.
See Appendix G: for details on the format of the tokens.
Token and Security Configuration
Level 3 Operations sets the configuration parameters for this feature after coordination with the customer to
customize the defined set of content, the token type, the shared secret(s), the resulting action to be taken
upon an authentication failure, and the identification of the query string name-value pairs to use for the
validity window as well as those to be excluded from the hashing function.
Further details are available in the CDN Asset Security Technical Brief.
Token Authentication and Dynamic/Smooth/Adaptive Streaming
The usual tactic to implement token authentication for dynamic streaming is to allow a token to cover either
a set of named resources or a directory as defined by the configuration parameters. The directory one is
easily implemented – the configuration can be set to ignore the filename when calculating the token for
comparison purposes.
Page 51
For multiple discrete resources, a list of valid files can be provided in the query string. The token is then
calculated over the entire URL (again, without the filename of the resource being requested). Finally, a
check is made to ensure that the filename being requested is one of the ones in that query string list.
For FMS, it is possible to perform authentication checks at connect time rather than play time – that
potentially means that any stream will be allowed over that connection, so it is also generally configured
with the same options outlined above.
Example of Token Auth with a Multiple Bit Rate URL
All files associated to a common media content that needs to be secured under a single token are included
in the query string parameter and delimited with a ―;‖. The files also have to begin with a ―/‖ and are
identified as resource= in the query string element.
URL Before the Token Is Added
rtmp://xyzmedia.f35.c.footprint.net/xyzmedia/rtmp/mp4:sampleVideo500k?resour
ce=/sampleVideo 500k;/sampleVideo800k.mp4;/sampleVideo1500k.mp4
URL After the Token Is Added
rtmp://xyzmedia.f35.c.footprint.net/xyzmedia/rtmp/mp4:sampleVideo500k?resour
ce=/sampleVideo500k;/sampleVideo800k.mp4;/sampleVideo1500k.mp4?hash=046787b8
76e7539d78cc9
In the above example, the Flash Media Server looks at the manifest list style URL and is instructed to start
on the 500k content and is pre-approved to allow transition changes to the 800k & 1500k files without
needing additional tokens. Note that the start and end validity times were not used to simplify the example.
However, the codec specification should be removed before the hash is performed.
Tokens and FMS
If a request for an FLV object does not include the .flv extension on the object name in the URL, the system
adds the extension before computing the hash. For example, given a URL of:
ID=1234&NotUsed=ThisOne&stime=20080101120000&etime=20101231235900&hash=0dc0f
6611f819bc2a632c
Before computing the hash, the token authentication mechanism first adds a .flv extension to the filename,
like so:
rtmp://xyzmedia.f35.c.footprint.net/xyzmedia/liveStreams/testStream.flv?Cust
omerID=1234&NotUsed=ThisOne&stime=20080101120000&etime=20101231235900&hash=0
dc0f6611f819bc2a632c
When a customer is computing the hash to add to the URL, the extension should be added. The extension
can then be removed in the actual published URL.
Alternatively, the property can be configured to ignore all file extensions in the computation of the hashes.
One caveat is that two files with identical paths and file names except for the extensions, e.g., stream.flv
and stream.mp4, could potentially have the same token, depending on what name-value pairs are included
in the hash.
Playlist Mode
In an Adobe Dynamic Streaming implementation, token authentication is best achieved at the ―connect‖
level, combined with a defined list of the stream versions that are contained within the dynamic streaming
―playlist‖ (e.g., 500kbps, 750kbps, and 1500 kbps streams). When the token and its valid time window are
verified and access is granted, switching between the versions only requires checking the token without
considering the valid time window as long as the persistent connection to the edgeserver continues. With
this approach, the verification is essentially done at the ―play‖ level.
Page 52
Secure Live Ingest
Level 3 ingest token authentication is a method of securing content ingest that protects encoder
connections to Level 3 ingest servers for the purpose of live streaming using authentication and expiration.
Implementation of this feature involves customers writing a script or application to generate the token. The
result is a ―token‖ that is included in the connection process between the encoder and content ingest
server, which is validated along with the time window to reject or accept the connection.
Ingest token authentication is supported for Adobe Flash RTMP-based live streaming.
When using Level 3 edge token authentication and ingest token authentication in combination, you use the
same secret key both for ingest and for edge. For ingest, a name-value pair for the publish event should be
added to the URL to make the token different than the corresponding hash for the play event.
Geographic Location Blocking
Level 3‘s geographic restriction includes two distinct operations — the geographic determination where the
request originated and the evaluation of rules that specify which geographies may or may not have access
to the resource.
Level 3‘s CDN incorporates a geographic database that allows end users‘ physical location on the Internet
to be anonymously identified based on their IP address location. Level 3‘s implementation does not require
the use of cookies or behavioral profiling.
Customers can specify that an arbitrary group of content is subject to a GeoBlocking rule. The rule can be
set on an entire property, on a group of assets (partial directory, file extension, URL parameters), or on an
individual asset.
Once enabled and configured, this function causes the edgeserver, upon receiving a request for a
GeoBlocked resource, to use the client-provided IP address (either the actual IP address of the client or an
IP address in a customer-defined request header) to determine a geo-location. The customer can provide
either an allow list (―whitelist‖) or a deny list (―blacklist‖) of geo-locations. If using an allow list, only requests
originating in the locations in the list are allowed. If using a deny list, requests from included locations are
denied. The customer should also specify a default behavior if no match occurs (i.e., the opposite behavior
of the configured list).
How Geographic Intelligence works in Level 3’s CDN
1. End user requests an object or stream from the Level 3 network.
2. The Level 3 edgeserver evaluates the request for the resource. The edgeserver determines if the end
user is in a geo-location that should be blocked or authorized.
3. If the end user request is authorized, Level 3 delivers the object or stream to the end user. If the end
user is not authorized, the edgeserver redirects the end user to an alternate asset or hand back an
error or to the end user
End User
Request
1
3
2
Level3 CDN
Figure 20: Geo Intelligence Explanation
The customer can specify the behavior of the CDN upon encountering a targeted geo-location. This
behavior can be one of the following:
Page 53
•
200 OK – Serve the resource
•
403 Unauthorized – Deny the request
•
302 Redirect – Send the requestor to an alternate resource/page
Level 3‘s CDN support two levels of Geographic Intelligence:
•
Basic Geo Intelligence: Enables geographic filtering to be applied by Country
•
Enhanced Geo Intelligence: Enables geographic filtering to be applied by Continent, Country, State /
Province, City, MSA, DMA, Zip, Device, and Network.
Further details are available in the CDN Asset Security Technical Brief.
Referrer Blocking
The Referrer Blocking feature allows customers to specify an allow list (―whitelist‖) of hostnames of
referrers (such as the customer‘s own website or known syndication partners) that are granted access to
content within a property. The list can include explicit hostnames as well as wildcarded hostnames such as
*.example.com.
The Referer: header attached to a request for content is compared to this whitelist. If no match is found,
then a 403 (Forbidden) status code is returned.
Additionally, special handling is available in the case that the Referrer header is missing or blank and for
the case where the customer wants to ensure that the Referer: and Host: headers match (i.e., content
is referenced only from same host as the referencing page).
If a Referer: header contains a relative (non-absolute) URI (i.e., one without http://), the Host:
header value is used for the validity check.
Specific resources may be exempted from the Referer: header check. This can allow access to an entry
point or other resource that may be legitimately linked to from search engines or other external sources.
Arbitrary Header Blocking
The Arbitrary Header Blocking facility enables headers other than Referer: to be used to restrict access
to resources by specifying the header name and its acceptable values. If a request for content does not
contain the specified header information, then the 403 (forbidden) status code is returned.
IP/CIDR Blocking
The IP/CIDR Blocking feature can deny requests from designated IP addresses or Classless Inter-domain
Routing (CIDR) blocks. If the IP address associated with the end user matches the IP address(es) or CIDR
block designations specified, then the 403 (forbidden) status code is returned. Both whitelists and blacklists
are supported. The configuration be can set up to return a different return code, if desired.
Origin Server Security Features
Custom Request Header for Origin Cache Fills
The edgeserver can insert a custom header and value on all origin server requests to assist the origin in
identifying the source and validity of the request as coming from the Level 3 CDN. See the section HTTP
Header Manipulation.
SWF Verification
SWF Verification ensures that an On-Demand or Live Flash stream is only played back in authorized Flash
players. By ensuring that Flash streams can only play back in authorized players, the customer can better
control branding, advertising, and media placement. If an end user were to attempt to stream a Flash
Page 54
media asset in an unauthorized Flash player whose assets were protected using SWF Validation, the
media file will not play. This feature is only available for Flash On-Demand and Live streaming.
To use SWF Verification, Level 3 must be given the SWF file(s) to be embedded with a unique signature
profile. The files are then deployed throughout Level 3‘s CDN.
When an end user makes a request for a stream from Level 3‘s edgeserver, the signature of the end user‘s
SWF file is then compared to what is posted on the Level 3 Flash Media Server. If the SWF file signatures
do not match, the stream will not play back.
How SWF Verification works in Level 3’s CDN
1. Customer transfers the SWF player file to Level 3 OSP.
2. Level 3 distributes the SWF files to the edgeservers.
3. The HTML page with embedded SWF player is delivered.
4. The end user requests the Flash stream from the edgeserver. The Level 3 FMS server determines if
the SWF player requesting the stream matches what was uploaded.
5. If the SWF signature matches, the stream plays back to the end user. If the SWF signature does not
match, the stream does not play.
3
Customer
Web Server
End User
Request
1
4
5
2
Level3 CDN
Level 3
Origin
Storage
Figure 21: SWF Verification Flow
How to use SWF Verification in Level 3’s CDN
1. Level 3‘s Origin Storage service must be used in order to upload SWF files into Level 3‘s CDN.
Level 3 provides an Origin Storage account upon activation of SWF Verification.
2. A /SWF subfolder must be created in the directory from where the On-Demand content or Live
streams are managed.
On-Demand examples
rtmp://xyzmedia.f35.c.footprint.net/xyzmedia/rtmp/swf/sampleVideo.flv
Page 55
rtmpe://xyzmedia.f35.c.footprint.net/xyzmedia/rtmpe/swf/sampleVideo.flv
Live examples
rtmp://xyzmedia.f35.c.footprint.net/xyzmedia/rtmp/swf/liveStreams/livestream02
rtmpe://xyzmedia.f35.c.footprint.net/xyzmedia/rtmpe/swf/liveStreams/livestream03
3. Within the /SWF subfolder, the dirindex.txt file contains the names of the SWF files within the
/SWF folder that will be used for verification. The dirindex.txt file should contain:

One line per SWF file

No pathname is needed as part of the filename — just the filename itself

Exclude any SWF files in the /SWF subfolder that should not be considered for verification
Order of Authentication Checks
The edgeservers can be configured to perform multiple authentication checks on a particular piece of
content as multiple methods may be needed for a particular application. For example, a video might require
geographic restrictions but also need token authentication. If two or more authentication checks are
configured for the same piece of content, the following list shows the order of the authentication checks:
1. Simple Referrer, IP/CIDR Block, and Arbitrary Header Blocking
2. GeoBlocking; Complex Referrer, IP/CIDR Block, and Arbitrary Header Blocking
3. Token Authentication
4. Proxy Authentication
Secure Protocols
Secure Delivery
The delivery of confidential information requires the utilization of secure communications for both sensitive
data and supporting content such as images and text. Due to the increased computing power required to
process secure traffic, origin server workload reduction along with significant performance gains may be
realized by offloading those processes to high-performance CDN edge-servers.
The Secure Delivery option includes a dedicated pool of edgeservers configured to cache and deliver
secure, shared content using Secure Sockets Layer (SSL) or Transport Layer Security (TLS) and HTTPS.
Communications with the customer origin infrastructure can also be secured using HTTPS.
Secured Sockets Layer (SSL) is implemented in Level 3‘s CDN through its own Footprint-Secure
architecture which enables the delivery of content and sensitive data of secure channels.
Page 56
Figure 22: Footprint/Secure
Level 3‘s CDN supports two levels of SSL:
•
Standard SSL – Level 3 provides a general certificate for the customer(s) to use
•
Premium SSL – Level 3 is provided the certificate to be used
Level 3 supports SSL Version 3 and TLS Version 1.2.
For detailed information on Asset Security see the CDN Asset Security Technical Brief.
Secure Flash Streaming (RTMPE, RTMPTE, RTMPT)
Encrypted Real Time Messaging Protocol (RTMPE) is a propriety protocol unique to Adobe Flash,
designed to be lightweight and transparent to the end user. RTMPE uses a 128-bit encryption capability
that establishes an encrypted connection between the end user client and the Level 3 edgeserver. This
feature is only available for Flash On-Demand and Live streaming.
To manage RTMPE protected On-Demand content and Live streams, the /rtmpe subfolder must be
created within the directory from where the content file and live streams are being managed and the
streaming files placed within it.
On-Demand examples
rtmp://xyzmedia.f35.c.footprint.net/xyzmedia/rtmp/sampleVideo.flv
rtmpe://xyzmedia.f35.c.footprint.net/xyzmedia/rtmpe/sampleVideo.flv
Live examples
rtmp://xyzmedia.f35.c.footprint.net/xyzmedia/rtmp/liveStreams/livestream02
rtmpe://xyzmedia.f35.c.footprint.net/xyzmedia/rtmpe/liveStreams/livestream03
Note: RTMPS is not supported.
Page 57
Request and Response Inspection and
Manipulation
HTTP Header Manipulation
Normally, HTTP request headers received from the client are sent to the origin server on a cache fill
request as-is; however, the edgeserver can manipulate the headers before contacting the origin server.
Headers can be added, removed, or modified using a request header modification configuration setting.
Similarly, HTTP response headers received from the origin can be manipulated before the edgeserver
sends the reply to the client using a response header modification configuration setting.
In both cases, the value of the header can either be a static pre-configured constant or a dynamic value
generated using rich header expression syntax.
HTTP Status Code Manipulation
The CDN can be configured to return a specified response code for a request matching a RuleBase filter
(matching a path segment, file extension, etc.). There are 2 possible scenarios:
1. The edgeserver generates its own static response code instead of contacting the origin server. The
HTTP status code returned to the client is pre-configured using a RuleBase ―Error=‖ flag. The body of
the response is a generic ―File Not Found‖ message and cannot be customized.
2. The edgeserver contacts the origin server but alters the HTTP status code received from the origin
before serving the response to the client. The HTTP status code returned to the client is preconfigured using a RuleBase ―Status=‖ flag which specifies a response code to be returned to the
client every time the resource is served but does not affect the retrieval or caching of the content.
For either ―Error=‖ or ―Status=‖ flags the value should be an integer 100-599 which is interpreted as an
HTTP status code to be returned to the client.
If redirection is desired for an ―Error=‖ or ―Status=‖ flag, a 301 or 302 value must be specified with the
desired location indicated by an attached Location: header added via the RuleBase response header
flag.
Response Body Manipulation
By default, the edgeserver passes the body of the response received from the origin onto the client and
stores it in cache if the response is considered cacheable. The CDN does not have the ability to parse
and/or modify the body of the response generated by the origin server; however, it can substitute the
original body with a new message body constructed using RuleBase response body flag.
The same response body flag can be used in the request manipulation part of the RuleBase to generate a
message body without contacting the origin server. The edgeserver-generated body is cached and
delivered to the clients with a 200 HTTP status code. Optionally, the edgeserver can change the response
code sent to the client.
Redirect on Error
Normally, when a CDN server receives an HTTP response from the origin server as a result of a cache fill,
the response is sent back to the client with minimal additional processing. The Redirect on Error feature
allows the CDN server to issue a redirect with a custom-generated Location: header based on the value
of the HTTP status code in the origin response. The redirect can be handed out to the client, or it can be
followed by the CDN server itself, thus causing it to retry the failed cache fill from an alternate location.
Page 58
This feature can be used to create a simple failover for the origin and to create custom landing pages for
various error conditions. Example use cases could include:
•
Backup Origin – In case the ―primary‖ origin site is unreachable, overloaded, or simply not able to
locate the requested resource, an alternate origin location can be retried. This feature could be used in
conjunction with the Level 3 Origin Storage
•
Error Page – In the event of an overload or origin unavailability, including during maintenance periods,
the edgeserver directs traffic to an alternate resource, such as an error page, holding queue, or other
application with a different class of service.
This feature is implemented as a configuration filter and as such can be used to apply redirect on error
processing to individual resources or groups of resources.
Utilization of this feature is accomplished by constructing RuleBase rules and requires the following to be
defined:
1. Error codes to match (for example 404 or 5xx)
2. Location: header specifying desired target of the redirect
3. Action to take, either:
 Have the edgeserver follow the redirect and retry cache fill from the alternate location without
delivering the redirect to the client

Have the edgeserver send the redirect to the client which should then follow that redirect to the
alternate location
Advanced Path Rewriting
The Level 3 CDN supports extensive operations to manipulate the path and object name requested by the
client prior to its use in setting the cache key and requesting a resource or authentication from the origin.
The Advanced Path Rewriting (aka Path Substitute) capability can be used to alter the URI of the incoming
request prior to looking for the resource in the cache. This has an effect similar to the Selective Query
String Handling Mode, for example, but it operates on the path as well as the query string.
The path-substitute configuration setting is applied on per property basis and allows for regexp processing
of the incoming URI for find/replace operations. POSIX Extended Regular Expression syntax is supported
including up to 9 sub-expressions and back referencing.
This feature allows for a wide array of ―content adaptation‖ applications in conjunction with other
configuration settings.
Override Vary Header
This feature, VHOMode, allows the manipulation of a Vary: header received from the origin server. The
header may be removed, replaced, or modified by adding or deleting values. May be used to apply
consistent Vary processing across groups or types of resources delivered from disparate locations or origin
server applications.
Alternative Range Headers (URL-based Range Requests)
Customer applications may request a portion of a cached resource by specifying the byte-range request in
the URL rather than using standard HTTP byte range request headers.
The request token may be specified in either of two ways:
1. @<x>-<y>@ coded at the end of the URL
2. x-bits-range=<x>-<y> as the first token of the query string
If configured and present, this results in the CDN serving bytes <x> thru <y> (inclusive) of the requested
resource.
Page 59
If the resource is subject to authentication, a revalidation request is submitted to the authentication server
with the byte-range parameter removed.
If the resource is not in cache, a cache-fill request is sent to the origin server. If more than 100KB of the
resource (from the beginning or the current fill-point) is required to satisfy the request, a Range: header is
attached to the request to the origin.
If successful, the origin server returns the requested range with a 206 (Partial Content) response code, the
resource is served to the requestor and a full-resource cache-fill is initiated in the background.
If a cache-fill is in progress that will satisfy the request, the request waits for the fill to finish.
Examples:
http://www.example.com/largefile@<1001>-<1999>@
http://www.example.com/largefile?x-bits-range=1001-1999&custid=12345
X-Forwarded-For Manipulation
The edgeserver has the ability to perform a variety of manipulations on the X-Forwarded-For header
which is intended to provide a ―trail‖ of the various clients and proxies from which a request originated or
through which it was proxied. This feature allows the origin to see the addresses of only desired proxies
and/or the client.
If present, the X-Forwarded-For: header contains a comma-separated list of the IP addresses in the
chain, with the rightmost address being the most recent.
Level 3‘s CDN controls the content of the X-Forwarded-For: header sent to origin servers, so that
information about the external client request is in a useful form.
The entire header may be supplied or an existing header may be appended to or replaced.
This does not affect the headers sent to cache peers which convey forwarding information via a different
mechanism.
Geographic Intelligence
Level 3‘s Geographic Intelligence module is an optional feature for Streaming and Caching Services.
Whether your needs call for basic country level policy management or complex delivery policies based on
multiple geographic and network attributes simultaneously, Level 3‘s Geo Intelligence module offers
customers the capability to seamlessly support their business objectives.
If the country of origin of a request is to be used to determine validity, a configuration setting will indicate
that the edgeserver should determine the country and attach a country-code header to the request. The
header is passed to the origin server or the authentication location with cache fill or revalidation requests.
This facility also provides the origin server the ability to deliver a different version of a resource based upon
the country code. When used, a Vary: header should be attached so that the edgeserver may properly
cache the resource and serve it for subsequent requests from different countries.
Level 3‘s CDN support two levels of Geographic Intelligence:
•
Basic Geo Intelligence – Enables geographic filtering to be applied by Country
•
Enhanced Geo Intelligence – Enables geographic filtering to be applied by Country, State / Province,
City, MSA, DMA, Zip, Device, and Network
Page 60
Performance Features
Compressed Content Encoding
Modern browsers and media players are capable of accepting compressed content to improve download
times and overall performance. Level 3‘s CDN supports several different compression styles and may be
configured to perform compression at the edge, offloading varying amounts of overhead from origin
servers.
Commonly used compression styles are ―gzip‖ and ―compress.‖ The ―identity‖ style indicates no
compression.
Available options further allow compression to be suppressed or ignore encoding headers.
When an Accept-Encoding: header is received, the edgeserver determines which actions are to be
taken, based on the configuration for that object. Available options are:
•
NoConvert – End user Accept-Encoding: headers are passed unchanged to the origin. No
conversions are performed at the edge. This is the default value
•
AllowConvert – Conversion between compression styles (and/or the identity style) is permitted at the
edge. The standard Level 3 Accept-Encoding: header is always sent when requesting content from
the origin, even if one was present in the end user‘s request
•
ServeIdentity – The standard Level 3 Accept-Encoding: header is always used when requesting
content from the origin server, but the identity style is always returned to the client (the client AcceptEncoding: header is ignored). Conversion between compression styles is permitted at the edge, but
only to the identity style
•
Ignore – No special handling is enabled and no conversion is performed. When requesting content from
the origin server an Accept-Encoding: identity header is always used. Any AcceptEncoding: header in the client request is ignored. Any Content-Encoding: header received from
the origin server is also ignored, but passed through unchanged to the client
Page 61
Compression
Method
NoConvert
Accept-Encoding Header
Sent to Origin
End User
Object sent by Origin
Object sent to End User
Uncompressed
Uncompressed
Compressed
Compressed
(Error if incompatible
compression types)
ServeIdentity
Level 3 Standard
Uncompressed or
Compressed
Uncompressed
Uncompressed
Compressed
(Uncompressed if browser
does not accept compressed
encoding)
AllowConvert
Level 3 Standard
Compressed
Compressed by compression
method requested by browser
(Uncompressed if browser
does not accept compressed
encoding)
Ignore
Accept-Encoding:
identity
Uncompressed
Uncompressed
Compressed
Compressed
(Error if incompatible
compression types)
The default Level 3 standard Accept-Encoding: header value is:
deflate;q=1.0,gzip;q=.5,identity;q=.2,*;q=0
Foreground/Background Traffic
Level 3‘s CDN service is used by many different customers with different application profiles. This feature
implements Foreground and Background traffic categories in which Foreground traffic (the default
category) receives priority over Background traffic if both are ―competing‖ for capacity. This is not directly a
performance ―class of service‖ but more an optimization of capacity allocation, where Background traffic is
allowed to fluctuate and consume any available ―spare‖ or idle capacity within the CDN (governed by
bindings policies).
Example Cases
This feature is most directly applicable to applications where the download experience does not have high
end-user perception requirements. Typical uses of the Background class of service are for downloads that
occur in an automatic or transparent fashion and use a programmatic updater or download manager to
facilitate the retrieval of software updates, security updates, media files, etc. Good examples are
applications such as:
•
Automatic Updates – An automatic updater checks with a web service to determine if updates are
available/required. If so, it manages the download in the background completely transparently to the
end-user. It can accommodate interruptions, throttling of the download based on ―idleness‖ of the
connection/computer, even resuming the download if it is interrupted (e.g., the computer is shutdown
during a long-running download). When the download is complete, the updates are installed/applied –
which is often the first/only indication that a download was actually performed
Page 62
•
Antivirus Pattern Updates – All security software, in addition to downloading periodic program updates,
perform regular updates of virus pattern files, spyware detection, and other elements due to the
frequent emergence of new threats. Again, this experience is typically transparent to the end user, is
invoked automatically upon system startup, and runs in the background with perhaps an indication that
an update has occurred upon completion
•
Buy-now/Play-later or time-shifted media delivery – Consider a popular online media delivery model.
The user selects from an available programming list and the selected assets are made available within
a specified amount of time (i.e., next day, 2 hours, etc). Other emerging applications are nVoD (near
Video on Demand), ―TiVo‖-style episodic delivery (always record a certain episode, genre, artist, etc.)
Feature Description
With this feature, a Property or Configuration Set can now be flagged as using the Background profile
(Foreground is the default and the most widely used). This causes the network to allow Background traffic
to be shed to other clusters when an individual cluster is approaching its load limit. In this way, Background
traffic can be bound to a wider cross section of CDN infrastructure and will automatically ebb and flow
based upon traffic requirements of all Foreground traffic. This feature is implemented through enhanced
collection of differentiated metrics at each of the traffic serving clusters and integration of those metrics into
the traffic management system (BDS/DNS) such that Background traffic can be directed to alternate
locations as individual locations become busy.
Extended Library Support (CDXL)
End users demand a high-quality experience when requesting any Internet content – popular or unpopular.
We have combined our massively scalable storage capabilities with the latest caching technologies and
intelligent analytics to deliver content precisely to the right place at the right time, every time. Should a
piece of content become highly popular, our intelligent algorithms instantly detect a change, and populate
the edge caches with the relevant files. Files requested less often are delivered from locations closer to our
storage super nodes to help reduce costs while still providing end users the quality experience they
demand.
Content Delivery for Extended Libraries (or CDXL) is a complimentary service offering within the Caching &
Download segment of the CDN Portfolio that combines the Level 3 Storage and Caching & Download
solutions together with an Intelligent Popularity-based Redirection Service to effectively support the
distribution and delivery of very large libraries of content that often have an extensive ―long tail‖
consumption pattern.
The architecture of this capability consists of a standard Caching & Download service implementation in
which requests for a customer‘s content get directed using standard Best Distributor Selection (BDS) to
appropriate edge caching clusters. For the set of content which is configured as CDXL-enabled, if the
content is not currently in the cache, instead of directly making a cache fill request to the configured origin,
the caching cluster first contacts the Popularity Service that runs as a distributed web service overlayed
across a subset of edgeserver cluster locations. This Popularity Service keeps a running histogram of all
requested assets across the configured properties. Based upon a set of pre-defined thresholds, the
Popularity service returns a response to the requesting cache which determines where the resource is
served from. There are 3 basic types of response:
•
Serve from Origin – This is the case in which the requested resource has NOT achieved a popularity
threshold indicating that it has been requested frequently enough for retrieval into the CDN. This
response returns in the form of a standard HTTP redirect which causes the edgeserver to pass the
redirect along to the client which will then make a subsequent retrieval request from the designated
Origin location. It is important to note that the configured Origin can be any arbitrary host which
contains the content. Therefore, the origin could be the Level 3 Storage service or the customer‘s own
Origin server.
•
Serve from Parent – This is the case in which the requested resource has achieved a degree of
popularity that is sufficient to warrant caching the resource in a subset of locations that is broader than
Page 63
the Origin but not as extensive as the Edge footprint. This case assumes that there is the existence of a
hierarchy of caches configured as a Parent or mid- tier. It is important to note that this is not necessarily
the case and that the threshold parameters can be configured in a variety of ways to support the
existence or absence of a Parent tier or hierarchy, depending upon the needs of the application. In this
case, the response to the requesting cache, again, takes the form of a redirect issued to the edgeserver
which is then issued to the client. In this case, rather than the origin hostname, an alternate hostname
configured via ITM policy is issued that directs requests to the Parent hierarchy based on bindings,
performance, and load-based policies within the CDN.
•
Serve from Edge – This is the case in which the requested resource has become sufficiently popular as
to warrant retrieval and caching at the edge of the network. In this case, the response to the requesting
cache is a redirect with the ―follow‖ flag set (see Follow Redirects feature described below). This
causes the edgeserver to follow the redirect to the source of the content rather than issuing the redirect
back to the client. The result of following the redirect is that the edgeserver receives and caches the
resource. Subsequent requests would then be served directly from cache per normal processing with
all normal cache control, aging, and other aspects of the CDN applying.
The general operation of the CDXL service is pictured below:
Figure 23: Scenario: Content Served from Edge (“Popular” Scenario)
1. The edgeserver receives a request for content that is designated as ―Extended Library‖ using
Supername or property configuration rules (i.e., ―Long tail‖ feature is enabled on a per-Property
basis). Extended Library content results in a request being generated to the Popularity Service if the
resource is not already in cache – implying that it has not yet exceeded the ―edge‖ popularity
threshold.
2. The Popularity Service tracks popularity of resources using request histograms. Popularity
Thresholds are established at setup to determine whether to serve resources from Edge, Parent, or
Storage tier.
Page 64
3. In this scenario, the resource has achieved ―edge‖ popularity threshold. The Popularity Service issues
an HTTP redirect (302) response to the edgeserver. The redirect destination corresponds to the
normal cache-fill path configured for the property.
4. The HTTP Redirect is received by the edgeserver that received the original request. The edgeserver
follows the redirect itself instead of passing it back to the client.
5. Upon receiving the response from the Parent or Origin, the edgeserver caches the resource per the
normal process. At this point, subsequent requests for this resource can be satisfied directly out of
this edge cache until the resource expires or is aged out of the cache.
6. The edgeserver serves the requested resource to the end user.
Operational Explanation
The Popularity Service is a fairly simplistic mechanism whose purpose is to track requests for resources
across a period of time, determine whether a given resource has reached one of the pre-defined popularity
thresholds, and based upon the threshold achieved, tell the cache making the request how/where to
service the request. The popularity service does not itself take into account other metrics like load, network
performance, etc. Once the appropriate response (a redirect) has been generated, the edgeserver or client
following the redirect will make use of an additional BDS or ITM policy decision about which physical
infrastructure will service the subsequent redirected request.
The Popularity Service is designed around resource libraries on the order of 100 million resources. Beyond
this limit the library would have to be segmented across multiple Properties or Configuration Sets.
In order to track popularity across a time domain and provide appropriate aging characteristics, the
Popularity Service establishes a per-resource histogram containing some number of buckets, each
representing a unit of time. While the number of buckets and time per bucket are configurable per Property,
they are established during configuration and are anticipated to be relatively static for the Property. Each
bucket tracks the number of requests received within the allocated time. Popularity is determined by the
sum of the request counts across all the buckets. The combination of buckets and time intervals is intended
to provide a balance between responsiveness (i.e., detecting increasing/decreasing popularity within a
suitable amount of time), and data volume (i.e., amount of popularity data to have to store in memory). We
configure the Popularity Service to track popularity across some small number of hours or days (e.g., 6 –
48 hours). Further the number of requests in a given unit of time that triggers the various thresholds is
anticipated to be reasonably small. Some small number (tens to dozens) of requests in that range of time
would be anticipated to be sufficient to move a given resource up the popularity ―stack‖.
The following diagram depicts some of the mechanics of the Popularity Service and how popularity
histograms and thresholds interact.
Page 65
Figure 24: Object Popularity and Thresholds
Follow Redirect
When an edgeserver receives a redirect from an origin server in response to a cache-fill request, it
ordinarily returns the redirect to the client where a new request will be generated and submitted to the new
location. The Follow Redirect option allows an additional custom header to be detected that enables
special handling of redirects.
Utilization of this feature retrieves the resource from the indicated redirect location, serves it to the end
user, and stores it in cache as appropriate without the additional overhead required to return the request to
the client.
The origin server may attach a flag to specify the desired redirection behavior for a response.
This feature can be implemented on a property-wide basis or restricted to particular resources via a typical
match, such as for a path element or a resource file name extension. The feature has the following options:
Page 66
Option
Definition
header
Inspect the response headers for the presence of an X-WR-Features: header. If present and the header contains the
name/value pair follow=true, then the Follow Redirect mode is applied to this response. Otherwise, the redirect is
processed normally
always
Always follow redirects when received for this property or resource unless the X-WR-Features: header is present and
contains a follow=false directive
never
Do not process follow redirects for this property or resource
Other Considerations
This feature can be used recursively and will follow redirects up to an arbitrary depth (by default 32).
This feature can be applied to the various ―flavors‖ of redirection (temporary and permanent) and can be
configured to be applied to an arbitrary status code response.
Large File Delivery
Level 3 can normally support delivery of files up to 7 GB in size. Operations can work with a customer to
develop custom configuration settings to deliver files sizes above 7 GB. See your sales engineer for more
details.
China In-Country Delivery
In order to improve the speed and performance of delivery to end user located within China, delivering
content from edgeservers located in-country is important. Without this option, all content is delivered to end
users located within China from edgeservers outside of China.
Level 3 currently supports only non-secure delivery within China with this option.
The customer needs to sign a special Level 3 China contract amendment and have their own ICP license.
Page 67
Streaming Features
Dynamic Streaming
Dynamic Streaming is a new feature Adobe has introduced into FMS 3.5. It is a new quality of service
monitoring feature that detects any changes in end-users bandwidth and, during playback, automatically
switches to a content bit-rate that more appropriately matches the quality of the end user‘s connection. This
ensures a high quality, uninterrupted stream. Dynamic Streaming is ActionScript-controlled with newly
introduced methods and requires Flash CS4 or Flash Player 10 and above to play the stream.
Smooth Streaming
Smooth Streaming is a new feature Microsoft has introduced into Silverlight. It adapts the quality of the
video stream sent to the player in real-time based on the player‘s bandwidth and CPU load (for video
rendering) by changing the stream sent to the player to either a higher or lower bandwidth version if
available. The streams are delivered in chunks over HTTP. End users with faster video-processing
capabilities and higher bandwidth receive higher quality streams, and those with slower processing or
lower bandwidth receive a lower-quality stream that is appropriate for the capabilities and environment of
their player.
QuickTime X (iPhone) HTTP Streaming
Apple has introduced QuickTime X which supports HTTP streaming. As with Smooth Streaming, it adapts
the quality of the video stream sent to the player in real-time based on the player‘s bandwidth and CPU
load by changing the stream sent to the player to either a higher or lower bandwidth version if available.
The streams are delivered in chunks over HTTP along with the manifest. The player has to pull the
manifest as it is not included with the chunks.
Flash Scrubbing
Flash ―scrubbing‖ refers to the use of various navigational elements to jump forward or backward in a
media asset during progressive download playback. This is often implemented using various user interface
elements on the player presentation such as forward/backward arrows, slider bars, ―chapter‖ indexes/jumppoints, etc. This capability is also sometimes referred to as ―FLV Seek‖. It is important to note that while
standard player implementations typically include these functions (at least fwd/rew and play progress bar),
these can be disabled via metadata in the media asset or by the customer ―wrapping‖ the core player
window within a custom UI by skinning, or embedding on a web page. As such, there is no universal
standard for implementing scrubbing or in-play navigation. It is up to each property and indeed the
technical approach taken by the site developers.
In the end, the effect of enabling in-play navigation is that the player can make a series of ―range requests‖
for portions of the media file. As is typically the case, if the file is being streamed (using the proprietary
Flash Media Server) the player and the server have the appropriate interfaces to accomplish this natively.
However, as Flash delivery via HTTP progressive download is starting to dominate many segments of the
media delivery market, there are some issues that arise:
•
Range Request – When a scrubbing operation is performed, the player makes an associated ―range
request‖ (request for certain bytes of the resource). While HTTP supports a standard range request
format via request headers, the Flash player does not support manipulation of standard HTTP headers.
This has tended to force developers to use non-standard practices for making range requests for Flash
progressive download content. This is usually implemented using parameters or tokens within a query
string
•
Metadata Stitching – When a portion of a media file is requested, the player expects the presence of
metadata in the file describing the file, various keyframe indices, and other elements in order to
Page 68
successfully render the partial ―chunk‖ of the media file. Alignment may also be required to ensure that
the requested chunk starts at a keyframe and other factors specific to the Flash codecs, but these
considerations are beyond the scope of this feature
This feature is designed to deal with both of these pre-conditions to delivering partial content requests for
Flash-encoded media content over HTTP.
Implementation
Flash scrubbing is enabled at the Property / Configuration Set level. The following parameters govern the
behavior of this feature:
•
Scrubbable – a Boolean value that indicates that this feature is either enabled or not for this property
(i.e., the feature is ―on‖ or ―off‖). Default is ―off‖
•
Scrub_Extensions – specifies appropriate filetypes. The system checks the filetype/extension on the
requested URL to ensure that it is one of the affected file types
•
Scrub_Tokens – identifies the URL ―Range Tokens‖ that will specify the starting and ending range
values for the request in the Querystring element of the URL. As with other similar features, we allow
the customer to specify the tokens that they use. This avoids creating a syntactic constraint on their
publishing system, and better enables us to participate in a multi-vendor implementation scenario by
providing flexibility around the format of the URL. The value of the tokens is a string literal that will be
matched in the URL. Two possible tokens can be specified:

Start – the token that will represent the starting byte of the range request (e.g., ―start‖, ―s‖, ―from‖,
etc.)

End – the token that will represent the ending byte of the range request (e.g., ―end‖, ―e‖, ―to‖, etc.)
The following diagram depicts how Flash Scrubbing is supported by the CDN.
Page 69
Figure 25: Flash Scrubbing
Supported Flash Streaming Protocols
The CDN platform supports RTMP, RTMPE, RTMPT, and RTMPTE.
RTMPS is not supported.
FCSubscribe Support
Level 3 supports the Adobe FCSubscribe client-to-server call syntax that is used to begin sending the live
Flash stream to the player and begin buffering and then playing. This call sends a message to the
edgeserver to pull the live stream from the ingest server if it is not already being delivered to that
edgeserver.
Page 70
Vyvx Broadcast Services
Level 3 Vyvx Broadcast Services
We are America‘s largest provider of integrated video transmissions services, providing customers true
end-to-end solutions using our network of fiber switching centers, teleports, and satellites. Level 3 Vyvx
offers acquisition and distribution video services that the media industry has relied on for more than 18
years.
We support your needs to transport broadcast-quality video content anywhere at any time with our 24 x 7
booking and customer care center, online vyvxInView® system, and Local Interconnectivity Directory (LID),
all used to manage your video transmission needs.
We offer both occasional and dedicated services, depending on your solution requirements.
From our analog services to our digital standard definition (SD) and high definition (HD) offerings, our
Level 3 Vyvx services set the pace for the media business by achieving industry-leading SLAs and by
maintaining worldwide connectivity.
Additional components of the Vyvx offering include:
•
Award-winning customer service and media industry expertise
•
Largest terrestrial HD footprint, as well as largest domestic teleport footprint
•
Fiber connectivity to more than 115 cities in the United States, Canada, UK, Continental Europe, and
Japan
•
Direct connectivity to more than 100 professional sports venues in the United States and Canada
•
Full-service, 24 x 7 secure facilities staffed with an experienced and responsive team of professionals
to provide trouble-free, reliable operations
•
Accessibility to all major television markets
•
Continual network investments to support your performance
Terrestrial Service Offerings
The Level 3 Vyvx portfolio is a suite of offerings to cover all video backhaul needs, from video conferencing
and talking-head interviews, to dedicated cable content and live sports events. Also, our First Video Affiliate
(FVA) partners are available for ad-hoc, U.S. video transmission and production needs by maintaining fulltime connectivity to our network. This provides end-to-end solutions for all types of media, including postproduction and graphic design services.
Terrestrial services include Analog Transport, MPEG, Digital Transport, and HD offerings.
Teleport and Satellite Service Offerings
The Level 3 Vyvx offerings rely on three strategically located Teleports in Atlanta, Denver, and Los
Angeles, which Level 3 owns and operates, in addition to 22 Virtual Teleport cities, which offer analog
backhaul to the physical teleport facilities at no additional cost. Our Teleports offer a wide range of
dedicated and occasional teleport and transponder services, including analog and digital transmission,
encryption, standards conversion, HD encoding, tape playback and record, and colocation.
Page 71
Live Encoding Services
Level 3SM Encoding Services provides scalable, redundant, and cost-effective encoding as a facilitator for
the delivery of IP-based live streaming content in the industry-leading formats. Today these formats are
part of media platforms that include Adobe Flash, Microsoft Silverlight, and Apple QuickTime.
Encoding is the process whereby a video source is converted from the format in which it was captured,
usually ―uncompressed‖ (highest quality available) or of much higher quality, into a compatible format,
typically ―compressed‖, that is suitable for IP-based delivery. Encoding is accomplished using software and
hardware which is licensed as a product or service and ―codecs‖ which are compression algorithms that
are used to reduce the size of content while maintaining various levels of quality.
In contrast to on-demand encoding or transcoding, live encoding is the conversion of a ―live‖ video signal in
one format, typically at broadcast quality, to a format that is suitable for IP-based live streaming delivery.
Live encoding is a key component in the digital media workflow required to delivery IP-based live streaming
content, which typically consists of the following:
•
Content creation (camera and production, onsite at the venue)
•
Signal acquisition (video signal transmission, commonly accomplished using terrestrial means or
satellite downlink from the venue, ultimately to the encoding facility)
•
Live encoding (conversion of the live video signal into compatible formats for delivery online)
•
Distribution (ingest from the encoding facility into the appropriate networks, including Level 3 CDN)
•
Consumption (viewing of the content by the end user)
•
CDN
Streaming
Vyvx Broadcast
Encoding
Services
Origin
Storage
Cache/Download
Network
Figure 26: Broadcast Encoding to Streaming
Key features
Key features include:
•
Geographically disperse locations for high availability, flexibility, and redundancy
•
Support for multiple sources of signal acquisition including:
Page 72
•
•

Fiber transmission using Vyvx services with SDI (SD and HD quality input signal sources) or ASI
(SD only)

Satellite downlink using Level 3 Teleport, Virtual Teleport, and consumer grade services

Support for dedicated (24/7) and occasional use
Multiple output streaming formats including:

Microsoft Windows Media (VC1-encoded and H.264-encoded content)

Adobe Flash (VP6-encoded and H.264-encoded content)
Adaptive streaming

Microsoft Smooth Streaming

Adobe Dynamic Streaming

Apple HTTP streaming for the iPhone*
•
Archive for on-demand playback*
•
DVR for rewind*
•
Site and stream level redundancy
Supports the following value-added options:
•
Conditional access control. Protect (i.e., prevent unwanted possession and use) and target (e.g., serve
different quality based on factors such as device) content at the ―link‖ and ―stream‖ levels through token
authentication, geographic intelligence, and encryption (protocol and DRM) during and after a live event
•
Live DVR/PVR. Rewind and pause live streaming content during a live event
•
Auto-archive. Provide access to live streaming content after a live event is completed through true ondemand, file-based playback
•
Live content control. Prevent portions in live streaming content from being displayed (in accordance to
content owner/publisher demands) automatically with a schedule defined using an Electronic
Programming Guide (EPG), and optionally replace this content with a slate
•
Enhanced monitoring. Assurance that live streaming content is working as intended with automated
and ―eyes on glass‖ support. This is above the standard guarantee that live streaming content is active
(i.e., services are operating)
Page 73
Management Services
Level 3 Media Portal
The Level 3 Media Portal is a robust online customer tool, providing fingertip access to information at any
time. As a single point of secure access, the portal provides a transparent interface to back-end source
systems to offer more efficient resolution of service issues.
The Portal also provides access to a broad set of functionality to view and manage service needs.
Supported functions include ordering, ticketing, billing, network performance reports, and CDN functions.
Viewing permissions are customized based on user-specific requirements.
The CDN-based functions include Reporting and Invalidation.
Reports may be viewed on-demand or scheduled for email delivery and may include URL-based
information (hits, download sizes, errors, etc.), performance, and SLA compliance, as well as Property,
regional, and storage usage.
The Dashboard provides traffic data, including hits, sizes and times in map, list, and chart formats.
Figure 27: Portal Dashboard
URL-based data may display only the most popular resources or only those generating the most errors.
The CDN Invalidation Portal provides on-demand invalidation of cached resources to assure the freshness
of web-based content when automated expiration policies are insufficient. Resource designations may be
identified in a web form, submitted from a file, or transmitted using a command line interface. Resources to
be invalidated are identified by origin path using expressions with wildcards and flexible match-criteria.
Page 74
Invalidations are broadcast to all applicable CDN servers in the network. The status of submitted
invalidations may be monitored and reported as pending, in-process, or complete.
See the on-line Help in the Media Portal for a complete description of the reporting and configuration
features.
Logging
In addition to the reports available in the Level 3 Media Portal, standard and Remote Logs can be made
available for customers to download.
Analysis of transaction logs can provide insight into the utilization and performance of web sites,
applications, content, and hardware/software resources, as well as being an invaluable tool for analyzing or
debugging new or errant functionality. Response times, resource usage, traffic, trending, geographic
patterns, errors, and a wealth of available information can be derived from the logs generated by CDN
edgeservers.
Since the volume of log data generated by a busy server can be extremely high, handling of the sizeable
log files produced requires planning and consideration of potential value gained vs. the resources required
to retrieve and analyze the data.
Log volumes may be reduced by sampling (keeping only every nth entry) but are increased if Cookie:,
Referer: or User-agent: (OS/Browser/Media player specifications) headers are needed.
Standard log data may be retrieved for analysis and archival with the CDN Advanced Log Retrieval Tool
(ALR). Versions are available for installation on Windows or UNIX workstations.
Level3
CDN
Standard
Logs
Level3 Log
Collection
Servers
Customer
Workstation
With ALR
Remote
Logs /
Download
Receipts
Customer
Remote Logging
HTTP Server
Figure 28: Log Processing
CDN Configuration
Log generation at the edgeservers may be configured by the specification of options at the Configuration
property level or for all properties belonging to a customer.
Available options include:
•
Keep entries for standard log processing
•
Select entries for Remote Logging
Page 75
•
Keep only every nth entry (sampling)
•
Log Cookie:, Referer:, or User-agent: (Browser/Media player specifications) headers
Additionally, a configuration flag may indicate log suppression at the resource level using flexible patternmatching notation (e.g., images/*.jpeg).
By default, the log file entries contain the entire URL, including the full query string, as presented by the
end-user, even if CDN is configured to ignore query strings for the purpose of caching (QSHMode).
Download Receipts (Remote Logging)
The Download Receipts feature (Remote Logging) configures the CDN to notify a remote server about
certain requests whose responses either served the last byte of the requested resource or resulted in an
error. The edgeserver transmits the Download Receipts to the appropriate customer-designated Remote
Logging collection server.
With this feature enabled, the edgeserver sends data about these events as they occur instead of waiting
for the standard log collection and reporting processes.
The Download Receipt can include the following for each applicable event – timestamp, resource ID, URL,
download size, download time, IP address, status codes, and flags. Current remote log records are
collected on a time interval basis and forwarded to a collection point specified by the customer.
The customer must host a suitable HTTP server with adequate transaction processing and storage
capacity.
See the Logging / Log Retrieval Remote Logging Technical Feature Brief for more details.
Page 76
Professional Services
Event Management Services
Level 3 Communications offers an end-to-end, global Event Management service for online event delivery
and support. We combine our signal acquisition experience with Level 3 Encoding services and CDN
platform and deliver it to you with project management and professional services expertise.
Our Event Management offering combines a powerful, end-to-end feature set with centralized project
management and operations assistance. We connect you with the technical expertise and day-to-day
assistance necessary to deliver mission critical events at the highest levels of performance. Our
comprehensive platform reduces the need for multiple vendors to deliver and support both live and ondemand events, to offer you a uniquely qualified offering.
Benefits
End-to-End Delivery and Support for Online Events
Our comprehensive platform reduces the need to work with multiple vendors to deliver and support online
events.
Tested Event Delivery Experience
We combine a 20-year signal acquisition track record with our Encoding Services and CDN platform to
bring proven services to online audiences.
Combined Technology and Expertise
Our powerful, end-to-end feature set is delivered with centralized project management capabilities and
operations assistance to help bring high performance to your mission critical events.
Service Details
•
Signal acquisition services (Level 3 Vyvx Services)
•
Level 3SM Encoding services (using Adobe Flash, Windows Media, Smooth Streaming, Apple
QuickTime, and Move Networks technologies)
•
CDN services including progressive download delivery, streaming support and storage
•
Content Management System support (EU only)
•
Self-service provisioning tools
•
Reporting and analytics
•
Dedicated project management support
•
Dedicated technical resource support
Integration Services
Level 3 offers different levels of standard and custom integration services, depending on customer
requirements. Integration services may include the following tasks:
•
Content delivery optimization
•
Customer token authentication generation and validation
•
Geo-blocking and geo-targeting rule set generation
•
Content ingest mechanism integration
Page 77
•
Video player implementation and integration
•
Provisioning of streaming mount points
•
Storage account configuration
•
Log file delivery automation
•
Third party CMS/DAM integration
Level 3 is able to undertake custom integration services as required for specific customer implementations
and projects. Cross-functional teams with appropriate domain expertise across Caching, Streaming,
Storage, and ITM can be assembled as required to address specific integration requirements.
Application Development Services
In addition to Integration Services, Level 3 is able to undertake complex application development projects
that leverage our content delivery platform. Specifically, Level 3 Media Delivery services comprise a set of
application level components designed to enable management of online content. Media Delivery services
provide comprehensive support for content management, protection, and monetization together with a
flexible reporting package.
Level 3 has extensive experience in the implementation and service management of customized
application services. Specific functionality included in past implemented solutions includes: live and ondemand streaming facilities, Digital Rights Management (DRM), Geo-Targeting solutions, EPG (Electronic
Program Guide) integration, Auto Archiving of live broadcasts, full reporting capabilities, transaction
processing and subscriber management for paid content solutions.
Project management methodology for custom application development follows Rational Unified Process
(RUP) together with a combination of best practices in project management areas that are not covered by
RUP.
Page 78
Appendix A: Using ASX Files
Level 3‘s Microsoft Windows Media platform has the ability to use Advanced Stream Redirector files also
known as ASX files. ASX files allow streaming links to be embedded as an abstraction method rather than
directly exposing the streaming links to the media player. The example provided below is only for
demonstration.
<ASX version = "3.0">
<TITLE>Simple ASX Demo</TITLE>
<ENTRY>
<TITLE>An Entry in a Simple ASX</TITLE>
<AUTHOR>Level 3 Communications</AUTHOR>
<COPYRIGHT>(c)2008 Level 3 Communications, LLC</COPYRIGHT>
<REF HREF = "mms://Level 3mediawm.fplive.net/Level 3media/testFile.wmv" />
</ENTRY>
</ASX>
Advanced ASX functionality such as generating dynamic library lists and inserting playback times is
beyond the scope of this document.
Page 79
Appendix B: Firewall Port Access
Some end users have very restrictive firewall policies and do not allow unfettered access to the Internet. It
may be necessary to open up specific ports in order to enable streaming media to be played back by the
end user. The following is a list of IP ports that should be enabled in order to allow for streaming services:
Microsoft Windows Media
Application
Protocol
Protocol
Port
Number
Description
MMS
UDP/TCP
1755
A proprietary protocol used with earlier versions of the Media Player. Often still used as
the default streaming protocol as it assures compatibility with end users. Level 3‘s
streaming service is designed to take advantage of rollover capability where Level 3 first
attempts to connect to the player using UDP and then rollover to TCP. The MMS
protocol was depreciated with version 9 of the Microsoft Media Player; however, it can
be used with current Media Players. MMS is only used as a rollover protocol in Windows
Media Player 11.
MMSU
UDP
1755
Forces requests to only use UDP as the protocol
HTTP
TCP
80
Secure streaming.
Real Time
Streaming
Protocol
(RTSP)
TCP
554
Streaming RTSP over TCP. Not backwards compatible with older Windows Media
Players.
RTSPU
UDP
5005
Forces the RTSP request over UDP only. Not compatible with older Windows Media
Players.
Application
Protocol
Protocol
Port
Number
Description
RTMP
UDP
1935
Default streaming port
RTMPe
UDP
443
Secure streaming
RTMP
UDP
80
Streaming over HTTP
RTMPt
TCP
80
Tunneling RTMP within HTTP packets
Adobe Flash
The Level 3 streaming platform will progresses through the various ports in an attempt to connect to the
end user. It is recommended that customers specify the protocol to improve startup time and minimize the
cycling time that the end user player would otherwise go through as it progresses through the various port
options.
Page 80
Appendix C: Protocol Rollover
Level 3‘s streaming platform supports protocol rollover to help mitigate issues with NAT and firewall
devices. If the customer specifies a generic protocol such as RTSP or RTMP, the end user player will
attempt various connection options with the edge Level 3 streaming media server until it finds a suitable
port/transport method for stream delivery.
Windows Media
When Windows Media Player 9 Series or later or a player that uses the Windows Media Player 9 Series
ActiveX control tries to connect to the server using a Microsoft Media Server (MMS) URL moniker
(mms://) in the connection URL to a streaming content, for example:
mms://Server_Name/File_Name.wma
The server automatically delivers the content by using RTSP.
1. The server will try to deliver the content using RTSP with TCP-based transport (RTSPT).
2. If the Player does not support that protocol, then the server tries to deliver the content using RTSP
with UDP-based transport (RTSPU)
3. If that connection is also not successful, the server will try to deliver the content by using the HTTP
protocol
When an earlier version of the Player, such as Windows Media Player for Windows XP, tries to connect to
the server using a URL with an mms:// prefix, the server automatically try to deliver the content by using
the HTTP protocol.
As mms continues to be used as the default streaming protocol, it has been depreciated by Microsoft.
However, the Level 3 streaming platform will auto negotiate to an acceptable port.
A specific transport can be forced to use a protocol such as RTSPT, RTSPU, MMSU, or MMST. If a
particular protocol is specified and the client player to connect, the Windows Media Server will not attempt
to auto negotiate to a different delivery protocol.
Adobe Flash
The end user client will attempt to auto negotiate its port/protocol differently depending upon which protocol
is initially requested.
RTMP – Real Time Messaging Protocol
1. If the port is not specified, the server will attempt to connect over port 1935
2. The sever/client will then attempt to negotiate a handshake over port 443
3. Subsequently, the server/client will attempt to connect via RTMPT over port 80
RTMPe – Encrypted Real Time Messaging Protocol (available with Secure Flash Streaming) Requires
Flash Player 9,0,115,0 minimum; Adobe AIR; Adobe Media Player
1. If the port is not specified, the server will attempt to connect over port 1935
2. The sever/client will then attempt to negotiate a handshake over port 443
3. Subsequently, the server/client will attempt to connect via RTMPTE over port 80
RTMPt – Real Time Messaging Protocol via TCP (encapsulated RTMP over HTTP)
1. The server/client will attempt to handshake over port 80
Page 81
RTMPte – Encrypted Real Time Messaging Protocol via TCP (available with Secure Flash Streaming)
1. The server/client will attempt to handshake over port 80
Notes
RTMPS and SSL encrypted delivery of RTMP streams is not supported.
H.264 playback in Flash Player supports most popular profiles including Base, Main, and HiP (High
Profile). The F4V format will be a new format moving forward that is a subset of MPEG-4 ISO 14496-10
and AAC+ (ISO 14496-3).
Page 82
Appendix D: Legacy Flex Token
Support
Token Types
Level 3 supports two different token types. The Flex token is supported as a legacy feature and should only
be used when compatibility with existing implementations is required. The Standard token should be used
in all new implementations. Each can be used with both streaming and with caching services.
Flex Token
Standard Token
Hash Algorithm
MD5
HMAC-SHA1
Hash Contents
Take the full URL and remove the protocol,
hostname, and unneeded query string
parameters
Take the full URL and remove the protocol,
hostname, and unneeded query string
parameters
Add start time, end time, #SharedSecret
Add any desired arbitrary or time validity tokens
Time Format
yyyymmddHHmmss in GMT or in epochseconds
yyyymmddHHMMSS in GMT or in epochseconds
SaltValue/SecretKey
The key should be expressed as a string value
less than 64 characters and should not include
the following Special Reserved Characters:
ASCII character string of up to 64 bytes
No Reserved characters
<>\?%&'#"{}|^[]*~$
Secret Table
No
Yes, up to 10 active secrets with Validity Times
for the secrets
Hash / Token Length
in URL
Token Query String
Parameter Name
token
Configurable, for example ―hash=‖
Base64 Encoded
Yes, start time, end time, and the hash are
Base64 encoded to create the token
No
Start/End parameter
names
start_time= and end_time=
Configurable, for example ―stime=‖ and
―etime=‖
First character designates secret number used,
then first 20 characters of calculated hash
Figure 29: Comparison of Flex and Standard Tokens
Page 83
Appendix E: Perl Self-Generated
Token Code Sample for Standard Token
#!/usr/bin/perl
# Sample code Copyright (C) 2009, Level 3 Communications LLC
# This sample requires perl modules freely available from CPAN.
# To obtain the needed modules, use e.g., "cpan -i Digest::HMAC"
## Parameters you would normally obtain from your configuration
$gen = "3"; # secret key generation number (0-9)
$key = "There's no place like home!"; # secret key
## Process an abspath URI
$uri = "/path/to/resource?sessionid=12345"; # the URI to authenticate
print "Orig URI: $uri\n";
$hash = ComputeHash($gen, $key, $uri, \$error); # Compute the hash code
$uri .= "&misc=abcde"; # Append a non-authenticated element
$uri .= "&hash=$hash"; # Append the hash code
print $hash ? "New URI: $uri\n" : "$error\n";
print "\n";
# Import the HMAC-SHA1 library
use Digest::HMAC_SHA1 qw(hmac_sha1 hmac_sha1_hex);
# ComputeHash() - compute the hash authenticator to append to a URI
#
# Parameters:
# IN $gen: A number 0-9 identifying the key generation number
# IN $key: A character string key between 20 and 64 bytes long
# IN $uri: The URI, less the hash code, to be authenticated
# OUT $rerr: Reference to scalar to return any error message
#
# Returns the hash string value if successful, otherwise returns undef
# and an error string via $$rerr
sub ComputeHash
{
Page 84
my ($gen, $key, $uri, $rerr) = @_;
# Most of this error checking would not be necessary in a production
# environment - it is provided for illustration of usage only.
$$rerr = "ERROR: Invalid GEN value", return undef
unless $gen =~ /^\d$/;
$$rerr = "ERROR: Invalid key length", return undef
unless length($key) >= 20 && length($key) <= 64;
$$rerr = "ERROR: No URI provided", return undef
unless $uri;
# compute the hash and check to be sure it worked
my $hmac = hmac_sha1_hex($uri, $key);
$$rerr = "ERROR: Failed to compute hash!", return undef
unless defined($hmac);
return sprintf "%1.1s%20.20s", $gen, $hmac;
}
Page 85
Appendix F: Perl Self-Generated
Token Code Sample for Standard Token
#!/usr/bin/perl
# TokenGenerator.pl
# Level 3 Communications
# October 1, 2008
# generateToken Function
#
# Creates a base64 token to use with
# Level 3 Communications CDN Streaming Token Authentication feature
# Server must be using GMT
#
# Input: String, StreamURL
# Output: String, Token (32-character hexadecimal md5 hash)
# use Digest::MD5 qw(md5_hex); use MIME::Base64;
sub generateToken($url)
{
# CUSTOMER - Change to your Customer Secret Key
$key = "secret";
# CUSTOMER - Change to token expiration time (in seconds)
$delay = 600;
# CUSTOMER - Use debug flag and logfile for troubleshooting
$debug = "false";
$logfile = "c:/logs/TokenGenerator.log";
# Set start_time to current time (Format: YYYYMMDDHHmmss)
($sec,$min,$hour,$mday,$mon,$year) = gmtime(time);
$start_time = sprintf("%04d%02d%02d%02d%02d%02d", $year+1900, $mon+1, $mday, $hour, $min,
$sec);
# Set end_time to current time plus delay (Format: YYYYMMDDHHmmss)
($sec,$min,$hour,$mday,$mon,$year) = gmtime(time + $delay);
$end_time = sprintf("%04d%02d%02d%02d%02d%02d", $year+1900, $mon+1, $mday, $hour, $min,
$sec);
# Create resource_path from url (remove protocol, hostname, port, queries & fragments)
$resource_path = $url;
$resource_path =~ s#^.*://([A-Za-z0-9_:\.\-]+){1}/#/#;
# remove queries or fragments
$resource_path =~ s#[\?\#].*##;
# Create message (Format: ResourcePath?start_time=StartTime&end_time=EndTime#SecretKey)
Page 86
$message = $resource_path."?start_time=".$start_time."&end_time=".$end_time."#".$key;
# Create digest by md5 encoding the message
$digest = md5_hex($message);
# Create token_value (Format: start_time=StartTime&end_time=EndTime&digest=Digest)
$token_value = "start_time=".$start_time."&end_time=".$end_time."&digest=".$digest;
# Create token by base64 encoding the token_value
$token = encode_base64($token_value);
# Remove any carriage returns inserted into token by encode function
$token =~ s#\n##g;
# If debug flag is set, write values to logfile
if ($debug eq "true")
{
open (FD, '>>', $logfile);
($sec,$min,$hour,$mday,$mon,$year) = gmtime(time);
$date = sprintf("%02d/%02d/%02d %02d:%02d:%02d", $mon+1, $mday, $year+1900, $hour, $min,
$sec);
print FD "$date - TokenGenerator Debug Output:\r\n ResourcePath-$resource_path\r\n
Message-$message\r\n TokenValue-$token_value\r\n Token-$token\r\n";
close (FD);
}
# Return token return $token;
} 1;
Page 87
Appendix G: Flex Token Format
Token URL Format
Level 3‘s URL that contains a Token follows a simple construct as follows…
Protocol://Hostname/Level 3_SubscriberID/ContentLocation/TokenString
the content, such as: (1) mms and rtsp for Windows Media; and (2) rtmp and rtmpe for Flash.
Hostname can be an external or Level 3-generated sub-domain from the f35.c.footprint.net
domain.
billing purposes.
TokenString contains all the necessary attributes for authentication that includes:
1. Delimited list of Files: All files associated to a common media content, that needs to be secured
under a single token, are included in the query string (QS) parameter and delimited with a ―;‖.
The files also have to begin with a ―/‖ and are identified as resource= in the QS element.
Windows Media example
Adobe Flash example
rtmp://xyzmedia.f35.c.footprint.net/xyzmedia/rtmp/mp4:sampleVideo500k?res
ource=/sampleVideo 500k;/sampleVideo800k.mp4;/sampleVideo1500k.mp4
In the above example, the Flash Media Server is instructed to start on the 500k content and is preapproved to allow transition changes to the 800k & 1500k files without needing additional tokens.
2. HMAC-SHA1 Hash: The other part of the query string (QS) is the hashed token itself. This is
included after the delimited list of resources and identified as token=.
Windows Media example
Adobe Flash example
rtmp://xyzmedia.f35.c.footprint.net/xyzmedia/rtmp/mp4:sampleVideo500k?res
ource=/sampleVideo500k;/sampleVideo800k.mp4;/sampleVideo1500k.mp4?token=0
46787b876e7539d78cc9
The token itself is made up of:
•
―Start Time‖ or ―Not Valid Before‖
•
―Stop Time‖ or ―Not Valid After‖
•
―SaltValue/SecretKey‖ that is then hashed together
Start and Stop times are in UTC/GMT format, for example: yyyymmddHHMMSS
Page 88
SaltValue / SecretKey is an ASCII character string of up to 64 bytes
On-Demand Flash .flv Streaming Token Example
Parameter
Example Input
Streaming URL:
rtmp://xyzmedia.f35.c.footprint.net/xyzmedia/rtmp/sampleVideo3
00kbps.flv
Start Time:
20080101120000
End Time:
20101231235900
Customer Key:
secret
ResourcePath:
/xyzmedia/rtmp/sampleVideo300kbps.flv
Message:
/xyzmedia/rtmp/sampleVideo300kbps.flv?start_time=20080101120000&end_time=201
01231235900#secret
Digest:
f06471ef3c5b2795576797463a4f8afb
TokenValue:
start_time=20080101120000&end_time=20101231235900&digest=f06471ef3c5b2795576
797463a4f8afb
Flex Token:
c3RhcnRfdGltZT0yMDA4MDEwMTEyMDAwMCZlbmRfdGltZT0yMDEwMTIzMTIzNTkwMCZkaWdlc3Q9
ZjA2NDcxZWYzYzViMjc5NTU3Njc5NzQ2M2E0ZjhhZmI=
URL:
rtmp://xyzmedia.f35.c.footprint.net/xyzmedia/rtmp/sampleVideo300kbps.flv?tok
en=c3RhcnRfdGltZT0yMDA4MDEwMTEyMDAwMCZlbmRfdGltZT0yMDEwMTIzMTIzNTkwMCZkaWdlc
3Q9ZjA2NDcxZWYzYzViMjc5NTU3Njc5NzQ2M2E0ZjhhZmI=
On-Demand Flash .mp4 Streaming Token Example
Parameter
Example Input
Streaming URL:
rtmp://xyzmedia.f35.c.footprint.net/xyzmedia/rtmp/sampleVideo3
00kbps.mp4
Start Time:
20080101120000
End Time:
20101231235900
Customer Key:
Secret
ResourcePath:
/xyzmedia/rtmp/sampleVideo300kbps.mp4
Message:
/xyzmedia/rtmp/sampleVideo300kbps.mp4?start_time=20080101120000&end_time=201
01231235900#Secret
Page 89
Digest:
f06471ef3c5b2795576797463a4f8afb
TokenValue:
start_time=20080101120000&end_time=20101231235900&digest=f06471ef3c5b2795576
797463a4f8afb
Flex Token:
ZjA2NDcxZWYzYzViMjc5NTU3Njc5NzQ2M2E0ZjhhZmI=
URL:
rtmp://xyzmedia.f35.c.footprint.net/rtmp/xyzmedia?token=c3RhcnRfdGltZT0yMDA4
MDEwMTEyMDAwMCZlbmRfdGltZT0yMDEwMTIzMTIzNTkwMCZkaWdlc3Q9ZjA2NDcxZWYzYzViMjc5
NTU3Njc5NzQ2M2E0ZjhhZmI=/mp4:xyzmedia/sampleVideo300kbps
When calling NetStream.Play(), the mp4: prefix must be included in the ‗name‘ parameter to identify
the file as an .mp4 file type, as follows:
var nc = new NetConnection();
nc.connect("rtmp://host[:port]/app/ins?token=value", ...);
...
...
NetStream.Play (“mp4:xyzmedia/sampleVideo300kbps”, ...);
On-Demand Windows Media Streaming Token Example
Parameter
Example Input
Streaming URL:
rtsp://xyzmedia.fplive.net/xyzmedia/sample/sampleVideo300kbps.
wmv
Start Time:
20080101120000
End Time:
20101231235900
Customer Key:
Secret
ResourcePath:
/xyzmedia/sample/sampleVideo300kbps.wmv
Message:
/xyzmedia/sample/sampleVideo300kbps.wmv?start_time=20080101120000&end_time=2
0101231235900#Secret
Digest:
4a524c3794615863d54020a272ab2f49
TokenValue:
start_time=20080101120000&end_time=20101231235900&digest=4a524c3794615863d54
020a272ab2f49
Page 90
Flex Token:
ZmIwYTMwZDg4NDEyMzQ5NDk1NTMyZDZiOGUwZWZiOTY=
URL:
rtsp://xyzmedia.fplive.net/xyzmedia/sample/sampleVideo300kbps.wmv?token=c3Rh
cnRfdGltZT0yMDA4MDEwMTEyMDAwMCZlbmRfdGltZT0yMDEwMTIzMTIzNTkwMCZkaWdlc3Q9ZmIw
YTMwZDg4NDEyMzQ5NDk1NTMyZDZiOGUwZWZiOTY=
Live Flash Streaming Token Example
Parameter
Example Input
Streaming URL:
rtmp://xyzmedia.f35.c.footprint.net/xyzmedia/liveStreams/testS
tream
Start Time:
20080101120000
End Time:
20101231235900
Customer Key:
Secret
ResourcePath:
/xyzmedia/liveStreams/testStream
Message:
/xyzmedia/liveStreams/testStream?start_time=20080101120000&end_time=20101231
235900#Secret
Digest:
c5b58df76e212e2db9ec26845ac6fec8
TokenValue:
start_time=20080101120000&end_time=20101231235900&digest=c5b58df76e212e2db9e
c26845ac6fec8
Flex Token:
YzViNThkZjc2ZTIxMmUyZGI5ZWMyNjg0NWFjNmZlYzg=
URL:
rtmp://xyzmedia.f35.c.footprint.net/xyzmedia/liveStreams/testStream?token=c3
RhcnRfdGltZT0yMDA4MDEwMTEyMDAwMCZlbmRfdGltZT0yMDEwMTIzMTIzNTkwMCZkaWdlc3Q9Yz
ViNThkZjc2ZTIxMmUyZGI5ZWMyNjg0NWFjNmZlYzg=
Live Windows Media Streaming Token Example
Parameter
Example Input
Streaming URL:
mms://xyzmedia.fplive.net/xyzmedia/liveStreams
Start Time:
20080101120000
End Time:
20101231235900
Customer Key:
Secret
Page 91
ResourcePath:
/xyzmedia/liveStreams
Message:
/xyzmedia/liveStreams?start_time=20080101120000&end_time=20101231235900#Secr
et
Digest:
d8e3625db57d27e4607ce63215608236
TokenValue:
start_time=20080101120000&end_time=20101231235900&digest=d8e3625db57d27e4607
ce63215608236
Flex Token:
ZDhlMzYyNWRiNTdkMjdlNDYwN2NlNjMyMTU2MDgyMzY=
URL:
mms://xyzmedia.fplive.net/xyzmedia/liveStreams?token=c3RhcnRfdGltZT0yMDA4MDE
wMTEyMDAwMCZlbmRfdGltZT0yMDEwMTIzMTIzNTkwMCZkaWdlc3Q9ZDhlMzYyNWRiNTdkMjdlNDY
wN2NlNjMyMTU2MDgyMzY=
Page 92
Appendix H: Standard Token Format
Live Flash Streaming Token Example for Player
Parameter
Example Input
Streaming URL:
tream
Not-valid-before
Keyword
stime
stime:
20080101120000
Not-valid-before
Keyword
etime
etime:
20101231235900
Secret #:
0
Customer Key:
SecretWord
Token Name
hash
(Optional)
Included
Customer
Name-Value
Pair:
CustomerID=1234
ResourcePath:
Message:
/xyzmedia/liveStreams/testStream?CustomerID=1234&stime=20080101120000&etime=
20101231235900
Digest:
d80e2320f8e192a7caa7
Standard Token:
0d80e2320f8e192a7caa7
URL:
ID=1234&stime=20080101120000&etime=20101231235900&hash=0d80e2320f8e192a7caa7
Page 93
Live Flash Streaming Token Example for Secure Ingest
Parameter
Example Input
Streaming URL:
tream
Not-valid-before
Keyword
stime
stime:
20080101120000
Not-valid-before
Keyword
etime
etime:
20101231235900
Secret #:
0
Customer Key:
SecretWord
Token Name
hash
(Optional)
Included
Customer
Name-Value
Pair:
CustomerID=1234
Event Keyword:
event
Event:
Publish
ResourcePath:
Message:
/xyzmedia/liveStreams/testStream?CustomerID=1234&stime=20080101120000&etime=
20101231235900&event=Publish
Digest:
6c8b1bea1b6d313092f9
Standard Token:
06c8b1bea1b6d313092f9
URL:
ID=1234&stime=20080101120000&etime=20101231235900&event=Publish&hash=06c8b1b
ea1b6d313092f9
Page 94
Appendix I: Jeroen Wijering (JW) FLV
Media Player
The sample embedded Flash code referencing the JW FLV Media Player is only for demonstration
purposes and is neither an endorsement nor should be considered a commercial license to use the Jeroen
Wijering player.
Jeroen Wijering has an easy to use Web-based form that automatically generates the code base and
extended functionality using the JW player with a few simple inputs. The following web form can be used to
help test the proper syntax to ensure that the Level 3 Flash streaming service is operating.
http://www.jeroenwijering.com/?page=wizard&example=4
Figure 30: Excerpt from JW Setup Wizard
The file name includes the .flv extension. This may not be the case with other Flash players and it may
be necessary to remove the extension in order to ensure proper playback. The file extension may be
particularly important with stand alone Flash players that need to associate the file MIME type with the
player or in the case where the same asset name is available in different formats, e.g., .mp3 and .flv.
Page 95
Figure 31: Output of JW Setup Wizard
Page 96

Content Delivery Network

Transcription

Similar documents

Playing the Best Variety of the 60`s and 70`s

SCE 093 Twentieth Century Fox

WELCOME TO CAESARS PALACE

- Discovery Education

WHAT`S NEW!

Dedicated to Success - Arc Industries, Inc.

2015 Winners

the truth - Join RE/MAX

You`ve Got the Power! - Ethos Education Group