Qwilt

6, Ha'harash Hod HaSharon 4524079 Israel nir@apache.org

Verizon

13100 Columbia Pike Silver Spring MD 20904 United States of America sanjay.mishra@verizon.com

art cdni Open Caching architecture is a use case of Content Delivery Network 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). RFC 8006 defines footprint types that are used for footprint objects as part of the Metadata interface (MI). The footprint types are also used for the Footprint & Capabilities Advertisement interface (FCI) as defined in RFC 8008. This document defines two new footprint types. The first footprint type defined is an ISO 3166-2 country subdivision code. Defining this country subdivision code improves granularity for delegation as compared to the ISO 3166-1 country code footprint type defined in RFC 8006. The ISO 3166-2 country subdivision code is also added as a new entity domain type in the "ALTO Entity Domain Types" registry defined in Section 7.4 of RFC 9241. The second footprint type defines a footprint union to aggregate footprint objects. This allows for additive semantics over the narrowing semantics defined in Appendix B of RFC 8008 and therefore updates RFC 8008. The two new footprint types are based on the requirements raised by Open Caching but are also applicable to CDNI use cases in general.

Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2023 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 () 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

• .  Introduction
  • .  Terminology
  • .  Requirements Language
• .  CDNI Metadata Additional Footprint Types
  • .  CDNI Metadata "subdivisioncode" Footprint Type
    • .  CDNI Metadata "subdivisioncode" Data Type
      • .  CDNI Metadata "subdivisioncode" Data Type Description
    • .  CDNI Metadata "subdivisioncode" Footprint Type Description
  • .  CDNI Metadata "footprintunion" Footprint Type
    • .  CDNI Metadata "footprintunion" Data Type
    • .  CDNI Metadata "footprintunion" Footprint Type Description
• .  ALTO Property Map Service Entity
  • .  SUBDIVISIONCODE Domain
    • .  Entity Domain Type
    • .  Domain-Specific Entity Identifiers
    • .  Hierarchy and Inheritance
• .  IANA Considerations
  • .  CDNI Metadata Footprint Types
  • .  ALTO Entity Domain Types
• .  Security Considerations
• .  References
  • .  Normative References
  • .  Informative References
• Acknowledgements
• Authors' Addresses

Introduction The Streaming Video Technology Alliance 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 of the SVTA is focused on the delegation of video delivery requests from commercial Content Delivery Networks (CDNs) to a caching layer at the ISP's network. Open Caching architecture is a specific use case of Content Delivery Network Interconnection (CDNI) where the commercial CDN is the upstream CDN (uCDN) and the ISP caching layer is the downstream CDN (dCDN). The "Open Caching Request Routing Functional Specification" defines the Request Routing process and the interfaces that are required for its provisioning. This document defines and registers CDNI Footprint and Capabilities objects that are required for Open Caching Request Routing. For consistency with other CDNI documents, this document follows the CDNI convention of using "uCDN" and "dCDN" to represent the commercial CDN and ISP caching layer, respectively. This document registers two CDNI Metadata footprint types () for the defined objects:

• Country subdivision code footprint type (e.g., for a dCDN advertising a footprint that is specific to a state in the United States of America)
• Footprint union footprint type (for a dCDN advertising a footprint that consists of a group built from multiple footprint types, e.g., both IPv4 and IPv6 client subnets)

Terminology The following terms are used throughout this document:

CDN:

Content Delivery Network

Additionally, this document reuses the terminology defined in , , , and . Specifically, we use the following CDNI abbreviations:

uCDN:

upstream CDN (see )

dCDN:

downstream CDN (see )

Requirements Language The key words "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 when, and only when, they appear in all capitals, as shown here.

