Internet-Draft Content Delivery Network Interconnection March 2023
Arolovitch Expires 29 September 2023 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-arolovitch-cdni-named-footprints-00
Updates:
7336, 8006, 8008 (if approved)
Published:
Intended Status:
Standards Track
Expires:
Author:
A. Arolovitch
Viasat

Content Delivery Network Interconnection (CDNI) Named Footprints

Abstract

Open Caching architecture is a use case of Content Delivery Networks Interconnection (CDNI) in which the commercial Content Delivery Network (CDN) is the upstream CDN (uCDN) and the ISP caching layer serves as the downstream CDN (dCDN). This document extends the Footprint & Capabilities Advertisement Interface (FCI) defined in RFC8008, to allow advertising of named footprint objects, that can be referenced in a consistent manner from Metadata Interface (MI), also defined in RFC8006, as well as from the FCI itself as well as additional interfaces in the Open Caching architecture. This document also supplements the CDNI Metadata Footprint Types defined in RFC8006 and modifies the CDNI operation as described in RFC7336.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 29 September 2023.

Table of Contents

1. Introduction

The Streaming Video Technology Alliance [SVTA] is a global association that works to solve streaming video challenges in an effort to improve end-user experience and adoption. The Open Caching Working Group [OCWG] of the Streaming Video Technology Alliance [SVTA] is focused on the delegation of video delivery requests from commercial CDNs to a caching layer at the ISP's network. Open Caching architecture is a specific use case of CDNI where the commercial CDN is the upstream CDN (uCDN) and the ISP caching layer is the downstream CDN (dCDN).

For consistency with other CDNI documents this document follows the CDNI convention of uCDN (upstream CDN) and dCDN (downstream CDN) to represent the commercial CDN and ISP caching layer respectively.

1.1. What is a Footprint

The definition of footprint within existing CDNi and open caching architecture literature remains ambiguous. Appendix B "Semantics for Footprint Advertisement" of RFC8006 [RFC8006] reads:

Generally speaking, one can imagine two categories of footprints to be advertised by a dCDN:

  • A footprint could be defined based on coverage/reachability, where "coverage/reachability" refers to a set of prefixes, a geographic region, or similar boundary. The dCDN claims that it can cover/reach "end user requests coming from this footprint".
  • A footprint could be defined based on resources, where "resources" refers to Surrogates a dCDN claims to have (e.g., the location of Surrogates/resources). The dCDN claims that "from this footprint" it can serve incoming end user requests.

Within the open caching architecture the use of footprints revolves around uCDN handling an end user request. Therefore this document is going to focus on the coverage footprints - a collection of end users that dCDN is willing and able to serve, while leaving the room for future use of footprints for management of dCDN cache resources. The coverage footprint is defined through end user IP address (IPv4 and/or IPv6 CIDRs), or attributes that can be derived from this address (BGP autonomous system number, country code, subdivision code)

1.2. Types of footprint

Several types of CDN footprints may be be defined:

  • Disaggregated - CDN spanning disparate coverage regions, which lie in different geographies and/or jurisdictions, yet share common management.
  • Regional - Different coverage regions within contiguous coverage, that have distinct properties, yet users within one region may be served from other CDN regions, for example in case of failure or overload
  • Functional - CDN regions with different functional and capacity characteristics, e.g. highly distributed CDN with limited storage capacity at each node

Furthermore, dCDN may manage different footprint break-down for various traffic subsets it carries - by CDN tenant, type of traffic, hostname, service identifier etc.

1.3. Footprint support in FCI today

The Footprint and Capabilities Interface (FCI), as specified in [RFC8006] provides an interface, allowing uCDNs to query dCDN capabilities, published via object-based data model in compliance with [RFC8006] and [RFC8008]. The dCDN capabilities objects published by FCI may optionally be associated with one or more footprint, via the "footprints" property, which is an array of MI Footprint objects.

The MI Footprint objects are encoded in compliance with [RFC8006] and contain two properties: "footprint-type" and "footprint-value". They are declarative and are scoped within their parent capability object. The footprint types specified in [RFC8006] include IPv4 CIDR block ("ipv4cidr"), IPv6 CIDR block ("ipv6cidr"), BGP autonomous system number ("asn") and country ("countrycode"). The footprint value property is an array of one or more footprint values of the same type.

According to [RFC8008], combination of multiple footprint types is to be understood as additive or, in other words, as an implicit boolean OR operation.

Neither [RFC8006] nor [RFC8008] provide instruction on how uCDN is to match end user requests with higher-level footprint types like country.

1.4. Motivations

A need exists for dCDN to advertise footprints for use across multiple dCDN interfaces in a way that is consistent, flexible and can support complex footprint structure in a computationally efficient way. Various motivations for having such capability include:

1.4.1. Interface-level footprint awareness

