draft-ietf-cdni-footprint-capabilities-semantics-18.txt   draft-ietf-cdni-footprint-capabilities-semantics-19.txt 
CDNI J. Seedorf CDNI J. Seedorf
Internet-Draft NEC Internet-Draft NEC
Intended status: Standards Track J. Peterson Intended status: Standards Track J. Peterson
Expires: October 30, 2016 Neustar Expires: November 15, 2016 Neustar
S. Previdi S. Previdi
Cisco Cisco
R. van Brandenburg R. van Brandenburg
TNO TNO
K. Ma K. Ma
Ericsson Ericsson
April 28, 2016 May 14, 2016
CDNI Request Routing: Footprint and Capabilities Semantics CDNI Request Routing: Footprint and Capabilities Semantics
draft-ietf-cdni-footprint-capabilities-semantics-18 draft-ietf-cdni-footprint-capabilities-semantics-19
Abstract Abstract
This document captures the semantics of the "Footprint and This document captures the semantics of the "Footprint and
Capabilities Advertisement" part of the CDNI Request Routing Capabilities Advertisement" part of the CDNI Request Routing
interface, i.e., the desired meaning of "Footprint" and interface, i.e., the desired meaning of "Footprint" and
"Capabilities" in the CDNI context, and what the "Footprint and "Capabilities" in the CDNI context, and what the "Footprint and
Capabilities Advertisement Interface (FCI)" offers within CDNI. The Capabilities Advertisement Interface (FCI)" offers within CDNI. The
document also provides guidelines for the CDNI FCI protocol. It document also provides guidelines for the CDNI FCI protocol. It
further defines a Base Advertisement Object, the necessary registries further defines a Base Advertisement Object, the necessary registries
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 30, 2016. This Internet-Draft will expire on November 15, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 38 skipping to change at page 2, line 38
2.3. Advertisement versus Queries . . . . . . . . . . . . . . 7 2.3. Advertisement versus Queries . . . . . . . . . . . . . . 7
2.4. Avoiding or Handling 'cheating' dCDNs . . . . . . . . . . 7 2.4. Avoiding or Handling 'cheating' dCDNs . . . . . . . . . . 7
3. Focusing on Capabilities with Footprint Restrictions . . . . 8 3. Focusing on Capabilities with Footprint Restrictions . . . . 8
4. Footprint and Capabilities Extension . . . . . . . . . . . . 8 4. Footprint and Capabilities Extension . . . . . . . . . . . . 8
5. Capability Advertisement Object . . . . . . . . . . . . . . . 10 5. Capability Advertisement Object . . . . . . . . . . . . . . . 10
5.1. Base Advertisement Object . . . . . . . . . . . . . . . . 10 5.1. Base Advertisement Object . . . . . . . . . . . . . . . . 10
5.2. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 11 5.2. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 11
5.3. Delivery Protocol Capability Object . . . . . . . . . . . 11 5.3. Delivery Protocol Capability Object . . . . . . . . . . . 11
5.3.1. Delivery Protocol Capability Object Serialization . . 12 5.3.1. Delivery Protocol Capability Object Serialization . . 12
5.4. Acquisition Protocol Capability Object . . . . . . . . . 12 5.4. Acquisition Protocol Capability Object . . . . . . . . . 12
5.4.1. Acquisition Protocol Capability Object Serialization 12 5.4.1. Acquisition Protocol Capability Object Serialization 13
5.5. Redirection Mode Capability Object . . . . . . . . . . . 13 5.5. Redirection Mode Capability Object . . . . . . . . . . . 13
5.5.1. Redirection Mode Capability Object Serialization . . 13 5.5.1. Redirection Mode Capability Object Serialization . . 13
5.6. CDNI Logging Capability Object . . . . . . . . . . . . . 14 5.6. CDNI Logging Capability Object . . . . . . . . . . . . . 14
5.6.1. CDNI Logging Capability Object Serialization . . . . 15 5.6.1. CDNI Logging Capability Object Serialization . . . . 15
5.7. CDNI Metadata Capability Object . . . . . . . . . . . . . 15 5.7. CDNI Metadata Capability Object . . . . . . . . . . . . . 15
5.7.1. CDNI Metadata Capability Object Serialization . . . . 16 5.7.1. CDNI Metadata Capability Object Serialization . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
6.1. CDNI Payload Types . . . . . . . . . . . . . . . . . . . 17 6.1. CDNI Payload Types . . . . . . . . . . . . . . . . . . . 17
6.1.1. CDNI FCI DeliveryProtocol Payload Type . . . . . . . 17 6.1.1. CDNI FCI DeliveryProtocol Payload Type . . . . . . . 17
6.1.2. CDNI FCI AcquisitionProtocol Payload Type . . . . . . 18 6.1.2. CDNI FCI AcquisitionProtocol Payload Type . . . . . . 18
skipping to change at page 5, line 12 skipping to change at page 5, line 12
document does not presume to define them all; this document document does not presume to define them all; this document
describes a scheme for defining new capabilities and how to describes a scheme for defining new capabilities and how to
transport them in Footprint and Capabilities Advertisement transport them in Footprint and Capabilities Advertisement
messages. messages.
2. Design Decisions for Footprint and Capabilities 2. Design Decisions for Footprint and Capabilities
A large part of the difficulty in discussing the FCI lies in A large part of the difficulty in discussing the FCI lies in
understanding what exactly is meant when trying to define footprint understanding what exactly is meant when trying to define footprint
in terms of "coverage" or "reachability." While the operators of in terms of "coverage" or "reachability." While the operators of
CDNs pick strategic locations to situate caches, a cache with a CDNs pick strategic locations to situate surrogates, a surrogate with
public IPv4 address is reachable by any endpoint on the Internet a public IPv4 address is reachable by any endpoint on the Internet
unless some policy enforcement precludes the use of the cache. unless some policy enforcement precludes the use of the surrogate.
Some CDNs aspire to cover the entire world; we refer to these as 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 global CDNs. The footprint advertised by such a CDN in the CDNI
environment would, from a coverage or reachability perspective, environment would, from a coverage or reachability perspective,
presumably cover all prefixes. Potentially more interesting for CDNI presumably cover all prefixes. Potentially more interesting for CDNI
use cases, however, are CDNs that claim a more limited coverage, but 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 seek to interconnect with other CDNs in order to create a single CDN
fabric which shares resources. fabric which shares resources.
Furthermore, not all capabilities need to be footprint restricted. Furthermore, not all capabilities need to be footprint restricted.
skipping to change at page 5, line 41 skipping to change at page 5, line 41
limited coverage area, and how a uCDN would use such advertisements limited coverage area, and how a uCDN would use such advertisements
to decide among one of several dCDNs. The following section will to decide among one of several dCDNs. The following section will
discuss some of the trade-offs and design decisions that need to be discuss some of the trade-offs and design decisions that need to be
decided upon for the CDNI FCI. decided upon for the CDNI FCI.
2.1. Advertising Limited Coverage 2.1. Advertising Limited Coverage
The basic use case that would motivate a dCDN to advertise a limited 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 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 of the Internet. For example, an ISP could purpose-build a CDN to
serve only their own customers by situating caches in close serve only their own customers by situating surrogates in close
topological proximity to high concentrations of their subscribers. topological proximity to high concentrations of their subscribers.
The ISP knows the prefixes it has allocated to end users and thus can The ISP knows the prefixes it has allocated to end users and thus can
easily construct a list of prefixes that its caches were positioned easily construct a list of prefixes that its surrogates were
to serve. positioned to serve.
When such a purpose-built CDN interconnects with other CDNs and When such a purpose-built CDN interconnects with other CDNs and
advertises its footprint to a uCDN, however, the original intended advertises its footprint to a uCDN, however, the original intended
coverage of the CDN might not represent its actual value to the 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 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, their own CDNs, which they interconnect via CDNI. A given user E,
who is a customer of ISP-B, might happen to be topologically closer who is a customer of ISP-B, might happen to be topologically closer
to a cache fielded by ISP-A, if E happens to live in a region where to a surrogate fielded by ISP-A, if E happens to live in a region
ISP-B has few customers and ISP-A has many. In this case, is it ISP- where ISP-B has few customers and ISP-A has many. In this case, is
A's CDN that "covers" E? If ISP-B's CDN has a failure condition, is it ISP-A's CDN that "covers" E? If ISP-B's CDN has a failure
it up to the uCDN to understand that ISP-A's caches are potentially condition, is it up to the uCDN to understand that ISP-A's surrogates
available as back-ups - and if so, how does ISP-A advertise itself as are potentially available as back-ups - and if so, how does ISP-A
a "standby" for E? What about the case where CDNs advertising to the advertise itself as a "standby" for E? What about the case where
same uCDN express overlapping coverage (for example, mixing global CDNs advertising to the same uCDN express overlapping coverage (for
and limited CDNs)? example, mixing global and limited CDNs)?
The answers to these questions greatly depend on how much information 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 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, three dCDNs to choose from that "cover" the IP address of user E,
obviously the uCDN might be interested to know how optimal the obviously the uCDN might be interested to know how optimal the
coverage is from each of the dCDNs - coverage need not be binary, coverage is from each of the dCDNs - coverage need not be binary,
either provided or not provided. dCDNs could advertise a coverage either provided or not provided. dCDNs could advertise a coverage
"score," for example, and provided that they all reported scores "score," for example, and provided that they all reported scores
fairly on the same scale, uCDNs could use that to make their fairly on the same scale, uCDNs could use that to make their
topological optimality decision. Alternately, dCDNs could advertise topological optimality decision. Alternately, dCDNs could advertise
the IP addresses of their caches rather than prefix "coverage," and the IP addresses of their surrogates rather than prefix "coverage,"
let the uCDN decide for itself (based on its own topological and let the uCDN decide for itself (based on its own topological
intelligence) which dCDN has better resources to serve a given user. intelligence) which dCDN has better resources to serve a given user.
In summary, the semantics of advertising footprint depend on whether In summary, the semantics of advertising footprint depend on whether
such qualitative metrics for expressing footprint (such as the such qualitative metrics for expressing footprint (such as the
coverage 'score' mentioned above) are included as part of the CDNI coverage 'score' mentioned above) are included as part of the CDNI
FCI, or if the focus is just on 'binary' footprint. FCI, or if the focus is just on 'binary' footprint.
2.2. Capabilities and Dynamic Data 2.2. Capabilities and Dynamic Data
In cases where the apparent footprints of dCDNs overlap, uCDNs might In cases where the apparent footprints of dCDNs overlap, uCDNs might
also want to rely on other factors to evaluate the respective merits also want to rely on other factors to evaluate the respective merits
of dCDNs. These include facts related to the caches themselves, to of dCDNs. These include facts related to the surrogates themselves,
the network where the cache is deployed, to the nature of the to the network where the surrogate is deployed, to the nature of the
resource sought, and to the administrative policies of the respective resource sought, and to the administrative policies of the respective
networks. networks.
In the absence of network-layer impediments to reaching caches, the In the absence of network-layer impediments to reaching surrogates,
choice to limit coverage is necessarily an administrative policy. the choice to limit coverage is necessarily an administrative policy.
Much policy needs to be agreed upon before CDNs can interconnect, Much policy needs to be agreed upon before CDNs can interconnect,
including questions of membership, compensation, volumes, and so on. including questions of membership, compensation, volumes, and so on.
A uCDN certainly will factor these sorts of considerations into its A uCDN certainly will factor these sorts of considerations into its
decision to select a dCDN, but there is probably little need for decision to select a dCDN, but there is probably little need for
dCDNs to actually advertise them through an interface - they will be dCDNs to actually advertise them through an interface - they will be
settled out-of-band as a precondition for interconnection. settled out-of-band as a precondition for interconnection.
Other facts about the dCDN would be expressed through the interface Other facts about the dCDN would be expressed through the interface
to the uCDN. Some capabilities of a dCDN are static, and some are to the uCDN. Some capabilities of a dCDN are static, and some are
highly dynamic. Expressing the total storage built into its caches, highly dynamic. Expressing the total storage built into its
for example, changes relatively rarely, whereas the amount of storage surrogates, for example, changes relatively rarely, whereas the
in use at any given moment is highly volatile. Network bandwidth amount of storage in use at any given moment is highly volatile.
similarly could be expressed as either total bandwidth available to a Network bandwidth similarly could be expressed as either total
cache, or based on the current state of the network. A cache can at bandwidth available to a surrogate, or based on the current state of
one moment lack a particular resource in storage, but have it the the network. A surrogate can at one moment lack a particular
next. resource in storage, but have it the next.
The semantics of the capabilities interface will depend on how much The semantics of the capabilities interface will depend on how much
of the dCDN state needs to be pushed to the uCDN and qualitatively of the dCDN state needs to be pushed to the uCDN and qualitatively
how often that information needs to be updated. how often that information needs to be updated.
2.3. Advertisement versus Queries 2.3. Advertisement versus Queries
In a CDNI environment, each dCDN shares some of its state with the 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 uCDN. The uCDN uses this information to build a unified picture of
all of the dCDNs available to it. In architectures that share all of the dCDNs available to it. In architectures that share
detailed capability information, the uCDN could perform the entire detailed capability information, the uCDN could perform the entire
request-routing operation down to selecting a particular cache in the request-routing operation down to selecting a particular surrogate in
dCDN. However, when the uCDN needs to deal with many potential the dCDN. However, when the uCDN needs to deal with many potential
dCDNs, this approach does not scale, especially for dCDNs with dCDNs, this approach does not scale, especially for dCDNs with
thousands or tens of thousands of caches; the volume of updates to thousands or tens of thousands of surrogates; the volume of updates
footprint and capability becomes onerous. to footprint and capability becomes onerous.
Were the volume of FCI updates from dCDNs to exceed the volume of 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 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 dCDNs upon receiving requests (as is the case in the recursive
redirection mode described in [RFC7336]), instead of receiving redirection mode described in [RFC7336]), instead of receiving
advertisements and tracking the state of dCDNs. The advantage of advertisements and tracking the state of dCDNs. The advantage of
querying dCDNs would be that much of the dynamic data that dCDNs 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 cannot share with the uCDN would now be factored into the uCDN's
decision. dCDNs need not replicate any state to the uCDN - uCDNs decision. dCDNs need not replicate any state to the uCDN - uCDNs
could effectively operate in a stateless mode. could effectively operate in a stateless mode.
skipping to change at page 8, line 28 skipping to change at page 8, line 28
3. Focusing on Capabilities with Footprint Restrictions 3. Focusing on Capabilities with Footprint Restrictions
Given the design considerations listed in the previous section, it Given the design considerations listed in the previous section, it
seems reasonable to assume that in most cases it is the uCDN that seems reasonable to assume that in most cases it is the uCDN that
makes the decision on selecting a certain dCDN for request routing makes the decision on selecting a certain dCDN for request routing
based on information the uCDN has received from this particular dCDN. based on information the uCDN has received from this particular dCDN.
It can be assumed that 'cheating' CDNs will be dealt with via means It can be assumed that 'cheating' CDNs will be dealt with via means
outside the scope of CDNI and that the information advertised between outside the scope of CDNI and that the information advertised between
CDNs is accurate. In addition, excluding the use of qualitative CDNs is accurate. In addition, excluding the use of qualitative
information (e.g., cache proximity, delivery latency, cache load) to information (e.g., surrogate proximity, delivery latency, surrogate
predict the quality of delivery would further simplify the use case load) to predict the quality of delivery would further simplify the
allowing it to better focus on the basic functionality of the FCI. use case allowing it to better focus on the basic functionality of
the FCI.
Further understanding that in most cases contractual agreements will Further understanding that in most cases contractual agreements will
define the basic coverage used in delegation decisions, the primary define the basic coverage used in delegation decisions, the primary
focus of FCI is on providing updates to the basic capabilities and focus of FCI is on providing updates to the basic capabilities and
coverage by the dCDNs. As such, FCI has choosen the semantics of coverage by the dCDNs. As such, FCI has choosen the semantics of
"capabilities with footprint restrictions". "capabilities with footprint restrictions".
4. Footprint and Capabilities Extension 4. Footprint and Capabilities Extension
Other optional "coverage/reachability" types of footprint or Other optional "coverage/reachability" types of footprint or
skipping to change at page 10, line 36 skipping to change at page 10, line 36
To support extensibility, the FCI defines a generic base object To support extensibility, the FCI defines a generic base object
(similar to the CDNI Metadata interface GenericMetadata object) (similar to the CDNI Metadata interface GenericMetadata object)
[I-D.ietf-cdni-metadata] to facilitate a uniform set of mandatory [I-D.ietf-cdni-metadata] to facilitate a uniform set of mandatory
parsing requirements for all future FCI objects. parsing requirements for all future FCI objects.
Future object definitions (e.g. regarding CDNI Metadata or Logging) Future object definitions (e.g. regarding CDNI Metadata or Logging)
will build off the base object defined here, but will be specified in will build off the base object defined here, but will be specified in
separate documents. 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 5.1. Base Advertisement Object
The FCIBase object is an abstraction for managing individual CDNI The FCIBase object is an abstraction for managing individual CDNI
capabilities in an opaque manner. capabilities in an opaque manner.
Property: capability-type Property: capability-type
Description: CDNI Capability object type. Description: CDNI Capability object type.
Type: FCI specific CDNI Payload type (from the CDNI Payload Type: FCI specific CDNI Payload type (from the CDNI Payload
skipping to change at page 14, line 47 skipping to change at page 14, line 47
Property: fields Property: fields
Description: List of supported CDNI Logging fields that are Description: List of supported CDNI Logging fields that are
optional for the specified record-type. optional for the specified record-type.
Type: List of Strings corresponding to entries from the CDNI Type: List of Strings corresponding to entries from the CDNI
Logging Field Names registry [I-D.ietf-cdni-logging]. Logging Field Names registry [I-D.ietf-cdni-logging].
Mandatory-to-Specify: No. Default is that all optional fields Mandatory-to-Specify: No. Default is that all optional fields
are supported. Inclusion of an empty list SHALL be understood are supported. Omission of this field MUST be interpreted as
to mean that none of the optional fields are supported. "all optional fields are supported". An empty list MUST be
Otherwise, only those optional fields that are listed SHALL be interpreted as "no optional fields are supported. Otherwise,
understood to be supported. if a list of fields is provided, the fields in that list MUST
be interpreted as "the only optional fields that are
supported".
5.6.1. CDNI Logging Capability Object Serialization 5.6.1. CDNI Logging Capability Object Serialization
The following shows an example of CDNI Logging Capability Object The following shows an example of CDNI Logging Capability Object
Serialization, for a CDN that supports the optional Content Serialization, for a CDN that supports the optional Content
Collection ID logging field (but not the optional Session ID logging Collection ID logging field (but not the optional Session ID logging
field) for the "cdni_http_request_v1" record type. field) for the "cdni_http_request_v1" record type.
{ {
"capabilities": [ "capabilities": [
skipping to change at page 16, line 9 skipping to change at page 16, line 9
CDNI GenericMetadata types [I-D.ietf-cdni-metadata]. CDNI GenericMetadata types [I-D.ietf-cdni-metadata].
Property: metadata Property: metadata
Description: List of supported CDNI GenericMetadata types. Description: List of supported CDNI GenericMetadata types.
Type: List of Strings corresponding to entries from the CDNI Type: List of Strings corresponding to entries from the CDNI
Payload Type registry [RFC7736]) that correspond to CDNI Payload Type registry [RFC7736]) that correspond to CDNI
GenericMetadata objects. GenericMetadata objects.
Mandatory-to-Specify: Yes. It SHALL be understood that only Mandatory-to-Specify: Yes. An empty list MUST be interpreted
those GenericMetadata types listed are supported; an empty list as "no GenericMetadata types are supported", i.e., "only
SHALL be understood to mean that only structural metadata and structural metadata and simple types are supported"; otherwise,
simple types are supported [I-D.ietf-cdni-metadata]. 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 5.7.1. CDNI Metadata Capability Object Serialization
The following shows an example of CDNI Metadata Capability Object The following shows an example of CDNI Metadata Capability Object
Serialization, for a CDN that supports only the SourceMetadata Serialization, for a CDN that supports only the SourceMetadata
GenericMetadata type (i.e., it can acquire and deliver content, but GenericMetadata type (i.e., it can acquire and deliver content, but
cannot enforce and security policies, e.g., time, location, or cannot enforce and security policies, e.g., time, location, or
protocol ACLs). protocol ACLs).
{ {
skipping to change at page 20, line 22 skipping to change at page 20, line 22
8.1. Normative References 8.1. Normative References
[I-D.ietf-cdni-logging] [I-D.ietf-cdni-logging]
Faucheur, F., Bertrand, G., Oprescu, I., and R. Faucheur, F., Bertrand, G., Oprescu, I., and R.
Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni- Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni-
logging-25 (work in progress), April 2016. logging-25 (work in progress), April 2016.
[I-D.ietf-cdni-metadata] [I-D.ietf-cdni-metadata]
Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma,
"CDN Interconnection Metadata", draft-ietf-cdni- "CDN Interconnection Metadata", draft-ietf-cdni-
metadata-15 (work in progress), April 2016. metadata-16 (work in progress), April 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <http://www.rfc-editor.org/info/rfc5226>.
skipping to change at page 23, line 14 skipping to change at page 23, line 14
Generally speaking, one can imagine two categories of footprint to be Generally speaking, one can imagine two categories of footprint to be
advertised by a dCDN: advertised by a dCDN:
o Footprint could be defined based on "coverage/reachability", where o Footprint could be defined based on "coverage/reachability", where
coverage/reachability refers to a set of prefixes, a geographic coverage/reachability refers to a set of prefixes, a geographic
region, or similar boundary. The dCDN claims that it can cover/ region, or similar boundary. The dCDN claims that it can cover/
reach 'end user requests coming from this footprint'. reach 'end user requests coming from this footprint'.
o Footprint could be defined based on "resources", where resources o Footprint could be defined based on "resources", where resources
refers to surrogates/caches a dCDN claims to have (e.g., the refers to surrogates a dCDN claims to have (e.g., the location of
location of surrogates/resources). The dCDN claims that 'from surrogates/resources). The dCDN claims that 'from this footprint'
this footprint' it can serve incoming end user requests. it can serve incoming end user requests.
For each of these footprint types, there are capabilities associated For each of these footprint types, there are capabilities associated
with a given footprint: with a given footprint:
o capabilities such as delivery protocol, redirection mode, and o capabilities such as delivery protocol, redirection mode, and
metadata, which are supported in the coverage area for a metadata, which are supported in the coverage area for a
"coverage/reachability" defined footprint, or "coverage/reachability" defined footprint, or
o capabilities of resources, such as delivery protocol, redirection o capabilities of resources, such as delivery protocol, redirection
mode, and metadata, which apply to a "resource" defined footprint. mode, and metadata, which apply to a "resource" defined footprint.
skipping to change at page 24, line 25 skipping to change at page 24, line 25
Appendix C. Semantics for Capabilities Advertisement Appendix C. Semantics for Capabilities Advertisement
In general, the dCDN needs to be able to express its general In general, the dCDN needs to be able to express its general
capabilities to the uCDN. These general capabilities could express capabilities to the uCDN. These general capabilities could express
if the dCDN supports a given service, for instance, HTTP vs HTTPS if the dCDN supports a given service, for instance, HTTP vs HTTPS
delivery. Furthermore, the dCDN needs to be able to express delivery. Furthermore, the dCDN needs to be able to express
particular capabilities for the delivery in a particular footprint particular capabilities for the delivery in a particular footprint
area. For example, the dCDN might in general offer HTTPS but not in area. For example, the dCDN might in general offer HTTPS but not in
some specific areas, either for maintenance reasons or because the some specific areas, either for maintenance reasons or because the
caches covering this particular area cannot deliver this type of surrogates covering this particular area cannot deliver this type of
service. Hence, in certain cases footprint and capabilities are tied service. Hence, in certain cases footprint and capabilities are tied
together and cannot be interpreted independently from each other. In together and cannot be interpreted independently from each other. In
such cases, i.e., where capabilities need to be expressed on a per such cases, i.e., where capabilities need to be expressed on a per
footprint basis, it could be beneficial to combine footprint and footprint basis, it could be beneficial to combine footprint and
capabilities advertisement. capabilities advertisement.
A high-level and very rough semantic for capabilities is thus the A high-level and very rough semantic for capabilities is thus the
following: Capabilities are types of information that allow a uCDN to following: Capabilities are types of information that allow a uCDN to
determine if a dCDN is able (and willing) to accept (and properly determine if a dCDN is able (and willing) to accept (and properly
handle) a delegated content request. In addition, Capabilities are handle) a delegated content request. In addition, Capabilities are
characterized by the fact that this information can change over time characterized by the fact that this information can change over time
based on the state of the network or caches. based on the state of the network or surrogates.
At a first glance, several broad categories of capabilities seem At a first glance, several broad categories of capabilities seem
useful to convey via an advertisement interface, however, advertising useful to convey via an advertisement interface, however, advertising
capabilities that change highly dynamically (e.g., real-time delivery capabilities that change highly dynamically (e.g., real-time delivery
performance metrics, CDN resource load, or other highly dynamically performance metrics, CDN resource load, or other highly dynamically
changing QoS information) is beyond the scope for CDNI FCI. First, changing QoS information) is beyond the scope for CDNI FCI. First,
out of the multitude of possible metrics and capabilities, it is hard 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 to agree on a subset and the precise metrics to be used. Second, it
seems infeasible to specify such highly dynamically changing seems infeasible to specify such highly dynamically changing
capabilities and the corresponding metrics within a reasonable time- capabilities and the corresponding metrics within a reasonable time-
 End of changes. 23 change blocks. 
53 lines changed or deleted 65 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/