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]