By creating addressable footprints resources, it becomes possible for all open caching interfaces to associate interface operations and responses with specific footprints, including but not limited to: CDN configuration by footprint, request routing methods by footprint, cache management operations by footprint, logging by footprint, capacity management and monitoring by footprint.

1.4.2. Cross-interface consistency

In several cases use of footprints may affect multiple interfaces. For example, differentiated CDN configuration may trigger logging by footprint or affect footprint-specific cache management operations. In these cases common footprint definition that is external to individual interfaces is required to assure consistency.

1.4.3. CDN slicing

In some cases, CDN providers may want to operate CDN footprints as fully autonomous virtual CDNs, with their own configuration, management and reporting as well as a distinct set of content provider tenants. This capability is particularly useful for CDN providers that manage disaggregated CDN footprints across different geographies. In the CDN slicing scenario, the footprints may optionally share some aspects of operation (i.e. have common tenants), while differing in every other aspect, for operational reasons. It is the duty of the uCDN to consistently use the footprint across different interfaces, once advertised.

1.4.4. Management of complex 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 and benefit from caching support, unlike capabilities advertisement which is relatively static in nature. Because of this, it would be beneficial to allow querying of individual footprint resources separately from capabilities advertisement, which tends to be mostly static.

1.4.5. Computational efficiency

Some of the uses of footprint advertisements are tied to uCDN request handling, and should be as computationally efficient as possible.

1.5. Terminology

The following terms are used throughout this document:

  • CDN - Content Delivery Network
  • CIDR - Classless Internet-Domain Routing

Additionally, this document reuses the terminology defined in [RFC7337], [RFC8006], and [RFC8008]. Specifically, we use the following CDNI acronyms:

  • uCDN, dCDN - Upstream CDN and Downstream CDN respectively (see [RFC7336])

2. Requirements

2.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 be 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.

2.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.

2.3. Backwards compatibility

The footprint definition must be backwards 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 business logic of footprint advertisement, the specification may introduce new footprint types as well as footprint properties, in addition to footprint type and value.

2.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 exressions as defined in Section 3 of [CDNI-Metadata-Model-Extensions]. 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" )"
    }

2.5. Consistent Datasource

While IP-based footprint types like "ipv4cidr", "ipv6cidr" and "asn" are unambiguous, higher level footprints types like "country" rely on external databases for lookup. Multiple databases for IP address intelligence are in use in the industry today. To assure consistent interpretation of these footprint types, footprint value should include datasource, e.g. "maxmind-01012023:us" or "maxmind-latest:br"

2.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.

To allow such differentiated break-down in an open way, footprint namespaces are introduced, allowing dCDN to publish more than one footprint break-down advertisement to each uCDN tenant. Matching of IP address to footprint is unique within each namespace.

2.7. Footprints and Service Identifiers

Need exists to provide differentiated capabilities by traffic subset, e.g. type of traffic, hostname, service identiers or combination thereof, which may not be related to "coverage" footprint as defined above. It is to be determined whether this requirement is best addressed by scoping such capabilities in a footprint, which would be extended to refer to traffic subsets, or through a new scoping object that defines named traffic classes in a manner similar to named footprints.

3. Changes to CDNI Metadata

3.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].

3.1.1. Expression Footprint Type

The "expr" footprint type specified in Section 3.1.1.1 describes a footprint using CDNI Metadata Expression Language as defined in Section 3 of [CDNI-Metadata-Model-Extensions]. The data type is added to the list of data types described in section 4.3 of [RFC8006]. This data type may supersede the "footprintunion" datatype proposed in [cdni-additional-footprint-types]

3.1.1.1. Expression Footprint Type Description

The footprint value is a CDNI Metadata Expression Language expression, as defined in Section 3 of [CDNI-Metadata-Model-Extensions].

  • Type: String
  • Examples:
  • ( $ep.country == "us" ) and
  • not $ep.ipv4addr ipmatch ( "10.1.1/24" or "10.1.2.0/24" )"
  • ( $ep.asn = 1234 ) or ( $ep.ipv4addr ipmatch "192.168.1/24" ) or
  • ( $ep.ipv6addr ipmatch "2001:db8:3333:4444/48" )

3.1.2. Named Footprint Type

The "named" footprint type specified in Section 3.1.2.1 describes an addressable footprint, that can be referenced by other CDNI Metadata objects as well as used within CDNI interfaces using CDNI Metadata Expression Language "[CDNI-Metadata-Model-Extensions]. The data type is added to the list of data types described in section 4.3 of [RFC8006].

3.1.2.1. Named Footprint Type Description

The footprint value is the URI of named footprint advertised via the FCI footprint advertised as described in Section 4.2

  • Type: String
  • Example:
  • "https://oc.dcdn.com/FCI/footprints/live/us"

3.2. Changes to Existing CDNI Metadata Footprint Types

