idnits 2.17.1 draft-ni-cdni-criteria-metadata-extension-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 are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. 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 9, 2012) is 4302 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2616' is defined on line 362, but no explicit reference was found in the text == Unused Reference: 'RFC3986' is defined on line 366, but no explicit reference was found in the text == Unused Reference: 'I-D.draft-cdni-problem-statement' is defined on line 372, but no explicit reference was found in the text == Unused Reference: 'I-D.draft-cdni-requirements' is defined on line 376, but no explicit reference was found in the text == Unused Reference: 'I-D.davie-cdni-framework' is defined on line 379, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- No information found for draft-cdni-problem-statement - is the name correct? -- No information found for draft-cdni-requirements - is the name correct? == Outdated reference: A later version (-01) exists of draft-davie-cdni-framework-00 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CDNI Working Group Wei Ni 2 Internet Draft Yana Bi 3 Intended status: Standards Track Yunfei Zhang 4 Expires: January 2013 China Mobile 5 July 9, 2012 7 CDNI Delivery Criteria Metadata Extension for Mobile Network 9 draft-ni-cdni-criteria-metadata-extension-00.txt 11 Status of this Memo 13 This Internet-Draft is submitted in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on January 9, 2013. 34 Copyright Notice 36 Copyright (c) 2012 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with 44 respect to this document. Code Components extracted from this 45 document must include Simplified BSD License text as described in 46 Section 4.e of the Trust Legal Provisions and are provided without 47 warranty as described in the Simplified BSD License. 49 Abstract 51 In CDNI deployment, the downstream CDN may probably delivers 52 content to mobile devices, which is served by cellular networks 53 (e.g., 2G, 3G). The purpose of this document is to provide some 54 complement to the delivery criteria in current Metadata Interface 55 with a more precise criteria model, which is in consideration of 56 content delivery service to mobile devices. 58 Table of Contents 60 1. Introduction ................................................ 3 61 1.1. Terminology ............................................ 3 62 1.2. Abbreviations .......................................... 3 63 2. Conventions used in this document ........................... 3 64 3. Internet Gateway in Mobile Network .......................... 4 65 4. CDNI with Mobile Access Scenario ............................ 5 66 5. Delivery Criteria in Metadata Interface ..................... 8 67 6. Security Considerations ..................................... 9 68 7. IANA Considerations ......................................... 9 69 8. References ................................................. 10 70 8.1. Normative References .................................. 10 71 8.2. Informative References ................................ 10 72 9. Acknowledgments ............................................ 11 74 1. Introduction 76 In some CDNI deployment, the downstream CDN may probably deliver 77 content to mobile devices, which serves by 2G/3G cellular networks. 78 In some cases, the User Agent is connected to CDN's surrogate via an 79 intermediate gateway (eg., WAP Gateway and Internet Gateway). 81 The metadata interface is defined by several CDNI documents, such as 82 [draft-caulfield-cdni-metadata-core-00], [draft-liu-cdni-metadata- 83 interface-01], and [draft-jenkins-cdni-metadata-00]. For the reason 84 of copyright protection, CSPs often need to restrict content access 85 to users in certain regions (e.g., within a given country or through 86 a given access network). The delivery criteria metadata provides a 87 list of valid source IP subnets from which content requests may be 88 accepted. However, few considerations have been made for mobile 89 network. This document focuses on the delivery criteria in the 90 metadata interface. It enables a downstream CDN to obtain more 91 information about cellular network, so that the downstream CDN can 92 properly process and respond to content request from mobile devices. 94 1.1. Terminology 96 This document reuses the terminology defined in [I-D.draft-cdni- 97 problem-statement] and [draft-fmn-cdni-advanced-use-cases-00]. 99 1.2. Abbreviations 101 o UE: User Equipment 102 o MSISDN: Mobile Subscriber ISDN Number 103 o APN: Access Point Name 104 o WAP: Wireless Application Protocol 105 o HLR: Home Location Register 107 2. Conventions used in this document 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC-2119 [RFC2119]. 113 3. Internet Gateway in Mobile Network 115 In cellular network, some mobile devices are not powerful enough to 116 render and process web pages built for desktop browsers. So WAP 117 Gateway (or Internet Gateway) is extensively deployed as a bridge to 118 ensure the connection and conversion of information between mobile 119 devices and content server. For example, WAP Gateway unpacks all the 120 layers in the stack, translates requests from a wireless protocol to 121 Internet protocols, and compresses the original content into a 122 compact format in order to save bandwidth over the air and reduce 123 the processing requirements for mobile device. With the advent of 124 fast processors, large memory and the deployment of 3G and 4G 125 networks, many mobile devices can directly process web pages and 126 content without WAP Gateway. 128 However, APN identifies the form of access, in most cases one APN 129 setting (i.e. "cmwap" for China Mobile, and "uniwap" for China 130 Unicom) is used for both Internet and WAP access. Users may access 131 different information sources with a single APN. In this condition, 132 all the requests from the mobile devices will be sent to the WAP 133 Gateway. 135 Figure 1 shows a typical end-to-end WAP system in mobile networks. 136 WAP Gateway locates between the mobile network service provider's 137 core network and the content server. 139 +------------+ +---------------+ 140 | WAP Gateway|---------| Content Server| 141 +------------+ +---------------+ 142 | 143 | 144 ,--,--,--. ,--,--,--. 145 ,-' `-. ,-' `-. 146 ( Core Network )---------( Mobile Access ) 147 `-. ,-' `-. Network ,-' 148 `--'--'--' `--'--'--' 149 | 150 | 151 +------------+ 152 | Mobile UE | 153 +------------+ 155 Figure 1 Typical architecture of WAP system in mobile network 157 In addition to the protocol translation and content compression, WAP 158 Gateway can be configured to provide additional information through 159 HTTP headers, for instance the IP address of UE, user's MSISDN, type 160 of mobile network, and even cell ID. 162 The following is an example of HTTP request sent from WAP Gateway to 163 content server. The x-forwarded-for header field specifies the UE's 164 IP address assigned by the mobile core network. The x-up-calling- 165 line-id header field specifies user's MSISDN. 167 GET /articles/news/default.aspx HTTP/1.1 168 Accept: */* 169 Accept-Language: en-us 170 Connection: Keep-Alive 171 Host: wap.monternet.com 172 Referer: http:// wap.monternet.com/default.jsp 173 Accept-Encoding: gzip, deflate 174 x-CTRL-Req: x_Ctrl_Version =v1.0 175 User-Agent = Nokia5100/2.0 Profile/MIDP-1.0 Configuration/CLDC- 176 1.0 177 x-wap-profile = "http://nds1.nds.nokia.com/uaprof/N6220r100.xml" 178 x-bear-type=GPRS 179 x-forwarded-for=10.18.18.1 180 x-up-calling-line-id =8613912345678 181 x-source-id=192.111.111.1 183 4. CDNI with Mobile Access Scenario 185 In many cases, CDN may deliver content to mobile devices as well as 186 PC. In CDNI deployment, mobile devices can also access the content 187 of CSP via mobile networks and dCDN/uCDN, as depicted in Figure 2. 189 +------+ +------+ +------+ 190 | dCDN |------| uCDN |------| CSP | 191 +------+ +------+ +------+ 192 | 193 | 194 +----------------+ 195 | WAP Gateway | 196 +----------------+ 197 / \ 198 / \ 199 ,--,--,--. ,--,--,--. 200 ,-' `-. ,-' `-. 201 ( Mobile Network )-------( Mobile Network ) 202 `-. ,-' `-. ,-' 203 `--'--'--' `--'--'--' 204 | | 205 | | 206 +------------+ +------------+ 207 | Mobile UE | | Mobile UE | 208 +------------+ +------------+ 210 Figure 2 Content access via mobile networks in CDNI deployment 212 Scenario 1: 214 During packet switch attachment, mobile device is assigned an IP 215 address by the entities of core network (i.e. GGSN or PDSN). For 216 different configurations of APN, the IP address could be either 217 public or private. As mentioned before, WAP Gateway is the 218 aggregation point of all requests from mobile devices. It provides a 219 Network Address Translator function that maps the mobile device's IP 220 address and port number combination to a public IP address and port 221 number. In this condition, the downstream CDN receives content 222 request from the WAP Gateway's IP address. The IP address of mobile 223 devices assigned by mobile core network cannot be seen by dCDN. 225 Typically, the amount of WAP gateway is much less than that of the 226 Core Network entities (i.e. GGSN and PDSN). In real deployments, 227 several GGSN/PDSN is connected to one WAP Gateway. 229 CSPs often need to restrict content access to users in certain 230 regions (e.g., within a given country or through a given access 231 network). In some cases, CSP may need to apply geo-blocking policy 232 with finer granularity (e.g., in province level or city level). So 233 common geo-blocking information (i.e., AS number and IP subnet) 234 cannot provide such kind of location information very well. 236 Scenario 2: 237 MSISDN is the most important numbers used for identifying a mobile 238 subscriber. For data services and applications provided by network 239 operator, MSISDN is usually used as user's default account, so the 240 users do not need to input username and password manually. 242 MSISDN consists of following parts: 243 O CC Country code. 244 O NDC National destination code. 245 O SN Subscriber number(e.g., H0 H1 H2 H3 A B C D) 247 The first few digits of SN specify HLR Identifier, which is also 248 used to provide user's area information. An assignment example in 249 China Mobile is shown in Table 1. 250 +-------------+---------------+---------------+ 251 | Case No. | Area Code | Location/City | 252 | | | | 253 +-------------+---------------+---------------+ 254 | 1 | 0101 | Beijing | 255 +-------------+---------------+---------------+ 256 | 2 | 0201 | Tianjin | 257 +-------------+---------------+---------------+ 258 | 3 | 0301 | Shenzhen | 259 +-------------+---------------+---------------+ 260 | 4 | 0401 | Shenyang | 261 +-------------+---------------+---------------+ 262 | 5 | 0501 | Zhangzhou | 263 +-------------+---------------+---------------+ 264 | 6 | 0601 | Xiamen | 265 +-------------+---------------+---------------+ 266 | 7 | 0801 | Chengdu | 267 +-------------+---------------+---------------+ 268 | 8 | 0901 | Guangzhou | 269 +-------------+---------------+---------------+ 270 Table 1. Area code assignment example 272 In some cases, CSPs need t apply blocking policy using MSISDN 273 information. In this condition, MSISDN should be taken into 274 consideration for precise control policy. Even roaming to other area, 275 a mobile user can still have right to access the content. 277 5. Delivery Criteria Extension 279 The CDNI Metadata interface allows signaling of content distribution 280 control policies, such as geo-blocking information, availability 281 windows, and delegation whitelist/blacklist. To achieve more precise 282 control of blocking policy for mobile network, more information 283 should be able to convey via in-band mechanisms, and be considered 284 by the downstream CDN when delivering content to users. 286 The Delivery Criteria object specifies a set of criteria to match 287 against incoming content requests including protocol, region and 288 time window. The Region object specifies a region where the content 289 is either allowed or disallowed. A region may be described in 290 several ways, only one of which needs to be present per Region 291 object. The object includes the following fields: 292 O country - a string containing the country code for the region. 293 O bgpAs - a number containing the BGP AS identifier of the region. 294 O subnet - a string containing a dotted decimal IP address and 295 subnet mask, here the IP address is the source IP address in IP 296 layer. 297 O msdnPrefix - a few digits in MSISDN specifying user's home area 298 information in mobile network. MSISDN should be extracted from HTTP 299 Header by the surrogate of downstream CDN. 300 O subnet2 - a string containing a dotted decimal IP address 301 extracted from the HTTP x-forwarded-for header and the corresponding 302 subnet mask, which specifies the real IP address of mobile devices 303 assigned by mobile core network. The IP address should be extracted 304 from HTTP Header by the surrogate of downstream CDN. 306 If the Region object is set and the IP address or MSISDN of a 307 requesting client does not match any of the metadata listed, the 308 downstream CDN should respond to the content request with a 403 309 Forbidden status code. 311 Example Object 1: 313 "deliveryCriteria" : 314 [ 315 { 316 "region" : { "subnet" : "10.1.0.54/18" }, 317 }, 318 { 319 "protocol" : "http" 320 } 321 ] 323 Example Object2: 325 "deliveryCriteria" : 326 [ 327 { 328 "region" : { "subnet2" : "10.5.31.10/24" }, 329 }, 330 { 331 "protocol" : "http" 332 } 333 ] 335 Example Object3: 337 "deliveryCriteria" : 338 [ 339 { 340 "region" : { "msdnPrefix" : "135038" }, 341 } 342 { 343 "protocol" : "http" 344 } 345 ] 347 6. Security Considerations 349 TBD. 351 7. IANA Considerations 353 This document makes no request of IANA. 355 8. References 357 8.1. Normative References 359 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 360 Requirement Levels", BCP 14, RFC 2119, March 1997. 362 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 363 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 364 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 366 [RFC3986] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 367 Resource Identifiers (URI): Generic Syntax and Semantics", 368 RFC 3986, January 2005. 370 8.2. Informative References 372 [I-D.draft-cdni-problem-statement] 373 "Content Distribution Network Interconnection (CDNI) Problem 374 Statement", B. Niven-Jenkins, F. Le Faucheur, N. Bitar, June, 375 2012. 376 [I-D.draft-cdni-requirements] 377 "Content Distribution Network Interconnection (CDNI) 378 Requirements", K. Leung, Y. Lee, September, 2011. 379 [I-D.davie-cdni-framework] 380 B. Davie, and L. Peterson, "Framework for CDN 381 Interconnection", draft-davie-cdni-framework-00 (work in 382 progress), April 2012. 383 [I-D. caulfield-cdni-metadata-core] 384 M. Caulfield, and K. Leung, " Content Distribution Network 385 Interconnection (CDNI) Core Metadata", draft-caulfield-cdni- 386 metadata-core-00 (work in progress), October, 2011. 388 9. Acknowledgments 390 This document was prepared using 2-Word-v2.0.template.dot. 392 Authors' Addresses 394 Wei Ni 395 China Mobile Communication Corporation 396 niwei@chinamobile.com 398 Yana Bi 399 China Mobile Communication Corporation 400 biyana@chinamobile.com 402 Yunfei Zhang 403 China Mobile Communication Corporation 404 zhangyunfei@chinamobile.com