draft-ietf-cdni-footprint-capabilities-semantics-14.txt   draft-ietf-cdni-footprint-capabilities-semantics-15.txt 
CDNI J. Seedorf CDNI J. Seedorf
Internet-Draft NEC Internet-Draft NEC
Intended status: Informational J. Peterson Intended status: Informational J. Peterson
Expires: October 6, 2016 Neustar Expires: October 14, 2016 Neustar
S. Previdi S. Previdi
Cisco Cisco
R. van Brandenburg R. van Brandenburg
TNO TNO
K. Ma K. Ma
Ericsson Ericsson
April 4, 2016 April 12, 2016
CDNI Request Routing: Footprint and Capabilities Semantics CDNI Request Routing: Footprint and Capabilities Semantics
draft-ietf-cdni-footprint-capabilities-semantics-14 draft-ietf-cdni-footprint-capabilities-semantics-15
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 6, 2016. This Internet-Draft will expire on October 14, 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 39 skipping to change at page 2, line 39
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 . . . . . . . . . . . . . . . . . . . 14
7. Capability Advertisement Object . . . . . . . . . . . . . . . 14 7. Capability Advertisement Object . . . . . . . . . . . . . . . 14
7.1. Base Advertisement Object . . . . . . . . . . . . . . . . 14 7.1. Base Advertisement Object . . . . . . . . . . . . . . . . 14
7.2. Delivery Protocol Capability Object . . . . . . . . . . . 15 7.2. Delivery Protocol Capability Object . . . . . . . . . . . 15
7.3. Acquisition Protocol Capability Object . . . . . . . . . 15 7.3. Acquisition Protocol Capability Object . . . . . . . . . 15
7.4. Redirection Mode Capability Object . . . . . . . . . . . 15 7.4. Redirection Mode Capability Object . . . . . . . . . . . 16
7.5. Capability Advertisement Object Serialization . . . . . . 16 7.5. Capability Advertisement Object Serialization . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8.1. CDNI Payload Types . . . . . . . . . . . . . . . . . . . 16 8.1. CDNI Payload Types . . . . . . . . . . . . . . . . . . . 17
8.1.1. CDNI FCI DeliveryProtocol Payload Type . . . . . . . 17 8.1.1. CDNI FCI DeliveryProtocol Payload Type . . . . . . . 18
8.1.2. CDNI FCI AcquisitionProtocol Payload Type . . . . . . 17 8.1.2. CDNI FCI AcquisitionProtocol Payload Type . . . . . . 18
8.1.3. CDNI FCI RedirectionMode Payload Type . . . . . . . . 17 8.1.3. CDNI FCI RedirectionMode Payload Type . . . . . . . . 18
8.2. Redirection Mode Registry . . . . . . . . . . . . . . . . 17 8.2. Redirection Mode Registry . . . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
10.1. Normative References . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . 20
10.2. Informative References . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Acknowledgment . . . . . . . . . . . . . . . . . . . 20 Appendix A. Acknowledgment . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
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. This CDN interconnection (CDNI) interconnection of multiple CDNs. This CDN interconnection (CDNI)
can serve multiple purposes, as discussed in [RFC6770], for instance, 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 to extend the reach of a given CDN to areas in the network which are
not covered by this particular CDN. 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 15 skipping to change at page 13, line 15
It is not feasible to enumerate all the possible options for the It is not feasible to enumerate all the possible options for the
mandatory capabilities listed above (e.g., all the potential delivery mandatory capabilities listed above (e.g., all the potential delivery
protocols or metadata options) or anticipate all the future needs for protocols or metadata options) or anticipate all the future needs for
additional capabilities. It would be unreasonable to burden the CDNI additional capabilities. It would be unreasonable to burden the CDNI
FCI specification with defining each supported capability. Instead, FCI specification with defining each supported capability. Instead,
the CDNI FCI specification SHOULD define a generic protocol for the CDNI FCI specification SHOULD define a generic protocol for
conveying any capability information (e.g. with common encoding, conveying any capability information (e.g. with common encoding,
error handling, and security mechanism; further requirements for the error handling, and security mechanism; further requirements for the
CDNI FCI Advertisement Interface are listed in [RFC7337]). In this CDNI FCI Advertisement Interface are listed in [RFC7337]). In this
respect, it seems reasonable to define a registry which initially respect, it seems reasonable to initially define the mandatory
contains the mandatory capabilities listed above, but can be extended capabilities listed above and extend the list as needs dictate. This
as needs dictate. This document defines the registry (and the rules document registers CDNI Payload Types [RFC7736] for the mandatory
for adding new entries to the registry) for the different capability capability types (see Section 8), prefixing each payload type with
types (see Section 8). Each capability type MAY have a list of valid "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 values. Future specifications which define a given capability MUST
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 record-types" registry [I-D.ietf-cdni-logging]
logging fields, including mandatory-to-implement logging fields. defines all known record types, including mandatory-to-implement
Advertising support for mandatory-to-implement logging fields SHOULD record-types Advertising support for mandatory-to-implement record-
be supported but would be redundant. CDNs SHOULD NOT advertise types would be redundant. CDNs SHOULD NOT advertise support for
support for mandatory-to-implement logging fields. The following mandatory-to-implement record-types.
logging fields are defined as optional in the CDNI Logging Interface
document [I-D.ietf-cdni-logging]: 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-ccid
o s-sid o s-sid
The CDNI Metadata Interface document [I-D.ietf-cdni-metadata] does The CDNI Metadata Interface document [I-D.ietf-cdni-metadata]
not define any optional GenericMetadata types. Advertising support requires that CDNs be able to parse all the defined metadata objects,
for mandatory-to-implement GenericMetadata types SHOULD be supported. but does not require dCDNs to support enforcement of non-structural
Advertisement of mandatory-to-implement GenericMetadata MAY be GenericMetadata objects. Advertising support for mandatory-to-
necessary, e.g., to signal temporary outages and subsequent recovery, enforce GenericMetadata types MUST be supported. Advertising support
however, it is expected that mandatory-to-implement GenericMetadata for non-mandatory-to-enforce GenericMetadata types SHOULD be
will be supported and available in the typical case. In the typical supported. Advertisement of non-mandatory-to-enforce GenericMetadata
case, advertising support for mandatory-to-implement GenericMetadata MAY be necessary, e.g., to signal temporary outages and subsequent
would be redundant, therefore, CDNs SHOULD NOT advertise support for recovery. It is expected that structural metadata will be supported
mandatory-to-implement GenericMetadata types by default. at all times.
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 might not support all kinds of footprint that certain implementations might 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 MUST specify how protocol. In particular, any FCI solution protocol MUST specify how
to handle failure cases or non-supported types of footprint/ to handle failure cases or non-supported types of footprint/
skipping to change at page 15, line 10 skipping to change at page 15, line 19
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.
Property: footprints
Description: CDNI Capability Footprint.
Type: List of CDNI Footprint objects (as defined in
[I-D.ietf-cdni-metadata]).
Mandatory-to-Specify: No.
7.2. Delivery Protocol Capability Object 7.2. Delivery Protocol Capability Object
The Delivery Protocol capability object is used to indicate support The Delivery Protocol capability object is used to indicate support
for one or more of the protocols listed in the CDNI Metadata Protocol for one or more of the protocols listed in the CDNI Metadata Protocol
Types registry (defined in the CDNI Metadata Interface document Types registry (defined in the CDNI Metadata Interface document
[I-D.ietf-cdni-metadata]). [I-D.ietf-cdni-metadata]).
Property: delivery-protocols Property: delivery-protocols
Description: List of supported CDNI Delivery Protocols. Description: List of supported CDNI Delivery Protocols.
skipping to change at page 16, line 14 skipping to change at page 17, line 8
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
7.5. Capability Advertisement Object Serialization 7.5. Capability Advertisement Object Serialization
The following shows an example of CDNI FCI Capability Advertisement The following shows an example of CDNI FCI Capability Advertisement
Object Serialization. Object Serialization.
{ {
"capabilities": [ "capabilities": [
{ {
"capability-type": "FCI.DeliveryProtocol" "capability-type": "FCI.DeliveryProtocol",
"capability-value": { "capability-value": {
"delivery-protocols": [ "delivery-protocols": [
"http1.1" "http1.1"
] ]
} },
"footprints": [
<Footprint objects>
]
}, },
{ {
"capability-type": "FCI.AcquisitionProtocol" "capability-type": "FCI.AcquisitionProtocol",
"capability-value": { "capability-value": {
"acquisition-protocols": [ "acquisition-protocols": [
"http1.1", "http1.1",
"https1.1" "https1.1"
] ]
} }
}, },
{ {
"capability-type": "FCI.RedirectionMode" "capability-type": "FCI.RedirectionMode",
"capability-value": { "capability-value": {
"redirection-modes": [ "redirection-modes": [
"DNS-I", "DNS-I",
"HTTP-I" "HTTP-I"
] ]
} }
} }
] ]
} }
skipping to change at page 19, line 20 skipping to change at page 20, line 20
for HTTP as per [RFC2818] and [RFC7230], with usage guidance from for HTTP as per [RFC2818] and [RFC7230], with usage guidance from
[RFC7525]). There is no apparent need for further object-level [RFC7525]). There is no apparent need for further object-level
security in this framework, as the trust relationships it defines are security in this framework, as the trust relationships it defines are
bilateral relationships between uCDNs and dCDNs rather than bilateral relationships between uCDNs and dCDNs rather than
transitive relationships. transitive relationships.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-cdni-metadata]
Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma,
"CDN Interconnection Metadata", draft-ietf-cdni-
metadata-15 (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>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000, DOI 10.17487/RFC2818, May 2000,
<http://www.rfc-editor.org/info/rfc2818>. <http://www.rfc-editor.org/info/rfc2818>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
skipping to change at page 19, line 50 skipping to change at page 21, line 10
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <http://www.rfc-editor.org/info/rfc7525>. 2015, <http://www.rfc-editor.org/info/rfc7525>.
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-24 (work in progress), April 2016. 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-13 (work in progress), March 2016.
[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem Distribution Network Interconnection (CDNI) Problem
Statement", RFC 6707, DOI 10.17487/RFC6707, September Statement", RFC 6707, DOI 10.17487/RFC6707, September
2012, <http://www.rfc-editor.org/info/rfc6707>. 2012, <http://www.rfc-editor.org/info/rfc6707>.
[RFC6770] Bertrand, G., Ed., Stephan, E., Burbridge, T., Eardley, [RFC6770] Bertrand, G., Ed., Stephan, E., Burbridge, T., Eardley,
P., Ma, K., and G. Watson, "Use Cases for Content Delivery P., Ma, K., and G. Watson, "Use Cases for Content Delivery
Network Interconnection", RFC 6770, DOI 10.17487/RFC6770, Network Interconnection", RFC 6770, DOI 10.17487/RFC6770,
November 2012, <http://www.rfc-editor.org/info/rfc6770>. November 2012, <http://www.rfc-editor.org/info/rfc6770>.
 End of changes. 16 change blocks. 
49 lines changed or deleted 72 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/