Network Working Group E. Stephan Internet-Draft S. Ellouze Intended status: Standards Track France Telecom - Orange Expires: January 10, 2013 July 09, 2012 ALTO session for CDN Interconnection draft-stephan-cdni-alto-session-ext-01 Abstract The selection of a downstream CDN by an upstream CDN is based on multi-dimensional criteria such as the number of hops, the performance of the connections between the user-agent and downstream CDNs, the availability of downstream CDNs resources and business policies. Various protocols, such as BGP or ALTO, may be used by a downstream CDN to expose content routing information and interconnection preferences to an upstream CDN. This draft specifies the parameters of an ALTO session between two interconnected CDNs. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 10, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. Stephan & Ellouze Expires January 10, 2013 [Page 1] Internet-Draft CDNi ALTO session July 2012 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. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Stephan & Ellouze Expires January 10, 2013 [Page 2] Internet-Draft CDNi ALTO session July 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. CDN1 views . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2. CDN2 views . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3. Map Maintenance . . . . . . . . . . . . . . . . . . . . . 9 3. Requirements for an ALTO Session for CDNi . . . . . . . . . . 9 3.1. ALTO Information Customization . . . . . . . . . . . . . . 9 3.2. View HTTP GET . . . . . . . . . . . . . . . . . . . . . . 10 3.3. Initialization of the Session . . . . . . . . . . . . . . 10 3.4. Server Discovery . . . . . . . . . . . . . . . . . . . . . 10 3.5. Maps Update . . . . . . . . . . . . . . . . . . . . . . . 10 3.6. Information Resource Directory . . . . . . . . . . . . . . 11 3.7. Redistribution . . . . . . . . . . . . . . . . . . . . . . 11 3.8. PID Stability . . . . . . . . . . . . . . . . . . . . . . 11 3.9. Scalability . . . . . . . . . . . . . . . . . . . . . . . 12 3.10. Performance . . . . . . . . . . . . . . . . . . . . . . . 12 3.11. Heart Beat . . . . . . . . . . . . . . . . . . . . . . . . 13 3.12. dCDN Traffic Optimization . . . . . . . . . . . . . . . . 13 4. Specification of the ALTO Session for CDNi . . . . . . . . . . 13 4.1. ALTO session Framework . . . . . . . . . . . . . . . . . . 13 4.2. View Configuration . . . . . . . . . . . . . . . . . . . . 15 4.2.1. PoINT . . . . . . . . . . . . . . . . . . . . . . . . 15 4.2.2. View Configuration Examples . . . . . . . . . . . . . 15 4.3. Session Configuration Parameters . . . . . . . . . . . . . 16 4.4. Error Handling . . . . . . . . . . . . . . . . . . . . . . 17 5. Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.1. Incremental Update . . . . . . . . . . . . . . . . . . . . 17 5.1.1. Level of Details of a Map . . . . . . . . . . . . . . 18 5.2. Bi-directional Exchange of Information . . . . . . . . . . 18 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 9.2. Informative References . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Stephan & Ellouze Expires January 10, 2013 [Page 3] Internet-Draft CDNi ALTO session July 2012 1. Introduction The selection of a downstream CDN by an upstream CDN is based on multi-dimensional criteria such as the number of hops, the performance of the connections between the user-agent and downstream CDNs, the availability of downstream CDNs resources and business policies. Various protocols, such as BGP or ALTO, may be used by a downstream CDN to expose content routing information and interconnection preferences to an upstream CDN. This draft specifies the parameters of an ALTO session between two interconnected CDNs. Currently the ALTO protocol is designed for the communication of network information to untrusted internet applications. In the context of a CDN interconnection (CDNi) there is a certain level of trust, at least enough to mount a subset of the interfaces depicted in [I-D.ietf-cdni-problem-statement]. In practice the level of trust differs with each interconnection. There are situations where a CDNi ALTO server has to exchange information with an ALTO client of an affiliate and with an ALTO client of a competitor (see [I-D.ietf-cdni-use-cases]). In the first case topology hiding [RFC5693] may not be required. In the second case the operator of a dCDN may consider a fine control of the exposed information. Consequently the ALTO server of a dCDN operator must be able to adapt the information exposed to each uCDN. The document discusses firstly the insightful aspects of such a use cases in section 2. Then in section 3 it presents the motivations for specifying an ALTO session to customize the information exposed in each CDN interconnection. In section 4, it provides a proposal for an appropriate specification of an ALTO session for a CDN interconnection. Finally it discusses different enhancements of interest to a CDNi ALTO session. N.B.: this version of the memo covers only the Network Map. 1.1. Terminology The reader must be familiar with the terminology given by the drafts [I-D.ietf-cdni-problem-statement], and [I-D.ietf-cdni-requirements] , and [I-D.ietf-alto-protocol]. The following abbreviations are recalled: dCDN : downstream CDN: The CDN which provide the delivery resource; Stephan & Ellouze Expires January 10, 2013 [Page 4] Internet-Draft CDNi ALTO session July 2012 uCDN : upstream CDN: The CDN which may rely on dCDN server to deliver contents; PID : Provider-defined Network Location Identifier; NSP : Network Service Provider (e.g. ISP connecting End User to Internet); ALTO Information Resource Directory: (Directory): The Information Resource Directory indicates to ALTO Clients which Information Resources are made available by an ALTO Server (section 7.6 [I-D.ietf-alto-protocol] ). Following are terms and abbreviations introduced in the document: adCDN: ALTO downstream CDN server; auCDN: ALTO upstream CDN client; PIDs of Interest (PoINT) : The PIDs which are in the scope of an ALTO session or of a view. They may be defined as a list or by a XSLT-like statement (e.g. 'map/*/ipv6'); Costs of Interest (CoINT) : The Costs which are in the scope of an ALTO session or of a view; ALTO Client-Server session: The logical association between an CDNi ALTO Client and an CDNi ALTO server which maintains the context across the ALTO HTTP connections made by the client to the server. View: A view is the set of URIs which provide an auCDN with a mean for downloading the maps reflecting an agreement between an uCDN and a dCDN. A view is defined by PIDs of Interest (PoINT) and Costs of Interest (CoINT). 2. Use Cases This section depicts a situation where a dCDN exposes information according to the agreements of each CDN interconnection. The infomation is exposed within an ALTO session based on the current ALTO protocol version. There is not time dependency between the content requests received by the upstream CDN and the information exchanged over the CDNi ALTO interface. To ease the reading, the content of the Network Maps is intentionally limited with regards to real situation. Stephan & Ellouze Expires January 10, 2013 [Page 5] Internet-Draft CDNi ALTO session July 2012 The use case is about a NSP which deployed a CDN named CDN0 over its network and where CDN0 acts as a downstream CDN for two CDNs named CDN1 and CDN2. CDN1 is an affiliate of CDN0. In the figure 1, the network of NSP provides CDN0 with an aggregated view of the routing information. The grouping of the routing information results from the processing of information provided by BGP according to various policies of the NSP (network, content distribution, etc). +----------------------------------+ | NSP | | | | | | +---------+ | | | Network | | | +---------+ | | | | | | | | BGP|Info | | | | | | | | +-------V---------+ | | | Community Tags, | | | |Grouping Policies| | | +-----------------+ | | | | | | | | Routing Information | | | | | | | | +---------V---------+ | | | | | | | CDN0 CDN | | | | | | | +-------------------+ | +----------------------------------+ Figure 1: Internal Routing Information The Figure 2 shows CDN0 acting as a dCDN for CDN1 and CDN2. CDN0 ALTO server (adCDN0) filters and sends stable Network and Cost Maps to the uCDN ALTO clients according to its policies and with respect to the peering agreement between the NSP and the operators of CDN1 and CDN2. adCDN0 is connected to 2 CDNi ALTO clients named auCDN1 and auCDN2. Stephan & Ellouze Expires January 10, 2013 [Page 6] Internet-Draft CDNi ALTO session July 2012 +-------------------------------------------+ | NSP | | | | | | | +-----------+ |+---------------------+ +---------------+ | | | Cost Map || dCDN ALTO server | | CDN0 | | | uCDN1 |<--------------- adCDN0 | | | | | | || | | | | | ALTO | network Map || | | +----------+ | | | Client |<--------------- +---------------+ | | |Monitoring| | | | | || | | |<----| info | | | +-----------+ || |Interconnection| | | +----------+ | | || | Policies | | | +----------+ | | +-----------+ || | | |<----| | | | | | Cost Map || +---------------+ | | | Routing | | | | uCDN2 |<--------------- | | | Info | | | | | || | | +----------+ | | | ALTO | network Map || | | | | | Client |<--------------- | | | | | | |+---------------------+ +---------------+ | +-----------+ +-------------------------------------------+ Figure 2: CDNs interconnection The Figure 3 presents the internal representation of the Network Map computed by CDN0 ALTO server. "map" : { "PID_DSL" : { "ipv4" : [ "192.0.2.0/24", "198.51.100.0/25" ], "ipv6": [ "2001:db8:0:1::/64", ] }, "PID_FTTH" : { "ipv4" : [ "198.51.100.128/25" ], "ipv6": [ "2001:db8:0:2::/64" ] } } Stephan & Ellouze Expires January 10, 2013 [Page 7] Internet-Draft CDNi ALTO session July 2012 Figure 3: CDN0 internal Network Map 2.1. CDN1 views CDN0 and CDN1 agreed that CDN1 needs only the IPv4 view of the Network Map. The Network Map, presented in figure 4, is downloadable by CDN1 at the URI 'http://cdni.alto.example.com/CDN1/networkmap/ipv4'. "map" : { "PID_DSL" : { "ipv4" : [ "192.0.2.0/24", "198.51.100.0/25" ] }, "PID_FTTH" : { "ipv4" : [ "198.51.100.128/25" ] } } Figure 4: CDN1 IPv4 Network Map view 2.2. CDN2 views CDN0 and CDN2 have 2 separate agreements. Both are relative to the geographical extension of CDN2 coverage . The first agreement concerns the exposition of FFTH customers only. The second one covers IPv6 customers only. They are reflected as separated Network Maps. The first Network Map, exposed in figure 5, is downloadable by CDN2 at the URI 'http://cdni.alto.example.com/CDN2/networkmap/FTTH'. "map" : { "PID_FTTH" : { "ipv4" : [ "198.51.100.128/25" ], "ipv6": [ "2001:db8:0:2::/64" ] } } Figure 5: CDN2 FTTH Network Map. The second Network Map, exposed in the figure 6, is downloadable by auCDN2 at the URI 'http://cdni.alto.example.com/CDN2/networkmap/IPv6'. Stephan & Ellouze Expires January 10, 2013 [Page 8] Internet-Draft CDNi ALTO session July 2012 "map" : { "PID_DSL" : { "ipv6": [ "2001:db8:0:1::/64", ] }, "PID_FTTH" : { "ipv6": [ "2001:db8:0:2::/64" ] } } Figure 6: CDN2 IPv6 Network Map 2.3. Map Maintenance auCDN1 and auCDN2 need a mean for maintaining the content of the maps. The ALTO server of CDN0 provides each view with an URI towards a list of the PIDs which were really modified in the last update. Each dCDN can download this information and determine whenever or not it have to update the Network Map of this view again. This is not optimal. Nevertheless it provides an update mechanism based on HTTP GET which contribute to the reduction of both the volume of information exchanged and the processing on each side. 3. Requirements for an ALTO Session for CDNi This section motivates the necessity of specifying an ALTO session between a dCDN and a uCDN with adequate features for addressing CDN interconnection requirements. 3.1. ALTO Information Customization The current ALTO approach excludes that the Maps exposed by the ALTO server differ according to the client . This is enforced by section 7.2.6 of [I-D.ietf-alto-protocol] which recommends ignoring HTTP session parameters and HTTP cookies. CDNi widely differs in such aspects because a dCDN operator must be able to adapt the information exposed to each uCDN according first to its policies and second to its agreements with uCDN. Moreover it is important for a uCDN client to optimize the volume and the relevance of the information received by avoiding downloading unwanted information in order to enhance the performance of the processing of the received data. Stephan & Ellouze Expires January 10, 2013 [Page 9] Internet-Draft CDNi ALTO session July 2012 Consequently the customization of the ALTO interface between an uCDN and a dCDN requires the specification of a minimal set of session parameters. This must be specified inside the CDNi WG to provide a minimal level of interoperabilty amongst CDNs. 3.2. View HTTP GET Currently [I-D.ietf-alto-protocol] (section 7.6.2 and 7.6.4.1) allows 2 Information Resources of the Information Resource Directory to match the same view of a map and to be downloadable using either an HTTP POST or a HTTP GET. In the context of ALTO session for CDNi this is not allowed. An view of a map is accessible by an unique URI using HTTP GET request only. The session configuration defines all the information resources that an auCDN can download. 3.3. Initialization of the Session The setting of the session between an uCDN and a dCDN reflects their agreements and expectancies. A minimal configuration of the session is required for ensuring an efficient initialization of the interface, for decreasing the service time, increasing the interoperability and improving the security. The exchange of the session configuration parameters can be performed either out-of-band (human settings) or through the CDNi Control interface. In both cases the setting of a CDNi ALTO session requires an agreement between the 2 CDNs operators and a technical description of the session configuration (ALTO server and client addresses, URL, authentication methods, etc.), of the information which can be exchanged (PID of Interest, Cost of interest, level of details of the maps, etc) and of the way the information is exchanged (update method, time-scale for updates, etc ). 3.4. Server Discovery The discovery of a dCDN server by a uCDN relies on parameters exchanged out-of-band or on the CDNi Control interface. Consequenty a CDN interconnection does not require any discovery mechanisms like described in [I-D.ietf-alto-server-discovery]. 3.5. Maps Update Maps update is under discussion in the ALTO WG as there is a strong need to optimize the volume of exchanged information and to reduce the duration of the acquisition of the updates. , [I-D.schwan-alto-incr-updates] presents solutions for incremental Stephan & Ellouze Expires January 10, 2013 [Page 10] Internet-Draft CDNi ALTO session July 2012 update (download of update by the client). Another possibility is the specification of a synchronous update procedure where the server pushes the updates on the fly towards the client. Incremental update and synchronous update may not be required for CDN interconnection when the customization of the session leads to a limited amount of information to be exchanged. Nevertheless, the adCDN server must at least provide hints to each auCDN for reducing the volume of exchanged information. If no update mechanism is implemented, each view must include a information resource exposing a summary of the map updates (the list or the number of PIDs which were updated, etc). This approach provides the client logic with enough information to decide whether to re-download the whole map or not (e.g. depending on the importance of the PIDs which were updated). 3.6. Information Resource Directory Section 7.6 of [I-D.ietf-alto-protocol] requires the availability of Information Resource Directory for exposing the Information Resources (i.e. URIs of the maps). In a CDNi interconnection it is not necessary to provide such directory as the two interconnected CDNs previously agreed on the URI names. Besided, avoiding the exposition of URIs enhances the security of the system (see section 11.5. [I-D.ietf-alto-protocol] ). 3.7. Redistribution Redistribution of network Map and Cost Map by an uCDN is forbidden because first it results on the exposition of information exclusively destined to a well defined entity and second others uCDNs must not be flooded with unwished information. The information exposed by dCDN to uCDN reflects only the agreement between the operators of these 2 CDNs only. Hence, redistributing maps content will lead to inconsistency because the semantic of the information differs with the session. As an example a PID name may cover different meaning or content. 3.8. PID Stability Currently ALTO servers scramble the prefixes among the PIDs to prevent reverse engineering by ALTO clients ( [I-D.ietf-alto-protocol], section 12.1). Stephan & Ellouze Expires January 10, 2013 [Page 11] Internet-Draft CDNi ALTO session July 2012 CDNi situations differ widely in such aspects. Such nondeterministic semantics is totally unusable by a request routing function of a uCDN, or may lead to suboptimal decision. The dCDN must expose meaningful information to uCDN. Consequently the meaning of the PIDs must not change during the session duration. As described in section 4.1 of [I-D.previdi-cdni-footprint-advertisement] a CDN acquires part of the content routing information from legacy BGP. As given by figure 1, The NSP may use part of the community tags carried by its legacy internal BGP to filter and gather the prefixes in stable groups (see section 5.1.7 of [I-D.ietf-alto-deployments]) that may then by used by its internal CDN [I-D.jenkins-alto-cdn-use-cases]. 3.9. Scalability The routing function of an uCDN might not require all the information that an ALTO server of an dCDN might expose. Furthermore, as by nature an uCDN interconnects with several dCDNs this volume might harm its performance and its reliability [I-D.ietf-alto-deployments]. The same applies for dCDN ALTO server. It must not be overloaded by dCDNs requests. Consequently the CDNi ALTO session will provide dCDN and uCDN with a mean to shape the information to exchange in an interoperable manner. For instance, an uCDN may not want to receive the very last detailed level of the network map of all the dCDNs it is interconnected with; it may not want to receive each update; it may be interested only by one cost type attribute of the Cost Map service, etc. N.B.: The situation will be even worse when the maps will include multi-cost as proposed by ( [I-D.randriamasy-alto-multi-cost] and [I-D.marocco-alto-next] section 3.2) because the size of the maps will increase. 3.10. Performance The amount of information to be processed impacts directly the performance of an auCDN. As an example an uCDN does not want to download all the PIDs when it needs only the PIDs of the Endpoints managed directly by each dCDN. Currently, as given by section 7.2.2. of [I-D.ietf-alto-protocol] , this is achieved using HTTP POST querying the ALTO Map Filtering Service or by HTTP GET of pre- generated maps. To optimize the performance the ALTO Map Filtering Service is not exposed. Map filtering is accessible only throught HTTP GET toward Stephan & Ellouze Expires January 10, 2013 [Page 12] Internet-Draft CDNi ALTO session July 2012 pre-generated maps according to the configuration of the session agreed by the CDNs. Consequently the ALTO session configuration must include must include filters (PIDs, cost, etc) to reduce the volume of information exchanged about to the PIDs of Interest (PoINT) and to the Cost of Interest (CoINT) agreed by uCDN and dCDN operators. These filters apply during all the duration of the ALTO session. 3.11. Heart Beat Neither the ALTO server nor the ALTO client want the session to be overflooded. A heart beat parameter is needed to control the intensity of the communication for exchanging information over the ALTO session. It provides a hint of the periodicity of the download of the maps by the client (e.g. every minute, hour, day, week, etc). As an example to avoid useless maps download auCDN and adCDN might agreed to set the value of the heart beat to the period of refreshment of the considered maps. 3.12. dCDN Traffic Optimization Considering that ALTO is about traffic optimization at the application level, in the context of a CDNi interconnection between an uCDN and a dCDN, ALTO is capable of covering the exchange of information from dCDN to uCDN, allowing for the optimization of the delivery at the uCDN side only. In contrast, exchanging information the other way around for allowing delivery optimization at the dCDN level is not addressed yet. Indeed a dCDN is subject to rival uCDNs requesting resources based on information exposed by the dCDN. By exposing their constraints and their needs, the uCDNs requirements are better addressed by dCDNs through a smart resource provisioning and sharing. A uCDN should be able to provide dCDN with information that may help dCDN to optimize it resources. 4. Specification of the ALTO Session for CDNi This section specifies the ALTO session for CDNi. 4.1. ALTO session Framework The figure 7 presents the Framework of the ALTO Session for CDN interconnection: Stephan & Ellouze Expires January 10, 2013 [Page 13] Internet-Draft CDNi ALTO session July 2012 The Map filtering logic is represented to reflect the customization of the content of the internal maps to the server according to the scope of the sessions with uCDNs. There are PID and Cost filters to limit the scope of the session with regard to the content of the internal maps content of the server. Network Map and Cost Map are unchanged. Nevertheless the session PIDs and Cost filtering applies to all the information exchanged; It does not require the support of the End point Information Services because an uCDN does not request individual endpoints information to a dCDN. The Sessions Handler maintains the logical association between an uCDN and a dCDN. It controls the session according to the session parameters: It handles the filtering of the network Map and of the Cost Map according the PoINTs and of the CoINTs of the session. The Sessions Handler handles the views given by the configuration of the session. Information Services are accessible through HTTP GET messages only. A dCDN ALTO server does not expose the URIs nor provides an Information Resource Directory. The Map Filtering logic and the sessions handler replace the Map Filtering service of the current version of the ALTO protocol. .-------------------------------. | | | .-----------. .-----------. | | | Network | | Cost | | | | Map | | Map | | | | | | | | | `-----------' `-----------' | | | | .-----------. .-----------. | | | Sessions | | Map | | | | Handler | | Filtering | | | | | | logic | | | `-----------' `-----------' | | | `-------------------------------' Stephan & Ellouze Expires January 10, 2013 [Page 14] Internet-Draft CDNi ALTO session July 2012 Figure 5: ALTO Protocol for CDN interconnection 4.2. View Configuration Views are similar to pre-generated maps presented in the section 7.6.3. of [I-D.ietf-alto-protocol]. Their configurations are local to the ALTO server. The configuration includes a name, a PoINT and a CoINT. A view provides an ALTO CLient with at least 2 Information Resources: the network map associated with the PoINT and the cost map associated with the CoINT. Its definition includes the setting of the URIs towards these pre- generated maps. N.B.: Cost of Interest (CoINT) will be defined in the next version fo the document. 4.2.1. PoINT A PoINT applies at the view level. It specifies a local filter tied to an URI which provides the ALTO client with a link to download the ouput of this filter (see examples in section 4.2.2). It applies during all the duration of the session. This filter produces pre-generated maps. The output of the filter is a pre-generated network map and a optionnal pre-generated Network Map Status. The Network Map Status will be specified in the next version of the document. Note: Filters value are not exchanged over the network. Nevertheless, as ALTO Maps are JSON documents it is desirable to write the filter using JSON document filtering mechanisms like JSON pointer [I-D.pbryan-zyp-json-pointer]. In this memo the filters are defined using a syntax similar to JSON pointer but allowing wildcard (like W3C XPATH does). 4.2.2. View Configuration Examples Following are the PoINT corresponding to the use case of the section 2. Note: View Configurations are internal to an ALTO Server. They are not exchanged between the ALTO server and the ALTO Client. In this section the View Configurations are writen in JSON to ease the reading only. Stephan & Ellouze Expires January 10, 2013 [Page 15] Internet-Draft CDNi ALTO session July 2012 { "view" : "ipv4", "point" : { "filter": "map/PID_*/ipv4" , "map" : "http://cdni.alto.example.com/CDN1/networkmap/ipv4" "map_status" : "http://cdni.alto.example.com/CDN1/networkmap/ipv4/status" } "coint" : [] } CDN1 IPv4 view { "view" : "FTTH", "point" : { "filter": "map/PID_FTTH" , "map" : "http://cdni.alto.example.com/CDN2/networkmap/FTTH" "map_status" : "http://cdni.alto.example.com/CDN2/networkmap/FTTH/status" } "coint" : [] } CDN2 FTTH view { "view" : "IPv6", "point" : { "filter": "map/PID_*/IPv6" , "map" : "http://cdni.alto.example.com/CDN2/networkmap/IPv6" "map_status" : "http://cdni.alto.example.com/CDN2/networkmap/ipv6/status" } "coint" : [] } CDN2 IPv6 view 4.3. Session Configuration Parameters The agreement between uCDN and dCDN operators defines the configuration set of the ALTO session. The configuration of the ALTO interface between an uCDN and a dCDN requires the exchange of session parameters between the two CDNs operators. This can be performed either out-of-band or through the CDNi Control interface. In both cases the setting of a CDNi ALTO session requires an agreement between the 2 CDNs operators and a technical description of the session configuration (addresses, URL, authentication methods, etc.), of the information which can be exchanged (PID filtering, level of details of the maps) and of the way the information is exchanged (update procedure, time scale of updates ). Stephan & Ellouze Expires January 10, 2013 [Page 16] Internet-Draft CDNi ALTO session July 2012 The session configuration relies on the following parameters: connection: server and client addresses, URL base, authentication methods, etc.; session_filter: The PIDs which are in the scope of the session. The Cost parameters which are in the scope of the session; views: a list of views; PoINTs; CoINTs; nmap_heartbeat: Order of magnitude of the periodicity of the download of the Network Maps by the client (e.g. every minute or every week); cmap_heartbeat: Order of magnitude of the periodicity of the download of the Cost Maps by the client (e.g. every minute or every week); 4.4. Error Handling Errors are reported using legacy ALTO and HTTP errors. 5. Enhancements The ALTO session presented in this memo relies on basic ALTO services to permit a good level of interoperability, performance and security and to help preserving individual CDN know-how. This section discussed enhancements to a CDNi ALTO session. 5.1. Incremental Update There are different ways to implement maps update [I-D.schwan-alto-incr-updates]. Two important aspects are to be considered: Improving the processing time in the ALTO client and providing auCDN with relevant updates. An update based on the diff of JSON file entries is useful but not optimized with regard to the uCDN processing because it requires the re-processing of the whole map from scratch after each upload. A better approach consists in defining an update mechanism providing the diff for a grouping of entries such as PIDs. The approach proposed in section 4.2.1 does not optimize the protocol but provide additionnal Information Resources to let the uCDN Stephan & Ellouze Expires January 10, 2013 [Page 17] Internet-Draft CDNi ALTO session July 2012 optimizes it exchanges according to its logic. 5.1.1. Level of Details of a Map The level of information exchanged between a dCDN ALTO server and a uCDN ALTO client must be customizable in order to decrease the amount of exchanged data while providing the required information. uCDN may not need the full details of each entry map. It may need the details later. Furthermore there are cases where an uCDN needs only the list of the PIDs of dCDN. This covers situations where the very detail of each PID of a Network Map is available over existing interfaces like BGP. For these reasons an uCDN ALTO client should be allowed to get only the summary of the maps (e.g. the list of the PIDs of a Network Map). This can be achieved by defining additional session parameters which set the level of detail of the maps. 5.2. Bi-directional Exchange of Information In the CDNi context, tied interactions between an uCDN and a dCDN may be required. As Discussed in section 3, there are different aspects requiring a Bi-directionnal exchange of information including: Network Map Update Notifications: The update mechanism based on HTTP download is sub-optimal when the uCDN requires a real time propagation of the updates. Bi-directional interactions allow adCDN to notify auCDN with Network Map updates; Exposition of uCDN constraints: Allowing an uCDN to inform dCDN about its high level constraints like forecast indications provides dCDN with valuable information for optimizing its resources provisioning; Session Customization: There are situations where an uCDN may require other Views or modify existing Views and where there is a high level of trust between the two CDNs. Consequently the ALTO session might support the modification of the Views by the auCDN. One solution consists in upgrading the HTTP session to a bi directional protocol. WebSocket Protocol [RFC6455] is one potential candidate. Stephan & Ellouze Expires January 10, 2013 [Page 18] Internet-Draft CDNi ALTO session July 2012 6. IANA Considerations This document will request the registration of the media type corresponding to new information services introduced, if any. 7. Security Considerations This memo defines an ALTO session for CDN interconnection. It specifies a mean to manage finely the information exchanged over the ALTO protocol. By reducing the information exposed it increase the security in general. Performance: The usage of the ALTO services by the client may stress the server. Consequently the volume and the number of these messages may affect the availability and the performance of the ALTO server. Despite the information services provide an uCDN ALTO client with means to control the amount of information downloaded from a dCDN ALTO server it should protect itself from the download of huge network map. Privacy: The extension has less privacy concerns than the current ALTO specification because it does not require the support of the End point Information Services. Know-how protection: unlike section 8 of [I-D.ietf-alto-protocol], an ALTO client is not allowed to redistribute information received from a ALTO server. 8. Acknowledgments Part of this work is funded by the EU FP7 Envision project. The authors would like to thank Christian Jacquenet for its feedbacks on preliminary versions of this document. 9. References Stephan & Ellouze Expires January 10, 2013 [Page 19] Internet-Draft CDNi ALTO session July 2012 9.1. Normative References [I-D.ietf-alto-protocol] Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", draft-ietf-alto-protocol-11 (work in progress), March 2012. [I-D.ietf-cdni-requirements] Leung, K. and Y. Lee, "Content Distribution Network Interconnection (CDNI) Requirements", draft-ietf-cdni-requirements-03 (work in progress), June 2012. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References [I-D.ietf-alto-deployments] Stiemerling, M., Kiesel, S., and S. Previdi, "ALTO Deployment Considerations", draft-ietf-alto-deployments-04 (work in progress), March 2012. [I-D.ietf-alto-server-discovery] Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and S. Yongchao, "ALTO Server Discovery", draft-ietf-alto-server-discovery-03 (work in progress), March 2012. [I-D.ietf-cdni-problem-statement] Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content Distribution Network Interconnection (CDNI) Problem Statement", draft-ietf-cdni-problem-statement-08 (work in progress), June 2012. [I-D.ietf-cdni-use-cases] Bertrand, G., Emile, S., Burbridge, T., Eardley, P., Ma, K., and G. Watson, "Use Cases for Content Delivery Network Interconnection", draft-ietf-cdni-use-cases-08 (work in progress), June 2012. [I-D.jenkins-alto-cdn-use-cases] Niven-Jenkins, B., Watson, G., Bitar, N., Medved, J., and S. Previdi, "Use Cases for ALTO within CDNs", draft-jenkins-alto-cdn-use-cases-03 (work in progress), June 2012. [I-D.marocco-alto-next] Stephan & Ellouze Expires January 10, 2013 [Page 20] Internet-Draft CDNi ALTO session July 2012 Marocco, E. and V. Gurbani, "Extending the Application- Layer Traffic Optimization (ALTO) Protocol", draft-marocco-alto-next-00 (work in progress), January 2012. [I-D.medved-alto-svr-apis] Medved, J., Ward, D., Peterson, J., Woundy, R., and D. McDysan, "ALTO Network-Server and Server-Server APIs", draft-medved-alto-svr-apis-00 (work in progress), March 2011. [I-D.pbryan-json-patch] Bryan, P., "JSON Patch", draft-pbryan-json-patch-04 (work in progress), December 2011. [I-D.pbryan-zyp-json-pointer] Bryan, P. and K. Zyp, "JSON Pointer", draft-pbryan-zyp-json-pointer-02 (work in progress), October 2011. [I-D.penno-alto-cdn] Penno, R., Medved, J., Alimi, R., Yang, R., and S. Previdi, "ALTO and Content Delivery Networks", draft-penno-alto-cdn-03 (work in progress), March 2011. [I-D.previdi-cdni-footprint-advertisement] Previdi, S., Faucheur, F., Faucheur, F., Medved, J., and L. Faucheur, "CDNI Footprint Advertisement", draft-previdi-cdni-footprint-advertisement-01 (work in progress), March 2012. [I-D.randriamasy-alto-multi-cost] Randriamasy, S. and N. Schwan, "Multi-Cost ALTO", draft-randriamasy-alto-multi-cost-06 (work in progress), March 2012. [I-D.schwan-alto-incr-updates] Schwan, N. and B. Roome, "ALTO Incremental Updates", draft-schwan-alto-incr-updates-01 (work in progress), March 2012. [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", RFC 5693, October 2009. [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, December 2011. Stephan & Ellouze Expires January 10, 2013 [Page 21] Internet-Draft CDNi ALTO session July 2012 Authors' Addresses Emile Stephan France Telecom - Orange 2 avenue Pierre Marzin Lannion F-22307 France Email: emile.stephan@orange.com Selim Ellouze France Telecom - Orange 2 avenue Pierre Marzin Lannion F-22307 France Email: selim.ellouze@orange.com Stephan & Ellouze Expires January 10, 2013 [Page 22]