Internet DRAFT - draft-manning-cdni-additional-csf-reqs
draft-manning-cdni-additional-csf-reqs
Internet Engineering Task Force S. Manning
Internet Draft Huawei
Intended status: Informational R. Streijl
Expires: April 2012 V. Prasad
P. Tarapore
AT&T
M. Geller
Cisco
R. Krishnan
Brocade
October 21, 2011
Additional Content Distribution Network Interconnection (CDNI)
Requirements Based on ATIS CSF
draft-manning-cdni-additional-csf-reqs-00
Abstract
The purpose of Content Delivery Networks (CDNs) is to deliver
content to end users in an efficient manner from the perspective of
the network providers and with consistently good performance from
the perspective of the end user. Due to footprint limitations of a
single network provider, it may be necessary to interconnect CDNs
between different providers. The Content Distribution Network
Interconnection (CDNI) working group has been chartered to develop
an interoperable and scalable solution for such CDN interconnection.
The requirements for CDN interconnection are being discussed and
developed in various industry forums. One example is the Alliance
for Telecommunications Industry Solutions (ATIS) Cloud Services
Forum (CSF) which is looking at CDN interconnection requirements
from the perspective of telecom providers. This document introduces
some additional requirements to be included in the CDNI working
group based on conclusions reached by ATIS CSF. The goal is for
specifications developed by CDNI to successfully support some of the
needs expressed by ATIS CSF as interpreted by the authors of this
document.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
Manning, et al. Expires April 21, 2012 [Page 1]
Internet-Draft Additional CDNI Reqs October 2011
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 21, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction...................................................3
2. Requirements Language..........................................3
3. Logging Interface Requirements.................................4
3.1. Logging Failures..........................................4
3.2. Storage Resources.........................................4
3.3. Performance Information...................................5
3.4. Delete Requests...........................................5
3.5. Extensible Information Fields.............................6
4. Control Interface Requirements.................................6
4.1. Deletion of Objects.......................................6
4.2. Reservation of Resources..................................7
5. Security Considerations........................................8
6. IANA Considerations............................................8
Manning, et al. Expires April 21, 2012 [Page 2]
Internet-Draft Additional CDNI Reqs October 2011
7. References.....................................................8
7.1. Normative References......................................8
7.2. Informative References....................................8
8. Acknowledgments................................................8
1. Introduction
[I-D.ietf-cdni-use-cases] and [I-D.ietf-cdni-requirements] describe
the majority of use cases and requirements needed for the
development of CDN interconnection specifications. This document
introduces some additional requirements based on the conclusions
reached by the Alliance for Telecommunications Industry Solutions
(ATIS) Cloud Services Forum (CSF) which is looking at CDN
interconnection requirements from the perspective of telecom
providers. Based on the ATIS specification [CSF] as well as analysis
and discussions within CSF, the authors have captured requirements
suitable for the CDNI working group in this document.
Although working on largely the same problem area, ATIS CSF has a
wider scope than the CDNI working group and considers interactions
between Content Service Providers (CSPs) and CDNs as well as
examining interface "domains" that include Operations & Customer
Care (establishment of SLAs), Back Office (provisioning and
charging), and aspects of the "data plane" [2]. Therefore, some of
the ATIS CSF use cases and requirements fall outside the solution
scope of the CDNI working group. However, some ATIS CSF
requirements, especially in the CDNI logging and control interfaces,
are well matched to the CDNI solution scope. The hope is that the
inclusion of the appropriate requirements in this document will
allow the CDNI working group specifications to support the ATIS
community and help foster aligned solutions to the common CDNI
problem. This will benefit the CDN community and encourage wider
adoption of IETF CDNI standards.
2. Requirements Language
The key words "High Priority", "Medium Priority" and "Low Priority"
in this document are to be interpreted in the following way:
o "High Priority" indicates requirements that are to be supported
by the CDNI interfaces. A requirement is stated as "High
Priority" when it is established by the working group that it
can be met without compromising the targeted schedule for WG
deliverables, or when it is established that specifying a
solution without meeting this requirement would not make sense
and would justify re-adjusting the WG schedule, or both. This
is tagged as "[HIGH]".
Manning, et al. Expires April 21, 2012 [Page 3]
Internet-Draft Additional CDNI Reqs October 2011
o "Medium Priority" indicates requirements that are to be
supported by the CDNI interfaces unless the WG realizes at a
later stage that attempting to meet this requirement would
compromise the overall WG schedule (for example it would
involve complexities that would result in significantly
delaying the deliverables). This is tagged as "[MED]".
o "Low Priority" indicates requirements that are to be supported
by the CDNI interfaces provided that dedicating WG resources to
this work does not prevent addressing "High Priority" and
"Medium Priority" requirements and that attempting to meet this
requirement would not compromise the overall WG schedule. This
is tagged as "[LOW]".
3. Logging Interface Requirements
3.1. Logging Failures
One of ATIS CSF explicit requirements is for the logging interface
to record individual actions on content items which includes
unsuccessful deliveries. See [CSF] section 7.1.2, requirement R1.
This leads to the following additional CDNI requirements:
LOG-A1 [HIGH] The CDNI Logging interface shall support logging of
incomplete deliveries to User Agents performed by the
Downstream CDN as a result of request redirection by the
Upstream CDN.
LOG-A2 [MED] In the case of cascaded CDNs, the CDNI Logging
interface shall support the Downstream CDN for reporting
to the Upstream CDN logging for incomplete deliveries
performed by the Downstream CDN itself as well as logging
for incomplete deliveries performed by cascaded CDNs on
behalf of the Downstream CDN.
3.2. Storage Resources
ATIS CSF requirements for the logging interface include the use of
storage resources in the dCDN when such resources are requested by
the uCDN. This is primarily useful for pre-positioning content. See
[CSF] section 7.1.4, requirement R4 and R11. This leads to the
following additional CDNI requirements:
Manning, et al. Expires April 21, 2012 [Page 4]
Internet-Draft Additional CDNI Reqs October 2011
LOG-A3 [MED] The CDNI Logging interface shall support logging of
storage resources to the upstream CDN for deliveries where
content is stored by the downstream CDN for delivery to
User Agents. The information logged may include the type
of storage (e.g., Origin, Intermediate, Edge, Cache) as
well as the amount of storage (e.g., total GB, GB used,
per time period, per content domain) all of which may
impact the cost of the services.
LOG-A4 [MED] In the case of cascaded CDNs, the CDNI Logging
interface shall support the Downstream CDN to report
storage resources to the Upstream CDN where content is
stored by the Downstream CDN itself as well as logging for
storage resources when content storage is performed by
cascaded CDNs on behalf of the Downstream CDN.
LOG-A5 [MED] The CDNI Logging interface shall support the
upstream CDN to request the downstream CDN to return
information on storage resources to the upstream CDN for
deliveries where content is currently being stored by the
downstream CDN for delivery to User Agents.
3.3. Performance Information
ATIS CSF requirements for the logging interface includes the
reporting of performance statistics between the CDNs. This is
especially important for monitoring common data traffic such as HTTP
streaming sessions. See [CSF] section 7.1.2, requirement R6. This
leads to the following additional CDNI requirement:
LOG-A6 [MED] The CDNI Logging interface shall support logging of
performance data for deliveries to User Agents performed
by the Downstream CDN as a result of request redirection
by the Upstream CDN. Performance data may include various
traffic statistics (the specific parameters are to be
determined). The Logging interface shall support the
upstream CDN to indicate the nature and contents of the
performance data to be reported by the downstream CDN.
3.4. Delete Requests
ATIS CSF requirements for the logging interface includes recording
explicit deletions of content (e.g., over the control interface).
This leads to the following additional CDNI requirement:
LOG-A7 [HIGH] The CDNI Logging interface shall support logging of
deleted objects from the downstream CDN to the upstream
Manning, et al. Expires April 21, 2012 [Page 5]
Internet-Draft Additional CDNI Reqs October 2011
CDN as a result of explicit delete requests on via the
Control interface from the upstream CDN.
3.5. Extensible Information Fields
ATIS CSF requirements for the logging interface involves
extensibility in the protocol to support implementation dependent
information. See [CSF] section 7.1.2, requirement R2. This leads to
the following additional CDNI requirements:
LOG-A8 [HIGH] The CDNI Logging interface shall support
extensibility to allow proprietary information fields to
be carried. These information fields must be agreed upon
ahead of time between the corresponding CDNs.
LOG-A9 [HIGH] The CDNI Logging interface shall support the
exchange of extensible log file formats to support
proprietary information fields. These information fields
must be agreed upon ahead of time between the
corresponding CDNs.
4. Control Interface Requirements
4.1. Deletion of Objects
The uCDN may explicitly command the dCDN to delete certain content
objects. ATIS CSF views that the deletion of objects is particular
sensitive to CDN providers and the interface operation needs some
clarifications. For example, it might take some finite amount of
time to process deletions in the dCDN. During this time, the uCDN
may assume that the dCDN will continue to deliver the content marked
for deletion. But once the delete acknowledgement is received, the
uCDN should be certain that no more deliveries will take place out
of the dCDN and all copies of the content have been completely
removed. The following CDNI requirement makes these assumptions
clear:
CNTL-A1 [HIGH] The CDNI Control interface shall support the
process by which the uCDN receives confirmation that the
deletion of all copies of content have been done by the
dCDN upon request by the uCDN. The confirmation receipt
should be supported through a synchronous and/or
asynchronous mechanism and should include a success or
failure indication. The failure indication is used if the
dCDN cannot delete the content.
Manning, et al. Expires April 21, 2012 [Page 6]
Internet-Draft Additional CDNI Reqs October 2011
Another situation is where an object is made up of a collection of
sub-objects. The dCDN may fail to delete the entire object. In this
case, a partial delete indication should be sent to the uCDN
specifying which sub-objects were successfully deleted. The
following CDNI requirement makes this clear:
CNTL-A2 [MED] The CDNI Control interface should support the
Downstream CDN to indicate to the Upstream CDN a list of
sub-objects that were successfully deleted and a list of
sub-objects that were unsuccessfully deleted in the case
of an object made up of a collection of sub-objects was
not fully deleted by the Downstream CDN.
Finally, there is the case where an uCDN wishes to purge all content
associated with a particular dCDN without issuing multiple delete
requests for each and every content object. The CDN pair, however,
continues to have a business relationship and therefore may elect to
maintain the established CDNI session. The following CDNI
requirement supports this:
CNTL-A3 [MED] The CDNI Control interface should support the
Upstream CDN to efficiently request that the Downstream
CDN that all content stored in the Downstream CDN on
behalf of the Upstream CDN be deleted without enumeration
of each individual object. Further, a single delete
request may operate across many objects based on
parameters such as content type, content provider name,
content domain, etc.
4.2. Reservation of Resources
ATIS CSF has requirements for the uCDN to ask the dCDN to reserve
bandwidth/storage resources in anticipation of content deliveries.
For example, this may be important for the delivery of live
streaming content. This is seen in [CSF] section 7.2.3, requirement
R12. The following CDNI requirement supports this:
CNTL-A4 [MED] The CDNI Control interface shall support the
Upstream CDN to request that the Downstream CDN to reserve
capacity at some future time in terms of streaming
bandwidth between the CDNs and/or storage resources in the
downstream CDN prior to content delivery.
Manning, et al. Expires April 21, 2012 [Page 7]
Internet-Draft Additional CDNI Reqs October 2011
5. Security Considerations
This document adds no additional security considerations beyond
those found in [I-D.ietf-cdni-use-cases] and [I-D.ietf-cdni-
requirements].
6. IANA Considerations
This document makes no request of IANA.
7. References
7.1. Normative References
[I-D.ietf-cdni-requirements]
K. Leung, K. and Lee Y. (Editors), "Content Distribution
Network Interconnection (CDNI) Requirements", draft-ietf-
cdni-requirements-00 (work in progress), September 2011.
[I-D.ietf-cdni-use-cases]
Bertrand, G. (Editor), Stephan, E., Watson, G.,
Burbridge, T., Eardley, P., and Ma, K., "Use Cases for
Content Delivery Network Interconnection", draft-ietf-
cdni-use-cases-00 (work in progress), September 2011.
7.2. Informative References
[CSF] Tarapore, P. and Munson G. (Editors), "CDN Interconnection
Use Case Specification and High Level Requirements",
Alliance for Telecommunications Industry Solutions: ATIS-
0200003, June 2011.
8. Acknowledgments
The authors wish to thank Gary Munson, Andrew White, Spencer
Dawkins, and Jincheng Li, as well as the members of the ATIS Cloud
Services Forum for their discussions and input.
Authors' Addresses
Serge Manning
Huawei US Research Center
Plano, TX
Email: sergem913@gmail.com
Manning, et al. Expires April 21, 2012 [Page 8]
Internet-Draft Additional CDNI Reqs October 2011
Robert Streijl
AT&T
Chicago, IL
Email: rs0608@att.com
Vishwa Prasad
AT&T
Middletown, NJ
Email: vp2613@att.com
Percy Tarapore
AT&T
Middletown, NJ
Email: pt5947@att.com
Mike Geller
Cisco Systems
Email: mgeller@cisco.com
Ramki Krishnan
Brocade Communications
San Jose, CA
Email: ramk@brocade.com
Manning, et al. Expires April 21, 2012 [Page 9]
