Using Configuration Management V3

Getting there

Go to the My Services > Caching in the main menu, then select the caching service you wish to work on. If you don’t have this menu option, ask your company domain admin to grant you permission.

Version 3.0 is our next generation of caching configuration self-service. In the Service Component/Property list, Media portal lists the version number for Configuration Management. If you see a version earlier than v3, you will need to request a service migration by opening a ticket with your regional CDN support team. Learn how to activate Configuration Management version 3

Introduction

Let’s begin by reviewing the core components of the Configuration Management system:

Configuration (stored, deployed)	This is synonymous with service image. It is a collection and container of Lumen CDN properties and optional match logic. Configurations are stored in our repository with a version that is increased when your changes are committed. Once you have completed all updates, you will deploy the appropriate version into production.
Lumen CDN Property	This is the key atomic unit of a configuration. It is an association of aliases to an origin fill policy with optional property match logic to provide behaviors based on specified criteria. Once you deploy a configuration, the CDN extracts all properties contained in your configuration into the property registry where all properties persist with a designated state of active or inactive. To make a property inactive, is to deploy a configuration that does not contain a previously active property.
Aliases	Aliases are essentially host names you would like served by the Lumen CDN. These names are presented in the host header of a client's HTTP/HTTPS request for content. The alias is the key for the CDN nodes to determine treatments to apply to the request, which origin to fill from, etc. Requests for unrecognized Aliases result in the CDN returning a 404 error response.
Match Logic	Match logic contains all of the granular directives (match rules) for given conditions you specify. Each match rule is an association of conditions (for instance, “for all files with the .txt extension”) and features applied to content matching these conditions (e.g., “change the Cache TTL to 1000 seconds”).
Features	Features represent behavior that are invoked when a specific match rule condition is met. Examples include URI rewrites, cache control header overrides, geo restriction, IP restrictions, etc. For a complete list of available features, we encourage you to explore Configuration Management 3.0 by creating a match rule. Learn more about match rules features list.
Definitions	Definitions are passive elements of your configuration. They represent collections of objects that are references within match rules. For example, you wish to create a geo restriction that excludes all client requests originating from countries you are not allowed to operate. The list of countries can be create once, but used for many as many match rules as you’d like. And when you need to update the list, it will automatically update everywhere it is referenced. You can create definitions as a stand‑alone for use later, or add them on‑the‑fly as needed when a match rule feature requires one. Learn more about definitions

CMV3 primary workflow

Making the configuration settings you define live on our network typically follows the following process:

Create a configuration with a unique name and add all required Lumen CDN Properties.
Save changes along the way and commit changes to ensure changes are not lost.
Deploy the appropriate version of the configuration to production (continue reading to learn about using our Staged Activation mechanism for introducing updates).

1. Add a configuration

Go to the Configurations section in the main menu of CMv3, click add Configuration, and give it a unique name without spaces or dashes. You are now ready to add your Properties. Read on to become familiar with optional and required settings.

Add properties to your configuration

Click "Add property", and give it a unique descriptive name that distinguishes it from others. Giving it the same name as your Primary Alias is a useful convention to follow.

A property is composed of the following elements:

1. Origin fill policy definition

An Origin fill policy represents the source of the content you want to be delivered by the Lumen CDN. When you create a property, you may select an existing one or create a new one from scratch. You’ll provide all the necessary details regarding accessing your source content, including but not limited to Host address, fill protocol, fill port, and authentication details if protected.

We offer two type of policies:

Single origin: this option allows you to define a single origin host name to use as the content source.
Failover: if you have several copies of your source content, You can add up to two additional failover origins to a primary origin in case the primary isn’t reachable.

Origin fill policy components

Name your policy something meaningful for easy reference. Additionally, we’ll need you to provide the Fully Qualified Domain Name (FQDN) or IP address of the host members. If desired, we can also use the host header of the client request. And if needed, we can also prefix the processed request URI with the webroot you provide.

Origin Fill Policy Name: Chose a unique descriptive name, especially if you opt to reuse it in other Property Definitions. This one of many definitions you will find in the Definitions tab. (Definitions are covered in the Match Logic section.)

Origin Host (FQDN or IP address): By default, an origin is defined by its host name (fully qualified domain name) or an IP address. You can choose the “use client host header” option if you would like to use the client request’s host header as the default value. In this case, you will need to provide an IP or DNS address for the origin.

