



Network Working Group                                      A. Arolovitch
Internet-Draft                                                    Viasat
Updates: 7336, 8006, 8008 (if approved)                      7 July 2025
Intended status: Standards Track                                        
Expires: 8 January 2026


    Content Delivery Network Interconnection (CDNI) Named Footprints
                  draft-ietf-cdni-named-footprints-02

Abstract

   The document specifies an object-based semantics to CDNI footprint
   advertisement, that enables RESTful implementations of the FCI
   protocol.  This approach enables multiple CDNI capabilities within
   the FCI to share common footprint definitions and allows footprint
   advertisement to be used in additional CDNI interfaces.  This
   document further specifies operational enhancements to the CDNI
   footprint support.

   The document specifies an alternative, object-based approach to CDNI
   footprint advertisement, that enables RESTful implementations of the
   FCI protocol.  This approach enables multiple CDNI capabilities
   within the FCI to share common footprint definitions and allows
   footprint advertisement to be used in additional CDNI interfaces.
   This document further specifies operational enhancements to the CDNI
   footprint support.

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 8 January 2026.







Arolovitch               Expires 8 January 2026                 [Page 1]

Internet-Draft  Content Delivery Network Interconnection       July 2025


Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   5
   2.  Use cases . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.1.  Footprints shared by multiple FCI objects . . . . . . . .   5
     2.2.  Use of footprints in multiple CDNI interfaces . . . . . .   5
     2.3.  Dynamic footprints  . . . . . . . . . . . . . . . . . . .   5
     2.4.  Complex footprints  . . . . . . . . . . . . . . . . . . .   6
     2.5.  Footprint hieratchy . . . . . . . . . . . . . . . . . . .   6
     2.6.  Footprint by type of traffic  . . . . . . . . . . . . . .   6
     2.7.  Footprint definitions mismatch  . . . . . . . . . . . . .   6
   3.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Footprints Advertisement  . . . . . . . . . . . . . . . .   6
     3.2.  Hierarchy . . . . . . . . . . . . . . . . . . . . . . . .   7
     3.3.  Backward compatibility  . . . . . . . . . . . . . . . . .   7
     3.4.  Explicit Logic  . . . . . . . . . . . . . . . . . . . . .   8
     3.5.  Consistent Datasource . . . . . . . . . . . . . . . . . .   9
     3.6.  Footprint Namespaces  . . . . . . . . . . . . . . . . . .   9
     3.7.  Footprints and Service Identifiers  . . . . . . . . . . .   9
   4.  Changes to CDNI Metadata  . . . . . . . . . . . . . . . . . .   9
     4.1.  CDNI Metadata Additional Footprint Types  . . . . . . . .   9
       4.1.1.  Expression Footprint Type . . . . . . . . . . . . . .  10
         4.1.1.1.  Expression Footprint Type Description . . . . . .  10
       4.1.2.  Named Footprint Type  . . . . . . . . . . . . . . . .  10
         4.1.2.1.  Named Footprint Type Description  . . . . . . . .  10
     4.2.  Changes to Existing CDNI Metadata Footprint Types . . . .  11
     4.3.  Changes to CDNI Metadata  . . . . . . . . . . . . . . . .  11
       4.3.1.  MI NamedFootprint . . . . . . . . . . . . . . . . . .  11
       4.3.2.  MI NamedFootprintNamespace  . . . . . . . . . . . . .  12
       4.3.3.  MI FootprintSource  . . . . . . . . . . . . . . . . .  13
   5.  Changes to CDNI Operation . . . . . . . . . . . . . . . . . .  14
     5.1.  CDNI Operation Overview . . . . . . . . . . . . . . . . .  14
     5.2.  FCI Advertisement . . . . . . . . . . . . . . . . . . . .  15



Arolovitch               Expires 8 January 2026                 [Page 2]

Internet-Draft  Content Delivery Network Interconnection       July 2025


     5.3.  Use of Named Footprints . . . . . . . . . . . . . . . . .  17
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
     6.1.  CDNI Metadata Footprint Types . . . . . . . . . . . . . .  17
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  17
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  18
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  19

