idnits 2.17.1 draft-yang-cdni-rr-foot-cap-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 28, 2012) is 4284 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4288' is defined on line 284, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4288 (Obsoleted by RFC 6838) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CDNi Y. Yang 3 Internet-Draft Yale University 4 Intended status: Informational July 28, 2012 5 Expires: January 29, 2013 7 Service Access/Anchor Point (SAP) Based CDN Capacity/QoE Exposure 8 draft-yang-cdni-rr-foot-cap-00 10 Abstract 12 The objective of the Footprint and Capability Interface of CDNi is to 13 allow a dCDN to expose information to a uCDN so that the uCDN can 14 select a set of dCDN(s) to delivery contents for content publishers. 15 In this draft, we propose a flexible approach for a dCDN to expose 16 its footprint and capabilities based on a generic concept called 17 Service Access or Anchor Point. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC 2119 [RFC2119]. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 29, 2013. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. A Generic CDN QoE Information Base . . . . . . . . . . . . . . 3 61 3. Service Access/Anchor Point Based Information Bases . . . . . . 4 62 4. Additional Information Bases for Request Routing . . . . . . . 6 63 5. Encoding and Transport of Information Bases . . . . . . . . . . 6 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 66 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 69 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 1. Introduction 74 There are many recent studies on the Footprint and Capacity Interface 75 of CDNi. In particular, the semantics draft [] and multiple recent 76 proposals (e.g., He et al. [], Le Louedec et al. [], Previdi et al. 77 [], Seedorf [], Song et al. [], Stephan et al. []) provide much 78 insight on the design of the Capacity and Footprint Interface. In 79 this draft, we outline one potential design direction to motivate 80 more discussions on this important interface. The draft is 81 incomplete and focuses more on the motivation and basic concepts. 83 2. A Generic CDN QoE Information Base 85 Our design is based on the following observations/assumptions: 87 o A major motivation for the adoption of CDN by a Content Publisher 88 is to provide better quality of experiences (QoE). Hence the 89 information exposed by a CDN should include delivery QoE, beyond 90 reachability/willingness. 92 o The QoE provided by a CDN depends on a set of properties of an End 93 User (EU) request. One key property of a request is the network 94 location of the End User (e.g., an IP in North America); another 95 property is the property of the User Agent (e.g., a mobile device 96 vs a desktop device); the other set of properties are from the 97 requested URI (e.g., http, https, rtsp, image, streaming, etc). 99 o The QoE provided by a CDN also depends on how a CDN handles a 100 request. In particular, a CDN may provide differentiated 101 services. For example, a CDN may offer both a Premium service 102 (i.e., high priority) and an Economy service. Different service 103 levels from the same CDN may offer different levels of QoE (or 104 SLA). Advertising different service levels can provide more 105 flexible uCDN selection. 107 Given the preceding observations, we may design that a dCDN, 108 regarding its QoE, offers the following capability/QoE information 109 structure: 111 -> QoE metrics. 113 Figure 1: CDN QoE Raw Table. 115 3. Service Access/Anchor Point Based Information Bases 117 The preceding information structure is quite general, but does not 118 provide enough operational information. In particular, there is no 119 information for a uCDN to direct a request to a chosen dCDN. Below, 120 we consider the domain knowledge of CDN request routing to propose 121 another information structure to convey the same preceding info, with 122 operational information as well. 124 Specifically, a generic conceptual framework of a CDN is that it 125 consists of two types of logical entities: request routers to direct 126 requests around and surrogate servers to actually serve requests. 127 Consider a dCDN with a two-level DNS-based request routing system: a 128 (logical) global DNS request router (say dCDN.com) and multiple 129 (logical) 2nd level DNS request routers (say east.dCDN.com and 130 west.dCDN.com). A request (for example, a DNS name resolution) first 131 arrives at the 1st level request router, who forwards the request to 132 a chosen 2nd level request router (say east.dCDN.com). Since the 133 term request router is too entity-oriented (as we see later), we way 134 that the CDN has three request routing service access/anchor points 135 (RR-SAP) or service access/anchor points (SAP) for short. In other 136 words, in this example, the request to the dCDN's request routing 137 system may visit 3 service access points: 1) protocol=DNS, 138 server=dCDN.com, query=CP DNS name; 2) protocol=DNS, 139 server=east.dCDN.com, query=CP DNS name; and 3) protocol=DNS, 140 server=west.dCDN.com, query=CP DNS name. How a request is forwarded 141 among the three service access points (e.g., hierarchy, consistent 142 hashing) is a CDN's internal structure. 144 To summarize, the framework of CDN RR we use is that a CDN consists 145 of a set of SAPs, and a set of surrogate servers. One may consider 146 surrogate as special case SAPS. The objective of RR is to expose 147 SAPS. 149 With the introduction of the SAP concept, we now specify a 150 capability/footprint information structure based on SAP. In 151 particular, we first introduce two information bases (tables). These 152 information bases provide not only information in the preceding 153 section but offer more info for request routing. 155 o SAP Information Base (SIB): which specifies the information on 156 each SAP. There can be multiple types of SAPs, e.g., DNS resolver 157 SAP, IP Anycast SAP, and HTTP load balancer SAP. The SAP 158 information base specifies information about how to access each 159 revealed SAP, as well as properties (e.g., cap) of each SAP to the 160 uCDN. For example, for a DNS SAP, it can be the DNS name (e.g., 161 east.dCDN.com) or the IP address. There can be additional 162 information on how to protect the access to an SAP. Each SAP also 163 provides an *online (syncrhonous) redirection request point* 164 (e.g., URI). This point may or may not be the same as SAP contact 165 server. To summarize, the SAP Information Base is a mapping: SAP 166 -> SAP name, SAP type, SAP access info. 168 o SAP QoE Information Base (SQIB): which specifies the QoE and 169 capability, depending on the access SAP. In other words, the SAP 170 QoE Information Base is a mapping: -> 171 d2CDN -> d4CDN; and dCDN -> d3CDN -> d4CDN. 227 Then dCDN can define 2 SAPs: SAP-d2CDN-d4CDN and SAP-d3CDN-d4CDN 228 and offer both paths for a uCDN to select. The dCDN may or may 229 not offer shortcuts, as in the preceding example. As a comparison 230 between SAP based specification and BGP, SAP provides an ability 231 for multi-path routing, which can be quite valuable, and BGP 232 cannot (i.e., BGP cannot announce dCDN->d2CDN->IP and 233 dCDN->d3CDN->IP for the same IP, because the data path does not 234 have the mechanism to specify such split. 236 4. Additional Information Bases for Request Routing 238 In addition to SAP Information Base (SIB) and SAP QoE Information 239 Base (SQIB), there are additional information (tables) that if 240 exchanged, can help a uCDN to select dCDNs for request routing. Here 241 are some examples: 243 o GeoMapping Information Base (GIB): a CDN, who owns a subset of 244 IPs, may have more authoritative information on the geolocation of 245 the IP. 247 o Charging Region Information Base (CRIB): Some CDNs (e.g., Amazon) 248 use the concept of charging regions. Then there is the need of 249 End User IP to charging region mapping. 251 5. Encoding and Transport of Information Bases 253 There are multiple ways to encode the aforementioned information 254 bases (SIB, SQIB, GIB, and CRIB). One possibility is to base on the 255 ALTO protocol with extensions. A particular large information that 256 needs to be encoded is SAP QoE Information Base (SQIB). One can use 257 the Network Map and Cost Map (SAP -> PID) to encode the information 258 base, with extensions to handle updates/notification. The details 259 will need to be determined later. The ALTO protocol, the proposed 260 CDNI MetaData, and the proposed CDNI Control are use HTTP Restful 261 Encoding and may form a coherent protocol for CDNI. 263 6. Security Considerations 265 To be added. 267 7. IANA Considerations 269 This document does not have any IANA considerations. 271 8. Acknowledgments 273 To be added. 275 9. References 277 9.1. Normative References 279 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 280 Requirement Levels", BCP 14, RFC 2119, March 1997. 282 9.2. Informative References 284 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 285 Registration Procedures", BCP 13, RFC 4288, December 2005. 287 Author's Address 289 Y. Richard Yang 290 Yale University 292 Email: yry@cs.yale.edu