idnits 2.17.1 draft-song-alto-usecase-ext-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 : ---------------------------------------------------------------------------- ** 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 15, 2013) is 3937 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5693' is defined on line 510, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-alto-deployments' is defined on line 514, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-lee-alto-ext-dc-resource-02 == Outdated reference: A later version (-27) exists of draft-ietf-alto-protocol-16 == Outdated reference: A later version (-16) exists of draft-ietf-alto-deployments-06 Summary: 3 errors (**), 0 flaws (~~), 7 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: January 16, 2014 V. Lopez 6 D. Lopez 7 Telefonica I+D 8 L. Deng 9 W. Chen 10 China Mobile 11 July 15, 2013 13 Extension Use Cases and Requirements for ALTO 14 draft-song-alto-usecase-ext-00 16 Abstract 18 This document describes new usecases for ALTO, and identifie its 19 related requirements to extend the ALTO protocol. The use cases in 20 this document include overlay routing, NaaS, data center information, 21 and P2P cache. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 16, 2014. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Use Cases and Requirements . . . . . . . . . . . . . . . . . 3 60 3.1. Minor Extensions in ISP or Overlay Network . . . . . . . 3 61 3.1.1. Overlay Routing . . . . . . . . . . . . . . . . . . . 4 62 3.1.2. Inter NSP ASQ . . . . . . . . . . . . . . . . . . . . 5 63 3.1.3. Network As A Service (NaaS) . . . . . . . . . . . . . 6 64 3.1.4. P2P Cache . . . . . . . . . . . . . . . . . . . . . . 6 65 3.2. Data Center Network . . . . . . . . . . . . . . . . . . . 9 66 3.2.1. Data Center Network Deployment . . . . . . . . . . . 9 67 3.2.2. VM Migration Between Data Centers . . . . . . . . . . 10 68 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 4.1. Normative References . . . . . . . . . . . . . . . . . . 11 70 4.2. Informative References . . . . . . . . . . . . . . . . . 11 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 73 1. Introduction 75 ALTO protocol [I-D.ietf-alto-protocol]provides an interface to 76 applications with appropriate information to guide an optimal node 77 selection when there are more than one application nodes providing 78 the same service. It usually aggregates network locations into PIDs, 79 and assigns lower cost value for a PID pair that are topologically 80 close. So when application node follows the advice from ALTO server 81 to choose one resource provider with a PID that has lower cost from 82 its own PID, with higher probability the application node can keep 83 the content request and response traffic flow intra domain, which can 84 reduce the suffering increasing interdomain traffic for ISPs, and 85 avoid the congestion in the backbone network. More factors for node 86 selection can be considered, such as pricing, congestion, and etc. 88 The existing ALTO protocol has its limitations too. For example, in 89 a cost map it only gives one cost value between source PID and 90 destination PID, assuming there is only one path between them. But 91 it can be routed through different paths in overlay routing. So we 92 propose to add a "via" parameter as an extension to the cost map. In 93 this document, we give use cases first, and then the possible way to 94 extend the ALTO protocol to achieve it. 96 2. Terminology 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. And the 101 following terms used in this document have their definitions below. 103 I2AEX: Infrastructure to Application Exposure. 105 ALTO: application layer traffic optimization. For ALTO protocol, 106 please refer to . [I-D.ietf-alto-protocol] 108 IaaS: Infrastructure as a Service. One common IaaS service is 109 leasing virtual machines with appropriate bandwidth to tennants. 111 NaaS: Networking as a service. The common NaaS services include 112 dynamic VPN service, virtual network service, and etc. 114 AP: a wireless access point (WAP) is a device that allows wireless 115 devices to connect to a wired network using WLAN. The AP usually 116 connects to a AC as a standalone device, but it can also be an 117 integral component of the router itself. 119 AC: a wireless access controller (WAC) is the network entity that 120 provides wire access via APs to the network infrastructure in the 121 data plane, control plane, management plane, or a combination 122 therein. 124 Fowarding Cache: is a traditional content cache, which caches content 125 flows from outside its coverage and serves subsequent requestors 126 under its coverage for the content. 128 Reverse Cache: is a special content cache proposed for WLAN accessing 129 networks, which caches content flows from inside its coverage and 130 serves subsequent requests from outside its coverage for the content. 132 Bidirectional Cache: is a combination of a forwarding cache and a 133 reverse cache. 135 Cooperative Cache: is a content cache deployed by network operators 136 in cooperation with specific content deliverying SPs (e.g. P2P 137 streaming services), which participates in the overlay's service 138 provision explicitly. 140 3. Use Cases and Requirements 142 3.1. Minor Extensions in ISP or Overlay Network 143 3.1.1. Overlay Routing 145 An overlay network is a computer network which is built on the top of 146 another network. Nodes in the overlay can be thought of as being 147 connected by virtual or logical links, each of which corresponds to a 148 path, perhaps through many physical links, in the underlying 149 network[overlay_network]. One example of overlay netwok over IP 150 network is CDN network. A CDN network consists of many CDN nodes 151 with different levels. One edge CDN node often needs to pull content 152 from another node that is in a higher distribution level position in 153 the CDN topology. There usually can be several paths to send the 154 content from the source CDN node to the edge CDN node. One way 155 obviously is the direct IP routing. And if the direct routing path 156 is not good, then the source CDN node will select another CDN node as 157 the intermediate node to transport the content to the that 158 destination edge node, which will be more efficiency than the direct 159 routing path. Of course, there are usually more than one 160 intermediate node available, and the source CDN node needs to select 161 a "best" one. 163 In some cases, there can also be a VPN tunnel between two CDN nodes 164 to transfer contents. 166 /--------\ 167 |/// \\\| 168 | CDN Node | 169 |\\\ 1 ///|\ 170 \-+------/| \\ 171 | | \ 172 | | \\ overlay routing 173 | \ 174 direct Internet routing | \\ 175 | \ 176 | | \\ 177 /--------\ | | /----\---\ 178 /// \\\ | | |/// \\\| 179 | CDN Node | \ | | CDN Node | 180 \\\ 2 /// \ | |\\\ 3 ///| 181 \--------/ \ | \--------/ 182 \ VPN tunnel / 183 \ | / 184 \ | / 185 \ | 186 \ | / overlay routing 187 \ | / 188 /------+-\ / 189 |/// \\\| / 190 | CDN Node | 191 |\\\ 4 ///| 192 \--------/ 194 Figure 1. different ways for sending content from Node 1 to Node 4 196 So the transport between two overlay nodes can be from: 198 direct routing 200 one/more intermediate overlay nodes 202 a VPN tunnel 204 The proposed extension is to add a "via" parameter to each cost 205 value, and the value of the "via" parameter can be "direct routing", 206 or location identifiers that can represent intermeidate overlay nodes 207 (such like IP address), or "VPN". 209 3.1.2. Inter NSP ASQ 211 This use case is similiar to the overlay routing use case. When two 212 ASes are connected through more than one pairs of border gateway 213 routers, then there are more than one paths from a node in one of 214 these two ASes to another node in the other AS. And these paths 215 through different pair of border routers may have different service 216 quality. An ALTO server can contemplate the service quality through 217 the locations in one AS to its different boarder gateways, and 218 between boarder gateways, and through the other boarder gateway to 219 network locations in the other AS, and then provide guidance to 220 applications to choose an appropriate path for the service routing. 222 +------------------+ +------------------+ 223 | Edge NSP A | | Edge NSP B | 224 node---- | | | 225 | - ------- | PoI | node 226 | - ----BG--------------BG | 227 | - Path 1 | | \ | 228 | - | | \ | 229 | - | | \ node 230 node - | | \ | 231 | - | PoI | \ | 232 | Path 2 - BG-------------BG- \ | 233 | | | - \ | 234 node | | - \ node 235 | | | - \ | 236 | | | - \ | 237 | | PoI | - \ | 238 node BG-------------BG --\node 239 | | | | 240 node | | | 241 | | | node 242 +------------------+ +------------------+ 244 Figure 2 Inter-NSP ASQ use case 246 The "via" extension is also proposed to be used for this use case, 247 and the value of it can be the identifier of the boarder gateway. 249 3.1.3. Network As A Service (NaaS) 251 Network As A Service (NaaS) enables network operators to give 252 connectivity service to multiple users on top of the same physical 253 infrastructure. This connectivity service can be offered to 254 different customers, which have an interface to request for more 255 bandwidth to the network in case they need more capacity. Although 256 end users may have an interface to request for bandwidth to the 257 network, an interface is required to disseminate to the end points 258 with the changes in the network configuration. There are two options 259 to disseminating information using ALTO protocol: 261 o Dissemination of bandwidth information. ALTO can inform with a 262 cost map related to unreserved bandwidth so end points can decide 263 which connections they may use depending on the capacity in the 264 connections. This can be used to update routing tables in the end 265 points or priorities to interconnect two end points. Due to the 266 dynamicity of traffic, this unreserved bandwidth is based on 267 administrative reservations done through control plane protocols 268 like RSVP-TE. 270 o Bandwidth pricing. ALTO protocol can disseminate a cost map 271 related to price of the connectivity between locations (such like 272 PIDs). This information can be used to advertize customers, which 273 is the cost to request for more bandwidth between two locations 274 periodically. This can change depending on links utilization in 275 the physical infrastructure. The cost advertize by ALTO is not 276 directly the price charged to the customer, but a cost related to. 278 3.1.4. P2P Cache 280 Efforts have been put on using forwarding caches to reduce P2P 281 traffic in cross domain scenarios, which demonstrates great 282 improvement in user experience and considerable cost reduction at 283 interworking points. What's more, bidirectional caches are proposed 284 to be deployed at the AC level for mitigation of undesirable downlink 285 congestion caused by consistent uplink P2P traffic, as shown in 286 Figure 5, the reverse cache can provide uploading service instead of 287 the WLAN peers under the AC's coverage. 289 +--------------+ +------+ 290 | ISP 1 network+----------------+Peer 1| 291 +-----+--------+ +------+ 292 | 293 +--------+------------------------------------------------------+ 294 | | ISP 2 network | 295 | +----------------+ +------------------+ | 296 | |Interworking GW |----------------| Forwarding Cache | | 297 | +-----+----------+ +------------------+ | 298 | | | 299 | | | 300 | +-----+------+ +---------------------+ | 301 | | AC +----------------+ Bidirectional Cache | | 302 | +-----+------+ +---------------------+ | 303 | | | 304 | +-------------------------------+ | 305 | +----+------+ +-----+-----+ | 306 | | AP_1 | . . . . | AP_n | | 307 | +----+------+ +-----+-----+ | 308 | | | | 309 +--------+-------------------------------+----------------------+ 310 | | 311 +--+----------+ | 312 | | | 313 +--+--+ +--+--+ +--+--+ 314 |Peer2| |Peer3| |Peer4| 315 +-----+ +-----+ +-----+ 317 Figure 1: Architecture of T/B-cache in WLAN 319 With various P2P caches deployed, especially at a position as low as 320 the AC-level, it could be sub-optimal to simply use the accessing 321 network type as the divider for different PIDs and assign sufficient 322 high cost within the wireless PID to prefer accessing remote peers 323 over local peers blindly. Therefore, it is expected that the 324 cooperation between the network operator and the P2P SP in buiding up 325 cooperative caching system and sharing information through ALTO 326 protocol about these facilities bring benefits to both parties. 328 A straightforward proposal would be to use locations of caches as 329 dividers of different DIPs to further partition intra-ISP network 330 domain and mark costs among them according to the location and type 331 of relevant caches. However, as there is both CAPEX and OPEX 332 expenditures for dedicated P2P Cache devices, it may be cost- 333 efficient for caches to make buffering/serving decisions based on the 334 popularity of the specific content. In addition, in cooperative 335 mode, a P2P cache may be under the content scheduling of the specific 336 P2P SP instead of the direct control of the network operator. How to 337 expose this application-relevant information to ALTO under such 338 context is an open issue. 340 Luckily, in the cooperative-mode, a cache is playing as a normal peer 341 under the tracker, and the latter can make the "right" decision in 342 choosing in favor of the former under the guidance of the ALTO 343 response while the tracker itself would take care of the content 344 availability problem. If the cache doesn't have the content in 345 question, it would no appear in the peer list handed in to ALTO 346 server by the tracker. 348 In this case, the ALTO server can collect the information about 349 caching sub-system in the network, identify those "caching" peers in 350 the peer list of an cost request from an ALTO client, and arrange the 351 returned rank list accordingly. For example, a simple candidate- 352 ranking policy for a cost query to a WLAN peer, could be caching 353 peers at the begining, then inside wired peers, and lastly outside 354 wired peers. 356 Moreover, the P2P SP and WLAN network operator may benefit even more 357 by group popular files accroding to peers' geographic location or 358 access types, and adapt its internal caching scheduling decisions 359 about which files to be cached on which spot. In other words, it 360 would be helpful that the ALTO server provides the client with the 361 requesting peer's subscription types (i.e. wired/WLAN/ celluar/...) 362 as well as geographic locations. 364 The proposed extension to ALTO is to distinguish peers not only 365 according to IP prefixes, but also peer's access types and whether 366 it's a caching server or not. This kind of information can be 367 acquired through network management system or application system. 368 And it also requires that for endpoint property lookup, "exact 369 matching" has higher priority than "IP prefix matching". 371 3.2. Data Center Network 373 3.2.1. Data Center Network Deployment 375 Infrastructure as a service (IaaS) is a way how the data center 376 provides its services. There are different kinds of resources in a 377 data center, physical machines, virtual machines, switches, 378 firewalls, computing power, storage space, and electric power. The 379 draft [I-D.lee-alto-ext-dc-resource] proposes collecting data center 380 resource information to make use of such information for a key 381 decision to allocate the application request to an "optimal" Data 382 Center location in which to host the application request. Key 383 constraints in this decision include resource availability (e.g., 384 memory, storage, CPU, etc.), DC network cost, DC network resource 385 constraints (e.g., bandwidth), structure constraints (e.g., Data 386 Center power consumption) and others. 388 Combined computing and network resource optimization is of value to 389 both application owners and data center operators. For example a 390 data center operator with multiple buildings in a metropolitan area 391 may also want to balance compute and network costs. 393 Collect DC information 394 +----------+ 395 +--------------+ | ALTO | 396 Resource Request | Application | | Server | 397 -----------> | Orchestrator | /+----------+ 398 +-------+------+ / 399 | / 400 +--------+ +----+----+ / +--------+ 401 | | | |/ | | 402 | DC 1 |<-------------->| ALTO |<------------->| DC 2 | 403 | | | Client | | | 404 +--------+ +---------+ +--------+ 405 /|\ 406 | 407 | 408 | 409 \|/ 410 +---------+ 411 | | 412 | DC 3 | 413 | | 414 +---------+ 416 Figure 3 Data Center Resource Deployment use case 418 The intended ALTO protocol extension is going to provide the 419 following informaiton: 421 Data Center Identifier (DCI) 422 Data Center Location Identifier (e.g., IP address of the 423 gateway node) 424 Time Stamp 425 Abstracted Memory Usage 426 Abstracted CPU Level 427 Abstracted Power Consumption Level 428 DC Network cost 429 DC Network resource constraints 431 3.2.2. VM Migration Between Data Centers 433 Giant or large applications usually have to rent virtual machine 434 resources in more than one data centers for its application 435 deployment. These virtual machines do not only communicate with the 436 end users, but also with other virtual machines. Some applications 437 rent dedicated VPN links for the traffic among data centers, and some 438 applications pay money for the traffic among data centers that go 439 through Internet. There is a requirement to collects each VM traffic 440 pattern and direction among data centers, and consider them together 441 with the traffic pricing information, and use some specific 442 algorithm, to give advice on VM migration. For example, the 443 algorithm may let the VMs that have much communication traffic 444 migrate into one data center, so as to reduce the traffic among data 445 centers, and save money for the application. 447 A new "cost type" extension is proposed in ALTO, which represents the 448 cost between VMs, with regarding to the combined traffic volume and 449 pricing information. An application uses ALTO client to retrieve 450 this kind of information, and consider it together with the location 451 and any specific contraints of each VM, then decide whether to 452 migrate VMs that have high cost valume between each other into one 453 single data center, so as to reduce inter-DC traffic. 455 The actual use case is far more complex than the figure below. 456 Because each VM may communicate with multiple VMs, and a more complex 457 algorithm should be used for the VM migration. The application have 458 to compute the new total cost after the migration and compare it with 459 that before the migration. 461 +----------+ +------------+ 462 | | | DC 2 | 463 | DC 1 | | | 464 | +---+ | average: 2Mbps |+---+ | 465 | |VM1|----+---------------------+|VM2| ---+ | 466 | +---+ | |+---+ |VM3| | 467 | | | | +---+ | 468 +----------+ | | | 469 | +------------+ 470 ----------------------------+---------------------------------- 471 | 472 | 473 +----------+ \|/ +----------+ 474 | | | | 475 | DC 1 | | DC 2 | 476 | +---+ | | +---+ | 477 | |VM1| + + |VM3| | 478 | +-+ | | +---+ | 479 | |2Mbps | | | 480 | +-+-+ | +----------+ 481 | |VM2| | 482 | +---+ | 483 +----------+ 485 Figure 4: Inter-DC VM migration use case 487 4. References 489 4.1. Normative References 491 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 492 Requirement Levels", BCP 14, RFC 2119, March 1997. 494 [overlay_network] 495 , "overlay network", . 497 http://en.wikipedia.org/wiki/Overlay_network 499 4.2. Informative References 501 [I-D.lee-alto-ext-dc-resource] 502 Lee, Y., Bernstein, G., and D. Dhody, "ALTO Extensions for 503 Collecting Data Center Resource Information", draft-lee- 504 alto-ext-dc-resource-02 (work in progress), July 2013. 506 [I-D.ietf-alto-protocol] 507 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", draft- 508 ietf-alto-protocol-16 (work in progress), May 2013. 510 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 511 Optimization (ALTO) Problem Statement", RFC 5693, October 512 2009. 514 [I-D.ietf-alto-deployments] 515 Stimerling, M., Kiesel, S., and S. Previdi, "ALTO 516 Deployment Considerations", draft-ietf-alto-deployments-06 517 (work in progress), February 2013. 519 Authors' Addresses 521 Haibin Song 522 Huawei 524 Email: haibin.song@huawei.com 526 Young Lee 527 Huawei 529 Email: leeyoung@huawei.com 531 Victor Lopez 532 Telefonica I+D 534 Email: vlopez@tid.es 536 Diego R. Lopez 537 Telefonica I+D 539 Email: diego@tid.es 541 Lingli Deng 542 China Mobile 544 Email: denglingli@chinamobile.com 546 Wei Chen 547 China Mobile 549 Email: chenwei@chinamobile.com