As indicated in Section 2.5, resolution of complex footprint datatypes, relies on 3rd party datasources and maybe ambiguous. Such footprint types include "asn" and "country" defined in Section 4.2.2.2 of [RFC8006], as well as "subdivisioncode" footprint type, proposed in [cdni-additional-footprint-types]

It is hereby proposed to change footprint values for these datatypes to include an optional column-separated datasource, e.g. "maxmind-latest:us" or "bgpview:1234" Mechanism for defining standard naming convention for GeoIP datasource is beyond of the scope of this document. It is therefore assumed that uCDN and dCDN may agree on common datasource format.

3.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 introduction of new objects and thus backward compatibility with [RFC8006] is preserved

3.3.1. MI NamedFootprint

NamedFootprint is a new GenericMetadata object that defined a named footprint that can be explicitly referenced by the CDNI Metadata objects.

  • - Property: footprint-def
  • Description: Footprint definition
  • Type: JSON-encoded MI Footprint object as defined in Section 4.2.2.2 of [RFC8006]
  • Mandatory: Yes
  • - Property: subfootprints
  • Description: List of descendant footprints in the footprint hierarchy
  • Type: Array of MI NamedFootprint objects as defined in Section 3.3.1
  • Mandatory: No
  • - Property: footprint-name
  • Description: Footprint name, must be unique in same footprint namespace
  • Type: String
  • Mandatory: Yes
  • - Property: footprint-uri
  • Description: URI pointing to the footprint definition. Can be queried by uCDN separately
  • Type: String
  • Mandatory: Yes
  • - Property: footprint-expires
  • Description: Timestamp for footprint definition expiration, should be used for caching and refreshing of the footprint definition.
  • Type: Date-time
  • Mandatory: Yes

3.3.2. MI NamedFootprintNamespace

NamedFootprintName is a new GenericMetadata object that defines a namespace containing footprints. Footprints should have unique name within each namespace. dCDN should advertise footprints so that each endpoint resolves unambiguously to a footprint within each namespace.

  • - Property: footprint-namespace
  • Description: Footprint namespace name
  • Type: String
  • Mandatory: Yes
  • - Property: footprint-type
  • Description: Definition of footprint type advertised in the namespace as defined in Appendix B of [RFC8006]
  • Type: One of "coverage" or "resource"
  • Mandatory: Yes
  • - Property: footprints
  • Description: List of root footprints included in the namespace
  • Type: Array of MI NamedFootprint objects as defined in Section 3.3.1
  • Mandatory: Yes

4. Changes to CDNI Operation

4.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 3.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 capabiities 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 content request from a user agent.
  6. uCDN matches user agent IP address against the cached copy of footprint advertisement made by the dCDN and makes 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 require 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).

4.2. FCI Advertisement

The example of 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"
         }
      }
    ]
  }
]

4.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-Model-Extensions] 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"
          }
        }
      }
}

5. IANA Considerations

5.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"

6. Security Considerations

TBD

7. References

7.1. Normative References

[RFC8006]
Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, "Content Delivery Network Interconnection (CDNI) Metadata", RFC 8006, DOI 10.17487/RFC8006, , <https://www.rfc-editor.org/info/rfc8006>.
[RFC8008]
Seedorf, J., Peterson, J., Previdi, S., van Brandenburg, R., and K. Ma, "Content Delivery Network Interconnection (CDNI) Request Routing: Footprint and Capabilities Semantics", RFC 8008, DOI 10.17487/RFC8008, , <https://www.rfc-editor.org/info/rfc8008>.

7.2. Informative References

[cdni-additional-footprint-types]
"Content Delivery Network Interconnection (CDNI) Footprint Types: Subdivision Code and Union", <https://datatracker.ietf.org/doc/html/draft-ietf-cdni-additional-footprint-types-04>.
[CDNI-Metadata-Model-Extensions]
"CDNI Metadata Model Extensions - Metadata Expression Language", <https://datatracker.ietf.org/doc/html/draft-goldstein-cdni-metadata-model-extensions-02>.
[OCWG]
"Open Caching Home Page", <https://opencaching.svta.org/>.
[RFC7336]
Peterson, L., Davie, B., and R. van Brandenburg, Ed., "Framework for Content Distribution Network Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, , <https://www.rfc-editor.org/info/rfc7336>.
[RFC7337]
Leung, K., Ed. and Y. Lee, Ed., "Content Distribution Network Interconnection (CDNI) Requirements", RFC 7337, DOI 10.17487/RFC7337, , <https://www.rfc-editor.org/info/rfc7337>.
[SVTA]
"Streaming Video Technology Alliance Home Page", <https://www.svta.org/>.

Author's Address

Alan Arolovitch
Viasat
1295 Beacon street, Unit 249
Brookline, MA 02446
United States of America