RFC 9388

Content Delivery Network Interconnection (CDNI) Footprint Types: Country Subdivision Code and Footprint Union

πŸ“… published July 2023, from ietf

RFC 9388: Content Delivery Network Interconnection (CDNI) Footprint Types: Country Subdivision Code and Footprint Union πŸŽ€

Okay bestie, this one is from the IETF (Internet Engineering Task Force) and it's a Standards Track document, so it's an official Internet standard, not just a suggestion πŸ’…. It was written by N. Sopher (Qwilt) and S. Mishra (Verizon) in July 2023, and it's listed as ISSN 2070-1721. It updates RFC 8008 and doesn't obsolete anything. The whole thing is about adding two new footprint types for CDNI, the Content Delivery Network Interconnection system 🌈.

Abstract ✨

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.

Okay so the abstract is basically: two new footprint types, one for country subdivisions (like states) and one for unions. The union bit is a glow-up on the old narrowing rules πŸ¦‹.

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 https://www.rfc-editor.org/info/rfc9388.

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 (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
  1.1.  Terminology
  1.2.  Requirements Language
2.  CDNI Metadata Additional Footprint Types
  2.1.  CDNI Metadata "subdivisioncode" Footprint Type
    2.1.1.  CDNI Metadata "subdivisioncode" Data Type
      2.1.1.1.  CDNI Metadata "subdivisioncode" Data Type
              Description
    2.1.2.  CDNI Metadata "subdivisioncode" Footprint Type
            Description
  2.2.  CDNI Metadata "footprintunion" Footprint Type
    2.2.1.  CDNI Metadata "footprintunion" Data Type
    2.2.2.  CDNI Metadata "footprintunion" Footprint Type
            Description
3.  ALTO Property Map Service Entity
  3.1.  SUBDIVISIONCODE Domain
    3.1.1.  Entity Domain Type
    3.1.2.  Domain-Specific Entity Identifiers
    3.1.3.  Hierarchy and Inheritance
4.  IANA Considerations
  4.1.  CDNI Metadata Footprint Types
  4.2.  ALTO Entity Domain Types
5.  Security Considerations
6.  References
  6.1.  Normative References
  6.2.  Informative References
Acknowledgements
Authors' Addresses

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 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" [OC-RR] defines the Request Routing process and the interfaces that are required for its provisioning. This document defines and registers CDNI Footprint and Capabilities objects [RFC8008] 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 (Section 7.2 of [RFC8006]) 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)

1.1. Terminology πŸ“–

The following terms are used throughout this document:

CDN: Content Delivery Network

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

uCDN: upstream CDN (see [RFC7336])

dCDN: downstream CDN (see [RFC7336])

1.2. Requirements Language πŸ”‘

This is the part where the official key words live, so listen up πŸ‘‘. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

2. CDNI Metadata Additional Footprint Types 🧚

Section 5 of [RFC8008] 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 Section 4.2.2.2 of [RFC8006]. This document defines additional footprint types, beyond those mentioned in [RFC8006].

2.1. CDNI Metadata "subdivisioncode" Footprint Type πŸ‡ΊπŸ‡Έ

Section 4.3.8 of [RFC8006] specifies the "countrycode" footprint type for listing [ISO3166-1] 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 [ISO3166-2] country subdivision codes.

2.1.1. CDNI Metadata "subdivisioncode" Data Type πŸ’«

The "subdivisioncode" data type specified in Section 2.1.1.1 describes a country-specific subdivision using a code as defined in [ISO3166-2]. The data type is added to the list of data types described in Section 4.3 of [RFC8006] that are used as properties of CDNI Metadata objects.

2.1.1.1. CDNI Metadata "subdivisioncode" Data Type Description πŸ’•

An [ISO3166-2] code in lowercase. Each code consists of two parts separated by a hyphen. As per [ISO3166-2], the first part is the [ISO3166-1] 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"

2.1.2. CDNI Metadata "subdivisioncode" Footprint Type Description πŸ“

The "subdivisioncode" simple data type specified in Section 2.1.1 is added to the data types listed as footprint types in Section 4.2.2.2 of [RFC8006].

Figure 1 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 [ISO3166-2] codes "US-NJ" and "US-NY", respectively).

