ALTO H. Song Internet-Draft Y. Lee Intended status: Informational Huawei Expires: January 16, 2014 V. Lopez D. Lopez Telefonica I+D L. Deng W. Chen China Mobile July 15, 2013 Extension Use Cases and Requirements for ALTO draft-song-alto-usecase-ext-00 Abstract This document describes new usecases for ALTO, and identifie its related requirements to extend the ALTO protocol. The use cases in this document include overlay routing, NaaS, data center information, and P2P cache. 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 16, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. 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 Song, et al. Expires January 16, 2014 [Page 1] Internet-Draft usecase ext July 2013 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Use Cases and Requirements . . . . . . . . . . . . . . . . . 3 3.1. Minor Extensions in ISP or Overlay Network . . . . . . . 3 3.1.1. Overlay Routing . . . . . . . . . . . . . . . . . . . 4 3.1.2. Inter NSP ASQ . . . . . . . . . . . . . . . . . . . . 5 3.1.3. Network As A Service (NaaS) . . . . . . . . . . . . . 6 3.1.4. P2P Cache . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Data Center Network . . . . . . . . . . . . . . . . . . . 9 3.2.1. Data Center Network Deployment . . . . . . . . . . . 9 3.2.2. VM Migration Between Data Centers . . . . . . . . . . 10 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Normative References . . . . . . . . . . . . . . . . . . 11 4.2. Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction ALTO protocol [I-D.ietf-alto-protocol]provides an interface to applications with appropriate information to guide an optimal node selection when there are more than one application nodes providing the same service. It usually aggregates network locations into PIDs, and assigns lower cost value for a PID pair that are topologically close. So when application node follows the advice from ALTO server to choose one resource provider with a PID that has lower cost from its own PID, with higher probability the application node can keep the content request and response traffic flow intra domain, which can reduce the suffering increasing interdomain traffic for ISPs, and avoid the congestion in the backbone network. More factors for node selection can be considered, such as pricing, congestion, and etc. The existing ALTO protocol has its limitations too. For example, in a cost map it only gives one cost value between source PID and destination PID, assuming there is only one path between them. But it can be routed through different paths in overlay routing. So we propose to add a "via" parameter as an extension to the cost map. In this document, we give use cases first, and then the possible way to extend the ALTO protocol to achieve it. Song, et al. Expires January 16, 2014 [Page 2] Internet-Draft usecase ext July 2013 2. Terminology 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 [RFC2119]. And the following terms used in this document have their definitions below. I2AEX: Infrastructure to Application Exposure. ALTO: application layer traffic optimization. For ALTO protocol, please refer to . [I-D.ietf-alto-protocol] IaaS: Infrastructure as a Service. One common IaaS service is leasing virtual machines with appropriate bandwidth to tennants. NaaS: Networking as a service. The common NaaS services include dynamic VPN service, virtual network service, and etc. AP: a wireless access point (WAP) is a device that allows wireless devices to connect to a wired network using WLAN. The AP usually connects to a AC as a standalone device, but it can also be an integral component of the router itself. AC: a wireless access controller (WAC) is the network entity that provides wire access via APs to the network infrastructure in the data plane, control plane, management plane, or a combination therein. Fowarding Cache: is a traditional content cache, which caches content flows from outside its coverage and serves subsequent requestors under its coverage for the content. Reverse Cache: is a special content cache proposed for WLAN accessing networks, which caches content flows from inside its coverage and serves subsequent requests from outside its coverage for the content. Bidirectional Cache: is a combination of a forwarding cache and a reverse cache. Cooperative Cache: is a content cache deployed by network operators in cooperation with specific content deliverying SPs (e.g. P2P streaming services), which participates in the overlay's service provision explicitly. 3. Use Cases and Requirements 3.1. Minor Extensions in ISP or Overlay Network Song, et al. Expires January 16, 2014 [Page 3] Internet-Draft usecase ext July 2013 3.1.1. Overlay Routing An overlay network is a computer network which is built on the top of another network. Nodes in the overlay can be thought of as being connected by virtual or logical links, each of which corresponds to a path, perhaps through many physical links, in the underlying network[overlay_network]. One example of overlay netwok over IP network is CDN network. A CDN network consists of many CDN nodes with different levels. One edge CDN node often needs to pull content from another node that is in a higher distribution level position in the CDN topology. There usually can be several paths to send the content from the source CDN node to the edge CDN node. One way obviously is the direct IP routing. And if the direct routing path is not good, then the source CDN node will select another CDN node as the intermediate node to transport the content to the that destination edge node, which will be more efficiency than the direct routing path. Of course, there are usually more than one intermediate node available, and the source CDN node needs to select a "best" one. In some cases, there can also be a VPN tunnel between two CDN nodes to transfer contents. /--------\ |/// \\\| | CDN Node | |\\\ 1 ///|\ \-+------/| \\ | | \ | | \\ overlay routing | \ direct Internet routing | \\ | \ | | \\ /--------\ | | /----\---\ /// \\\ | | |/// \\\| | CDN Node | \ | | CDN Node | \\\ 2 /// \ | |\\\ 3 ///| \--------/ \ | \--------/ \ VPN tunnel / \ | / \ | / \ | \ | / overlay routing \ | / /------+-\ / |/// \\\| / | CDN Node | Song, et al. Expires January 16, 2014 [Page 4] Internet-Draft usecase ext July 2013 |\\\ 4 ///| \--------/ Figure 1. different ways for sending content from Node 1 to Node 4 So the transport between two overlay nodes can be from: direct routing one/more intermediate overlay nodes a VPN tunnel The proposed extension is to add a "via" parameter to each cost value, and the value of the "via" parameter can be "direct routing", or location identifiers that can represent intermeidate overlay nodes (such like IP address), or "VPN". 3.1.2. Inter NSP ASQ This use case is similiar to the overlay routing use case. When two ASes are connected through more than one pairs of border gateway routers, then there are more than one paths from a node in one of these two ASes to another node in the other AS. And these paths through different pair of border routers may have different service quality. An ALTO server can contemplate the service quality through the locations in one AS to its different boarder gateways, and between boarder gateways, and through the other boarder gateway to network locations in the other AS, and then provide guidance to applications to choose an appropriate path for the service routing. +------------------+ +------------------+ | Edge NSP A | | Edge NSP B | node---- | | | | - ------- | PoI | node | - ----BG--------------BG | | - Path 1 | | \ | | - | | \ | | - | | \ node node - | | \ | | - | PoI | \ | | Path 2 - BG-------------BG- \ | | | | - \ | node | | - \ node | | | - \ | Song, et al. Expires January 16, 2014 [Page 5] Internet-Draft usecase ext July 2013 | | | - \ | | | PoI | - \ | node BG-------------BG --\node | | | | node | | | | | | node +------------------+ +------------------+ Figure 2 Inter-NSP ASQ use case The "via" extension is also proposed to be used for this use case, and the value of it can be the identifier of the boarder gateway. 3.1.3. Network As A Service (NaaS) Network As A Service (NaaS) enables network operators to give connectivity service to multiple users on top of the same physical infrastructure. This connectivity service can be offered to different customers, which have an interface to request for more bandwidth to the network in case they need more capacity. Although end users may have an interface to request for bandwidth to the network, an interface is required to disseminate to the end points with the changes in the network configuration. There are two options to disseminating information using ALTO protocol: o Dissemination of bandwidth information. ALTO can inform with a cost map related to unreserved bandwidth so end points can decide which connections they may use depending on the capacity in the connections. This can be used to update routing tables in the end points or priorities to interconnect two end points. Due to the dynamicity of traffic, this unreserved bandwidth is based on administrative reservations done through control plane protocols like RSVP-TE. o Bandwidth pricing. ALTO protocol can disseminate a cost map related to price of the connectivity between locations (such like PIDs). This information can be used to advertize customers, which is the cost to request for more bandwidth between two locations periodically. This can change depending on links utilization in the physical infrastructure. The cost advertize by ALTO is not directly the price charged to the customer, but a cost related to. 3.1.4. P2P Cache Efforts have been put on using forwarding caches to reduce P2P traffic in cross domain scenarios, which demonstrates great Song, et al. Expires January 16, 2014 [Page 6] Internet-Draft usecase ext July 2013 improvement in user experience and considerable cost reduction at interworking points. What's more, bidirectional caches are proposed to be deployed at the AC level for mitigation of undesirable downlink congestion caused by consistent uplink P2P traffic, as shown in Figure 5, the reverse cache can provide uploading service instead of the WLAN peers under the AC's coverage. +--------------+ +------+ | ISP 1 network+----------------+Peer 1| +-----+--------+ +------+ | +--------+------------------------------------------------------+ | | ISP 2 network | | +----------------+ +------------------+ | | |Interworking GW |----------------| Forwarding Cache | | | +-----+----------+ +------------------+ | | | | | | | | +-----+------+ +---------------------+ | | | AC +----------------+ Bidirectional Cache | | | +-----+------+ +---------------------+ | | | | | +-------------------------------+ | | +----+------+ +-----+-----+ | | | AP_1 | . . . . | AP_n | | | +----+------+ +-----+-----+ | | | | | +--------+-------------------------------+----------------------+ | | +--+----------+ | | | | +--+--+ +--+--+ +--+--+ |Peer2| |Peer3| |Peer4| +-----+ +-----+ +-----+ Figure 1: Architecture of T/B-cache in WLAN With various P2P caches deployed, especially at a position as low as the AC-level, it could be sub-optimal to simply use the accessing network type as the divider for different PIDs and assign sufficient high cost within the wireless PID to prefer accessing remote peers over local peers blindly. Therefore, it is expected that the cooperation between the network operator and the P2P SP in buiding up cooperative caching system and sharing information through ALTO protocol about these facilities bring benefits to both parties. Song, et al. Expires January 16, 2014 [Page 7] Internet-Draft usecase ext July 2013 A straightforward proposal would be to use locations of caches as dividers of different DIPs to further partition intra-ISP network domain and mark costs among them according to the location and type of relevant caches. However, as there is both CAPEX and OPEX expenditures for dedicated P2P Cache devices, it may be cost- efficient for caches to make buffering/serving decisions based on the popularity of the specific content. In addition, in cooperative mode, a P2P cache may be under the content scheduling of the specific P2P SP instead of the direct control of the network operator. How to expose this application-relevant information to ALTO under such context is an open issue. Luckily, in the cooperative-mode, a cache is playing as a normal peer under the tracker, and the latter can make the "right" decision in choosing in favor of the former under the guidance of the ALTO response while the tracker itself would take care of the content availability problem. If the cache doesn't have the content in question, it would no appear in the peer list handed in to ALTO server by the tracker. In this case, the ALTO server can collect the information about caching sub-system in the network, identify those "caching" peers in the peer list of an cost request from an ALTO client, and arrange the returned rank list accordingly. For example, a simple candidate- ranking policy for a cost query to a WLAN peer, could be caching peers at the begining, then inside wired peers, and lastly outside wired peers. Moreover, the P2P SP and WLAN network operator may benefit even more by group popular files accroding to peers' geographic location or access types, and adapt its internal caching scheduling decisions about which files to be cached on which spot. In other words, it would be helpful that the ALTO server provides the client with the requesting peer's subscription types (i.e. wired/WLAN/ celluar/...) as well as geographic locations. The proposed extension to ALTO is to distinguish peers not only according to IP prefixes, but also peer's access types and whether it's a caching server or not. This kind of information can be acquired through network management system or application system. And it also requires that for endpoint property lookup, "exact matching" has higher priority than "IP prefix matching". Song, et al. Expires January 16, 2014 [Page 8] Internet-Draft usecase ext July 2013 3.2. Data Center Network 3.2.1. Data Center Network Deployment Infrastructure as a service (IaaS) is a way how the data center provides its services. There are different kinds of resources in a data center, physical machines, virtual machines, switches, firewalls, computing power, storage space, and electric power. The draft [I-D.lee-alto-ext-dc-resource] proposes collecting data center resource information to make use of such information for a key decision to allocate the application request to an "optimal" Data Center location in which to host the application request. Key constraints in this decision include resource availability (e.g., memory, storage, CPU, etc.), DC network cost, DC network resource constraints (e.g., bandwidth), structure constraints (e.g., Data Center power consumption) and others. Combined computing and network resource optimization is of value to both application owners and data center operators. For example a data center operator with multiple buildings in a metropolitan area may also want to balance compute and network costs. Collect DC information +----------+ +--------------+ | ALTO | Resource Request | Application | | Server | -----------> | Orchestrator | /+----------+ +-------+------+ / | / +--------+ +----+----+ / +--------+ | | | |/ | | | DC 1 |<-------------->| ALTO |<------------->| DC 2 | | | | Client | | | +--------+ +---------+ +--------+ /|\ | | | \|/ +---------+ | | | DC 3 | | | +---------+ Figure 3 Data Center Resource Deployment use case Song, et al. Expires January 16, 2014 [Page 9] Internet-Draft usecase ext July 2013 The intended ALTO protocol extension is going to provide the following informaiton: Data Center Identifier (DCI) Data Center Location Identifier (e.g., IP address of the gateway node) Time Stamp Abstracted Memory Usage Abstracted CPU Level Abstracted Power Consumption Level DC Network cost DC Network resource constraints 3.2.2. VM Migration Between Data Centers Giant or large applications usually have to rent virtual machine resources in more than one data centers for its application deployment. These virtual machines do not only communicate with the end users, but also with other virtual machines. Some applications rent dedicated VPN links for the traffic among data centers, and some applications pay money for the traffic among data centers that go through Internet. There is a requirement to collects each VM traffic pattern and direction among data centers, and consider them together with the traffic pricing information, and use some specific algorithm, to give advice on VM migration. For example, the algorithm may let the VMs that have much communication traffic migrate into one data center, so as to reduce the traffic among data centers, and save money for the application. A new "cost type" extension is proposed in ALTO, which represents the cost between VMs, with regarding to the combined traffic volume and pricing information. An application uses ALTO client to retrieve this kind of information, and consider it together with the location and any specific contraints of each VM, then decide whether to migrate VMs that have high cost valume between each other into one single data center, so as to reduce inter-DC traffic. The actual use case is far more complex than the figure below. Because each VM may communicate with multiple VMs, and a more complex algorithm should be used for the VM migration. The application have to compute the new total cost after the migration and compare it with that before the migration. +----------+ +------------+ | | | DC 2 | | DC 1 | | | | +---+ | average: 2Mbps |+---+ | Song, et al. Expires January 16, 2014 [Page 10] Internet-Draft usecase ext July 2013 | |VM1|----+---------------------+|VM2| ---+ | | +---+ | |+---+ |VM3| | | | | | +---+ | +----------+ | | | | +------------+ ----------------------------+---------------------------------- | | +----------+ \|/ +----------+ | | | | | DC 1 | | DC 2 | | +---+ | | +---+ | | |VM1| + + |VM3| | | +-+ | | +---+ | | |2Mbps | | | | +-+-+ | +----------+ | |VM2| | | +---+ | +----------+ Figure 4: Inter-DC VM migration use case 4. References 4.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [overlay_network] , "overlay network", . http://en.wikipedia.org/wiki/Overlay_network 4.2. Informative References [I-D.lee-alto-ext-dc-resource] Lee, Y., Bernstein, G., and D. Dhody, "ALTO Extensions for Collecting Data Center Resource Information", draft-lee- alto-ext-dc-resource-02 (work in progress), July 2013. [I-D.ietf-alto-protocol] Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", draft- ietf-alto-protocol-16 (work in progress), May 2013. Song, et al. Expires January 16, 2014 [Page 11] Internet-Draft usecase ext July 2013 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", RFC 5693, October 2009. [I-D.ietf-alto-deployments] Stimerling, M., Kiesel, S., and S. Previdi, "ALTO Deployment Considerations", draft-ietf-alto-deployments-06 (work in progress), February 2013. Authors' Addresses Haibin Song Huawei Email: haibin.song@huawei.com Young Lee Huawei Email: leeyoung@huawei.com Victor Lopez Telefonica I+D Email: vlopez@tid.es Diego R. Lopez Telefonica I+D Email: diego@tid.es Lingli Deng China Mobile Email: denglingli@chinamobile.com Wei Chen China Mobile Email: chenwei@chinamobile.com Song, et al. Expires January 16, 2014 [Page 12]