Origin Address (IP or DNS): This is required if you elected to use the client host header option for the Origin Host value.

Webroot: The webroot value will be prefixed to requests for origin content. For instance, if you use the Webroot value /mystreams content stored under myOrigin will be directly accessible through www.myalias.net/manifest.mpd.

Cache fill options

You tell us which cache fill protocol, and cache fill port to use and whether we should proceed to obtain and delivery the content if we encounter certificate errors for any origin policy member. Most importantly, we’ll need to know if and how to authenticate when requesting resources, be it through values provided in headers or via AWSv4. More authentication methods will be added in the near future.

Cache Fill Protocol: The internet protocol required to access the origin.

Ignore Invalid Certificate: If selected, origin server certificate errors will be ignored.

Cache fill port: The destination port for the origin. By default, 80 is used for HTTP and 443 for HTTPS.

Authentication: If your origin content is protected, you can add one of the authentication methods below:

Headers: allow you to add a specific header key and value to the origin request.
AWS Signature v4: allows you to use the AWS Signature version 4 Authorization method if your content is on AWS servers.

Timeouts and retries: You have the option to define the following to convey when to give up trying to contact your origin host. This applies to each origin in your Origin Fill Policy.

HTTP Timeout: The time to wait in seconds for an HTTP response from the origin before it is considered failed.
Connection Timeout: The maximum time to wait, in seconds, that is allowed to establish a connection to an origin server.
Timeout Retries: The number of connection timeout retries before giving up. Each retry will follow the Connection Timeout policy. 0 indicates never retry.

Failover Conditions: Each origin member of a failover origin group has its own time out and retry settings; however, you can set up specific failover conditions instead. If you have both individual timeout and retry settings, the failover conditions will take precedence. Failover conditions are comprised of the following options. You use some or all of these options, but only one needs to evaluate to true to result in a failover.

HTTP Timeout: The time to wait in seconds for an HTTP response from the origin before failing over.
5XX: Failover if an origin request results in a 5xx response code.
4XX: Failover if an origin request results in a 4xx response code.
Expression: Using the Lumen Expression Language to create failover criteria.

2. Aliases

Aliases are essentially host names you would like served by the Lumen CDN. You can define one or several Aliases to serve content from the same origin. You can use either your own domain names for CDN delivery or use shared Lumen CDN subdomains. If you use your own domain, you will need to connect your hostname to the CDN delivery via a CNAME record in your DNS.

Primary Alias (Required): The Primary Alias corresponds to the main hostname CDN content will be served from for this property. Its protocol settings are shared by all other aliases by default. It is also the name you see in real‑time and historical usage reports. By default, all traffic to all property aliases are reported under the primary alias URL in aggregate.

Secondary Alias(es) (Optional): Add secondary aliases if you would like to be able to serve the same origin content under different mirror URLs. Secondary aliases share the same protocol and cache key, as they share the same origin.

Delivery Protocol: Choose between HTTP and HTTPS.

SSL Certificate type (HTTPS only): To use HTTPS, configure your SSL settings:

Use a protected Lumen subdomain: this option allows you to secure your content without having to create a certificate with a CA. Your content will be distributed via a Lumen subdomain (i.e., https://mysite.secure.footprint.net or http://mysite.secure2.footprint.com if you’ve enabled HTTP2). Your primary and secondary aliases must be inside one of these subdomains.
Use my own certificate (SNI): this option allows you to use your own SSL certificate you have obtained from a CA. To use this option, make sure you have already added the corresponding SSL certificate in our Certificates section.
Use my own certificate (dedicated IP): This option allows you to get a dedicated IP address for your certificate. This is a premium option; please contact Support or your Sales representative to get a quote.

Learn more about how to set up SSL in your properties and manage your SSL certificates.

Encryption levels (HTTPS only): You can modify the default server encryption settings:. We provide three encryption level options:

Risky: corresponds to Mozilla’s Modern configuration. This configuration uses the most recent cypher suites, for clients with no need for backwards compatibility. Warning: Choosing this option can break content accessibility for some of your users.
Default (recommended): corresponds to Mozilla’s Intermediate configuration. This is the recommended configuration for the vast majority of services, as it is highly secure and compatible with nearly every client released in the last five (or more) years.
Advanced: corresponds to Mozilla’s Old configuration. This configuration is compatible with a number of very old clients, and should be used only as a last resort.

We strongly recommend that you leave the Default setting to optimize content deliverability.

OCSP (HTTPS only): Select this option to activate OCSP (Learn more about Online Certificate Status Protocol).

HTTP/2 (HTTPS only): Select this option to activate HTTP/2.

Certificate: Here you can choose the corresponding certificate from the list of certs you have uploaded in the Certificates section.

3. Alias protocol setting override Group(s) (optional)

Should you benefit from grouping additional aliases within a single property definition that need unique protocol settings, you can set up an alias override group with one or more additional aliases. Use this feature to differentiate any aspect of the protocol settings: HTTP vs. HTTPS, OCSP, HTTP2, or perhaps you would like to use a different security certificate.

4. Traffic type

We offer out-of-the-box property types to choose from, such as VOD, Live, Patch, etc., that correspond to proprietary network settings that are designed to optimize the content delivery performance of your property. If needed, our support engineers can create custom types for you.

5. Property match logic

Property match logic contains all granular settings expressed as ordered match rules you create for a specific Lumen CDN property. They are grouped and evaluated sequentially for a specified request stage that we call a match block:

Client requests
Origin requests
Origin responses

Once you’ve selected your match block, you’ll create at least one Match Rule group. Every rule, except the last one in a group, must have a Condition. A condition-less rule serves as a final 'ELSE/IF' statement in a rules set. Conditions are made up of one or more Expression. If you have more than one, all must be true to be considered a match. Expressions convey what to look for in a request to determine if any specific treatment - what we call Features - should be applied. Conditions are based on the characteristics of a request, be it the value of a header, a query string, a status code, a path, a combination thereof and more. Let’s review all Match Block components.

Match Rule Group: Every Match Block has one more groups with a sequential list of Match Rules. Groups and their elements are evaluated sequentially until the first match is found. The next group or next block will then be evaluated.
Match Rule: Match Rules are comprised of conditions-feature pairs . They act like 'IF/THEN' statements. The last one in a group may be condition-less acting as a final 'ELSE/IF' statement.
Condition(s): Conditions comprise the IF statement expressed using the Lumen Expression Language. We offer a form-based approach that generates the Lumen Expression Language syntax and a basic expression editor for advanced users familiar with this language.
Expressions: One or more expressions comprise a Condition. They can be connected with an 'And' or 'Or' operator, and all must evaluate to true for the condition to be met. If you are using the form-based expression builder, you will enter the following:
- Request-Response Component: The part of the Request-Response that should be evaluated. If you choose "Header" component, you’ll provide the header name as well.
- Operator: Choose from several options, such as 'Equals', 'Does not equal', 'Greater Than', and more.
- Value: The final piece of the condition expression that can be evaluated for a true/false result.
Features: Features represent the 'THEN' statement describing treatments to be applied to requests-responses when the condition is met. Now that you have built your condition, it’s time to choose the "Features" that should be applied if the Expression(s) in your Condition evaluate(s) to true. Features come in different formats. Some are simply activated, some require certain inputs, some refer to a reusable reference called a Definition, and some have a combination of inputs and Definition references. Learn more about available features.
Definitions: Definitions are intended to be created once and reused as needed. Most likely you’ll create them on the fly while adding "Features" that require them, but you can also create and manage them from the "Definitions" tab within the "Configuration" section. If you opt to edit a Definition remember that it will take affect everywhere it is referenced in your configuration.

Learn more about property match logic

If you are not able to find a rule and feature that corresponds to your needs, contact our Support or your Sales representative - your need might be answered by a custom Lua script on our CDN Edge nodes.

Saves, commits, versions, and rollbacks

As you add components, you will save your work as you go; however, an explicit commit of changes is required to create an official version that is stored in our repository. We also auto-save your changes to avoid losing work unintentionally, but these are only stored locally. Each time changes are committed, the version will be increased by 1. We keep a history of all versions, and you can always return to an older version to view, edit, or even deploy in order to roll back to a previous deployment. To see all versions, click Versions tab (in the Configurations section).

2. Deploying your configuration

Once your configuration is ready and committed, you can choose to deploy it using our Staged Activation feature.

Learn how to deploy your configurations in production safely with Staged Activation

Configuration Management API

All functions and features presented here are also available via API. Learn how to use our APIs