Content Delivery Network Interconnection (CDNI) Named Footprints

2.1. Footprints shared by multiple FCI objects

Multiple FCI capability objects are likely to share footprint definitions. Creating footprint resource definitions outside of individual capability objects, and referring the capability objects to such definition simplifies footprint management.¶

2.2. Use of footprints in multiple CDNI interfaces

Once differentiated capabilities are advertised by a dCDN, uCDN MAY want to scope its configuration and cache management operations accordingly. For example, when dCDN advertises logging capability object with a footprint scope, uCDN MAY configure logging characteristics differently for that footprint. Or in case of redirection mode capability object scoped by footprint, uCDN MAY want to scope CI/T triggers accordingly. In these cases, common footprint definitions that are external to individual CDNI interfaces is required to assure consistency.¶

2.3. Dynamic footprints

Some types of footprints (e.g. distributed last-mile footprint) can be highly dynamic and large in volume. Because of that, they would require high-frequency querying. Because of this, it would be beneficial to allow separate querying and client-side caching of individual footprint resources separately from other, more static footprints and capabilities objects.¶

2.4. Complex footprints

In some cases, footprints can be complex to define. For example, a footprint can include a large entity, e.g. country or autonomous system, but also be inclusive of additional IP ranges that have not been properly classified as belonging to that entity, and exclusive of specific IP ranges and/or autonomous systems. In this context, an ability to define footprints using an expression language with predicatle logic would be desirable.¶

2.5. Footprint hieratchy

Same CDN can use one or more types of footprints. Thus, a CDN provider can operate across multiple disaggregated regions, e.g. Brazil and US, and then further sub-divide the regions by region and/or functionality. In this case it is desirable to scope some CDN capabilities, configuration and operations at the top-level footprint, while others would be scoped at more granular level.¶

2.6. Footprint by type of traffic

In some cases, dCDN MAY want to advertise different footprints by type of traffic. For example, a dCDN may handle live and VOD traffic from the same uCDN differently, even for the same user.¶

2.7. Footprint definitions mismatch

Unless explicit IP addressing is used, footprint definitions typically rely on third-party geolocation and IP routing data sources to create higher-level abstractions such as "country" or "subcountrycode." However, these data sources can sometimes be outdated—particularly in access networks that support user mobility across geographic regions, such as satellite or mobile networks. To address this, it is desirable to allow the dCDN to publish its own geolocation data for use in uCDN-dCDN interactions, and/or to provide a mechanism for the uCDN and dCDN to agree on the specific data source used to map IP addresses to non-IP-based footprint types.¶

3.1. Footprints Advertisement

dCDN must advertise its footprints via FCI as named resources, separately from the capabilities advertised in the same interface. dCDN is solely responsible for the footprints it advertises. This footprint advertisement will provide a source of truth as to what footprints are available from dCDN and are referenceable from FCI capabilities and other open caching interfaces exposed by the same dCDN.¶

uCDNs must authenticate themselves when accessing the footprint advertising, subject to open caching authentication and authorization framework. dCDN is at freedom to advertise different footprints to different uCDN tenants. dCDN may change the content of footprint advertisements, including publishing footprints without any footprint values, however, it is not at liberty to retire a footprint once advertised as long as there are resources associated with it.¶

The footprints advertisement will provide mechanisms allowing uCDN to manage a local cached copy of advertising, and differentiated querying of individual, more dynamic footprints, while at the same time allowing for the whole footprint advertisement to be captured. The footprint advertising is to support both "coverage" and "resource" footprints.¶

3.2. Hierarchy

The dCDN advertisement must support explicit hierarchy, in which footprints resources may include sub-footprints, e.g. specific subdivision code within a country, list of IPv4 CIDRs within specific ISP defined by one or more ASN etc. A footprint resource encompasses all of the footprint values and sub-footprints within it, so interface resources (e.g. logging, configuration hostnames, cache management buckets) associated with a footprint apply to all of it, including sub-footprints.¶

In case of conflict between interface resources of lower-level footprint and higher-level footprint, the resources associated with the lower-level footprint take priority. It is dCDN responsibility to make sure that sub-footprints are indeed included in their parent footprint scope. When matching an IP address against footprint hierarchy, the lowest level footprint takes priority as well.¶

3.3. Backward compatibility

The footprint definition must be backward compatible with MI Footprint encoding as specified in Section 4.2.2.2 of [RFC8006], as well as all registered footprint types "CDNI Metadata Footprint Types" sub-registry in the "Content Delivery Network Interconnection (CDNI) Parameters". To enhance computability, consistency and the business logic of footprint advertisement, the specification may introduce new footprint types as well as footprint properties, in addition to footprint type and value.¶

3.4. Explicit Logic