1.  Introduction

   The Content Delivery Networks Interconnection (CDNI) framework in RFC
   6707 defines a set of protocols to interconnect CDNs to achieve
   multiple goals, including extending the reach of a given CDN.  A CDNI
   Request Routing Footprint & Capabilities Advertisement interface
   (FCI) is needed to achieve the goals of a CDNI.  Through the FCI
   interface, CDNs advertise their capabilities, optionally scoping them
   with footprints that are published together with the capabilities.
   RFC 8008 defines the FCI semantics and provides guidelines on the FCI
   protocol, however the exact FCI protocol is not specified.

   RFC 9241 defines an implementation of the FCI protocol that uses
   network topology information encoded in the Application-Layer Traffic
   Optimization (ALTO) protocol format, as specified in RFC 7285, to
   describe CDNI footprints.  It introduces a new "altopid" footprint
   type, in addition to the CDNI types introduced in RFC8006, enabling
   shared footprint definitions across CDNI capabilities.

   The document specifies an alternative, object-based approach to CDNI
   footprint advertisement, that enables RESTful implementations of the
   FCI protocol.  This approach enables multiple CDNI capabilities
   within the FCI to share common footprint definitions and allows
   footprint advertisement to be used in additional CDNI interfaces.
   This document further specifies operational enhancements to the CDNI
   footprint support.

   The definition of footprint within existing CDNI 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".




Arolovitch               Expires 8 January 2026                 [Page 3]

Internet-Draft  Content Delivery Network Interconnection       July 2025


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

   The use of footprints in the CDN interconnection context revolves
   around upstream CDN (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).

   Several types of CDN footprints may 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.

   Theses types of footprints represent consistent entities within a
   CDN, that have distinct operational and/or functional
   characteristics, 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 especially useful for
   CDN providers that manage disaggregated CDN footprints across
   different geographies.  Because of that multiplie capabilities
   advertised by the CDN are likely to be scoped within the same
   footprint and it is desirable to provide a consistent shared
   definition of such footprint.  Additionally, once a dCDN advertises
   differentiated, footprint-scoped capabilities, it is desirable to
   allow uCDNs to use differentiated configuraiton and operations, that
   are scoped in accordance to the capabiities advertised by the dCDN.



Arolovitch               Expires 8 January 2026                 [Page 4]

Internet-Draft  Content Delivery Network Interconnection       July 2025


1.1.  Terminology

   This document reuses the terminology defined in [RFC6707] and uses
   "uCDN" and "dCDN" as shorthand for "upstream CDN" and "downstream
   CDN", respectively.

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119][RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Use cases

   The following industry use cases have been identified requiring CDNI
   footprint support:

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.







Arolovitch               Expires 8 January 2026                 [Page 5]

Internet-Draft  Content Delivery Network Interconnection       July 2025


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

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



Arolovitch               Expires 8 January 2026                 [Page 6]

Internet-Draft  Content Delivery Network Interconnection       July 2025


   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.






Arolovitch               Expires 8 January 2026                 [Page 7]

Internet-Draft  Content Delivery Network Interconnection       July 2025


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" )" ]
       }





Arolovitch               Expires 8 January 2026                 [Page 8]

Internet-Draft  Content Delivery Network Interconnection       July 2025


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.  Changes to CDNI Metadata

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



Arolovitch               Expires 8 January 2026                 [Page 9]

Internet-Draft  Content Delivery Network Interconnection       July 2025


4.1.1.  Expression Footprint Type

   The "expr" footprint type specified in Section 4.1.1.1 describes a
   footprint using CDNI Metadata Expression Language as defined in
   Section 3 of [cdni-metadata-expression-language].  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 defined in [RFC9388]

4.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-expression-language].

      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" )

4.1.2.  Named Footprint Type

   The "named" footprint type specified in Section 4.1.2.1 describes an
   addressable footprint, that can be referenced by CDNI Metadata
   objects and used in CDNI interfaces using CDNI Metadata Expression
   Language "[cdni-metadata-expression-language].  The data type is
   added to the list of data types described in section 4.3 of
   [RFC8006].

4.1.2.1.  Named Footprint Type Description

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

      Type: String

      Example:

      "https://oc.dcdn.com/FCI/footprints/live/us"





Arolovitch               Expires 8 January 2026                [Page 10]

Internet-Draft  Content Delivery Network Interconnection       July 2025


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

4.3.1.  MI NamedFootprint

   NamedFootprint is a new GenericMetadata object that defines a named
   footprint, which can be explicitly referenced by 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 4.3.1

      Mandatory: No




