CDNI J. Seedorf Internet-Draft NEC Intended status: Standards Track J. Peterson Expires: November 21, 2016 Neustar S. Previdi Cisco R. van Brandenburg TNO K. Ma Ericsson May 20, 2016 CDNI Request Routing: Footprint and Capabilities Semantics draft-ietf-cdni-footprint-capabilities-semantics-20 Abstract This document captures the semantics of the "Footprint and Capabilities Advertisement" part of the CDNI Request Routing interface, i.e., the desired meaning of "Footprint" and "Capabilities" in the CDNI context, and what the "Footprint and 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. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 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 http://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." Seedorf, et al. Expires November 21, 2016 [Page 1] Internet-Draft CDNI RR Footprint/Capabilities Semantics May 2016 This Internet-Draft will expire on November 21, 2016. Copyright Notice Copyright (c) 2016 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 (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Design Decisions for Footprint and Capabilities . . . . . . . 5 2.1. Advertising Limited Coverage . . . . . . . . . . . . . . 5 2.2. Capabilities and Dynamic Data . . . . . . . . . . . . . . 6 2.3. Advertisement versus Queries . . . . . . . . . . . . . . 7 2.4. Avoiding or Handling 'cheating' dCDNs . . . . . . . . . . 7 3. Focusing on Capabilities with Footprint Restrictions . . . . 8 4. Footprint and Capabilities Extension . . . . . . . . . . . . 8 5. Capability Advertisement Object . . . . . . . . . . . . . . . 10 5.1. Base Advertisement Object . . . . . . . . . . . . . . . . 10 5.2. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 11 5.3. Delivery Protocol Capability Object . . . . . . . . . . . 11 5.3.1. Delivery Protocol Capability Object Serialization . . 12 5.4. Acquisition Protocol Capability Object . . . . . . . . . 12 5.4.1. Acquisition Protocol Capability Object Serialization 13 5.5. Redirection Mode Capability Object . . . . . . . . . . . 13 5.5.1. Redirection Mode Capability Object Serialization . . 13 5.6. CDNI Logging Capability Object . . . . . . . . . . . . . 14 5.6.1. CDNI Logging Capability Object Serialization . . . . 15 5.7. CDNI Metadata Capability Object . . . . . . . . . . . . . 15 5.7.1. CDNI Metadata Capability Object Serialization . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6.1. CDNI Payload Types . . . . . . . . . . . . . . . . . . . 17 6.1.1. CDNI FCI DeliveryProtocol Payload Type . . . . . . . 17 6.1.2. CDNI FCI AcquisitionProtocol Payload Type . . . . . . 18 6.1.3. CDNI FCI RedirectionMode Payload Type . . . . . . . . 18 6.1.4. CDNI FCI Logging Payload Type . . . . . . . . . . . . 18 6.1.5. CDNI FCI Metadata Payload Type . . . . . . . . . . . 18 Seedorf, et al. Expires November 21, 2016 [Page 2] Internet-Draft CDNI RR Footprint/Capabilities Semantics May 2016 6.2. Redirection Mode Registry . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.1. Normative References . . . . . . . . . . . . . . . . . . 20 8.2. Informative References . . . . . . . . . . . . . . . . . 20 Appendix A. Main Use Case to Consider . . . . . . . . . . . . . 21 Appendix B. Semantics for Footprint Advertisement . . . . . . . 22 Appendix C. Semantics for Capabilities Advertisement . . . . . . 24 Appendix D. Acknowledgment . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 1. Introduction and Scope The CDNI working group is working on a set of protocols to enable the interconnection of multiple CDNs. This CDN interconnection (CDNI) can serve multiple purposes, as discussed in [RFC6770], for instance, to extend the reach of a given CDN to areas in the network which are not covered by this particular CDN. The goal of this document is to achieve a clear understanding about the semantics associated with the CDNI Request Routing Footprint & Capabilities Advertisement Interface (from now on referred to as FCI), in particular the type of information a downstream CDN (dCDN) 'advertises' regarding its footprint and capabilities. To narrow down undecided aspects of these semantics, this document tries to establish a common understanding of what the FCI needs to offer and accomplish in the context of CDNI. It is explicitly outside the scope of this document to decide on specific protocols to use for the FCI. However, guidelines for such FCI protocols are provided. General assumptions in this document: o The CDNs participating in the interconnected CDN have already performed a boot strap process, i.e., they have connected to each other, either directly or indirectly, and can exchange information amongst each other. o The upstream CDN (uCDN) receives footprint and/or capability advertisements from a set of dCDNs. Footprint advertisement and capability advertisement need not use the same underlying protocol. o The uCDN receives the initial request-routing request from the endpoint requesting the resource. Seedorf, et al. Expires November 21, 2016 [Page 3] Internet-Draft CDNI RR Footprint/Capabilities Semantics May 2016 The CDNI Problem Statement [RFC6707] describes the Request Routing Interface as: "[enabling] a Request Routing function in a uCDN to query a Request Routing function in a dCDN to determine if the dCDN is able (and willing) to accept the delegated Content Request". In addition, RFC6707 says "the CDNI Request Routing interface is also expected to enable a dCDN to provide to the uCDN (static or dynamic) information (e.g., resources, footprint, load) to facilitate selection of the dCDN by the uCDN request routing system when processing subsequent content requests from User Agents". It thus considers "resources" and "load" as capabilities to be advertised by the dCDN. The range of different footprint definitions and possible capabilities is very broad. Attempting to define a comprehensive advertisement solution quickly becomes intractable. The CDNI requirements draft [RFC7337] lists the specific requirements for the CDNI Footprint & Capabilities Advertisement Interface in order to disambiguate footprints and capabilities with respect to CDNI. This document defines a common understanding of what the terms 'footprint' and 'capabilities' mean in the context of CDNI, and details the semantics of the footprint advertisement mechanism and the capability advertisement mechanism. 1.1. Terminology This document reuses the terminology defined in [RFC6707]. Additionally, the following terms are used throughout this document and are defined as follows: o Footprint: a description of a CDN's coverage area, i.e., the area from which client requests may originate for, and to which the CDN is willing to deliver, content. Note: There are many ways to describe a footprint, for example, by address range (e.g., IPv4/ IPv6 CIDR), by network ID (e.g., ASN), by nation boundaries (e.g., country code), by GPS coordinates, etc. This document does not define or endorse the quality or suitability of any particular footprint description method; this document only defines a method for transporting known footprint descriptions in Footprint and Capabilities Advertisement messages. o Capability: a feature of a dCDN, upon which a uCDN relies on the dCDN supporting, when making delegation decisions. Support for a given feature can change over time and can be restricted to a limited portion of a dCDN's footprint. Note: There are many possible dCDN features that could be of interest to a uCDN. This document does not presume to define them all; this document describes a scheme for defining new capabilities and how to Seedorf, et al. Expires November 21, 2016 [Page 4] Internet-Draft CDNI RR Footprint/Capabilities Semantics May 2016 transport them in Footprint and Capabilities Advertisement messages. 2. Design Decisions for Footprint and Capabilities A large part of the difficulty in discussing the FCI lies in understanding what exactly is meant when trying to define footprint in terms of "coverage" or "reachability." While the operators of CDNs pick strategic locations to situate surrogates, a surrogate with a public IPv4 address is reachable by any endpoint on the Internet unless some policy enforcement precludes the use of the surrogate. Some CDNs aspire to cover the entire world; we refer to these as global CDNs. The footprint advertised by such a CDN in the CDNI environment would, from a coverage or reachability perspective, presumably cover all prefixes. Potentially more interesting for CDNI use cases, however, are CDNs that claim a more limited coverage, but seek to interconnect with other CDNs in order to create a single CDN fabric which shares resources. Furthermore, not all capabilities need to be footprint restricted. Depending upon the use case, the optimal semantics of "footprints with capability attributes" vs. "capabilities with footprint restrictions" are not clear. The key to understanding the semantics of footprint and capability advertisement lies in understanding why a dCDN would advertise a limited coverage area, and how a uCDN would use such advertisements to decide among one of several dCDNs. The following section will discuss some of the trade-offs and design decisions that need to be decided upon for the CDNI FCI. 2.1. Advertising Limited Coverage The basic use case that would motivate a dCDN to advertise a limited coverage is that the CDN was built to cover only a particular portion of the Internet. For example, an ISP could purpose-build a CDN to serve only their own customers by situating surrogates in close topological proximity to high concentrations of their subscribers. The ISP knows the prefixes it has allocated to end users and thus can easily construct a list of prefixes that its surrogates were positioned to serve. When such a purpose-built CDN interconnects with other CDNs and advertises its footprint to a uCDN, however, the original intended coverage of the CDN might not represent its actual value to the interconnection of CDNs. Consider an ISP-A and ISP-B that both field their own CDNs, which they interconnect via CDNI. A given user E, Seedorf, et al. Expires November 21, 2016 [Page 5] Internet-Draft CDNI RR Footprint/Capabilities Semantics May 2016 who is a customer of ISP-B, might happen to be topologically closer to a surrogate fielded by ISP-A, if E happens to live in a region where ISP-B has few customers and ISP-A has many. In this case, is it ISP-A's CDN that "covers" E? If ISP-B's CDN has a failure condition, is it up to the uCDN to understand that ISP-A's surrogates are potentially available as back-ups - and if so, how does ISP-A advertise itself as a "standby" for E? What about the case where CDNs advertising to the same uCDN express overlapping coverage (for example, mixing global and limited CDNs)? The answers to these questions greatly depend on how much information the uCDN wants to use to make a selection of a dCDN. If a uCDN has three dCDNs to choose from that "cover" the IP address of user E, obviously the uCDN might be interested to know how optimal the coverage is from each of the dCDNs - coverage need not be binary, either provided or not provided. dCDNs could advertise a coverage "score," for example, and provided that they all reported scores fairly on the same scale, uCDNs could use that to make their topological optimality decision. Alternately, dCDNs could advertise the IP addresses of their surrogates rather than prefix "coverage," and let the uCDN decide for itself (based on its own topological intelligence) which dCDN has better resources to serve a given user. In summary, the semantics of advertising footprint depend on whether such qualitative metrics for expressing footprint (such as the coverage 'score' mentioned above) are included as part of the CDNI FCI, or if the focus is just on 'binary' footprint. 2.2. Capabilities and Dynamic Data In cases where the apparent footprints of dCDNs overlap, uCDNs might also want to rely on other factors to evaluate the respective merits of dCDNs. These include facts related to the surrogates themselves, to the network where the surrogate is deployed, to the nature of the resource sought, and to the administrative policies of the respective networks. In the absence of network-layer impediments to reaching surrogates, the choice to limit coverage is necessarily an administrative policy. Much policy needs to be agreed upon before CDNs can interconnect, including questions of membership, compensation, volumes, and so on. A uCDN certainly will factor these sorts of considerations into its decision to select a dCDN, but there is probably little need for dCDNs to actually advertise them through an interface - they will be settled out-of-band as a precondition for interconnection. Other facts about the dCDN would be expressed through the interface to the uCDN. Some capabilities of a dCDN are static, and some are Seedorf, et al. Expires November 21, 2016 [Page 6] Internet-Draft CDNI RR Footprint/Capabilities Semantics May 2016 highly dynamic. Expressing the total storage built into its surrogates, for example, changes relatively rarely, whereas the amount of storage in use at any given moment is highly volatile. Network bandwidth similarly could be expressed as either total bandwidth available to a surrogate, or based on the current state of the network. A surrogate can at one moment lack a particular resource in storage, but have it the next. The semantics of the capabilities interface will depend on how much of the dCDN state needs to be pushed to the uCDN and qualitatively how often that information needs to be updated. 2.3. Advertisement versus Queries In a CDNI environment, each dCDN shares some of its state with the uCDN. The uCDN uses this information to build a unified picture of all of the dCDNs available to it. In architectures that share detailed capability information, the uCDN could perform the entire request-routing operation down to selecting a particular surrogate in the dCDN. However, when the uCDN needs to deal with many potential dCDNs, this approach does not scale, especially for dCDNs with thousands or tens of thousands of surrogates; the volume of updates to footprint and capability becomes onerous. Were the volume of FCI updates from dCDNs to exceed the volume of requests to the uCDN, it might make more sense for the uCDN to query dCDNs upon receiving requests (as is the case in the recursive redirection mode described in [RFC7336]), instead of receiving advertisements and tracking the state of dCDNs. The advantage of querying dCDNs would be that much of the dynamic data that dCDNs cannot share with the uCDN would now be factored into the uCDN's decision. dCDNs need not replicate any state to the uCDN - uCDNs could effectively operate in a stateless mode. The semantics of both footprint and capability advertisement depend on the service model here: are there cases where a synchronous query/ response model would work better for the uCDN decision than a state replication model? 2.4. Avoiding or Handling 'cheating' dCDNs In a situation where more than one dCDN is willing to serve a given end user request, it might be attractive for a dCDN to 'cheat' in the sense that the dCDN provides inaccurate information to the uCDN in order to convince the uCDN to select it over 'competing' dCDNs. It could therefore be desirable to take away the incentive for dCDNs to cheat (in information advertised) as much as possible. One option is to make the information the dCDN advertises somehow verifiable for Seedorf, et al. Expires November 21, 2016 [Page 7] Internet-Draft CDNI RR Footprint/Capabilities Semantics May 2016 the uCDN. On the other hand, a cheating dCDN might be avoided or handled by the fact that there will be strong contractual agreements between a uCDN and a dCDN, so that a dCDN would risk severe penalties or legal consequences when caught cheating. Overall, the information a dCDN advertises (in the long run) needs to be somehow qualitatively verifiable by the uCDN, though possibly through non-real-time out-of-band audits. It is probably an overly strict requirement to mandate that such verification be possible "immediately", i.e., during the request routing process itself. If the uCDN can detect a cheating dCDN at a later stage, it might suffice for the uCDN to "de-incentivize" cheating because it would negatively affect the long-term business relationship with a particular dCDN. 3. Focusing on Capabilities with Footprint Restrictions Given the design considerations listed in the previous section, it seems reasonable to assume that in most cases it is the uCDN that makes the decision on selecting a certain dCDN for request routing based on information the uCDN has received from this particular dCDN. It can be assumed that 'cheating' CDNs will be dealt with via means outside the scope of CDNI and that the information advertised between CDNs is accurate. In addition, excluding the use of qualitative information (e.g., surrogate proximity, delivery latency, surrogate load) to predict the quality of delivery would further simplify the use case allowing it to better focus on the basic functionality of the FCI. Further understanding that in most cases contractual agreements will define the basic coverage used in delegation decisions, the primary focus of FCI is on providing updates to the basic capabilities and coverage by the dCDNs. As such, FCI has choosen the semantics of "capabilities with footprint restrictions". 4. Footprint and Capabilities Extension Other optional "coverage/reachability" types of footprint or "resource" types of footprint may be defined by future specifications. To facilitate this, a clear process for specifying optional footprint types in an IANA registry is specified in the CDNI Metadata Footprint Types registry (defined in the CDNI Metadata Interface document [I-D.ietf-cdni-metadata]). This document also registers CDNI Payload Types [RFC7736] for the initial capability types (see Section 6): o Delivery Protocol (for delivering content to the end user) Seedorf, et al. Expires November 21, 2016 [Page 8] Internet-Draft CDNI RR Footprint/Capabilities Semantics May 2016 o Acquisition Protocol (for acquiring content from the uCDN or origin server) o Redirection Mode (e.g., DNS Redirection vs. HTTP Redirection as discussed in [RFC7336]) o CDNI Logging (i.e., supported logging fields) o CDNI Metadata (i.e., supported Generic Metadata types) Each payload type is prefaced with "FCI.". Updates to capability objects MUST indicate the version of the capability object in a newly registered payload type, e.g., by appending ".v2". Each capability type MAY have a list of valid values. Future specifications which define a given capability MUST define any necessary registries (and the rules for adding new entries to the registry) for the values advertised for a given capability type. The "CDNI Logging record-types" registry [I-D.ietf-cdni-logging] defines all known record types, including mandatory-to-implement record-types Advertising support for mandatory-to-implement record- types would be redundant. CDNs SHOULD NOT advertise support for mandatory-to-implement record-types. The "CDNI Logging Fields Names" registry [I-D.ietf-cdni-logging] defines all known logging fields. Logging fields may be reused by different record-types and be mandatory-to-implement in some record- types, but optional in other record-types. CDNs MUST advertise support for optional logging fields within the context of a specific record-type. CDNs SHOULD NOT advertise support for mandatory-to- implement logging fields, for a given record-type. The following logging fields are defined as optional for the "cdni_http_request_v1" record-type in the CDNI Logging Interface document [I-D.ietf-cdni-logging]: o s-ccid o s-sid The CDNI Metadata Interface document [I-D.ietf-cdni-metadata] requires that CDNs be able to parse all the defined metadata objects, but does not require dCDNs to support enforcement of non-structural GenericMetadata objects. Advertising support for mandatory-to- enforce GenericMetadata types MUST be supported. Advertising support for non-mandatory-to-enforce GenericMetadata types SHOULD be supported. Advertisement of non-mandatory-to-enforce GenericMetadata MAY be necessary, e.g., to signal temporary outages and subsequent Seedorf, et al. Expires November 21, 2016 [Page 9] Internet-Draft CDNI RR Footprint/Capabilities Semantics May 2016 recovery. It is expected that structural metadata will be supported at all times. The notion of optional types of footprint and capabilities implies that certain implementations might not support all kinds of footprint and capabilities. Therefore, any FCI solution protocol MUST define how the support for optional types of footprint/capabilities will be negotiated between a uCDN and a dCDN that use the particular FCI protocol. In particular, any FCI solution protocol MUST specify how to handle failure cases or non-supported types of footprint/ capabilities. In general, a uCDN MAY ignore capabilities or types of footprints it does not understand; in this case it only selects a suitable dCDN based on the types of capabilities and footprint it understands. Similarly, if a dCDN does not use an optional capability or footprint which is, however, supported by a uCDN, this causes no problem for the FCI functionality because the uCDN decides on the remaining capabilities/footprint information that is being conveyed by the dCDN. 5. Capability Advertisement Object To support extensibility, the FCI defines a generic base object (similar to the CDNI Metadata interface GenericMetadata object) [I-D.ietf-cdni-metadata] to facilitate a uniform set of mandatory parsing requirements for all future FCI objects. Future object definitions (e.g. regarding CDNI Metadata or Logging) will build off the base object defined here, but will be specified in separate documents. Note: In the following sections, the term "mandatory-to-specify" is used to convey which properties MUST be included when serializing a given capability object. When mandatory-to-specify is defined as "Yes" for an individual property, it means that if the object containing that property is included in an FCI message, then the mandatory-to-specify property MUST also be included. 5.1. Base Advertisement Object The FCIBase object is an abstraction for managing individual CDNI capabilities in an opaque manner. Property: capability-type Description: CDNI Capability object type. Seedorf, et al. Expires November 21, 2016 [Page 10] Internet-Draft CDNI RR Footprint/Capabilities Semantics May 2016 Type: FCI specific CDNI Payload type (from the CDNI Payload Types registry [RFC7736]) Mandatory-to-Specify: Yes. Property: capability-value Description: CDNI Capability object. Type: Format/Type is defined by the value of capability-type property above. Mandatory-to-Specify: Yes. Property: footprints Description: CDNI Capability Footprint. Type: List of CDNI Footprint objects (as defined in [I-D.ietf-cdni-metadata]). Mandatory-to-Specify: No. 5.2. Encoding CDNI FCI objects MUST be encoded using JSON [RFC7159] and MUST also follow the recommendations of I-JSON [RFC7493]. FCI objects are composed of a dictionary of (key,value) pairs where the keys are the property names and the values are the associated property values. The keys of the dictionary are the names of the properties associated with the object and are therefore dependent on the specific object being encoded (i.e., dependent on the CDNI Payload Type of the capability or the CDNI Metadata Footprint Type of the footprint). Likewise, the values associated with each property (dictionary key) are dependent on the specific object being encoded (i.e., dependent on the CDNI Payload Type of the capability or the CDNI Metadata Footprint Type of the footprint). Dictionary keys (properties) in JSON are case sensitive. By convention, any dictionary key (property) defined by this document MUST be lowercase. 5.3. Delivery Protocol Capability Object The Delivery Protocol capability object is used to indicate support for one or more of the protocols listed in the CDNI Metadata Protocol Seedorf, et al. Expires November 21, 2016 [Page 11] Internet-Draft CDNI RR Footprint/Capabilities Semantics May 2016 Types registry (defined in the CDNI Metadata Interface document [I-D.ietf-cdni-metadata]). Property: delivery-protocols Description: List of supported CDNI Delivery Protocols. Type: List of Protocol Types (from the CDNI Metadata Protocol Types registry [I-D.ietf-cdni-metadata]) Mandatory-to-Specify: Yes. 5.3.1. Delivery Protocol Capability Object Serialization The following shows an example of Delivery Protocol Capability Object Serialization, for a CDN that supports only HTTP/1.1 without TLS for content delivery. { "capabilities": [ { "capability-type": "FCI.DeliveryProtocol", "capability-value": { "delivery-protocols": [ "http/1.1", ] }, "footprints": [ ] } ] } 5.4. Acquisition Protocol Capability Object The Acquisition Protocol capability object is used to indicate support for one or more of the protocols listed in the CDNI Metadata Protocol Types registry (defined in the CDNI Metadata Interface document [I-D.ietf-cdni-metadata]). Property: acquisition-protocols Description: List of supported CDNI Acquisition Protocols. Type: List of Protocol Types (from the CDNI Metadata Protocol Types registry [I-D.ietf-cdni-metadata]) Seedorf, et al. Expires November 21, 2016 [Page 12] Internet-Draft CDNI RR Footprint/Capabilities Semantics May 2016 Mandatory-to-Specify: Yes. 5.4.1. Acquisition Protocol Capability Object Serialization The following shows an example of Acquisition Protocol Capability Object Serialization, for a CDN that supports HTTP/1.1 with or without TLS for content acquisition. { "capabilities": [ { "capability-type": "FCI.AcquisitionProtocol", "capability-value": { "acquisition-protocols": [ "http/1.1", "https/1.1" ] }, "footprints": [ ] } ] } 5.5. Redirection Mode Capability Object The Redirection Mode capability object is used to indicate support for one or more of the modes listed in the CDNI Capabilities Redirection Modes registry (see Section 6.2). Property: redirection-modes Description: List of supported CDNI Redirection Modes. Type: List of Redirection Modes (from Section 6.2) Mandatory-to-Specify: Yes. 5.5.1. Redirection Mode Capability Object Serialization The following shows an example of Redirection Mode Capability Object Serialization, for a CDN that supports only iterative (but not recursive) redirection with HTTP and DNS. Seedorf, et al. Expires November 21, 2016 [Page 13] Internet-Draft CDNI RR Footprint/Capabilities Semantics May 2016 { "capabilities": [ { "capability-type": "FCI.RedirectionMode", "capability-value": { "redirection-modes": [ "DNS-I", "HTTP-I" ] } "footprints": [ ] } ] } 5.6. CDNI Logging Capability Object The CDNI Logging capability object is used to indicate support for CDNI Logging record-types, as well as CDNI Logging fields which are marked as optional for the specified record-types [I-D.ietf-cdni-logging]. Property: record-type Description: Supported CDNI Logging record-type. Type: String corresponding to an entry from the CDNI Logging record-types registry [I-D.ietf-cdni-logging]) Mandatory-to-Specify: Yes. Property: fields Description: List of supported CDNI Logging fields that are optional for the specified record-type. Type: List of Strings corresponding to entries from the CDNI Logging Field Names registry [I-D.ietf-cdni-logging]. Mandatory-to-Specify: No. Default is that all optional fields are supported. Omission of this field MUST be interpreted as "all optional fields are supported". An empty list MUST be interpreted as "no optional fields are supported. Otherwise, if a list of fields is provided, the fields in that list MUST be interpreted as "the only optional fields that are supported". Seedorf, et al. Expires November 21, 2016 [Page 14] Internet-Draft CDNI RR Footprint/Capabilities Semantics May 2016 5.6.1. CDNI Logging Capability Object Serialization The following shows an example of CDNI Logging Capability Object Serialization, for a CDN that supports the optional Content Collection ID logging field (but not the optional Session ID logging field) for the "cdni_http_request_v1" record type. { "capabilities": [ { "capability-type": "FCI.Logging", "capability-value": { "record-type": "cdni_http_request_v1", "fields": [ "s-ccid" ] }, "footprints": [ ] } ] } The next example shows the CDNI Logging Capability Object Serialization, for a CDN that supports all optional fields for the "cdni_http_request_v1" record type. { "capabilities": [ { "capability-type": "FCI.Logging", "capability-value": { "record-type": "cdni_http_request_v1" }, "footprints": [ ] } ] } 5.7. CDNI Metadata Capability Object The CDNI Metadata capability object is used to indicate support for CDNI GenericMetadata types [I-D.ietf-cdni-metadata]. Property: metadata Description: List of supported CDNI GenericMetadata types. Seedorf, et al. Expires November 21, 2016 [Page 15] Internet-Draft CDNI RR Footprint/Capabilities Semantics May 2016 Type: List of Strings corresponding to entries from the CDNI Payload Type registry [RFC7736]) that correspond to CDNI GenericMetadata objects. Mandatory-to-Specify: Yes. An empty list MUST be interpreted as "no GenericMetadata types are supported", i.e., "only structural metadata and simple types are supported"; otherwise, the list must be interpreted as containing "the only GenericMetadata types that are supported" (in addition to structural metadata and simple types) [I-D.ietf-cdni-metadata]. 5.7.1. CDNI Metadata Capability Object Serialization The following shows an example of CDNI Metadata Capability Object Serialization, for a CDN that supports only the SourceMetadata GenericMetadata type (i.e., it can acquire and deliver content, but cannot enforce and security policies, e.g., time, location, or protocol ACLs). { "capabilities": [ { "capability-type": "FCI.Metadata", "capability-value": { "metadata": ["MI.SourceMetadata"] }, "footprints": [ ] } ] } The next example shows the CDNI Metadata Capability Object Serialization, for a CDN that supports only structural metadata (i.e., it can parse metadata as a transit CDN, but cannot enforce security policies or deliver content). Seedorf, et al. Expires November 21, 2016 [Page 16] Internet-Draft CDNI RR Footprint/Capabilities Semantics May 2016 { "capabilities": [ { "capability-type": "FCI.Metadata", "capability-value": { "metadata": [] }, "footprints": [ ] } ] } 6. IANA Considerations 6.1. CDNI Payload Types This document requests the registration of the following CDNI Payload Types under the IANA CDNI Payload Type registry: +-------------------------+---------------+ | Payload Type | Specification | +-------------------------+---------------+ | FCI.DeliveryProtocol | RFCthis | | | | | FCI.AcquisitionProtocol | RFCthis | | | | | FCI.RedirectionMode | RFCthis | | | | | FCI.Logging | RFCthis | | | | | FCI.Metadata | RFCthis | +-------------------------+---------------+ [RFC Editor: Please replace RFCthis with the published RFC number for this document.] 6.1.1. CDNI FCI DeliveryProtocol Payload Type Purpose: The purpose of this payload type is to distinguish FCI advertisement objects for supported delivery protocols Interface: FCI Encoding: see Section 5.3 Seedorf, et al. Expires November 21, 2016 [Page 17] Internet-Draft CDNI RR Footprint/Capabilities Semantics May 2016 6.1.2. CDNI FCI AcquisitionProtocol Payload Type Purpose: The purpose of this payload type is to distinguish FCI advertisement objects for supported acquisition protocols Interface: FCI Encoding: see Section 5.4 6.1.3. CDNI FCI RedirectionMode Payload Type Purpose: The purpose of this payload type is to distinguish FCI advertisement objects for supported redirection modes Interface: FCI Encoding: see Section 5.5 6.1.4. CDNI FCI Logging Payload Type Purpose: The purpose of this payload type is to distinguish FCI advertisement objects for supported CDNI Logging record-types and optional CDNI Logging Field Names. Interface: FCI Encoding: see Section 5.6 6.1.5. CDNI FCI Metadata Payload Type Purpose: The purpose of this payload type is to distinguish FCI advertisement objects for supported CDNI GenericMetadata types. Interface: FCI Encoding: see Section 5.7 6.2. Redirection Mode Registry The IANA is requested to create a new "CDNI Capabilities Redirection Modes" registry in the "Content Delivery Networks Interconnection (CDNI) Parameters" category. The "CDNI Capabilities Redirection Modes" namespace defines the valid redirection modes that can be advertised as supported by a CDN. Additions to the Redirection Mode namespace conform to the "IETF Review" policy as defined in [RFC5226]. The following table defines the initial Redirection Modes: Seedorf, et al. Expires November 21, 2016 [Page 18] Internet-Draft CDNI RR Footprint/Capabilities Semantics May 2016 +------------------+----------------------------------+---------+ | Redirection Mode | Description | RFC | +------------------+----------------------------------+---------+ | DNS-I | Iterative DNS-based Redirection | RFCthis | | | | | | DNS-R | Recursive DNS-based Redirection | RFCthis | | | | | | HTTP-I | Iterative HTTP-based Redirection | RFCthis | | | | | | HTTP-R | Recursive HTTP-based Redirection | RFCthis | +------------------+----------------------------------+---------+ [RFC Editor: Please replace RFCthis with the published RFC number for this document.] 7. Security Considerations This specification describes the semantics for capabilities and footprint advertisement objects across interconnected CDNs. It does not, however, specify a concrete protocol for transporting those objects. Specific security mechanisms can only be selected for concrete protocols that instantiate these semantics. This document does, however, place some high-level security constraints on such protocols. All protocols that implement these semantics are REQUIRED to provide integrity and authentication services. Without authentication and integrity, an attacker could trivially deny service by forging a footprint advertisement from a dCDN which claims the network has no footprint or capability. This would prevent the uCDN from delegating any requests to the dCDN. Since a pre-existing relationship between all dCDNs and uCDNs is assumed by CDNI, the exchange of any necessary credentials could be conducted before the FCI interface is brought online. The authorization decision to accept advertisements would also follow this pre-existing relationship and any contractual obligations that it stipulates. All protocols that implement these semantics are REQUIRED to provide confidentiality services. Some dCDNs are willing to share information about their footprint or capabilities with a uCDN but not with other, competing dCDNs. For example, if a dCDN incurs an outage that reduces footprint coverage temporarily, that could be information the dCDN would want to share confidentially with the uCDN. As specified in this document, the security requirements of the FCI could be met by transport-layer security mechanisms coupled with domain certificates as credentials (e.g., TLS transport for HTTP as Seedorf, et al. Expires November 21, 2016 [Page 19] Internet-Draft CDNI RR Footprint/Capabilities Semantics May 2016 per [RFC2818] and [RFC7230], with usage guidance from [RFC7525]) between CDNs. There is no apparent need for further object-level security in this framework, as the trust relationships it defines are bilateral relationships between uCDNs and dCDNs rather than transitive relationships. 8. References 8.1. Normative References [I-D.ietf-cdni-logging] Faucheur, F., Bertrand, G., Oprescu, I., and R. Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni- logging-25 (work in progress), April 2016. [I-D.ietf-cdni-metadata] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, "CDN Interconnection Metadata", draft-ietf-cdni- metadata-16 (work in progress), April 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, . [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, . [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, . [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015, . 8.2. Informative References [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, . Seedorf, et al. Expires November 21, 2016 [Page 20] Internet-Draft CDNI RR Footprint/Capabilities Semantics May 2016 [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, . [RFC6770] Bertrand, G., Ed., Stephan, E., Burbridge, T., Eardley, P., Ma, K., and G. Watson, "Use Cases for Content Delivery Network Interconnection", RFC 6770, DOI 10.17487/RFC6770, November 2012, . [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, . [RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution Network Interconnection (CDNI) Requirements", RFC 7337, DOI 10.17487/RFC7337, August 2014, . [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, . [RFC7736] Ma, K., "Content Delivery Network Interconnection (CDNI) Media Type Registration", RFC 7736, DOI 10.17487/RFC7736, December 2015, . Appendix A. Main Use Case to Consider Focusing on a main use case that contains a simple (yet somewhat challenging), realistic, and generally imaginable scenario can help in narrowing down the requirements for the CDNI FCI. To this end, the following (simplified) use case can help in clarifying the semantics of footprint and capabilities for CDNI. In particular, the intention of the use case is to clarify what information needs to be exchanged on the CDNI FCI, what types of information need to be supported in a mandatory fashion (and which can be considered optional), and what types of information need to be updated with respect to a priori established CDNI contracts. Use case: A given uCDN has several dCDNs. It selects one dCDN for delivery protocol A and footprint 1 and another dCDN for delivery protocol B and footprint 1. The dCDN that serves delivery protocol B has a further, transitive (level-2) dCDN, that serves delivery protocol B in a subset of footprint 1 where the first-level dCDN Seedorf, et al. Expires November 21, 2016 [Page 21] Internet-Draft CDNI RR Footprint/Capabilities Semantics May 2016 cannot serve delivery protocol B itself. What happens if capabilities change in the transitive level-2 dCDN that might affect how the uCDN selects a level-1 dCDN (e.g., in case the level-2 dCDN cannot serve delivery protocol B anymore)? How will these changes be conveyed to the uCDN? In particular, what information does the uCDN need to be able to select a new first-level dCDN, either for all of footprint 1 or only for the subset of footprint 1 that the transitive level-2 dCDN served on behalf of the first-level dCDN? Appendix B. Semantics for Footprint Advertisement Roughly speaking, "footprint" can be defined as "ability and willingness to serve" by a dCDN. However, in addition to simple "ability and willingness to serve", the uCDN could want additional information to make a dCDN selection decision, e.g., "how well" a given dCDN can actually serve a given end user request. The "ability and willingness" to serve SHOULD be distinguished from the subjective qualitative measurement of "how well" it was served. One can imagine that such additional information is implicitly associated with a given footprint, due to contractual agreements, SLAs, business relationships, or past perceptions of dCDN quality. As an alternative, such additional information could also be explicitly tagged along with the footprint. It is reasonable to assume that a significant part of the actual footprint advertisement will happen in contractual agreements between participating CDNs, prior to the advertisement phase using the CDNI FCI. The reason for this assumption is that any contractual agreement is likely to contain specifics about the dCDN coverage (footprint) to which the contractual agreement applies. In particular, additional information to judge the delivery quality associated with a given dCDN footprint might be defined in contractual agreements, outside of the CDNI FCI. Further, one can assume that dCDN contractual agreements about the delivery quality associated with a given footprint will probably be based on high- level aggregated statistics and not too detailed. Given that a large part of footprint advertisement will actually happen in contractual agreements, the semantics of CDNI footprint advertisement refer to answering the following question: what exactly still needs to be advertised by the CDNI FCI? For instance, updates about temporal failures of part of a footprint can be useful information to convey via the CDNI request routing interface. Such information would provide updates on information previously agreed in contracts between the participating CDNs. In other words, the CDNI FCI is a means for a dCDN to provide changes/updates regarding a footprint it has prior agreed to serve in a contract with a uCDN. Seedorf, et al. Expires November 21, 2016 [Page 22] Internet-Draft CDNI RR Footprint/Capabilities Semantics May 2016 Generally speaking, one can imagine two categories of footprint to be advertised by a dCDN: o 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'. o 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. For each of these footprint types, there are capabilities associated with a given footprint: o capabilities such as delivery protocol, redirection mode, and metadata, which are supported in the coverage area for a "coverage/reachability" defined footprint, or o capabilities of resources, such as delivery protocol, redirection mode, and metadata, which apply to a "resource" defined footprint. "Resource" types of footprints are more specific than "coverage/ reachability" types of footprints, where the actual coverage/ reachability are extrapolated from the resource location (e.g., netmask applied to resource IP address to derive IP-prefix). The specific methods for extrapolating coverage/reachability from resource location are beyond the scope of this document. In the degenerate case, the resource address could be specified as a coverage/reachability type of footprint, in which case no extrapolation is necessary. Resource types of footprints could expose the internal structure of a CDN network which could be undesirable. As such, the resource types of footprints are not considered mandatory to support for CDNI. Footprints can be viewed as constraints for delegating requests to a dCDN: A dCDN footprint advertisement tells the uCDN the limitations for delegating a request to the dCDN. For IP prefixes or ASN(s), the footprint signals to the uCDN that it should consider the dCDN a candidate only if the IP address of the request routing source falls within the prefix set (or ASN, respectively). The CDNI specifications do not define how a given uCDN determines what address ranges are in a particular ASN. Similarly, for country codes a uCDN should only consider the dCDN a candidate if it covers the country of the request routing source. The CDNI specifications do not define how a given uCDN determines the country of the request routing source. Multiple footprint constraints are additive: the Seedorf, et al. Expires November 21, 2016 [Page 23] Internet-Draft CDNI RR Footprint/Capabilities Semantics May 2016 advertisement of different types of footprint narrows the dCDN candidacy cumulatively. Independent of the exact type of a footprint, a footprint might also include the connectivity of a given dCDN to other CDNs that are able to serve content to users on behalf of that dCDN, to cover cases with cascaded CDNs. Further, the dCDN needs to be able to express its footprint to an interested uCDN in a comprehensive form, e.g., as a data set containing the complete footprint. Making incremental updates, however, to express dynamic changes in state is also desirable. Appendix C. Semantics for Capabilities Advertisement In general, the dCDN needs to be able to express its general capabilities to the uCDN. These general capabilities could express if the dCDN supports a given service, for instance, HTTP vs HTTPS delivery. Furthermore, the dCDN needs to be able to express particular capabilities for the delivery in a particular footprint area. For example, the dCDN might in general offer HTTPS but not in some specific areas, either for maintenance reasons or because the surrogates covering this particular area cannot deliver this type of service. Hence, in certain cases footprint and capabilities are tied together and cannot be interpreted independently from each other. In such cases, i.e., where capabilities need to be expressed on a per footprint basis, it could be beneficial to combine footprint and capabilities advertisement. A high-level and very rough semantic for capabilities is thus the following: Capabilities are types of information that allow a uCDN to determine if a dCDN is able (and willing) to accept (and properly handle) a delegated content request. In addition, Capabilities are characterized by the fact that this information can change over time based on the state of the network or surrogates. At a first glance, several broad categories of capabilities seem useful to convey via an advertisement interface, however, advertising capabilities that change highly dynamically (e.g., real-time delivery performance metrics, CDN resource load, or other highly dynamically changing QoS information) is beyond the scope for CDNI FCI. First, out of the multitude of possible metrics and capabilities, it is hard to agree on a subset and the precise metrics to be used. Second, it seems infeasible to specify such highly dynamically changing capabilities and the corresponding metrics within a reasonable time- frame. Useful capabilities refer to information that does not change highly dynamically and which in many cases is absolutely necessary to decide Seedorf, et al. Expires November 21, 2016 [Page 24] Internet-Draft CDNI RR Footprint/Capabilities Semantics May 2016 on a particular dCDN for a given end user request. For instance, if an end user request concerns the delivery of a video file with a certain protocol, the uCDN needs to know if a given dCDN has the capability of supporting this delivery protocol. Similar to footprint advertisement, it is reasonable to assume that a significant part of the actual (resource) capabilities advertisement will happen in contractual agreements between participating CDNs, i.e., prior to the advertisement phase using the CDNI FCI. The role of capability advertisement is hence rather to enable the dCDN to update a uCDN on changes since a contract has been set up (e.g., in case a new delivery protocol is suddenly being added to the list of supported delivery protocols of a given dCDN, or in case a certain delivery protocol is suddenly not being supported anymore due to failures). Capabilities advertisement thus refers to conveying information to a uCDN about changes/updates of certain capabilities with respect to a given contract. Given these semantics, it needs to be decided what exact capabilities are useful and how these can be expressed. Since the details of CDNI contracts are not known at the time of this writing (and the CDNI interface are better off being agnostic to these contracts anyway), it remains to be seen what capabilities will be used to define agreements between CDNs in practice. One implication for standardization could be to initially only specify a very limited set of mandatory capabilities for advertisement and have on top of that a flexible data model that allows exchanging additional capabilities when needed. Still, agreement needs to be found on which capabilities (if any) will be mandatory among CDNs. It is not feasible to enumerate all the possible options for the mandatory capabilities listed above (e.g., all the potential delivery protocols or metadata options) or anticipate all the future needs for additional capabilities. It would be unreasonable to burden the CDNI FCI specification with defining each supported capability. Instead, the CDNI FCI specification should define a generic protocol for conveying any capability information (e.g. with common encoding, error handling, and security mechanism; further requirements for the CDNI FCI Advertisement Interface are listed in [RFC7337]). Appendix D. Acknowledgment Jan Seedorf is partially supported by the GreenICN project (GreenICN: Architecture and Applications of Green Information Centric Networking), a research project supported jointly by the European Commission under its 7th Framework Program (contract no. 608518) and the National Institute of Information and Communications Technology (NICT) in Japan (contract no. 167). The views and conclusions Seedorf, et al. Expires November 21, 2016 [Page 25] Internet-Draft CDNI RR Footprint/Capabilities Semantics May 2016 contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the GreenICN project, the European Commission, or NICT. Martin Stiemerling provided initial input to this document and valuable comments to the ongoing discussions among the authors of this document. Thanks to Francois Le Faucheur and Scott Wainner for providing valuable comments and suggestions to the text. Authors' Addresses Jan Seedorf NEC Kurfuerstenanlage 36 Heidelberg 69115 Germany Phone: +49 6221 4342 221 Fax: +49 6221 4342 155 Email: seedorf@neclab.eu Jon Peterson NeuStar 1800 Sutter St Suite 570 Concord CA 94520 USA Email: jon.peterson@neustar.biz Stefano Previdi Cisco Systems Via Del Serafico 200 Rome 0144 Italy Email: sprevidi@cisco.com Seedorf, et al. Expires November 21, 2016 [Page 26] Internet-Draft CDNI RR Footprint/Capabilities Semantics May 2016 Ray van Brandenburg TNO Brassersplein 2 Delft 2612CT The Netherlands Phone: +31-88-866-7000 Email: ray.vanbrandenburg@tno.nl Kevin J. Ma Ericsson 43 Nagog Park Acton, MA 01720 USA Phone: +1 978-844-5100 Email: kevin.j.ma@ericsson.com Seedorf, et al. Expires November 21, 2016 [Page 27]