CDNI Metadata Additional Footprint Types describes the Footprint & Capabilities Advertisement interface (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 . This document defines additional footprint types, beyond those mentioned in .

CDNI Metadata "subdivisioncode" Footprint Type specifies the "countrycode" footprint type for listing alpha-2 codes. Using footprint objects of this type, one can define an FCI Capability Advertisement object footprint constraint that matches a specific country. This document defines the "subdivisioncode" simple data type as well as a footprint type, allowing the dCDN to define constraints that match geographic areas with better granularity, specifically using the country subdivision codes.

CDNI Metadata "subdivisioncode" Data Type The "subdivisioncode" data type specified in describes a country-specific subdivision using a code as defined in . The data type is added to the list of data types described in that are used as properties of CDNI Metadata objects.

CDNI Metadata "subdivisioncode" Data Type Description An code in lowercase. Each code consists of two parts separated by a hyphen. As per , the first part is the code of the country and the second part is a string of up to three alphanumeric characters.

Type:

String

Example country subdivision codes:

• "ca-on"
• "us-ny"

CDNI Metadata "subdivisioncode" Footprint Type Description The "subdivisioncode" simple data type specified in is added to the data types listed as footprint types in . is an example using a footprint object of type "subdivisioncode". The footprint object in this example creates a constraint that matches clients in the state of either New Jersey or New York, USA (ISO codes "US-NJ" and "US-NY", respectively).

Illustration of Country Subdivision Code Footprint Advertisement { "capabilities": [ { "capability-type": <CDNI capability object type>, "capability-value": <CDNI capability object>, "footprints": [ { "footprint-type": "subdivisioncode", "footprint-value": ["us-nj", "us-ny"] } ] } ] }

CDNI Metadata "footprintunion" Footprint Type As described in , the FCI Capability Advertisement object includes an array of CDNI footprint objects. Appendix B of specifies the semantics for Footprint Advertisement such that multiple footprint constraints are additive. This implies that the advertisement of different footprint types narrows the dCDN's candidacy cumulatively. Sections and of specify the "ipv4cidr" and the "ipv6cidr" footprint types, respectively, for listing IP unscoped address blocks. Using footprint objects of these types, one can define FCI Capability Advertisement object footprint constraints that match either IPv4 or IPv6 clients, but not both. This is due to the described "narrowing" semantic of the Footprint Objects array, as described in Appendix B of , that prevents the usage of these objects together to create a footprint constraint that matches IPv4 clients with IPv6 clients. is an example attempting to create an object that matches IPv4 clients of subnet "192.0.2.0/24" as well as IPv6 clients of subnet "2001:db8::/32". Such a definition results in an empty list of clients, as the constraints are additives and a client address cannot be both IPv4 and IPv6.

Example of Narrowing Semantic Illustrating Advertisement of a Null Footprint { "capabilities": [ { "capability-type": <CDNI capability object type>, "capability-value": <CDNI capability object>, "footprints": [ { "footprint-type": "ipv4cidr", "footprint-value": ["192.0.2.0/24"] }, { "footprint-type": "ipv6cidr", "footprint-value": ["2001:db8::/32"] } ] } ] }

To overcome the described limitation and allow a list of footprint constraints that match both IPv4 and IPv6 client subnets, this document defines the "footprintunion" footprint type. This footprint type allows the collection of multiple footprint-objects into a unified object. Therefore, it resolves the above limitation and can be particularly applicable to unify semantically related objects: for example, an IPv4 CIDR together with an IPv6 CIDR or a country code together with a country subdivision code. Note: to avoid implementation complexity, a "footprintunion" MUST NOT list any "footprintunion" as a value. As a union of unions is simply a union, this syntactic restriction does not result with any semantic limitation.

CDNI Metadata "footprintunion" Data Type The "footprintunion" data type is based on the footprint object already defined in . The footprint value for a "footprintunion" object is an array of footprint objects, where the footprint objects MUST be of any footprint type other than "footprintunion".

CDNI Metadata "footprintunion" Footprint Type Description The "footprintunion" data type specified in is added to the data types listed as footprint types in . is an example using a footprint union combining both IPv4 and IPv6 client subnets.

Example of an Advertisement of Footprint Union for Multiple Classless Inter-Domain Routing (CIDR) Footprint Types { "capabilities": [ { "capability-type": <CDNI capability object type>, "capability-value": <CDNI capability object>, "footprints": [ { "footprint-type": "footprintunion", "footprint-value": [ { "footprint-type": "ipv4cidr", "footprint-value": ["192.0.2.0/24"] }, { "footprint-type": "ipv6cidr", "footprint-value": ["2001:db8::/32"] } ] } ] } ] }

The footprint union also enables composing of footprint objects based on the country code and country subdivision code. In , we create a constraint covering autonomous system 64496 within the USA (ISO alpha-2 code "US" as described in ) and the Ontario province of Canada (ISO code "CA-ON" as described in ).

Example of an Advertisement of Footprint Union for Multiple Geographical Footprint Types { "capabilities": [ { "capability-type": <CDNI capability object type>, "capability-value": <CDNI capability object>, "footprints": [ { "footprint-type": "asn", "footprint-value": ["as64496"] }, { "footprint-type": "footprintunion", "footprint-value": [ { "footprint-type": "countrycode", "footprint-value": ["us"] }, { "footprint-type": "subdivisioncode", "footprint-value": ["ca-on"] } ] } ] } ] }

ALTO Property Map Service Entity describes how to represent footprint objects as entities in the ALTO property map. The approach is to represent the footprint type as an entity domain type of the ALTO entity and the footprint value as its domain-specific identifier. further refers to the representation of footprint objects of types "asn" and "countrycode". Here, we extend this definition to the "subdivisioncode" footprint type.

SUBDIVISIONCODE Domain The SUBDIVISIONCODE domain associates property values that define codes for the names of the principal subdivisions.

Entity Domain Type The entity domain type of the SUBDIVISIONCODE domain is "subdivisioncode" (in lowercase).

Domain-Specific Entity Identifiers The entity identifier of an entity in a SUBDIVISIONCODE is encoded as an alpha-2 country code, followed by a separator and up to three alphanumeric characters.

Hierarchy and Inheritance There is no hierarchy or inheritance for properties associated with country subdivision codes.

IANA Considerations

CDNI Metadata Footprint Types specifies the "CDNI Metadata Footprint Types" subregistry within the "Content Delivery Network Interconnection (CDNI) Parameters" registry. This document registers two footprint types in that subregistry as defined in Sections and : Additions to the CDNI Metadata Footprint Types Subregistry

Footprint Type	Description	Reference
subdivisioncode	ISO 3166-2 country subdivision code: alpha-2 country code, followed by a hyphen-minus and up to 3 characters from A-Z;0-9 as a code within the country	RFC 9388
footprintunion	A combination of other footprint objects	RFC 9388

ALTO Entity Domain Types creates the "ALTO Entity Domain Types" subregistry within the "Application-Layer Traffic Optimization (ALTO) Protocol" registry. This document registers an additional ALTO Entity Domain Type within that subregistry: Addition to the ALTO Entity Domain Types Subregistry

Identifier	Entity Identifier Encoding	Hierarchy and Inheritance	Media Type of Defining Resource	Mapping to ALTO Address Type
subdivisioncode	See RFC 9388,	None	None	false

Security Considerations This specification is in accordance with "" and "". As such, it is subject to the security and confidentiality considerations as defined in and in , respectively.

References Normative References ISO ISO In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The Content Delivery Network Interconnection (CDNI) Metadata interface enables interconnected Content Delivery Networks (CDNs) to exchange content distribution metadata in order to enable content acquisition and delivery. The CDNI Metadata associated with a piece of content provides a downstream CDN with sufficient information for the downstream CDN to service content requests on behalf of an upstream CDN. This document describes both a base set of CDNI Metadata and the protocol for exchanging that metadata. <p>This document captures the semantics of the "Footprint and Capabilities Advertisement" part of the Content Delivery Network Interconnection (CDNI) Request Routing interface, i.e., the desired meaning of "Footprint" and "Capabilities" in the CDNI context and what the "Footprint & Capabilities Advertisement interface (FCI)" offers within CDNI. The document also provides guidelines for the CDNI FCI protocol. It further defines a Base Advertisement Object, the necessary registries for capabilities and footprints, and guidelines on how these registries can be extended in the future.</p> RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document specifies an extension to the base Application-Layer Traffic Optimization (ALTO) Protocol that generalizes the concept of "endpoint properties", which have been tied to IP addresses so far, to entities defined by a wide set of objects. Further, these properties are presented as maps, similar to the network and cost maps in the base ALTO Protocol. While supporting the endpoints and related Endpoint Property Service defined in RFC 7285, the ALTO Protocol is extended in two major directions. First, from endpoints restricted to IP addresses to entities covering a wider and extensible set of objects; second, from properties for specific endpoints to entire entity property maps. These extensions introduce additional features that allow entities and property values to be specific to a given information resource. This is made possible by a generic and flexible design of entity and property types. <p>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. RFC 8008 defines the FCI semantics and provides guidelines on the FCI protocol, but the exact protocol is not specified. This document defines a new Application-Layer Traffic Optimization (ALTO) service, called "CDNI Advertisement Service", that provides an implementation of the FCI, following the guidelines defined in RFC 8008.</p> Informative References Qwilt Disney Streaming Services Qwilt SiriusXM Limelight Networks Ericsson Viasat Verizon Qwilt SVTA Content Delivery Networks (CDNs) provide numerous benefits for cacheable content: reduced delivery cost, improved quality of experience for End Users, and increased robustness of delivery. For these reasons, they are frequently used for large-scale content delivery. As a result, existing CDN Providers are scaling up their infrastructure, and many Network Service Providers (NSPs) are deploying their own CDNs. It is generally desirable that a given content item can be delivered to an End User regardless of that End User's location or attachment network. This is the motivation for interconnecting standalone CDNs so they can interoperate as an open content delivery infrastructure for the end-to-end delivery of content from Content Service Providers (CSPs) to End Users. However, no standards or open specifications currently exist to facilitate such CDN Interconnection. The goal of this document is to outline the problem area of CDN Interconnection for the IETF CDNI (CDN Interconnection) working group. This document is not an Internet Standards Track specification; it is published for informational purposes. This document presents a framework for Content Distribution Network Interconnection (CDNI). The purpose of the framework is to provide an overall picture of the problem space of CDNI and to describe the relationships among the various components necessary to interconnect CDNs. CDNI requires the specification of interfaces and mechanisms to address issues such as request routing, distribution metadata exchange, and logging information exchange across CDNs. The intent of this document is to outline what each interface needs to accomplish and to describe how these interfaces and mechanisms fit together, while leaving their detailed specification to other documents. This document, in combination with RFC 6707, obsoletes RFC 3466. SVTA

Acknowledgements The authors would like to express their gratitude to and for their guidance and reviews throughout the development of this document. We would also like to thank all the Area Directors for their review and feedback in improving this document.

Authors' Addresses Qwilt

6, Ha'harash Hod HaSharon 4524079 Israel nir@apache.org

Verizon

13100 Columbia Pike Silver Spring MD 20904 United States of America sanjay.mishra@verizon.com