GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc9388



Internet Engineering Task Force (IETF) N. Sopher Request for Comments: 9388 Qwilt Updates: 8008 S. Mishra Category: Standards Track Verizon ISSN: 2070-1721 July 2023

Content Delivery Network Interconnection (CDNI) Footprint Types: Country

                Subdivision Code and Footprint Union

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.

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 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
 (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

 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.

2.2.1. CDNI Metadata "footprintunion" Data Type

 The "footprintunion" data type is based on the footprint object
 already defined in Section 4.2.2.2 of [RFC8006].  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".

2.2.2. CDNI Metadata "footprintunion" Footprint Type Description

 The "footprintunion" data type specified in Section 2.2.1 is added to
 the data types listed as footprint types in Section 4.2.2.2 of
 [RFC8006].
 Figure 3 is an example using a footprint union combining both IPv4
 and IPv6 client subnets.
 {
   "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 enables composing of footprint objects based
 on the country code and country subdivision code.  In Figure 4, we
 create 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]).
 {
   "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

 Section 6 of [RFC9241] 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.  [RFC9241]
 further refers to the representation of footprint objects of types
 "asn" and "countrycode".  Here, we extend this definition to the
 "subdivisioncode" footprint type.

3.1. SUBDIVISIONCODE Domain

 The SUBDIVISIONCODE domain associates 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.

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 an additional ALTO Entity Domain Type within
 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

 This specification is in accordance with "Content Delivery Network
 Interconnection (CDNI) Metadata" and "Content Delivery Network
 Interconnection (CDNI) Request Routing: Footprint and Capabilities
 Semantics".  As such, it is subject to the security and
 confidentiality considerations as defined in Section 8 of [RFC8006]
 and in Section 7 of [RFC8008], respectively.

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 would like to express their gratitude to Ori Finkelman
 and Kevin J. Ma 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

 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
/home/gen.uk/domains/wiki.gen.uk/public_html/data/pages/rfc/rfc9388.txt · Last modified: 2023/07/21 00:00 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki