Media Flow Controller Configuration Tasks : Policy Configurations : Namespace Options

Namespace Options
Create namespaces to define fine-grained delivery policies, including optionally adding a custom virtual player. You must create a namespace for each origin server and delivery criteria scheme you use. You can create up to 256 namespaces in one Media Flow Controller. Review the following sections as applicable for implementation details:
Then proceed to Configuring Namespaces or see namespace for CLI details.
See “Troubleshooting Media Flow Controller” on page 153 for additional tips.
Using namespace cache-inherit
Use the namespace cache-inherit option to add an existing namespace’s cache and UUID to a new one; the contents are not duplicated, but the new namespace uses the inherited cache rather than creating a new one. When a namespace is created, the system assigns it a Unique ID (UUID). There is no option in the CLI to set the UUID; but it can be set indirectly using the cache-inherit subcommand that sets a new namespace to inherit the cache of an existing namespace. This is useful under the following situations:
You add a new namespace and want it to share the UUID with an existing namespace; sharing the UUID allows the two namespaces to have a common cache.
You delete a namespace by accident and want to recreate it and you do not want it given a new UUID. In this case, you dump the namespace and its associated UUID, and force the UUID of an existing namespace for the one you are creating. You would do this by:
1.
Issue show namespace list to gather the list of "Currently defined" and "Deleted/non-existing" (but whose cache content still exists) namespaces and their associated UUIDs.
2.
Then issue namespace <name> cache-inherit <existing or non-existing namespace integer>.
Example output of show namespace list (namespace test2 inherited namespace test cache):
show namespace list
Currently defined namespaces :
Name : UID
new_ns : /new_ns:b3ad64a8 (inactive)
test2 : /test:1250bcac (active)
testIE : /testIE:b911b24 (inactive)
-------------------------
List of unmapped/deleted namespace UIDs (if any)
non-exsiting1: /test3:954ef8aa
Using namespace domain regex
This section provides some examples of namespace domain regex use. Change specifics accordingly. Note! Regex entries do not contain spaces; also, enclose all regex entries in single quotes (not shown in examples). See Table 8, below.
 
Table 8 Example namespace domain regex entries  
abcdef02.origin.cms.example.com:80
abcdef02.cdn.cms.example.com:80
abcdef02.cms.example.com:80
cms123.dc2.example.com:80
cms123.qcg7.example.com:80
orig.sv1.example.com:80
orig.qcg1.example.com:80
orig.qcg5.example.com:80
cms123.x.y.qcg0.example.com:80
cms123.x.y.qcg01.example.com:80
cms123.x.y.sv1.example.com:80
cms123.x.y.ch1.example.com:80
cms123.x.y.dc2.example.com:80
cms123.x.y.af1.example.com:80
Using namespace domain <FQDN:Port>
Media Flow Controller can listen for requests on multiple TCP ports, up to 64; default is port 80 for HTTP, port 554 for RTSP. In order to map incoming requests to the correct namespace, especially on a non-default port, the namespace domain MUST be set properly with port number included. Media Flow Controller maps an incoming URL to a namespace by extracting the value against the HOST header and matching it to the value set for the namespace domain.
When non-default port numbers are used you MUST ensure that the HOST header has the port number coded correctly in the incoming URL and also in the namespace domain.
Example: If Media Flow Controller listens on port 80, 8080, and 4040 for incoming HTTP requests; and the requests on port 80 must go to namespace ns80, those coming in on port 4040 must go to namespace ns4040, and those on port 5050 must go to namespace ns5050, then the configuration would be as follows:
namespace ns80
domain video.example.com
namespace ns8080
domain video.example.com:4040
namespace ns4040
domain video.example.com:5050
For requests to match ns80, domain/HOST: header must be video.example.com.
For requests to match ns4040, domain/HOST: header must be video.example.com:4040.
For requests to match ns5050, domain/HOST: header must be video.example.com:5050.
Using namespace match uri regex
This section provides some examples of namespace match uri regex use. Change specifics accordingly. Note! Regex entries do not contain spaces; also, enclose all regex entries in single quotes (not shown in examples). See Table 9, below.
For namespace match uri <uri-prefix>, the regex is written against the absolute path portion of the URL. For example, given the following URL: http://abc.com:8080/index.html,
/index.html would be the absolute path portion of the URI.
 