{
  "capabilities": [
    {
      "capability-type": <CDNI capability object type>,
      "capability-value": <CDNI capability object>,
      "footprints": [
          {
              "footprint-type": "subdivisioncode",
              "footprint-value": ["us-nj", "us-ny"]
          }
      ]
    }
  ]
}

     Figure 1: Illustration of Country Subdivision Code Footprint
                            Advertisement

2.2. CDNI Metadata "footprintunion" Footprint Type 🌈

As described in Section 5 of [RFC8008], the FCI Capability Advertisement object includes an array of CDNI footprint objects. Appendix B of [RFC8008] 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 4.3.5 and 4.3.6 of [RFC8006] 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 [RFC8008], that prevents the usage of these objects together to create a footprint constraint that matches IPv4 clients with IPv6 clients.

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

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

          Figure 2: Example of Narrowing Semantic Illustrating
                   Advertisement of a Null Footprint

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. πŸ™ˆ

That's the first half, babe πŸ¦‹. Part 2 covers the ALTO entity stuff, IANA, security, and the references, so stay tuned ✨.

2.2.1. CDNI Metadata "footprintunion" Data Type

okay so the "footprintunion" data type is built on the footprint object we already have in Section 4.2.2.2 of [RFC8006] πŸ’… The footprint value for a "footprintunion" object is an array of footprint objects, and those footprint objects MUST be of any footprint type other than "footprintunion" 🫢

2.2.2. CDNI Metadata "footprintunion" Footprint Type Description

the "footprintunion" data type from Section 2.2.1 gets added to the list of data types that count as footprint types in Section 4.2.2.2 of [RFC8006] ✨ it's givingη΅„γΏεˆγ‚γ› energy, bestie πŸ¦‹

Figure 3 is an example using a footprint union that combines both IPv4 and IPv6 client subnets. so cute, right? πŸŽ€

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

Figure 3: Example of an Advertisement of Footprint Union for Multiple Classless Inter-Domain Routing (CIDR) Footprint Types

the footprint union also lets you mix and match footprint objects based on the country code and the country subdivision code πŸŒπŸ’– In Figure 4, we make a constraint covering autonomous system 64496 within the USA (ISO alpha-2 code "US" as described in [ISO3166-1]) and the Ontario province of Canada (ISO code "CA-ON" as described in [ISO3166-2]). main character energy, literally πŸ‘‘

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

Figure 4: Example of an Advertisement of Footprint Union for Multiple Geographical Footprint Types

3. ALTO Property Map Service Entity 🧚

okay this section is where the ALTO property map gets involved πŸ’œ Section 6 of [RFC9241] explains how to represent footprint objects as entities in the ALTO property map. The idea is that the footprint type becomes an entity domain type of the ALTO entity, and the footprint value becomes its domain-specific identifier. [RFC9241] also talks about representing footprint objects of types "asn" and "countrycode". Here, we extend that definition to the "subdivisioncode" footprint type ✨

3.1. SUBDIVISIONCODE Domain

the SUBDIVISIONCODE domain holds property values that define codes for the names of the principal subdivisions 🌸

3.1.1. Entity Domain Type

the entity domain type of the SUBDIVISIONCODE domain is "subdivisioncode" (in lowercase) πŸŽ€

3.1.2. Domain-Specific Entity Identifiers

the entity identifier of an entity in a SUBDIVISIONCODE is encoded as an alpha-2 [ISO3166-1] country code, followed by a separator and up to three alphanumeric characters πŸ”₯

3.1.3. Hierarchy and Inheritance

there is no hierarchy or inheritance for properties associated with country subdivision codes. no drama, no family tree πŸ™ˆ

4. IANA Considerations πŸ“‹

4.1. CDNI Metadata Footprint Types