Arolovitch               Expires 8 January 2026                [Page 11]

Internet-Draft  Content Delivery Network Interconnection       July 2025


      - Property: footprint-name

      Description: Footprint name, must be unique in the 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 the footprint definition.

      Type: Date-time

      Mandatory: Yes

4.3.2.  MI NamedFootprintNamespace

   NamedFootprintName is a new GenericMetadata object that defines a
   namespace containing footprints.  Footprints should have a 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]




Arolovitch               Expires 8 January 2026                [Page 12]

Internet-Draft  Content Delivery Network Interconnection       July 2025


      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 4.3.1

      Mandatory: Yes

4.3.3.  MI FootprintSource

   FootprintSource is a new GenericMetadata object that defines a data
   source that MUST be used when matching IP addresses with a footprint.

      - Property: footprint-source-type

      Description: Type of data source.  Can be either "rfc8805" for
      geolocation feeds published by dCDN in accordance with [RFC8805]
      or "private" for data source utilizing proprietary data formats
      and/or APIs

      Type: String

      Mandatory: Yes

      - Property: footprint-source-uri

      Description: Footprint source URI.  For "rfc8805" footprint
      sources should be the self-published feed URI.  For other
      footprint sources, the URI should identify the footprint source in
      a unique way.

      Type: String

      Mandatory: Yes

      - Property: footprint-source-footprint-type

      Description: Footprint type(s) supported by this footprint source

      Type: Array of Strings, can take values of "country", "asn" or
      "subdivisioncode"

      Mandatory: Yes



Arolovitch               Expires 8 January 2026                [Page 13]

Internet-Draft  Content Delivery Network Interconnection       July 2025


   The example of a named footprint advertisement is as follows:



{
        "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.  Changes to CDNI Operation

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.



Arolovitch               Expires 8 January 2026                [Page 14]

Internet-Draft  Content Delivery Network Interconnection       July 2025


   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":



Arolovitch               Expires 8 January 2026                [Page 15]

Internet-Draft  Content Delivery Network Interconnection       July 2025


             "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" ]
            }
         }
       ]
     }
   ]



Arolovitch               Expires 8 January 2026                [Page 16]

Internet-Draft  Content Delivery Network Interconnection       July 2025


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.  IANA Considerations

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"

7.  Security Considerations

   TBD

8.  References

8.1.  Normative References




Arolovitch               Expires 8 January 2026                [Page 17]

Internet-Draft  Content Delivery Network Interconnection       July 2025


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8006]  Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma,
              "Content Delivery Network Interconnection (CDNI)
              Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016,
              <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, December 2016,
              <https://www.rfc-editor.org/info/rfc8008>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC9388]  Sopher, N. and S. Mishra, "Content Delivery Network
              Interconnection (CDNI) Footprint Types: Country
              Subdivision Code and Footprint Union", RFC 9388,
              DOI 10.17487/RFC9388, July 2023,
              <https://www.rfc-editor.org/info/rfc9388>.

8.2.  Informative References

   [cdni-metadata-expression-language]
              "CDNI Metadata Expression Language",
              <https://datatracker.ietf.org/doc/draft-power-metadata-
              expression-language/>.

   [RFC6707]  Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
              Distribution Network Interconnection (CDNI) Problem
              Statement", RFC 6707, DOI 10.17487/RFC6707, September
              2012, <https://www.rfc-editor.org/info/rfc6707>.

   [RFC7336]  Peterson, L., Davie, B., and R. van Brandenburg, Ed.,
              "Framework for Content Distribution Network
              Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336,
              August 2014, <https://www.rfc-editor.org/info/rfc7336>.

   [RFC8805]  Kline, E., Duleba, K., Szamonek, Z., Moser, S., and W.
              Kumari, "A Format for Self-Published IP Geolocation
              Feeds", RFC 8805, DOI 10.17487/RFC8805, August 2020,
              <https://www.rfc-editor.org/info/rfc8805>.




Arolovitch               Expires 8 January 2026                [Page 18]

Internet-Draft  Content Delivery Network Interconnection       July 2025


Author's Address

   Alan Arolovitch
   Viasat
   1295 Beacon street, Unit 249
   Brookline, MA 02446
   United States of America
   Email: alan.arolovitch@gmail.com











































Arolovitch               Expires 8 January 2026                [Page 19]
