draft-ietf-cdni-footprint-capabilities-semantics-01.txt   draft-ietf-cdni-footprint-capabilities-semantics-02.txt 
CDNI J. Seedorf CDNI J. Seedorf
Internet-Draft NEC Internet-Draft NEC
Intended status: Informational J. Peterson Intended status: Informational J. Peterson
Expires: April 24, 2014 Neustar Expires: August 18, 2014 Neustar
S. Previdi S. Previdi
Cisco Cisco
R. van Brandenburg R. van Brandenburg
TNO TNO
K. Ma K. Ma
Azuki Systems, Inc. Azuki Systems, Inc.
October 21, 2013 February 14, 2014
CDNI Request Routing: Footprint and Capabilities Semantics CDNI Request Routing: Footprint and Capabilities Semantics
draft-ietf-cdni-footprint-capabilities-semantics-01 draft-ietf-cdni-footprint-capabilities-semantics-02
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 and what "Footprint and interface, i.e. the desired meaning and what "Footprint and
Capabilities Advertisement" is expected to offer within CDNI. The Capabilities Advertisement" is expected to offer within CDNI. The
discussion in this document has the goal to facilitate the choosing discussion in this document has the goal to facilitate the choosing
of one or more suitable protocols for "Footprint and Capabilities of one or more suitable protocols for "Footprint and Capabilities
Advertisement" within CDNI Request Routing. Advertisement" within CDNI Request Routing.
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 Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 April 24, 2014. This Internet-Draft will expire on August 18, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 2 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 2
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 . . . . . . . . . . 6 2.4. Avoiding or Handling 'cheating' dCDNs . . . . . . . . . . 7
2.5. Focus on Main Use Cases may Simplify Things . . . . . . . 7 2.5. Focus on Main Use Cases may Simplify Things . . . . . . . 7
3. Main Use Case to Consider . . . . . . . . . . . . . . . . . . 7 3. Main Use Case to Consider . . . . . . . . . . . . . . . . . . 8
4. Semantics for Footprint Advertisement . . . . . . . . . . . . 8 4. Semantics for Footprint Advertisement . . . . . . . . . . . . 8
5. Semantics for Capabilities Advertisement . . . . . . . . . . 10 5. Semantics for Capabilities Advertisement . . . . . . . . . . 10
6. Negotiation of Support for Optional Types of 6. Negotiation of Support for Optional Types of
Footprint/Capabilities . . . . . . . . . . . . . . . . . . . 13 Footprint/Capabilities . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7.1. Footprint Sub-Registry . . . . . . . . . . . . . . . . . 14 7.1. Footprint Sub-Registry . . . . . . . . . . . . . . . . . 14
7.2. Protocol Sub-Registry . . . . . . . . . . . . . . . . . . 14 7.2. Protocol Sub-Registry . . . . . . . . . . . . . . . . . . 14
7.3. Redirection Mode Sub-Registry . . . . . . . . . . . . . . 14 7.3. Redirection Mode Sub-Registry . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Acknowledgment . . . . . . . . . . . . . . . . . . . 16 Appendix A. Acknowledgment . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
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
skipping to change at page 13, line 43 skipping to change at page 13, line 43
understands. Similarly, if a dCDN does not use an optional understands. Similarly, if a dCDN does not use an optional
capability or footprint which is, however, supported by a uCDN, this capability or footprint which is, however, supported by a uCDN, this
causes no problem for the FCI functionality because the uCDN decides causes no problem for the FCI functionality because the uCDN decides
on the remaining capabilities/footprint information that is being on the remaining capabilities/footprint information that is being
conveyed by the dCDN. conveyed by the dCDN.
7. IANA Considerations 7. IANA Considerations
IANA registries are to be used for mandatory and optional types of IANA registries are to be used for mandatory and optional types of
footprint and capabilities. Therefore, the mandatory types of footprint and capabilities. Therefore, the mandatory types of
footprint and capabilities listed in this document (see Section 5) capabilities listed in this document (see Section 5) are to be
are to be registered with IANA. In order to prevent namespace registered with IANA. In order to prevent namespace collisions for
collisions for capabilities a new IANA registry is requested for the capabilities a new IANA registry is requested for the "CDNI
"CDNI Capabilities" namespace. The namespace shall be split into two Capabilities" namespace. The namespace shall be split into two
partitions: standard and vendor defined. As with the CDNI Metadata partitions: standard and optional.
Interface [I-D.ietf-cdni-metadata], the vendor defined namespace
partition SHOULD use a namespace prefix of "ext.", while the standard
namespace partition MUST NOT.
The standard namespace partition MUST conform to the "RFC Required" The "standard" namespace partition is intended to contain mandatory
policy as defined in [RFC5226]. The vendor defined namespace to implement capabilities and conforms to the "IETF Review" policy as
partition should be further partitioned into vendor specific defined in [RFC5226]. The registry contains the name of the standard
partitions with the prefix "ext.vendor_name.". The vendor defined capability, the RFC number of the specification defining the
partition SHOULD conform to the "Expert Review" policy as defined in capability, and the version number of the FCI capability set to which
[RFC5226]. The expert review is simply to prevent namespace the standard capability applies.
hoarding. The vendor specific partitions MAY conform to the "First
Come First Served" policy as defined in [RFC5226], however, vendors
defining new capabilities which conflict with existing capabilities
SHOULD follow the guidelines for the "Specification Required" policy
as defined in [RFC5226].
The following table defines the initial capabilities for the standard The following table defines the initial capabilities for the standard
partition: partition:
+----------------------+---------------+ +----------------------+---------+---------+
| capability | Specification | | Capability | RFC | Version |
+----------------------+---------------+ +----------------------+---------+---------+
| Delivery Protocol | RFCthis | | Delivery Protocol | RFCthis | 1 |
| | | | | | |
| Acquisition Protocol | RFCthis | | Acquisition Protocol | RFCthis | 1 |
| | | | | | |
| Redirection Mode | RFCthis | | Redirection Mode | RFCthis | 1 |
+----------------------+---------------+ +----------------------+---------+---------+
Additional capabilities specific to the CDNI Metadata Interface [Ed. Note: Need to add the CDNI Metadata Interface
[I-D.ietf-cdni-metadata] and the CDNI Logging Interface [I-D.ietf-cdni-metadata] and the CDNI Logging Interface
[I-D.ietf-cdni-metadata] SHALL be addressed separately by those [I-D.ietf-cdni-logging] capabilities to this table before
documents. publication, or remove this note if this ends up being handled in
those documents directly.]
The initial FCI version number is set to 1. All three initial
capabilities are considered mandatory to implement for version 1.
The version field should be incremented when new capability sets are
added to the registry.
The "optional" namespace partition conforms to the "Expert Review"
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]. The Version field in the
registry is set to "-1" (negative one) for non-standard capabilities.
7.1. Footprint Sub-Registry 7.1. Footprint Sub-Registry
The "CDNI Metadata Footprint Types" namespace defined in the CDNI The "CDNI Metadata Footprint Types" namespace defined in the CDNI
Metadata Interface document [I-D.ietf-cdni-metadata] contains the Metadata Interface document [I-D.ietf-cdni-metadata] contains the
supported footprint formats for use in footprint advertisement. No supported footprint formats for use in footprint advertisement. No
further IANA action is required here. further IANA action is required here.
7.2. Protocol Sub-Registry 7.2. Protocol Sub-Registry
skipping to change at page 15, line 4 skipping to change at page 15, line 8
further IANA action is required here. further IANA action is required here.
7.2. Protocol Sub-Registry 7.2. Protocol Sub-Registry
The "CDNI Metadata Protocols" namespace defined in the CDNI Metadata The "CDNI Metadata Protocols" namespace defined in the CDNI Metadata
Interface document [I-D.ietf-cdni-metadata] contains the supported Interface document [I-D.ietf-cdni-metadata] contains the supported
protocol values for the Delivery Protocol and Acquisition Protocol protocol values for the Delivery Protocol and Acquisition Protocol
capabilities. No further IANA action is required here. capabilities. No further IANA action is required here.
7.3. Redirection Mode Sub-Registry 7.3. Redirection Mode Sub-Registry
The "CDNI Capabilities Redirection Modes" namespace defines the valid The "CDNI Capabilities Redirection Modes" namespace defines the valid
redirection modes that may be advertised as supported by a CDN. redirection modes that may be advertised as supported by a CDN.
Additions to the Redirection Mode namespace MUST conform to the Additions to the Redirection Mode namespace conform to the "IETF
"Expert Review" policy as defined in [RFC5226]. The expert review Review" policy as defined in [RFC5226].
should verify that new type definitions do not duplicate existing
type definitions and prevent gratuitous additions to the namespace.
For new Redirection Modes which apply to new standard protocols, it
is recommended that registration requests follow the "RFC Required"
policy as defined in [RFC5226].
The following table defines the initial Redirection Modes: The following table defines the initial Redirection Modes:
+------------------+----------------------------------+ +------------------+----------------------------------+---------+
| Redirection Mode | definition | | Redirection Mode | Description | RFC |
+------------------+----------------------------------+ +------------------+----------------------------------+---------+
| DNS-I | Iterative DNS-based Redirection | | DNS-I | Iterative DNS-based Redirection | RFCthis |
| | | | | | |
| DNS-R | Recursive DNS-based Redirection | | DNS-R | Recursive DNS-based Redirection | RFCthis |
| | | | | | |
| HTTP-I | Iterative HTTP-based Redirection | | HTTP-I | Iterative HTTP-based Redirection | RFCthis |
| | | | | | |
| HTTP-R | Recursive HTTP-based Redirection | | HTTP-R | Recursive HTTP-based Redirection | RFCthis |
+------------------+----------------------------------+ +------------------+----------------------------------+---------+
8. Security Considerations 8. Security Considerations
Security considerations will be discussed in a future version of this Security considerations will be discussed in a future version of this
document. document.
9. References 9. References
9.1. Normative References 9.1. Normative References
skipping to change at page 16, line 8 skipping to change at page 16, line 8
Distribution Network Interconnection (CDNI) Problem Distribution Network Interconnection (CDNI) Problem
Statement", RFC 6707, September 2012. Statement", RFC 6707, September 2012.
[RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma, [RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma,
K., and G. Watson, "Use Cases for Content Delivery Network K., and G. Watson, "Use Cases for Content Delivery Network
Interconnection", RFC 6770, November 2012. Interconnection", RFC 6770, November 2012.
9.2. Informative References 9.2. Informative References
[I-D.ietf-cdni-framework] [I-D.ietf-cdni-framework]
Peterson, L. and B. Davie, "Framework for CDN Peterson, L., Davie, B., and R. Brandenburg, "Framework
Interconnection", draft-ietf-cdni-framework-06 (work in for CDN Interconnection", draft-ietf-cdni-framework-09
progress), October 2013. (work in progress), January 2014.
[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-08 (work in progress), October 2013. logging-09 (work in progress), February 2014.
[I-D.ietf-cdni-metadata] [I-D.ietf-cdni-metadata]
Niven-Jenkins, B., Murray, R., Watson, G., Caulfield, M., Niven-Jenkins, B., Murray, R., Watson, G., Caulfield, M.,
Leung, K., and K. Ma, "CDN Interconnect Metadata", draft- Leung, K., and K. Ma, "CDN Interconnect Metadata", draft-
ietf-cdni-metadata-02 (work in progress), July 2013. ietf-cdni-metadata-04 (work in progress), December 2013.
[I-D.ietf-cdni-requirements] [I-D.ietf-cdni-requirements]
Leung, K. and Y. Lee, "Content Distribution Network Leung, K. and Y. Lee, "Content Distribution Network
Interconnection (CDNI) Requirements", draft-ietf-cdni- Interconnection (CDNI) Requirements", draft-ietf-cdni-
requirements-10 (work in progress), September 2013. requirements-17 (work in progress), January 2014.
Appendix A. Acknowledgment Appendix A. Acknowledgment
Jan Seedorf is partially supported by the CHANGE project (CHANGE: Jan Seedorf is partially supported by the CHANGE project (CHANGE:
Enabling Innovation in the Internet Architecture through Flexible Enabling Innovation in the Internet Architecture through Flexible
Flow-Processing Extensions, http://www.change-project.eu/), a Flow-Processing Extensions, http://www.change-project.eu/), a
research project supported by the European Commission under its 7th research project supported by the European Commission under its 7th
Framework Program (contract no. 257422). The views and conclusions Framework Program (contract no. 257422). 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
interpreted as necessarily representing the official policies or interpreted as necessarily representing the official policies or
 End of changes. 21 change blocks. 
63 lines changed or deleted 71 lines changed or added

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