idnits 2.17.1 draft-stephan-cdni-alto-session-ext-05.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 25 instances of too long lines in the document, the longest one being 8 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 17, 2014) is 3662 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: 'I-D.ietf-appsawg-json-patch' is defined on line 856, but no explicit reference was found in the text == Unused Reference: 'RFC6244' is defined on line 912, but no explicit reference was found in the text == Unused Reference: 'RFC6536' is defined on line 918, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-ietf-cdni-requirements (ref. 'I-D.ietf-cdni-requirements') ** Downref: Normative reference to an Informational RFC: RFC 6707 ** Downref: Normative reference to an Informational RFC: RFC 6770 == Outdated reference: A later version (-16) exists of draft-ietf-alto-deployments-09 == Outdated reference: A later version (-14) exists of draft-ietf-netconf-yang-patch-00 == Outdated reference: A later version (-10) exists of draft-randriamasy-alto-multi-cost-07 -- Obsolete informational reference (is this intentional?): RFC 6536 (Obsoleted by RFC 8341) Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Stephan 3 Internet-Draft Orange 4 Intended status: Standards Track S. Ellouze 5 Expires: October 19, 2014 H-log 6 April 17, 2014 8 ALTO session for CDN Interconnection 9 draft-stephan-cdni-alto-session-ext-05 11 Abstract 13 The selection of a downstream CDN by an upstream CDN is based on 14 multi-dimensional criteria. Various protocols, such as BGP or ALTO, 15 may be used by a downstream CDN to expose content routing information 16 and interconnection preferences to an upstream CDN. The selection of 17 such a protocol is premature as the WG, and especially the Footprint/ 18 Capabilities Design Team, is currently working on this topic. So 19 this draft does not promote the usage of the ALTO protocol for CDN 20 interconnection. It presents the limitations of the current ALTO 21 protocol in the case it would be selected for CDN interconnection. 22 It specifies the mechanism for controlling the session initialization 23 and for limiting the information exchanged. Then it discusses the 24 need of incremental update and proposes to study the usage of Netconf 25 /Yang to provide ALTO server with notifications. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on October 19, 2014. 50 Copyright Notice 52 Copyright (c) 2014 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 This document may contain material from IETF Documents or IETF 66 Contributions published or made publicly available before November 67 10, 2008. The person(s) controlling the copyright in some of this 68 material may not have granted the IETF Trust the right to allow 69 modifications of such material outside the IETF Standards Process. 70 Without obtaining an adequate license from the person(s) controlling 71 the copyright in such materials, this document may not be modified 72 outside the IETF Standards Process, and derivative works of it may 73 not be created outside the IETF Standards Process, except to format 74 it for publication as an RFC or to translate it into languages other 75 than English. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 80 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 81 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 82 2.1. CDN1 views . . . . . . . . . . . . . . . . . . . . . . . 8 83 2.2. CDN2 views . . . . . . . . . . . . . . . . . . . . . . . 8 84 2.3. Map Maintenance . . . . . . . . . . . . . . . . . . . . . 9 85 3. Requirements for an ALTO Session for CDNi . . . . . . . . . . 9 86 3.1. ALTO Information Customization . . . . . . . . . . . . . 9 87 3.2. View download with HTTP GET . . . . . . . . . . . . . . . 10 88 3.3. Initialization of the Session . . . . . . . . . . . . . . 10 89 3.4. Server Discovery . . . . . . . . . . . . . . . . . . . . 10 90 3.5. Asynchronous Maps Update . . . . . . . . . . . . . . . . 11 91 3.6. Information Resource Directory . . . . . . . . . . . . . 11 92 3.7. PID Stability . . . . . . . . . . . . . . . . . . . . . . 11 93 3.8. Scalability . . . . . . . . . . . . . . . . . . . . . . . 12 94 3.9. Performance . . . . . . . . . . . . . . . . . . . . . . . 12 95 3.10. dCDN Traffic Optimization . . . . . . . . . . . . . . . . 12 96 4. Specification of the ALTO Session for CDNi . . . . . . . . . 13 97 4.1. CDNi ALTO session Framework . . . . . . . . . . . . . . . 13 98 4.2. View Configuration . . . . . . . . . . . . . . . . . . . 14 99 4.2.1. PoINT . . . . . . . . . . . . . . . . . . . . . . . . 14 100 4.2.2. View Configuration Examples . . . . . . . . . . . . . 15 101 4.3. Session Configuration Parameters . . . . . . . . . . . . 16 102 4.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 16 103 5. Expected Enhancements . . . . . . . . . . . . . . . . . . . . 16 104 5.1. Asynchronous Updates . . . . . . . . . . . . . . . . . . 16 105 5.2. Incremental Download of the Updates . . . . . . . . . . . 16 106 5.2.1. Level of Details of a Map . . . . . . . . . . . . . . 17 107 5.3. Bi-directional Exchange of Information . . . . . . . . . 17 108 6. Extension for Asynchronous update . . . . . . . . . . . . . . 17 109 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 110 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 111 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 112 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 113 10.1. Normative References . . . . . . . . . . . . . . . . . . 18 114 10.2. Informative References . . . . . . . . . . . . . . . . . 19 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 117 1. Introduction 119 The selection of a downstream CDN by an upstream CDN is based on 120 multi-dimensional criteria. Various protocols, such as BGP or ALTO, 121 may be used by a downstream CDN to expose content routing information 122 and interconnection preferences to an upstream CDN. The selection of 123 such a protocol is premature as the WG, and especially the Footprint/ 124 Capabilities Design Team, is currently working on this topic. So 125 this draft does not promote the usage of the ALTO protocol for CDN 126 interconnection. It presents the limitations of the current ALTO 127 protocol in the case it would be selected for CDN interconnection. 128 It specifies the mechanism for controlling the session initialization 129 and for limiting the information exchanged. Then it discusses the 130 need of incremental update and proposes to study the usage of Netconf 131 /Yang to provide ALTO server with notifications. 133 Currently the ALTO protocol is designed for the communication of 134 network information to untrusted internet applications. In the 135 context of a CDN interconnection (CDNi) there is a certain level of 136 trust, at least enough to mount a subset of the interfaces depicted 137 in [RFC6707]. In practice the level of trust differs with each 138 interconnection. There are situations where a CDNi ALTO server has 139 to exchange information with an ALTO client of an affiliate and with 140 an ALTO client of a competitor (see [RFC6770]). 142 In the first case topology hiding [RFC5693] may not be required. In 143 the second case the operator of a dCDN may consider a fine control of 144 the exposed information. Consequently the ALTO server of a dCDN 145 operator must be able to adapt the information exposed to each uCDN. 147 The document discusses firstly the insightful aspects of such a use 148 cases in section 2. Then in section 3 it presents the motivations 149 for specifying an ALTO session to customize the information exposed 150 in each CDN interconnection. In section 4, it provides a proposal 151 for an appropriate specification of an ALTO session for a CDN 152 interconnection. Then in section 5 it discusses different 153 enhancements of interest to a CDNi ALTO session. Finally in the 154 section it studies the usage of Netconf/Yang works to provide ALTO 155 with server notifications. 157 N.B.: this version of the memo covers only the Network Map. 159 1.1. Terminology 161 The reader must be familiar with the terminology given by the drafts 162 [RFC6707], and [I-D.ietf-cdni-requirements] , and 163 [I-D.ietf-alto-protocol]. 165 The following abbreviations are recalled: 167 dCDN : downstream CDN: The CDN which provide the delivery 168 resource; 170 uCDN : upstream CDN: The CDN which may rely on dCDN server to 171 deliver contents; 173 PID : Provider-defined Network Location Identifier; 175 NSP : Network Service Provider (e.g. ISP connecting End User to 176 Internet); 178 ALTO Information Resource Directory: (Directory): The Information 179 Resource Directory indicates to ALTO Clients which Information 180 Resources are made available by an ALTO Server (section 7.6 181 [I-D.ietf-alto-protocol] ). 183 Following are terms and abbreviations introduced in the document: 185 adCDN: ALTO downstream CDN server; 187 auCDN: ALTO upstream CDN client; 189 PIDs of Interest (PoINT) : The PIDs which are in the scope of an 190 ALTO session or of a view. They may be defined as a list or by a 191 XSLT-like statement (e.g. 'map/*/ipv6'); 193 Costs of Interest (CoINT) : The Costs which are in the scope of an 194 ALTO session or of a view; 196 ALTO Client-Server session: The logical association between an CDNi 197 ALTO Client and an CDNi ALTO server which maintains the context 198 across the ALTO HTTP connections made by the client to the server. 200 View: A view is the set of URIs which provide an auCDN with a mean 201 for downloading the maps reflecting an agreement between an uCDN and 202 a dCDN. A view is defined by PIDs of Interest (PoINT) and Costs of 203 Interest (CoINT). 205 2. Use Cases 207 This section depicts a situation where a dCDN exposes information 208 according to the agreements of each CDN interconnection. The 209 infomation is exposed within an ALTO session based on the current 210 ALTO protocol version. There is not time dependency between the 211 content requests received by the upstream CDN and the information 212 exchanged over the CDNi ALTO interface. 214 To ease the reading, the content of the Network Maps is intentionally 215 limited with regards to real situation. 217 The use case is about a NSP which deployed a CDN named CDN0 over its 218 network and where CDN0 acts as a downstream CDN for two CDNs named 219 CDN1 and CDN2. CDN1 is an affiliate of CDN0. 221 In the figure 1, the network of NSP provides CDN0 with an aggregated 222 view of the routing information. The grouping of the routing 223 information results from the processing of information provided by 224 BGP according to various policies of the NSP (network, content 225 distribution, etc). 227 +----------------------------------+ 228 | NSP | 229 | | 230 | | 231 | +---------+ | 232 | | Network | | 233 | +---------+ | 234 | | | 235 | | | 236 | BGP|Info | 237 | | | 238 | | | 239 | +-------V---------+ | 240 | | Community Tags, | | 241 | |Grouping Policies| | 242 | +-----------------+ | 243 | | | 244 | | | 245 | Routing Information | 246 | | | 247 | | | 248 | +---------V---------+ | 249 | | | | 250 | | CDN0 CDN | | 251 | | | | 252 | +-------------------+ | 253 +----------------------------------+ 255 Figure 1: Internal Routing Information 257 The Figure 2 shows CDN0 acting as a dCDN for CDN1 and CDN2. CDN0 258 ALTO server (adCDN0) filters and sends stable Network and Cost Maps 259 to the uCDN ALTO clients according to its policies and with respect 260 to the peering agreement between the NSP and the operators of CDN1 261 and CDN2. adCDN0 is connected to 2 CDNi ALTO clients named auCDN1 and 262 auCDN2. 264 +-----------------------------------------+ 265 | NSP | 266 | | 267 | | 268 | | 269 +-----------+ |+--------------------+ +--------------+ | 270 | | Cost Map || dCDN ALTO server | | CDN0 | | 271 | uCDN1 |<--------------- adCDN0 | | | | 272 | | || | | | | 273 | ALTO | network Map || | | +----------+ | | 274 | Client |<--------------- +---------------+ | | |Monitoring| | | 275 | | || | | |<---| info | | | 276 +-----------+ || |Interconnection| | | +----------+ | | 277 || | Policies | | | +----------+ | | 278 +-----------+ || | | |<---| | | | 279 | | Cost Map || +---------------+ | | | Routing | | | 280 | uCDN2 |<--------------- | | | Info | | | 281 | | || | | +----------+ | | 282 | ALTO | network Map || | | | | 283 | Client |<--------------- | | | | 284 | | |+--------------------+ +--------------+ | 285 +-----------+ +-----------------------------------------+ 287 Figure 2: CDNs interconnection 289 The Figure 3 presents the internal representation of the Network Map 290 computed by CDN0 ALTO server. 292 "map" : { 293 "PID_DSL" : { 294 "ipv4" : [ 295 "192.0.2.0/24", 296 "198.51.100.0/25" 297 ], 298 "ipv6": [ 299 "2001:db8:0:1::/64", 300 ] 301 }, 302 "PID_FTTH" : { 303 "ipv4" : [ 304 "198.51.100.128/25" 305 ], 306 "ipv6": [ 307 "2001:db8:0:2::/64" 308 ] 309 } 310 } 312 Figure 3: CDN0 internal Network Map 314 2.1. CDN1 views 316 CDN0 and CDN1 agreed that CDN1 needs only the IPv4 view of the 317 Network Map. The Network Map, presented in figure 4, is downloadable 318 by CDN1 at the URI 'http://cdni.alto.example.com/CDN1/networkmap/ 319 ipv4'. 321 "map" : { 322 "PID_DSL" : { 323 "ipv4" : [ 324 "192.0.2.0/24", 325 "198.51.100.0/25" 326 ] 327 }, 328 "PID_FTTH" : { 329 "ipv4" : [ 330 "198.51.100.128/25" 331 ] 332 } 333 } 335 Figure 4: CDN1 IPv4 Network Map view 337 2.2. CDN2 views 339 CDN0 and CDN2 have 2 separate agreements. Both are relative to the 340 geographical extension of CDN2 coverage . The first agreement 341 concerns the exposition of FFTH customers only. The second one 342 covers IPv6 customers only. They are reflected as separated Network 343 Maps. The first Network Map, exposed in figure 5, is downloadable by 344 CDN2 at the URI 'http://cdni.alto.example.com/CDN2/networkmap/FTTH'. 346 "map" : { 347 "PID_FTTH" : { 348 "ipv4" : [ 349 "198.51.100.128/25" 350 ], 351 "ipv6": [ 352 "2001:db8:0:2::/64" 353 ] 354 } 355 } 357 Figure 5: CDN2 FTTH Network Map. 359 The second Network Map, exposed in the figure 6, is downloadable by 360 auCDN2 at the URI 'http://cdni.alto.example.com/CDN2/networkmap/ 361 IPv6'. 363 "map" : { 364 "PID_DSL" : { 365 "ipv6": [ 366 "2001:db8:0:1::/64", 367 ] 368 }, 369 "PID_FTTH" : { 370 "ipv6": [ 371 "2001:db8:0:2::/64" 372 ] 373 } 374 } 376 Figure 6: CDN2 IPv6 Network Map 378 2.3. Map Maintenance 380 auCDN1 and auCDN2 need a mean for maintaining the content of the 381 maps. The ALTO server of CDN0 provides each view with an URI towards 382 a list of the PIDs which were really modified in the last update. 383 Each dCDN can download this information and determine whenever or not 384 it have to update the Network Map of this view again. 386 This is not optimal. Nevertheless it provides an update mechanism 387 based on HTTP GET which contribute to the reduction of both the 388 volume of information exchanged and the processing on each side. 390 3. Requirements for an ALTO Session for CDNi 392 This section motivates the necessity of specifying an ALTO session 393 between a dCDN and a uCDN with adequate features for addressing CDN 394 interconnection requirements. 396 3.1. ALTO Information Customization 398 The current ALTO approach excludes that the Maps exposed by the ALTO 399 server differ according to the client. This is enforced by section 400 7.2.6 of [I-D.ietf-alto-protocol] which recommends ignoring HTTP 401 session parameters and HTTP cookies. 403 CDNi widely differs in such aspects because a dCDN operator must be 404 able to adapt the information exposed to each uCDN according first to 405 its policies and second to its agreements with uCDN. Moreover it is 406 important for a uCDN client to optimize the volume and the relevance 407 of the information received by avoiding downloading unwanted 408 information in order to enhance the performance of the processing of 409 the received data. 411 Consequently the customization of the ALTO interface between an uCDN 412 and a dCDN requires the specification of a minimal set of session 413 parameters. This must be specified inside the CDNi WG to provide a 414 minimal level of interoperabilty amongst CDNs. 416 3.2. View download with HTTP GET 418 Currently [I-D.ietf-alto-protocol] (section 7.6.2 and 7.6.4.1) allows 419 two Information Resources of the Information Resource Directory to 420 match the same view of a map and to be downloadable using either an 421 HTTP POST or a HTTP GET. 423 In the context of ALTO session for CDNi this is not allowed. An view 424 of a map is accessible by an unique URI using HTTP GET request only. 425 The session configuration defines all the information resources that 426 an auCDN can download. 428 3.3. Initialization of the Session 430 The setting of the session between an uCDN and a dCDN reflects their 431 agreements and expectancies. A minimal configuration of the session 432 is required for ensuring an efficient initialization of the 433 interface, for decreasing the service time, increasing the 434 interoperability and improving the security. 436 The exchange of the session configuration parameters can be performed 437 either out-of-band (human settings) or through the CDNi Control 438 interface. In both cases the setting of a CDNi ALTO session requires 439 an agreement between the 2 CDNs operators and a technical description 440 of the session configuration (ALTO server and client addresses, URL, 441 authentication methods, etc.), of the information which can be 442 exchanged (PID of Interest, Cost of interest, level of details of the 443 maps, etc) and of the way the information is exchanged (update 444 method, time-scale for updates, etc ). 446 3.4. Server Discovery 448 The discovery of a dCDN server by a uCDN relies on parameters 449 exchanged out-of-band or on the CDNi Control interface. Consequenty 450 a CDN interconnection does not require any discovery mechanisms like 451 described in [I-D.ietf-alto-server-discovery]. 453 3.5. Asynchronous Maps Update 455 The way the update is implemented is under discussion in the ALTO WG 456 because there is a strong need to optimize the volume of information 457 exchanged during the update and the processing of the information. 458 [I-D.schwan-alto-incr-updates] presents solutions for incremental 459 download where the auCDN download the diff of the Maps. 461 Incremental download does not resolve the case where auCDN require to 462 be informed in real time each time an information changes. In this 463 case, the adCDN must push the updates on the fly in notifications 464 towards the auCDN. 466 3.6. Information Resource Directory 468 Section 7.6 of [I-D.ietf-alto-protocol] requires the availability of 469 Information Resource Directory for exposing the Information Resources 470 (i.e. URIs of the maps). 472 In a CDNi interconnection it is not necessary to provide such 473 directory as the two interconnected CDNs previously agreed on the URI 474 names. Besided, avoiding the exposition of URIs enhances the 475 security of the system (see section 11.5. [I-D.ietf-alto-protocol] 476 ). 478 3.7. PID Stability 480 Currently ALTO servers scramble the prefixes among the PIDs to 481 prevent reverse engineering by ALTO clients ( 482 [I-D.ietf-alto-protocol], section 12.1). 484 CDNi situations differ widely in such aspects. Such nondeterministic 485 semantics is totally unusable by a request routing function of a 486 uCDN, or may lead to suboptimal decision. The dCDN must expose 487 meaningful information to uCDN. Consequently the meaning of the PIDs 488 must not change during the session duration. 490 As described in section 4.1 of 491 [I-D.previdi-cdni-footprint-advertisement] a CDN acquires part of the 492 content routing information from legacy BGP. As given by figure 1, 493 The NSP may use part of the community tags carried by its legacy 494 internal BGP to filter and gather the prefixes in stable groups (see 495 section 5.1.7 of [I-D.ietf-alto-deployments]) that may then by used 496 by its internal CDN [I-D.jenkins-alto-cdn-use-cases]. 498 3.8. Scalability 500 The routing function of an uCDN might not require all the information 501 that an ALTO server of an dCDN might expose. Furthermore, as per 502 nature an uCDN interconnects with several dCDNs, this volume might 503 harm its performance and its reliability [I-D.ietf-alto-deployments]. 505 The same applies for dCDN ALTO server. It must not be overloaded by 506 uCDNs requests. 508 Consequently the CDNi ALTO session will provide dCDN and uCDN with a 509 mean to shape the information to exchange in an interoperable manner. 510 For instance, an uCDN may not want to receive the very last detailed 511 level of the network map of all the dCDNs it is interconnected with; 512 it may not want to receive each update; it may be interested only by 513 one cost type attribute of the Cost Map service, etc. 515 N.B.: The situation will be even worse when the maps will include 516 multi-cost as proposed by ( [I-D.randriamasy-alto-multi-cost] and 517 [I-D.marocco-alto-next] section 3.2) because the size of the maps 518 will increase. 520 3.9. Performance 522 The amount of information to be processed impacts directly the 523 performance of an auCDN. As an example an uCDN does not want to 524 download all the PIDs when it needs only the PIDs of the Endpoints 525 managed directly by each dCDN. Currently, as given by section 7.2.2. 526 of [I-D.ietf-alto-protocol] , this is achieved using HTTP POST 527 querying the ALTO Map Filtering Service or by HTTP GET of pre- 528 generated maps. 530 To optimize the performance the ALTO Map Filtering Service is not 531 exposed. Map filtering is accessible only throught HTTP GET toward 532 pre-generated maps according to the configuration of the session 533 agreed by the CDNs. Consequently the ALTO session configuration must 534 include must include filters (PIDs, cost, etc) to reduce the volume 535 of information exchanged about to the PIDs of Interest (PoINT) and to 536 the Cost of Interest (CoINT) agreed by uCDN and dCDN operators. 537 These filters apply during all the duration of the ALTO session. 539 3.10. dCDN Traffic Optimization 541 Considering that ALTO is about traffic optimization at the 542 application level, in the context of a CDNi interconnection between 543 an uCDN and a dCDN, ALTO is capable of covering the exchange of 544 information from dCDN to uCDN, allowing for the optimization of the 545 delivery at the uCDN side only. In contrast, exchanging information 546 the other way around for allowing delivery optimization at the dCDN 547 level is not addressed yet. 549 Indeed a dCDN is subject to rival uCDNs requesting resources based on 550 information exposed by the dCDN. By exposing their constraints and 551 their needs, the uCDNs requirements are better addressed by dCDNs 552 through a smart resource provisioning and sharing. 554 A uCDN should be able to provide dCDN with information that may help 555 dCDN to optimize it resources. 557 4. Specification of the ALTO Session for CDNi 559 This section specifies the ALTO session for CDNi. 561 4.1. CDNi ALTO session Framework 563 The figure 7 presents the Framework of the ALTO Session for CDN 564 interconnection: 566 The Map filtering logic is represented to reflect the 567 customization of the content of the internal maps to the server 568 according to the scope of the sessions with uCDNs. 570 There are filters to limit the scope of the session with regard to 571 the content of the internal maps content of the server. 573 Network Map and Cost Map are unchanged. Nevertheless session 574 filtering applies to all the information exchanged; 576 It does not require the support of the End point Information 577 Services because an uCDN does not request individual endpoints 578 information to a dCDN. 580 The Sessions Handler maintains the logical association between an 581 uCDN and a dCDN. It controls the session according to the session 582 parameters: It handles the filtering of the network Map and of the 583 Cost Map according the PoINTs and of the CoINTs of the session. 585 The Sessions Handler handles the views given by the configuration 586 of the session. 588 Information Services are accessible through HTTP GET messages 589 only. 591 A dCDN ALTO server does not expose the URIs nor provides an 592 Information Resource Directory. 594 The Map Filtering logic and the sessions handler are similar to 595 the Map Filtering service of the current version of the ALTO 596 protocol. 598 .-------------------------------. 599 | | 600 | .-----------. .-----------. | 601 | | Network | | Cost | | 602 | | Map | | Map | | 603 | | | | | | 604 | `-----------' `-----------' | 605 | | 606 | .-----------. .-----------. | 607 | | Sessions | | Map | | 608 | | Handler | | Filtering | | 609 | | | | logic | | 610 | `-----------' `-----------' | 611 | | 612 `-------------------------------' 614 Figure 5: ALTO Protocol for CDN interconnection 616 4.2. View Configuration 618 Views are similar to pre-generated maps presented in the section 619 7.6.3. of [I-D.ietf-alto-protocol]. Their configurations are local 620 to the ALTO server. 622 The configuration includes a name, a PoINT and a CoINT. A view 623 provides an ALTO CLient with at least 2 Information Resources: the 624 network map associated with the PoINT and the cost map associated 625 with the CoINT. 627 Its definition includes the setting of the URIs towards these pre- 628 generated maps. 630 N.B.: Cost of Interest (CoINT) will be defined in a next version fo 631 the document. 633 4.2.1. PoINT 635 A PoINT applies at the view level. It specifies a local filter tied 636 to an URI which provides the ALTO client with a link to download the 637 ouput of this filter (see examples in section 4.2.2). It applies 638 during all the duration of the session. 640 This filter produces pre-generated maps. The output of the filter is 641 a pre-generated network map and an optionnal pre-generated Network 642 Map Status. The Network Map Status will be specified in a future 643 version of the document. 645 4.2.2. View Configuration Examples 647 Following are the views corresponding to the use case of the section 648 2. 650 { 651 "view" : "ipv4", 652 "point" : { 653 "filter": "map/PID_*/ipv4" , 654 "map" : "http://cdni.alto.example.com/CDN1/networkmap/ipv4" 655 "map_status" : "http://cdni.alto.example.com/CDN1/networkmap/ipv4/status" 656 } 657 "coint" : [] 658 } 660 CDN1 IPv4 view 662 { 663 "view" : "FTTH", 664 "point" : { 665 "filter": "map/PID_FTTH" , 666 "map" : "http://cdni.alto.example.com/CDN2/networkmap/FTTH" 667 "map_status" : "http://cdni.alto.example.com/CDN2/networkmap/FTTH/status" 668 } 669 "coint" : [] 670 } 672 CDN2 FTTH view 674 { 675 "view" : "IPv6", 676 "point" : { 677 "filter": "map/PID_*/IPv6" , 678 "map" : "http://cdni.alto.example.com/CDN2/networkmap/IPv6" 679 "map_status" : "http://cdni.alto.example.com/CDN2/networkmap/ipv6/status" 680 } 681 "coint" : [] 682 } 684 CDN2 IPv6 view 686 4.3. Session Configuration Parameters 688 The agreement between uCDN and dCDN operators defines the 689 configuration set of the ALTO session. The configuration of the ALTO 690 interface between an uCDN and a dCDN requires the exchange of session 691 parameters between the two CDNs operators. This can be performed 692 either out-of-band (by phone call, etc) or through the CDNi Control 693 interface. In both cases the setting of a CDNi ALTO session requires 694 an agreement between the 2 CDNs operators and a technical description 695 of the session configuration (Server addresses, URL, authentication 696 methods, etc.), of the information which can be exchanged (PID 697 filtering, level of details of the maps) and of the way the 698 information is exchanged (update procedure, etc). 700 The session configuration relies on the following parameters: 702 connection: server and client addresses, URL base, authentication 703 methods, etc.; 705 session_filter: The PIDs which are in the scope of the session. 706 The Cost parameters which are in the scope of the session; 708 views: a list of views; 710 4.4. Error Handling 712 Errors are reported using legacy ALTO and HTTP errors. 714 5. Expected Enhancements 716 This section discussed enhancements which might be required to 717 improve a CDNi ALTO session. 719 5.1. Asynchronous Updates 721 In the CDNi context, there are tied interactions between an uCDN and 722 a dCDN interconnected. It requires generally a high level of 723 synchronization of the Maps of the dCDN and of the uCDN. The update 724 mechanism based on HTTP download is sub-optimal when the uCDN 725 requires a real time propagation of the updates. To meet this 726 requirement the adCDN must notify the update to adCDN. 728 5.2. Incremental Download of the Updates 730 Incremental download reduces the volume of the information exchanged. 731 An update based on the diff of JSON file entries is useful but not 732 optimized because it requires the re-processing of the whole map from 733 scratch after each upload. A better approach might consist in 734 defining an update mechanism providing the diff for a grouping of 735 entries such as PIDs. T 737 The drawback is that incremental download does not provide a high 738 level of synchronization of the Maps of the dCDN and of the uCDN. 740 5.2.1. Level of Details of a Map 742 The level of information exchanged between a dCDN ALTO server and a 743 uCDN ALTO client must be customizable in order to decrease the amount 744 of exchanged data while providing the required information. 746 uCDN may not need the full details of each entry map or it may need 747 the details later. 749 Furthermore there are cases where an uCDN needs only the list of the 750 PIDs of dCDN (e.g. the very detail of each PID of a Network Map is 751 available over existing interfaces like BGP). 753 For these reasons an uCDN ALTO client should be allowed to get only 754 the summary of the maps (e.g. the list of the PIDs of a Network Map). 755 This can be achieved by defining additional session configuration 756 parameters which set the level of detail of the maps. 758 5.3. Bi-directional Exchange of Information 760 As Discussed in section 3, there are different aspects requiring a 761 Bi-directionnal exchange of information including: 763 Exposition of uCDN constraints: Allowing an uCDN to inform dCDN 764 about its high level constraints like forecast indications 765 provides dCDN with valuable information for optimizing its 766 resources provisioning; 768 Session Customization: There are situations where an uCDN may 769 require other Views or modify existing Views and where there is a 770 high level of trust between the two CDNs. Consequently the ALTO 771 session might support the modification of the Views by the auCDN. 773 6. Extension for Asynchronous update 775 There are many ways to address the enhancements expected in the 776 section 5. 778 One solution consists in upgrading the HTTP session to a bi- 779 directional protocol and in specifying an asynchronous update 780 mechanism. Netconf [RFC6241] and YANG [RFC6020] works fill this gap. 781 Netconf already include the specification of notifications [RFC6470] 782 based on subscriptions [RFC5277]. Maps update information can be 783 inserted into NETCONF notifications or updated as YANG or JSON patch 784 using the method being specified by the NETCONF WG in the draft 785 [I-D.ietf-netconf-yang-patch]. 787 7. IANA Considerations 789 none. 791 8. Security Considerations 793 This memo defines an ALTO session for CDN interconnection. It 794 specifies a mean to manage finely the information exchanged over the 795 ALTO protocol. By reducing the information exposed it increase the 796 security in general. 798 Performance: 800 The usage of the ALTO services by the client may stress the server. 801 Consequently the volume and the number of these messages may affect 802 the availability and the performance of the ALTO server. 804 Despite the information services provide an uCDN ALTO client with 805 means to control the amount of information downloaded from a dCDN 806 ALTO server it should protect itself from the download of huge 807 network map. 809 Privacy: 811 The extension has less privacy concerns than the current ALTO 812 specification because it does not require the support of the End 813 point Information Services. 815 9. Acknowledgments 817 The authors would like to thank Christian Jacquenet for its feedbacks 818 on preliminary versions of this document. 820 10. References 822 10.1. Normative References 824 [I-D.ietf-alto-protocol] 825 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", draft- 826 ietf-alto-protocol-27 (work in progress), March 2014. 828 [I-D.ietf-cdni-requirements] 829 Leung, K. and Y. Lee, "Content Distribution Network 830 Interconnection (CDNI) Requirements", draft-ietf-cdni- 831 requirements-17 (work in progress), January 2014. 833 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 834 Requirement Levels", BCP 14, RFC 2119, March 1997. 836 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 837 Distribution Network Interconnection (CDNI) Problem 838 Statement", RFC 6707, September 2012. 840 [RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma, 841 K., and G. Watson, "Use Cases for Content Delivery Network 842 Interconnection", RFC 6770, November 2012. 844 10.2. Informative References 846 [I-D.ietf-alto-deployments] 847 Stiemerling, M., Kiesel, S., Previdi, S., and M. Scharf, 848 "ALTO Deployment Considerations", draft-ietf-alto- 849 deployments-09 (work in progress), February 2014. 851 [I-D.ietf-alto-server-discovery] 852 Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and 853 S. Yongchao, "ALTO Server Discovery", draft-ietf-alto- 854 server-discovery-10 (work in progress), September 2013. 856 [I-D.ietf-appsawg-json-patch] 857 Bryan, P. and M. Nottingham, "JSON Patch", draft-ietf- 858 appsawg-json-patch-10 (work in progress), January 2013. 860 [I-D.ietf-netconf-yang-patch] 861 Bierman, A., Bjorklund, M., Watsen, K., and R. Fernando, 862 "YANG Patch Media Type", draft-ietf-netconf-yang-patch-00 863 (work in progress), March 2014. 865 [I-D.jenkins-alto-cdn-use-cases] 866 Niven-Jenkins, B., Watson, G., Bitar, N., Medved, J., and 867 S. Previdi, "Use Cases for ALTO within CDNs", draft- 868 jenkins-alto-cdn-use-cases-03 (work in progress), June 869 2012. 871 [I-D.marocco-alto-next] 872 Marocco, E. and V. Gurbani, "Extending the Application- 873 Layer Traffic Optimization (ALTO) Protocol", draft- 874 marocco-alto-next-00 (work in progress), January 2012. 876 [I-D.previdi-cdni-footprint-advertisement] 877 Previdi, S., Faucheur, F., Faucheur, F., Medved, J., and 878 L. Faucheur, "CDNI Footprint Advertisement", draft- 879 previdi-cdni-footprint-advertisement-02 (work in 880 progress), September 2012. 882 [I-D.randriamasy-alto-multi-cost] 883 Randriamasy, S., Roome, B., and N. Schwan, "Multi-Cost 884 ALTO", draft-randriamasy-alto-multi-cost-07 (work in 885 progress), October 2012. 887 [I-D.schwan-alto-incr-updates] 888 Schwan, N. and B. Roome, "ALTO Incremental Updates", 889 draft-schwan-alto-incr-updates-02 (work in progress), July 890 2012. 892 [NETCONF_YANG_TUT] 893 "Network Conguration Management with NETCONF and YANG", 894 . 897 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 898 Notifications", RFC 5277, July 2008. 900 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 901 Optimization (ALTO) Problem Statement", RFC 5693, October 902 2009. 904 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 905 Network Configuration Protocol (NETCONF)", RFC 6020, 906 October 2010. 908 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 909 Bierman, "Network Configuration Protocol (NETCONF)", RFC 910 6241, June 2011. 912 [RFC6244] Shafer, P., "An Architecture for Network Management Using 913 NETCONF and YANG", RFC 6244, June 2011. 915 [RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF) 916 Base Notifications", RFC 6470, February 2012. 918 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 919 Protocol (NETCONF) Access Control Model", RFC 6536, March 920 2012. 922 Authors' Addresses 924 Emile Stephan 925 Orange 926 2 avenue Pierre Marzin 927 Lannion F-22307 928 France 930 Email: emile.stephan@orange.com 932 Selim Ellouze 933 H-log 934 5 rue Guy Moquet 935 Orsay F-91400 936 France 938 Email: selim.ellouze@h-log.fr