Section 7.2 of [RFC8006] 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 2.1 and 2.2:

  +=================+=================================+===========+
  | Footprint Type  | Description                     | Reference |
  +=================+=================================+===========+
  | subdivisioncode | ISO 3166-2 country subdivision  | RFC 9388  |
  |                 | 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    |           |
  +-----------------+---------------------------------+-----------+
  | footprintunion  | A combination of other          | RFC 9388  |
  |                 | footprint objects               |           |
  +-----------------+---------------------------------+-----------+

       Table 1: Additions to the CDNI Metadata Footprint Types
                             Subregistry

4.2. ALTO Entity Domain Types

Section 12.3 of [RFC9240] creates the "ALTO Entity Domain Types" subregistry within the "Application-Layer Traffic Optimization (ALTO) Protocol" registry πŸ¦‹

this document registers one more ALTO Entity Domain Type in that subregistry:

 +=================+============+=============+==========+=========+
 | Identifier      | Entity     | Hierarchy   | Media    | Mapping |
 |                 | Identifier | and         | Type of  | to ALTO |
 |                 | Encoding   | Inheritance | Defining | Address |
 |                 |            |             | Resource | Type    |
 +=================+============+=============+==========+=========+
 | subdivisioncode | See RFC    | None        | None     | false   |
 |                 | 9388,      |             |          |         |
 |                 | Section    |             |          |         |
 |                 | 3.1.2      |             |          |         |
 +-----------------+------------+-------------+----------+---------+

    Table 2: Addition to the ALTO Entity Domain Types Subregistry

5. Security Considerations πŸ”

okay this part is SERIOUS, bestie 😭 This specification is in accordance with "Content Delivery Network Interconnection (CDNI) Metadata" and "Content Delivery Network Interconnection (CDNI) Request Routing: Footprint and Capabilities Semantics". So it is subject to the security and confidentiality considerations defined in Section 8 of [RFC8006] and in Section 7 of [RFC8008], respectively. go read those too, no skipping πŸ™πŸ’€

6. References πŸ“š

6.1. Normative References

[ISO3166-1] ISO, "Codes for the representation of names of countries and their subdivisions -- Part 1: Country code", ISO 3166-1:2020, Edition 4, August 2020, <https://www.iso.org/standard/72482.html>.

[ISO3166-2] ISO, "Codes for the representation of names of countries and their subdivisions -- Part 2: Country subdivision code", ISO 3166-2:2020, Edition 4, August 2020, <https://www.iso.org/standard/72483.html>.

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

[RFC9240] Roome, W., Randriamasy, S., Yang, Y., Zhang, J., and K. Gao, "An Extension for Application-Layer Traffic Optimization (ALTO): Entity Property Maps", RFC 9240, DOI 10.17487/RFC9240, July 2022, <https://www.rfc-editor.org/info/rfc9240>.

[RFC9241] Seedorf, J., Yang, Y., Ma, K., Peterson, J., and J. Zhang, "Content Delivery Network Interconnection (CDNI) Footprint and Capabilities Advertisement Using Application-Layer Traffic Optimization (ALTO)", RFC 9241, DOI 10.17487/RFC9241, July 2022, <https://www.rfc-editor.org/info/rfc9241>.

6.2. Informative References

[OC-RR] Finkelman, O., Ed., Zurat, B., Sahar, D., Klein, E., Hofmann, J., Ma, K.J., Stock, M., Mishra, S., and Y. Gressel, "Open Caching - Request Routing Functional Specification", Version 2.0, 15 January 2021, <https://www.svta.org/product/open-cache-request-routing-functional-specification/>.

[OCWG] SVTA, "Open Caching", <https://opencaching.svta.org/>.

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

[SVTA] SVTA, "Streaming Video Technology Alliance", <https://www.svta.org/>.

Acknowledgements 🫢

the authors want to say a huge thank you to Ori Finkelman and Kevin J. Ma for their guidance and reviews throughout the development of this document πŸ’– we also want to thank all the Area Directors for their review and feedback in making this document better ✨

Authors' Addresses πŸ’Œ

Nir B. Sopher Qwilt 6, Ha'harash Hod HaSharon 4524079 Israel Email: nir@apache.org

Sanjay Mishra Verizon 13100 Columbia Pike Silver Spring, MD 20904 United States of America Email: sanjay.mishra@verizon.com

πŸ“¦ where this page comes from