In some cases, CDNs require complex footprints definitions, that include inclusion and exclusion of specific footprint values from footprint definitions (e.g. country code, exclusive of some ISPs and that country but inclusive of some IPv4 or IPv6 CIDRs that are not included in the current country definition). To support that, footprint definitions to support Metadata Expression Language expressions as defined ino [cdni-metadata-expression-language] The new footprint type "expr" is to be introduced to the "CDNI Metadata Footprint Types" registry.¶

To accommodate footprint logic, the following MEL expression variables are hereby introduced¶

• ep.asn - Endpoint AS number¶

• ep.ipv4addr - Endpoint IPv4 address¶

• ep.ipv6addr - Endpoint IPv6 address¶

• ep.country - Endpoint country code¶

• ep.subdivision - Endpoint subdivision code¶

Thus, the following MEL expressions can be used for footprint advertisement:¶

    {
      "footprint-type": "expr",
      "footprint-value": [ " ( $ep.country == "us" ) and
        not $ep.ipv4addr ipmatch ( "10.1.1/24" or "10.1.2.0/24" )" ]
    }

    {
       "footprint-type": "expr",
       "footprint-value": [ "( $ep.asn = 1234 ) or
        ( $ep.ipv4addr ipmatch "192.168.1/24" ) or
        ( $ep.ipv6addr ipmatch "2001:db8:3333:4444/48" )" ]
    }

    {
      "footprint-type": "expr",
      "footprint-value": [ "( $ep.country == "us" ) and
         not ( $ep.subdivision=="us-ny" )" ]
    }

3.5. Consistent Datasource

Footprint types based on IP addresses, such as "ipv4cidr" and "ipv6cidr", are straightforward. However, when using types like "country" or "asn", the uCDN and dCDN must consult external databases to resolve footprint values from IP addresses. Multiple databases for IP address intelligence are in use in the industry today, which may be at odds with each other over how to map particular IP addresses. Often the ISP provider operating downstream CDN is the source of authoritative mapping of IP addresses under its management. Thus dCDN should be able to publish IP address mapping information in its network for use by uCDN. When publishing footprint values that rely on 3rd party data sources, dCDN should be able to indicate the origin and specific version of data source(s) used.¶

3.6. Footprint Namespaces

dCDN may utilize different footprint break-down for different uCDN traffic subsets it carries. There are multiple ways that dCDN may identify such traffic, including hostname, type of traffic, service identifiers, etc. Additionally, there is a need to accommodate both "resource" and "coverage" footprints.¶

Footprint namespaces are introduced to allow open and flexible differentiation of footprint breakdowns. This enables a dCDN to advertise multiple breakdowns to the same uCDN tenant, with IP address matching being uniquely scoped within each namespace.¶

3.7. Footprints and Service Identifiers

A need exists to provide differentiated capabilities by traffic subset, e.g. type of traffic, hostname, service identifiers or combination thereof, which may not be related to the "coverage" footprint as defined above. It remains to be determined whether this requirement is best met by extending footprints to scope capabilities to specific traffic subsets, or by introducing a new scoping object that defines named traffic classes in a manner analogous to named footprints.¶

4.1. CDNI Metadata Additional Footprint Types

Section 5 of [RFC8008] describes the FCI Capability Advertisement Object, which includes an array of CDNI Footprint Objects. Each such object has a footprint-type and a footprint-value, as described in section 4.2.2.2 of [RFC8006]. This document defines additional footprint types, beyond those mentioned in CDNI metadata [RFC8006].¶

4.2. Changes to Existing CDNI Metadata Footprint Types

As indicated in Section 3.5, the resolution of complex footprint datatypes relies on 3rd party data sources and may be ambiguous. Furthermore, it should be possible for the dCDN to independently publish its own IP address information. Such footprint types include "asn" and "country" defined in Section 4.2.2.2 of [RFC8006], as well as "subdivisioncode" footprint type, defined in [RFC9388]¶

It is hereby proposed to add an optional attribute "footprint-source" to the footprint object, typed as an array of MI FootprintSource objects, that enumerate all footprint data sources that MUST be used when evaluating whether an IP address belongs to the footprint in question. If no footprint source is provided, any data source can be used for this purpose.¶

4.3. Changes to CDNI Metadata

This section details proposed changes to the CDNI Metadata model, as defined in Section 4 of [RFC8006]. The changes are limited to the introduction of new objects and thus backward compatibility with [RFC8006] is preserved¶

{
        "footprint-source-type": "rfc8805",
        "footprint-source-uri": "http://noc.ietf.org/geo/google.csv"
        "footprint-source-footprint-type": [ "country", "subdivisioncode" ]
}


{
        "footprint-source-type": "private",
        "footprint-source-uri": "https://www.maxmind.com",
        "footprint-source-footprint-type": [ "country", "subdivisioncode" ]
}

{
        "footprint-source-type": "private",
        "footprint-source-uri": "https://tools.iplocation.net/ip-to-asn",
        "footprint-source-footprint-type": [ "asn" ]
}

5.1. CDNI Operation Overview

The CDNI framework presumes that uCDN consumes dCDN capabilities with footprint restrictions at the outset of uCDN delegating traffic to dCDN. The capabilities discovered in this way are subsequently used for metadata-driven configuration of dCDN and request routing. As an option, uCDN and dCDN may refresh the capabilities information via the FCI interface on periodic basis. This process is outlined in Section 3 of [RFC7336].¶

This document proposes the following change to the CDNI operation:¶

1. dCDN advertises the capabilities and footprints via the FCI interface. The footprint advertisement consists of MI NamedFootprint objects, as defined in Section 4.3.1, in one or more namespaces. The footprint advertisement contains expiration information and URIs for every named footprint. The capabilities advertised may be scoped to the named footprints advertised.¶

2. uCDN retrieves the dCDN advertised capabilities via FCI.¶

3. uCDN retrieves and caches the dCDN advertised footprints via FCI.¶

4. uCDN configures dCDN using CDNI Metadata over MI interface. The metadata may optionally reference the footprints advertised by dCDN.¶

5. uCDN receives a content request from a user agent.¶

6. uCDN matches thethe user agent IP address against the cached copy of footprint advertisement made by the dCDN and makes a decision to delegate the request to the dCDN¶

7. uCDN redirects the request to the dCDN by sending a response to the user agent (either DNS or HTTP).¶

8. At any time following the initial retrieval of the footprint advertisement, uCDN may refresh all or part of the cached footprint advertisement, subject to the expiration information provided with every footprint.¶

The FCI footprint advertisement allows for some footprints to be updated more frequently than others. uCDN will be required to query the frequently changing footprint definitions only in case these footprints affect uCDN handling of the user agent requests. Thus, it is expected that the dCDN will not advertise high-level footprints with low time-to-live (TTL).¶

5.2. FCI Advertisement

The example of a named footprint advertisement is as follows:¶

[
  {
  "footprint-namespace": "default",
  "footprint-type": "coverage",
  "footprints": [{
    "footprint-name": "default/us",
    "footprint-expires": "2023-02-09T17:32:28Z",
    "footprint-uri":
      "https://oc.dcdn.com/FCI/footprints/default/us",
    "footprint-def": {
      "footprint-type": "asn",
      "footprint-value": [ "1234:1" ]
    }
    "footprints": [
      {
        "footprint-name": "default:us/us-edge",
        "footprint-expires": "2023-02-09T17:32:28Z",
        "footprint-uri":
          "https://oc.dcdn.com/FCI/footprints/default/us/us-edge",
        "footprint-def": {
          "footprint-type": "expr",
          "footprint-value": [ "$ep.asn = 1234:1 and
             ( $ep.ipv4addr ipmatch "192.168.1/24"
               or $ep.ipv6addr ipmatch "2001:db8:3333:4444/48" ) "]
        }
       ]
     },
     {
       "footprint-name": "default/brasil",
       "footprint-expires": "2023-02-09T17:32:28Z",
       "footprint-uri":
       "https://oc.dcdn.com/FCI/footprints/default/brasil",
       "footprint-def": {
         "footprint-type": "asn",
        "footprint-value": [ "1234:2" ]
        }
      }
    ]
  },
  {
    "footprint-namespace": "live",
    "footprint-type": "coverage",
    "footprints": [
      {
        "footprint-name": "live/us",
        "footprint-expires": "2023-02-09T17:32:28Z",
        "footprint-uri":
          "https://oc.dcdn.com/FCI/footprints/live/us",
        "footprint-def": {
           "footprint-type": "asn",
           "footprint-value": [ "1234:1" ]
           }
      },
      {
         "footprint-name": "live/brasil",
         "footprint-expires": "2023-02-09T17:32:28Z",
         "footprint-uri":
           "https://oc.dcdn.com/FCI/footprints/live/brasil",
         "footprint-def": {
           "footprint-type": "asn",
           "footprint-value": [ "1234:2" ]
         }
      }
    ]
  }
]

5.3. Use of Named Footprints

The named footprints can be used in both FCI and MI footprints in the places where CDNI Metadata objects are scoped by footprint. Thus, the MI PrivateFeature object described in Section 2.5.2.1 of [cdni-metadata-expression-language] would use the named footprint advertisement as follows:¶

{
      "generic-metadata-type": "MI.PrivateFeatureList",
      "generic-metadata-value": {
        "feature": {
          "feature-oid": "Broadpeak",
          "feature-type": "S4Streaming",
          "feature-value": {
            "footprint": {
                "footprint-type": "named",
                "footprint-value": [ "https://oc.dcdn.com/FCI/footprints/live/us" ]
            }
            "activation": "ON",
            "mode": "transparent",
            "policy": "bandwidth-max"
          }
        }
      }
}

6.1. CDNI Metadata Footprint Types

Section 7.2 of [RFC8006] creates the "CDNI Metadata Footprint Types" subregistry within the "Content Delivery Network Interconnection (CDNI) Parameters" registry.¶

This document requests the registration of the two additional Footprint Types: "expr" and "named"¶