draft-ietf-cdni-footprint-capabilities-semantics-05.txt   draft-ietf-cdni-footprint-capabilities-semantics-06.txt 
CDNI J. Seedorf CDNI J. Seedorf
Internet-Draft NEC Internet-Draft NEC
Intended status: Informational J. Peterson Intended status: Informational J. Peterson
Expires: September 4, 2015 Neustar Expires: September 10, 2015 Neustar
S. Previdi S. Previdi
Cisco Cisco
R. van Brandenburg R. van Brandenburg
TNO TNO
K. Ma K. Ma
Ericsson Ericsson
March 3, 2015 March 9, 2015
CDNI Request Routing: Footprint and Capabilities Semantics CDNI Request Routing: Footprint and Capabilities Semantics
draft-ietf-cdni-footprint-capabilities-semantics-05 draft-ietf-cdni-footprint-capabilities-semantics-06
Abstract Abstract
This document tries to capture the semantics of the "Footprint and This document tries to capture 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)" is expected to offer Capabilities Advertisement Interface (FCI)" is expected to offer
within CDNI. The document also provides guidelines for a CDNI FCI within CDNI. The document also provides guidelines for a CDNI FCI
protocol. It further defines a Base Advertisement Object, the protocol. It further defines a Base Advertisement Object, the
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 September 4, 2015. This Internet-Draft will expire on September 10, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 34 skipping to change at page 2, line 34
2. Design Decisions for Footprint and Capabilities . . . . . . . 4 2. Design Decisions for Footprint and Capabilities . . . . . . . 4
2.1. Advertising Limited Coverage . . . . . . . . . . . . . . 4 2.1. Advertising Limited Coverage . . . . . . . . . . . . . . 4
2.2. Capabilities and Dynamic Data . . . . . . . . . . . . . . 5 2.2. Capabilities and Dynamic Data . . . . . . . . . . . . . . 5
2.3. Advertisement versus Queries . . . . . . . . . . . . . . 6 2.3. Advertisement versus Queries . . . . . . . . . . . . . . 6
2.4. Avoiding or Handling 'cheating' dCDNs . . . . . . . . . . 7 2.4. Avoiding or Handling 'cheating' dCDNs . . . . . . . . . . 7
2.5. Focusing on Main Use Cases . . . . . . . . . . . . . . . 7 2.5. Focusing on Main Use Cases . . . . . . . . . . . . . . . 7
3. Main Use Case to Consider . . . . . . . . . . . . . . . . . . 8 3. Main Use Case to Consider . . . . . . . . . . . . . . . . . . 8
4. Semantics for Footprint Advertisement . . . . . . . . . . . . 8 4. Semantics for Footprint Advertisement . . . . . . . . . . . . 8
5. Semantics for Capabilities Advertisement . . . . . . . . . . 11 5. Semantics for Capabilities Advertisement . . . . . . . . . . 11
6. Negotiation of Support for Optional Types of 6. Negotiation of Support for Optional Types of
Footprint/Capabilities . . . . . . . . . . . . . . . . . . . 14 Footprint/Capabilities . . . . . . . . . . . . . . . . . . . 13
7. Capability Advertisement Object . . . . . . . . . . . . . . . 14 7. Capability Advertisement Object . . . . . . . . . . . . . . . 14
7.1. Base Advertisement Object . . . . . . . . . . . . . . . . 14 7.1. Base Advertisement Object . . . . . . . . . . . . . . . . 14
7.2. Redirection Mode Advertisement Object . . . . . . . . . . 15 7.2. Delivery Protocol Capability Object . . . . . . . . . . . 15
7.3. Example of Advertisement Object Serialization . . . . . . 15 7.3. Acquisition Protocol Capability Object . . . . . . . . . 15
7.4. Redirection Mode Capability Object . . . . . . . . . . . 15
7.5. Capability Advertisement Object Serialization . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8.1. Capabilities Registry . . . . . . . . . . . . . . . . . . 16 8.1. Redirection Mode Registry . . . . . . . . . . . . . . . . 17
8.2. Footprint Sub-Registry . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8.3. Protocol Sub-Registry . . . . . . . . . . . . . . . . . . 17
8.4. Redirection Mode Sub-Registry . . . . . . . . . . . . . . 17
8.5. Logging Record Type Sub-Registry . . . . . . . . . . . . 17
8.6. Logging Field Name Sub-Registry . . . . . . . . . . . . . 17
8.7. Metadata Type Sub-Registry . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Acknowledgment . . . . . . . . . . . . . . . . . . . 19 Appendix A. Acknowledgment . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction and Scope 1. Introduction and Scope
The CDNI working group is working on a set of protocols to enable the The CDNI working group is working on a set of protocols to enable the
interconnection of multiple CDNs to a CDN federation. This CDN- interconnection of multiple CDNs to a CDN federation. This CDN-
federation should serve multiple purposes, as discussed in [RFC6770], federation should serve multiple purposes, as discussed in [RFC6770],
for instance, to extend the reach of a given CDN to areas in the for instance, to extend the reach of a given CDN to areas in the
network which are not covered by this particular CDN. network which are not covered by this particular CDN.
The goal of this document is to achieve a clear understanding about The goal of this document is to achieve a clear understanding about
skipping to change at page 13, line 30 skipping to change at page 13, line 30
as needs dictate. This document defines the registry (and the rules as needs dictate. This document defines the registry (and the rules
for adding new entries to the registry) for the different capability for adding new entries to the registry) for the different capability
types (see Section 8). Each capability type MAY have a list of valid types (see Section 8). Each capability type MAY have a list of valid
values. Future specifications which define a given capability SHOULD values. Future specifications which define a given capability SHOULD
define any necessary registries (and the rules for adding new entries define any necessary registries (and the rules for adding new entries
to the registry) for the values advertised for a given capability to the registry) for the values advertised for a given capability
type. type.
The "CDNI Logging Fields Names" registry defines all supported The "CDNI Logging Fields Names" registry defines all supported
logging fields, including mandatory-to-implement logging fields. logging fields, including mandatory-to-implement logging fields.
Advertisement of support for mandatory-to-implement logging fields Advertising support for mandatory-to-implement logging fields SHOULD
SHOULD be supported but would be redundant. CDNs SHOULD NOT be supported but would be redundant. CDNs SHOULD NOT advertise
advertise support for mandatory-to-implement logging fields. The support for mandatory-to-implement logging fields. The following
following logging fields are defined as optional in the CDNI Logging logging fields are defined as optional in the CDNI Logging Interface
Interface document [I-D.ietf-cdni-logging]: document [I-D.ietf-cdni-logging]:
o c-ip-anonimizing o c-ip-anonimizing
o s-ccid o s-ccid
o s-sid o s-sid
The "CDNI GenericMetadata Types" registry defines all supported The CDNI Metadata Interface document [I-D.ietf-cdni-metadata] does
GenericMetadats types, including mandatory-to-implement not define any optional GenericMetadata types. Advertiseing support
GenericMetadata types. Advertisement of support for mandatory-to- for mandatory-to-implement GenericMetadata types SHOULD be supported
implement GenericMetadata types SHOULD be supported but would be but would be redundant. CDNs SHOULD NOT advertise support for
redundant. CDNs SHOULD NOT advertise support for mandatory-to- mandatory-to-implement GenericMetadata types.
implement GenericMetadata types. The CDNI Metadata Interface
document [I-D.ietf-cdni-metadata] does not define any optional
GenericMetadata types.
6. Negotiation of Support for Optional Types of Footprint/Capabilities 6. Negotiation of Support for Optional Types of Footprint/Capabilities
The notion of optional types of footprint and capabilities implies The notion of optional types of footprint and capabilities implies
that certain implementations may not support all kinds of footprint that certain implementations may not support all kinds of footprint
and capabilities. Therefore, any FCI solution protocol must define and capabilities. Therefore, any FCI solution protocol must define
how the support for optional types of footprint/capabilities will be how the support for optional types of footprint/capabilities will be
negotiated between a uCDN and a dCDN that use the particular FCI negotiated between a uCDN and a dCDN that use the particular FCI
protocol. In particular, any FCI solution protocol needs to specify protocol. In particular, any FCI solution protocol needs to specify
how to handle failure cases or non-supported types of footprint/ how to handle failure cases or non-supported types of footprint/
skipping to change at page 14, line 39 skipping to change at page 14, line 33
[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.
7.1. Base Advertisement Object 7.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 (see Section 8.1) 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: MIME Type String (from Section 8) Type: MIME Type String (from Section 8)
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
Property: capability-value Property: capability-value
Description: CDNI Capability object. Description: CDNI Capability object.
Type: Format/Type is defined by the value of capability-type Type: Format/Type is defined by the value of capability-type
property above. property above.
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
7.2. Redirection Mode Advertisement Object 7.2. Delivery Protocol Capability Object
The Redirection Mode advertisement object is used to indicate support The Delivery Protocol capability object is used to indicate support
for one or more of the modes listed in the CDNI Capabilities for one or more of the protocols listed in the CDNI Metadata
Redirection Modes registry (see Section 8.4). Protocols registry (defined in the CDNI Metadata Interface document
[I-D.ietf-cdni-metadata]).
Property: redirection-modes Property: delivery-protocols
Description: List of supported CDNI Redirection Modes. Description: List of supported CDNI Delivery Protocols.
Type: List of Redirection Modes (from Section 8.4) Type: List of Protocol Types (from the CDNI Metadata Protocols
registry [I-D.ietf-cdni-metadata])
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
Redirection Mode is not contained in the CDNI Metadata or Logging 7.3. Acquisition Protocol Capability Object
specifications; it is FCI specific. It is defined here as an example
for future specifications that define further CDNI FCI objects.
7.3. Example of Advertisement Object Serialization The Acquisition Protocol capability object is used to indicate
support for one or more of the protocols listed in the CDNI Metadata
Protocols registry (defined in the CDNI Metadata Interface document
[I-D.ietf-cdni-metadata]).
The following shows an example of CDNI FCI Advertisement Object Property: acquisition-protocols
Serialization for two supported redirection modes and one supported
logging capability.
{ Description: List of supported CDNI Acquisition Protocols.
"capabilities": [
{
"capability-type": "application/cdni.FCI.RedirectionMode.v1"
"capability-value": {
"redirection-modes": [
"DNS-I",
"HTTP-I"
]
}
},
{
"capability-type": "application/cdni.FCI.LI.s-ccid.v1"
"capability-value": {
"s-ccid-support": true
}
}
]
}
8. IANA Considerations Type: List of Protocol Types (from the CDNI Metadata Protocols
registry [I-D.ietf-cdni-metadata])
This document requests the registration of the following MIME Media Mandatory-to-Specify: Yes.
Type under the IANA MIME Media Type registry
(http://www.iana.org/assignments/media-types/index.html).
application/cdni.FCI.RedirectionMode.v1 7.4. Redirection Mode Capability Object
8.1. Capabilities Registry 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 8.1).
IANA registries are to be used for mandatory and optional types of Property: redirection-modes
footprint and capabilities. Therefore, the mandatory types of
capabilities listed in this document (see Section 5) are to be
registered with IANA. In order to prevent namespace collisions for
capabilities a new IANA registry is requested for the "CDNI
Capabilities" namespace. The namespace shall be split into two
partitions: standard and optional.
The "standard" namespace partition is intended to contain mandatory Description: List of supported CDNI Redirection Modes.
to implement capabilities and conforms to the "IETF Review" policy as
defined in [RFC5226]. The registry contains the name of the standard
capability, the RFC number of the specification defining the
capability (including the capability advertisement object format and
serialization).
The following table defines the initial capabilities for the standard Type: List of Redirection Modes (from Section 8.1)
partition:
+-----------------------------------------+---------+ Mandatory-to-Specify: Yes.
| Capability | RFC |
+-----------------------------------------+---------+
| application/cdni.FCI.RedirectionMode.v1 | RFCthis |
+-----------------------------------------+---------+
The "optional" namespace partition conforms to the "Expert Review" 7.5. Capability Advertisement Object Serialization
policy as defined in [RFC5226]. The expert review is intended to
prevent namespace hoarding and to prevent the definition of redundant
capabilities. Vendors defining new capabilities which conflict with
existing capabilities follow the guidelines for the "Specification
Required" policy as defined in [RFC5226].
8.2. Footprint Sub-Registry The following shows an example of CDNI FCI Capability Advertisement
Object Serialization.
The "CDNI Metadata Footprint Types" namespace defined in the CDNI {
Metadata Interface document [I-D.ietf-cdni-metadata] contains the "capabilities": [
supported footprint formats for use in footprint advertisement. No {
further IANA action is required here. "capability-type": "application/cdni.FCI.DeliveryProtocol.v1+json"
"capability-value": {
"delivery-protocols": [
"HTTP1.1"
]
}
},
{
"capability-type": "application/cdni.FCI.AcquisitionProtocol.v1+json"
"capability-value": {
"acquisition-protocols": [
"HTTP1.1",
"HTTPS1.1"
]
}
},
{
"capability-type": "application/cdni.FCI.RedirectionMode.v1+json"
"capability-value": {
"redirection-modes": [
"DNS-I",
"HTTP-I"
]
}
}
]
}
8.3. Protocol Sub-Registry 8. IANA Considerations
The "CDNI Metadata Protocols" namespace defined in the CDNI Metadata This document requests the registration of the following MIME Media
Interface document [I-D.ietf-cdni-metadata] contains the supported Types under the IANA MIME Media Type registry
protocol values for the Delivery Protocol and Acquisition Protocol (http://www.iana.org/assignments/media-types/index.html).
capabilities. No further IANA action is required here.
8.4. Redirection Mode Sub-Registry application/cdni.FCI.DeliveryProtocol.v1+json
The "CDNI Capabilities Redirection Modes" namespace defines the valid application/cdni.FCI.AcquisitionProtocol.v1+json
redirection modes that may be advertised as supported by a CDN.
Additions to the Redirection Mode namespace conform to the "IETF application/cdni.FCI.RedirectionMode.v1+json
Review" policy as defined in [RFC5226].
8.1. Redirection Mode Registry
The IANA is requested to create a new "CDNI Capabilities Redirection
Modes" registry. The "CDNI Capabilities Redirection Modes" namespace
defines the valid redirection modes that may 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: The following table defines the initial Redirection Modes:
+------------------+----------------------------------+---------+ +------------------+----------------------------------+---------+
| Redirection Mode | Description | RFC | | Redirection Mode | Description | RFC |
+------------------+----------------------------------+---------+ +------------------+----------------------------------+---------+
| DNS-I | Iterative DNS-based Redirection | RFCthis | | DNS-I | Iterative DNS-based Redirection | RFCthis |
| | | | | | | |
| DNS-R | Recursive DNS-based Redirection | RFCthis | | DNS-R | Recursive DNS-based Redirection | RFCthis |
| | | | | | | |
| HTTP-I | Iterative HTTP-based Redirection | RFCthis | | HTTP-I | Iterative HTTP-based Redirection | RFCthis |
| | | | | | | |
| HTTP-R | Recursive HTTP-based Redirection | RFCthis | | HTTP-R | Recursive HTTP-based Redirection | RFCthis |
+------------------+----------------------------------+---------+ +------------------+----------------------------------+---------+
8.5. Logging Record Type Sub-Registry
The "CDNI Logging Record-Types" namespace defined in the CDNI Logging
Interface document [I-D.ietf-cdni-logging] contains the types of all
supported logging record-types. No further IANA action is required
here.
8.6. Logging Field Name Sub-Registry
The "CDNI Logging Fields Names" namespace defined in the CDNI Logging
Interface document [I-D.ietf-cdni-logging] contains the names of all
supported logging fields. No further IANA action is required here.
8.7. Metadata Type Sub-Registry
The "CDNI GenericMetadata Types" namespace defined in the CDNI
Metadata Interface document [I-D.ietf-cdni-metadata] contains the
names of the supported GenericMetadata objects. No further IANA
action is required here.
9. Security Considerations 9. Security Considerations
This specification describes the semantics for capabilities and This specification describes the semantics for capabilities and
footprint advertisement objects in content distribution networks. It footprint advertisement objects in content distribution networks. It
does not, however, specify a concrete protocol for transporting those does not, however, specify a concrete protocol for transporting those
objects, or even a specific object syntax. Specific security objects, or even a specific object syntax. Specific security
mechanisms can only be selected for concrete protocols that mechanisms can only be selected for concrete protocols that
instantiate these semantics. This document does, however, place some instantiate these semantics. This document does, however, place some
high-level security constraints on such protocols. high-level security constraints on such protocols.
skipping to change at page 19, line 35 skipping to change at page 19, line 8
10.2. Informative References 10.2. Informative 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-15 (work in progress), February 2015. logging-15 (work in progress), February 2015.
[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-08 (work in progress), October 2014. metadata-09 (work in progress), March 2015.
Appendix A. Acknowledgment Appendix A. Acknowledgment
Jan Seedorf is partially supported by the GreenICN project (GreenICN: Jan Seedorf is partially supported by the GreenICN project (GreenICN:
Architecture and Applications of Green Information Centric Architecture and Applications of Green Information Centric
Networking), a research project supported jointly by the European Networking), a research project supported jointly by the European
Commission under its 7th Framework Program (contract no. 608518) and Commission under its 7th Framework Program (contract no. 608518) and
the National Institute of Information and Communications Technology the National Institute of Information and Communications Technology
(NICT) in Japan (contract no. 167). The views and conclusions (NICT) in Japan (contract no. 167). The views and conclusions
contained herein are those of the authors and should not be contained herein are those of the authors and should not be
 End of changes. 38 change blocks. 
132 lines changed or deleted 101 lines changed or added

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