Table 9 Example namespace match uri regex entries  
Using namespace match <criteria> precedence
Use namespace <name> match <criteria> precedence to set unambiguous mapping of incoming GET requests in the case of match <criteria> overlap; precedence can be set on all match <criteria>. The lower the number, the higher the preference for that namespace; values 0 (highest precedence) - 10 (lowest precedence) can be used. All namespaces have a default precedence of 0. For example, consider three URLs and namespaces as follows:
1.
2.
3.
namespace ns1
domain a.com
match uri /abc/def precedence 1
origin-server http o1.com
status active
namespace ns2
domain a.com
match uri /abc precedence 2
origin-server http o2.com
status active
namespace ns3
domain a.com
match uri / precedence 3
origin-server http o3.com
status active
All three URLs match namespace ns3 set domain (a.com) and match uri / (slash). In order to ensure that match uri #1 (/abc/def) maps to ns1 and not ns3, set the precedence value. Same as the case with match uri #2 (/abc), to map to ns2. Only match uri 3 ( / )should be mapped to ns3 with the precedence value set as shown above.
Note! Excessive use of precedence has performance impact as precedence allows for longest prefix matching. If possible, namespaces should be configured in such a way that they have no overlaps in the domain and match <criteria> combination, which are used for mapping the incoming HTTP GET to a namespace.
Using namespace delivery protocol <protocol> origin-fetch cache-age
The namespace <name> delivery protocol <protocol> origin-fetch cache-age argument allows you to set granular cache aging policies based on content type, as well as a default cache age. The cache-age for each content-type must be specified separately with positive integers. Examples:
Irrespective of content-type, override your configured cache-age-default or, if cache-age-default is unconfigured, set the max-age for any content-type to 28800 seconds. If the content request does not specify a max-age, set it to max-age 28800.
When content-type is application/flv, set max-age to 2880 seconds. For all other content-types use default configuration (57900 seconds in the example). If the received max-age is set, use that value.
cache-age content-type application/flv 28800
cache-age content-type application/mov 2880
cache-age content-type application/3gp 288
cache-age content-type application/f4v 28
cache-age-default 57900
When content-type is application/flv, set max-age to 28800 seconds; for application/mov, set max-age to 2880 seconds; for application/3gp, set max-age to 288; and for application/f4v, set max-age to 28. For all other content-types use default configuration (57900 seconds in the example). If the received max-age is set, use that value.
cache-age content-type application/qmx 60
cache-age content-type application/qss 288000
When content-type is application/qmx, set cache-age to 60 seconds, for application/qss, set cache-age to 288000 seconds. For all other content-types use default configuration: if max-age isn't set in the data coming from origin, set it to the configured default value (28800 if unspecified). If the received max-age is set, use that value.
Using namespace origin-server <protocol> server-map
Media Flow Controller server-map allows you to define the origin server(s) to which Media Flow Controller goes in case of a cache-miss. To use this feature, define an XML file with the origin server parameters, such as host, protocol, and port number, described in detail in Appendix A, “Server Map Configuration,”. The XML file can reside in an external server; you specify the path to the XML file in a configured namespace.
namespace <name>
origin-server
http {absolute-url | follow {dest-ip [use-client-ip] | header <header> [use-client-ip]} | server-map <map_name> | <FQDN/path> [<port#>]}
nfs {<FQDN:path> [<port#>] | server-map <name>}
rtsp {<FQDN> [<port#>]} [follow dest-ip [use-client-ip]]
When defining a namespace origin-server, you can choose http, nfs, or rtsp; you can also choose a defined server-map, for either http or nfs only. A server map directs Media Flow Controller to an XML mapping file that you define; see Appendix A, “Server Map Configuration,” for details.
Using server-map to Create a Consistent Hash Cluster
The cluster-map server map lets you to define a consistent hashing scheme to bind objects to nodes. See “Consistent Hash-Based Clustering and Origin Escalation” on page 46 for an overview, server-map for CLI details, and cluster-map XML File in Appendix A, “Server Map Configuration,” for details on clustering and creating the XML file for cluster-map.
Consistent hash cluster requirements:
Example server-map cluster-map configuration:
server-map sm2
format-type cluster-map
file-url http://mapfile.nokeena.com/nfs/path/cluster.xml refresh-interval 60
Using server-map for Origin Escalation
The server-map format-type origin-escalation-map allows you to specify a set of origin-servers that are sequentially (in the order defined in the XML server map file) tried until a request is fulfilled or all defined origins have been tried; if no origin can fulfill the request a 404 (file not found) error is given. See “Consistent Hash-Based Clustering and Origin Escalation” on page 46 for an overview, server-map for CLI details, and origin-escalation-map XML File in Appendix A, “Server Map Configuration,” for details on creating the XML file for origin-escalation-map.
Origin escalation requirements:
Example server-map origin-escalation-map configuration:
server-map sm3
format-type origin-escalation-map
file-url http://mapfile.nokeena.com/nfs/path/originescalation.xml refresh-interval 60
To use a server-map for either HTTP or NFS origin server:
1.
First, create the server-map with a <name> and format-type. To map the incoming (target origin) HOST header value to a specified origin server, set format-type host-origin-map. To use consistent hashing to determine the origin server, set format-type cluster-map. To allow origin escalation (try another defined origin if the first fails), set format-type origin-escalation-map. To use NFS publishing points for origin, set format-type nfs-map. For cluster-map and origin-escalation-map only, you can define and add any number and combination of these two to a namespace; the order of in which the maps are added to the namespace denotes the order in which they are read.
server-map <name> [format-type <type>]
2.
Set a URL for the server-map; this tells Media Flow Controller where to fetch the XML mapping file. Also, set a refresh interval (how often Media Flow Controller refreshes the XML file). The default refresh-interval is 0 (zero), which means no refresh after the initial fetch. When you set the file-url Media Flow Controller immediately initiates an HTTP GET, retrieves the file, and executes MapXML to convert the data to binary.
file-url <URL> refresh-interval <time>
3.
The final step is to add a server-map (or, potentially, multiple server-maps in the case of cluster-map and origin-escalation-map) to a namespace origin-server configuration. When the server map is added, Media Flow Controller starts the heartbeat (cluster-map and origin-escalation-map only) to the defined nodes (10 beats/second).
namespace<name> origin-server <protocol> server-map <name>
Example (for NFS origin):
test-vos (config) # server-map newMap
test-vos (config server-map newMap) # file-url http://example.com/nfs/maps/ refresh-interval 9000
test-vos (config server-map newMap) # exit
test-vos (config) # show server-map
Server-map : newMap
Format-Type :
Map File : http://example.com/nfs/maps/
Refresh Interval : 9000
test-vos (config) # namespace newTest origin-server nfs server-map newMap
test-vos (config) #
Using namespace object delete | list
List or delete contents in a namespace. The command takes in the name of a namespace and applies a list or delete operation to the object(s) matching the given pattern.
namespace <name> object {list |delete} {all | <URI> | pattern}
For example, with this namespace and a URL of http://example.com/abc/def/file.flv:
namespace ns1
domain example.com
match uri /abc
1.
namespace ns1 object list /abc/def/file.flv
2.
namespace ns1 object delete /abc/def/file.flv
3.
namespace ns1 object delete all
4.
List all the first 50 objects in that disk cache and create a file named with the UUID of the namespace listing all cached objects for that namespace. In the example, if the namespace had a UUID of 80213A2C, the file containing the list is 80213A2C.lst. Note! Only the first 50 cached objects display; if there are more than 50, use the upload command. See the “Command Arguments Key” on page 161 for the scp URL format).
namespace ns1 object list all
upload object list <namespace> <SCP>
5.
You can also list and delete based on patterns. For example; you can specify *.flv as a pattern. Media Flow Controller does not support a full Regular Expression for deleting or listing. The command namespace ns1 object list all is equivalent to namespace ns1 object list /abc/def/*.
Using namespace for Live Streaming Delivery Without Caching
An example namespace configuration to deliver live streaming objects without caching is given below. Note that delivery protocol and live-pub-point both enter you to prefix mode.
namespace <name>
match uri <uri-prefix>
origin-server rtsp <IP_address | hostname> [port]
status active
delivery protocol rtsp
exit
live-pub-point <pp_ name>
receive-mode on-demand
status active
exit
exit
Using namespace for Live Streaming Delivery With Caching
An example namespace configuration to deliver live streaming objects with caching is given below. Note that delivery protocol and live-pub-point both enter you to prefix mode.
namespace <name>
match uri <uri-prefix>
origin-server rtsp <IP_address | hostname> [port]
status active
delivery protocol rtsp
exit
live-pub-point <pp_ name>
receive-mode on-demand
status active
caching enable
exit
exit
Using namespace for Proxy Configurations
You can use namespace settings to configure Media Flow Controller to operate as a proxy in various ways.
Reverse Proxy—Setting namespace origin-server to <FQDN> or server-map implies a reverse proxy configuration. Media Flow Controller as an edge cache is effectively a reverse proxy that reduces network and CPU load on an origin server by serving previously-retrieved content, and enhances user experience by decreasing latency.
Mid-Tier Proxy—Setting namespace origin-server to absolute-url implies a mid-tier proxy configuration. As a mid-tier proxy, Media Flow Controller must be explicitly configured in the browser to intercept all requests. After Media Flow Controller receives traffic from the client, it separates the traffic; cacheable requests are sent via Media Flow Controller for performance enhanced delivery. Non-cacheable requests are tunnelled. See also “Configure Media Flow Controller as a Mid-Tier Proxy” on page 113.
Virtual Proxy—Setting namespace origin-server to follow header HOST or follow dest?ip implies a virtual proxy configuration. As a virtual reverse proxy where origin-server access is derived from the HOST header or the destination IP address given in the incoming request, explicit origin-server configuration is disallowed. Use this as an alternate to providing a single origin server address.
Transparent Proxy—Setting namespace origin-server to follow header X-NKN or follow dest-ip use-client-ip implies a transparent proxy configuration. A transparent proxy is one that requires no browser configuration and is not readily visible to end-users. Be sure that delivery protocol http allow-req is set to all (default). See also Example Transparent Proxy Namespace Configuration, after Table 10.
Table 10, below, gives details on the configurations and defaults per proxy deployment.
Table 10 Namespace origin-server and origin-request Dependencies per Proxy Deployment  
Proxy Mode
Source IP for Cache Miss
Media Flow Controller IP address
Media Flow Controller IP address
DNS resolved IP address of origin-server picked from given server-map
NFS mount point to find origin
None
(NFS mounted)
Given server-map NFS mount point
None
(NFS mounted)
Client request absolute URL
Media Flow Controller IP address
DNS resolved IP address of origin-server chosen from the client request
Media Flow Controller IP address
DNS resolved IP address of the origin-server from the HOST header
Client request destination IP
Media Flow Controller IP address
No DNS resolution. Origin IP is the IP address of client destination
Client request destination IP
No DNS resolution. Origin IP is the IP address of client destination
DNS resolved IP address of the origin-server from the given header
Important! If a non-default origin-request host header inherit incoming-req value is configured against an origin-server setting, the behavior is undefined and no error or warning is issued. For example, if origin-server http absolute-url is set (Mid-Tier proxy), and you set origin-request host-header inherit incoming-req deny, the behavior is undefined.
Example Transparent Proxy Namespace Configuration
In Release 2.0.2, some namespace configurations are required for a transparent proxy; specifically, you must set proxy-mode transparent on-ip. Note! The non-default delivery protocol http origin-request option values given below are set automatically when proxy-mode transparent on-ip is configured. The value shown below for origin-fetch content-store media object-size is only a recommendation; default value is 0 (zero).
namespace tproxy
match uri / precedence 1
origin-server http follow dest-ip use-client-ip
proxy-mode transparent on-ip <IP_address_of_your_interface>
delivery protocol http
origin-request x-forwarded-for disable
origin-request host-header inherit incoming-req permit
origin-fetch content-store media object-size 32768
status active
exit
exit
About Virtual Host Configuration
You can specify a virtual host for the namespace match criteria; see Virtual Host for definition. To do this, enter the IP address of the virtual host and, optionally, a port number; you can also set a precedence, if needed. In this configuration, the incoming session's destination IP is used to find the match to the namespace. In order for the match to be based only on destination IP you should set domain to any. In that way, the incoming session's destination IP and destination port (if given) are used to match to the namespace. Examples:
Match all sessions whose destination IP is 10.1.1.1 to the namespace:
match virtual-host 10.1.1.1
Match all incoming HTTP REQ with destination IP 10.1.1.1 and port 8080 to this namespace:
match virtual-host 10.1.1.1:8080
Match all incoming REQ on destination port 8080 to this namespace:
match virtual-host 0.0.0.0:8080
Configuring Namespaces
1.
Configure a namespace with a name (enters you to namespace configuration mode, use exit when finished); optionally inherit another namespace’s cache or UUID. Use show namespace list to find namespace UUIDs. See namespace for CLI details.
namespace <name> [cache-inherit <namespace:UUID>]
2.
Configure domain settings (default is any). Note! The domain you enter should match whatever you have configured as HOST header, unless using regex; you may append a port number as well if needed (and used in HOST header). See “Using namespace domain regex” on page 80 and “Using namespace domain <FQDN:Port>” on page 80 for details.
domain {any | <FQDN> | regex <regex>}
3.
Configure origin-server settings (example uses http); multiple origin servers can be configured with the server-map option; port specification is optional. See “Using namespace origin-server <protocol> server-map” on page 83, for more information. See (namespace) origin-server for CLI details.
origin-server
http {absolute-url | follow {header <header> [use-client-ip] | dest-ip [use-client-ip]} | server-map <map_name> | <FQDN/path> [<port>]}
nfs {<FQDN:export_path> [<port>] | server-map <name>}
rtsp {<FQDN> [<port#>]} [alternate <string> [<port#>]]
4.
Configure match criteria options (determines the URI to cache). All match options may utilize the precedence argument to break ties when namespaces are defined with the same match criteria. See “Using namespace match <criteria> precedence” on page 81, for details.
match
header {<header> | regex <regex>} [precedence <number>]
query-string {<name> | regex <regex>} [precedence <number>]
uri <uri-prefix> | regex <regex>} [precedence <number>]
virtual-host <IP_address> [<port>] [precedence <number>]
header— (http only) A header name and value; can also be a regex. Optionally, set a precedence (defined above).
query-string—(http only) A defined query param; can also be a regex. Optionally, set a precedence (defined above).
uri—A <uri-prefix>; can also be a regex. See “uri-prefix” on page 31 for uri-prefix definition and usage details. Optionally, set a precedence (defined above).
virtual-host—The IP address must be a /32 address; it can take a special value of 0.0.0.0, which means any IP address. Port number specification is optional. To map requests by TCP port number only, set the IP address to 0.0.0.0 and configure the port number. If you set the domain to any, configure virtual-host IP to 0.0.0.0, then requests can be assigned to a namespace based solely on the port number on which the request comes in to Media Flow Controller. Optionally, set a precedence (defined above).
Note! All regex values should be enclosed in single quotes; for example, a regex for www.example.com plus example.com could be this: ‘^.*\example\.com’.
5.
Configure delivery protocol options; only origin-fetch options are available for rtsp. Note! To enable delivery protocol rtsp, press enter after rtsp; then set RTSP options.
client-request [cookie | query-string]—(http only) Optionally, set an action, whether or not to cache (default), for cookies or objects with a query-string (such objects are typically dynamic and often not appropriate for caching). For query-string you can also opt to not cache the query-string itself.
client-request [cookie | query-string] action {cache [exclude-query-string] | no-cache}
client-response—(http only) Optionally, configure client-response header actions. Up to sixteen client-response headers and actions may be specified.
client-response header <name> [<value>] action {add | delete}
origin-fetch—Optionally, configure origin-fetch parameters for data fetched from origin, including managing the cache, and modifying the Date header. See (namespace) delivery protocol {http | rtsp} origin-fetch for CLI details.
origin-fetch
cache-age {content-type<string> <seconds> | content-type-any<seconds>}
cache-age-default <seconds>
cache-directive no-cache {follow | override}
content-store media [cache-age-threshold<seconds>] [object-size<bytes>]
date-header modify {deny | permit}
origin-request—(http only) Optionally, configure parameters for data requested from origin. See (namespace) delivery protocol http origin-request for CLI details. Note! Set origin-request host-header inherit incoming-req in accordance with the origin-server setting; see Table 10, “Namespace origin-server and origin-request Dependencies per Proxy Deployment for CLI details. Use x-forwarded-for to allow (with enable) or disallow (with disable) setting the X-Forwarded-For header to the client IP address; default is enable.
origin-request
cache-revalidation {deny | permit}
header <name> [<value>] action add ...
host-header inherit incoming-req {deny | permit}
x-forwarded-for {disable | enable}
Example:
test-vos (config) # namespace test
test-vos (config namespace test) # domain any
test-vos (config namespace test) # origin-server http example.com/video
test-vos (config namespace test) # match uri / precedence 3
test-vos (config namespace test) # delivery protocol http
test-vos (config namespace test delivery protocol http) # client-request cookie action no-cache
test-vos (config namespace test delivery protocol http) # client-response header Location action delete
test-vos (config namespace test delivery protocol http) # origin-fetch cache-age-default 14400
test-vos (config namespace test delivery protocol http) # origin-request x-forwarded-for enable
test-vos (config namespace test delivery protocol http) # exit
test-vos (config namespace test) # exit
6.
Optionally, make live-pub-point settings if needed for live streaming.
caching—Enable caching for this service (default is disabled).
receive-mode—Set a method for receiving live streaming:
on-demand—When a request is received.
sdp-name <URL>—Use an SDP (service delivery protocol) file to set the live publishing point. The URL can be scp://... or http://... only. Once Media Flow Controller encounters this, it pulls in the file from the specified location, and saves it in the file system (not disk cache) so it is available for RTP/RTSP. Optionally, choose immediate, to start as soon as the file is retrieved or enter a start-time and, optionally, an end-time. See the “Command Arguments Key” on page 161 for the scp URL format).
status—Make active or inactive the live-pub-point.
7.
Set parameters for pre-staging content from origin; authentication schemes must be pre-configured to be used. See namespace for CLI details. The ftp user is auto-generated as <namespace>_ftpuser, without a password (login disallowed). Set the password here; this entry overrides a user <namespace>_ftpuser password setting. Verify with show usernames. Remove set password with no pre-stage ftp user <user_name>.
pre-stage ftp user <name> password {RADIUS | TACACS | <password> [encrypt]}
Example:
test-vos (config namespace test) # domain any
test-vos (config namespace test) # origin-server http example.com/video
test-vos (config namespace test) # pre-stage ftp user test_ftpuser password 678
test-vos (config namespace test) # show usernames
USERNAME FULL NAME CAPABILITY ACCOUNT STATUS
admin System Administrator admin No password required for login
cmcrendv CMC Rendezvous User cmcrendv Local password login disabled
monitor System Monitor monitor No password required for login
test_ftpuser ftpuser Password set
test-vos (config namespace test) # no pre-stage ftp user test_ftpuser
test-vos (config namespace test) # show usernames
USERNAME FULL NAME CAPABILITY ACCOUNT STATUS
admin System Administrator admin No password required for login
cmcrendv CMC Rendezvous User cmcrendv Local password login disabled
monitor System Monitor monitor No password required for login
test_ftpuser ftpuser Local password login disabled
8.
Also optional, add an existing virtual-player to the new namespace.
virtual-player <name>
9.
status active
10.
Type exit to leave namespace configuration mode.
Example:
test-vos (config namespace test) # virtual-player test
test-vos (config namespace test) # status active
test-vos (config namespace test) # exit
To make these configurations using the Management Console, go to the Service Config > NameSpace page. Enter a Namespace name and click Add Namespace, then select the new namespace in the Configuration List and click configure to open a new window and make configurations. Be sure to click Apply at each section and Save at the top right of the page to make the changes persistent across reboots/restarts.
Note! Configuration changes, including a namespace deletion, may not be updated for up to 30 seconds. This is due to a deferred update scheme that requires an HTTP request. An internal probe ensures that such a request occurs at least every 30 seconds.

Report an Error
Media Flow Controller Administrator's Guide and CLI Command Reference
Copyright © 2010 Juniper Networks, Inc.