idnits 2.17.1 draft-song-alto-i2rs-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Feb 22, 2013) is 4080 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-alto-protocol' is defined on line 242, but no explicit reference was found in the text == Unused Reference: 'RFC5693' is defined on line 247, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-lee-alto-ext-dc-resource-01 == Outdated reference: A later version (-27) exists of draft-ietf-alto-protocol-13 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO H. Song 3 Internet-Draft Y. Lee 4 Intended status: Informational Huawei 5 Expires: August 26, 2013 Feb 22, 2013 7 Infrastructure to Application Information Exposure 8 draft-song-alto-i2rs-01 10 Abstract 12 This document describes the scenarios that applications can use the 13 network layer especially the network routing system exposed 14 information, so as to optimize application layer traffic. The use 15 cases in this document include the ISP broadband network (using P2P 16 and CDN as examples) and the data center network. This document 17 also describes what information should be collected for 18 ALTO service for traffic optimization. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 26, 2013. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3.1. ISP network . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.2. Data Center Network . . . . . . . . . . . . . . . . . . . . 4 59 4. Open Discussion . . . . . . . . . . . . . . . . . . . . . . . . 6 60 5. Informative References . . . . . . . . . . . . . . . . . . . . 6 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 63 1. Introduction 65 ALTO provides an interface to applications and appropriate 66 information to guide an optimal node selection when there are more 67 than one application node providing the same service, through 68 aggregated network map and cost map. It usually aggregates network 69 locations into PIDs, and assigns lower cost value for a PID pair that 70 are topologically closer. So when application node follows the advice 71 from ALTO server to choose one resource provider within a PID that 72 has lower cost from its own PID, with higher probability the 73 application node can keep the content request and response traffic 74 flow intra domain. This can reduce interdomain traffic for ISPs, and 75 avoid the congestion in the backbone network. More factors for node 76 selection can be considered, such as pricing, congestion, and etc. 78 In order to assure optimality, the underlying infrastructure needs 79 to expose its topology information, node/link status information, 80 pricing information for path selection to ALTO server, which will 81 either be abstracted as the network map or as the impacting input 82 factor of cost map. 84 2. Terminology 86 I2AEX: Infrastructure to Application Exposure. 88 ALTO: application layer traffic optimization. 90 IaaS: Infrastructure as a Service. 92 3. Use Cases 94 3.1. ISP network 96 ISP broadband networks are consisted of interconnected autonomous 97 systems. They run BGP protocols between the boarder gateway routers, 98 and run IGP protocols intra autonomous systems. There are core 99 routers, and access routers (BRAS) which fullfill the admission 100 control through RADIUS servers, the access router connects to 101 multiple aggregation switches. And an aggregation switch connects to 102 multiple DSLAMs or OLTs. And the DSLAM or OLT connect to the home 103 gateways or ONUs, which connect to the user devices. [It's better to 104 give a figure here.] 106 The ISP network usually hide all its information to applications. 107 But in the trend of big traffic use case, the main motivation is to 108 reduce the backbone and interdomain traffic. CDN and P2P are the two 109 target applications. In a P2P application, the content requester 110 requests contents from peers in the same swarm. It may choose a peer 111 that is far way ignoring a peer that is topologically closer to it. 112 Due to the topology ignorance, the application may creates 113 unnecessary backbone and interdomain traffic. 115 In another application of CDN, a popular resource usually is stored 116 in multiple data centers. Without the knowledge of the network 117 topology, the CDN's DNS server can redirects the content requester to 118 a sub-optimal edge server, which is not always topolocially close to 119 the content requester. Even with measuring the round trip time 120 between its edge servers and the requester's local DNS server, it may 121 not get the accurate result because RTT is dynamic and user can 122 specify its own DNS server. 124 For the above two broadband network use cases, the infrastructure 125 information from the home to the access router does not help much. 126 But more attendtion should be paid to the information from the access 127 router to the routing system, which can provide important input for 128 the ALTO maps. An ALTO server needs the following information as 129 input: 131 o The network segments information. Every access router manages one 132 or more IP address pools, to be assigned to the users through DHCP or 133 other ways. 135 o The IP addresses of the interfaces of routers, and the routing 136 table information(IGP or BGP). This information can help to 137 construct the whole network topology. 139 o The congestion status of the router interfaces, but this 140 information could be reflected in the routing table change. 142 o Policy information. For example, one multi-homing AS prefers to 143 use which AS to transit its traffic, including the pricing 144 information. 146 ALTO can use the collected information mentioned above to be able to 147 select a node topologically closer, with lower transit price and 148 less congested link. 150 3.2. Data Center Network 152 Infrastructure as a service (IaaS) is a way how the data center 153 provides its services. There are different kinds of resources in a 154 data center, physical machines, virtual machines, switches, 155 firewalls, computing power, storage space, and electric power. 156 [I-D.lee-alto-ext-dc-resource] proposes collecting data 157 center resource information to make use of such information for a key 158 decision to allocate the application request to an "optimal" Data 159 Center location in which to host the application request. Key 160 constraints in this decision include resource availability (e.g., 161 memory, storage, CPU, etc.), DC network cost, DC network resource 162 constraints (e.g., bandwidth), structure constraints (e.g., Data 163 Center power consumption) and others. 165 Combined computing and network resource optimization is of value to 166 both application owners and data center operators. For example a 167 data center operator with multiple buildings in a metropolitan area 168 may also want to balance compute and network costs. 170 +--------------+ 171 Resource Request | Application | 172 -----------> | Orchestrator | 173 +-------+------+ 174 | 175 +--------+ +----+----+ +--------+ 176 | | | | | | 177 | DC 1 |<--------+------->| ALTO |<-------+------->| DC 2 | 178 | | ALTO-interface | Client | ALTO-interface | | 179 +--------+ +---------+ +--------+ 180 /|\ 181 | 182 + ALTO-interface 183 | 184 \|/ 185 +---------+ 186 | | 187 | DC 3 | 188 | | 189 +---------+ 191 The ALTO server needs to collect the following information so as to 192 provide this kind of service. 194 o All switches' network capacity information 196 o All physical servers' information(CPU, memory) in the data center 198 o The storage space information in the data center 200 o The physical links information 202 o The virtual machines' information(CPU, memory) and its affinity 204 o Pricing models 205 Based on the aforementioned information, ALTO server can provide the 206 load balancing/traffic optimization information to ALTO client for 207 data centers, through map or ranking. 209 4. Open Discussion 211 In order to optimize the application traffic, network layer needs to 212 provide necessary information to the according applications in the 213 previous section, with a method (request/response, or subscription/ 214 notification) to make the underlying information changes be timely 215 sent to the ALTO server. This requires more interactions between the 216 network layer and the application layer. I2RS seems to consider more 217 configuration use cases such like policy based routing, but what ALTO 218 protocol needs is the part that discloses the network information. 219 So there could be two ways to go forward. 221 (1) Defining a new protocol to cover all required functions such as 222 configuration and information disclosure required by I2RS. This 223 protocol covers ALTO's south bound information requirements on network 224 topology, with its one component. But this protocol will be 225 tremendously complicated. It will be related and overlapped with 226 other existing protocols, such like NetConf and YANG. 228 (2) Defining the south bound interface for ALTO, to collect the 229 infrastructure information, and bring the requirements discussion in 230 I2RS, and identify the final scope, to avoid the overlap between 231 different WGs(ALTO, NetConf, NetMod). In this case, the protocol 232 development will belong to ALTO WG. 234 5. Informative References 236 [I-D.lee-alto-ext-dc-resource] 237 Lee, Y., Bernstein, G., and D. Dhody, "ALTO Extensions for 238 Collecting Data Center Resource Information", 239 draft-lee-alto-ext-dc-resource-01 (work in progress), 240 January 2013. 242 [I-D.ietf-alto-protocol] 243 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", 244 draft-ietf-alto-protocol-13 (work in progress), 245 September 2012. 247 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 248 Optimization (ALTO) Problem Statement", RFC 5693, 249 October 2009. 251 Authors' Addresses 253 Haibin Song 254 Huawei 256 Email: haibin.song@huawei.com 258 Young Lee 259 Huawei 261 Email: leeyoung@huawei.com