Internet Engineering Task Force P. Fan Internet-Draft H. Deng Intended status: Informational China Mobile Expires: September 20, 2014 March 19, 2014 CONET (Collaborative Network) Problem Statement and Use Cases draft-fan-intarea-conet-ps-uc-00 Abstract This document describes problems of identifying and handling application traffic in an ISP' network, and use cases of collaborative network which enables active cooperation between ICPs and ISPs for better traffic operation. 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 September 20, 2014. Copyright Notice Copyright (c) 2014 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 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. Fan & Deng Expires September 20, 2014 [Page 1] Internet-Draft CONET Problem Statement and Use Cases March 2014 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Content based charging . . . . . . . . . . . . . . . . . 4 3.2. QoS ability opening . . . . . . . . . . . . . . . . . . . 5 3.3. Application experience enhancement . . . . . . . . . . . 6 4. Informative References . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction Internet service providers (ISPs) around the world have been seeing booming growth of subscriber population and traffic volume of internet service over the years. Data traffic congestion causes severe user experience degradation, which requires ISPs to better operate its data network. Today's ISPs are making efforts to handle the traffic that goes through their networks more effectively. [PCC] and [PCF] are some of the work that helps ISPs to solve the problems in data traffic operation. Meanwhile, internet content providers (ICPs) which provide the applications are gradually realizing the necessity of cooperation with the ISPs rather than having them be the dumb pipe. By utilizing the ability of agile traffic management and classification provided by the network, ICPs intends to receive better treatment and differentiation on the traffic of their products, so as to meet user requirement and expectation, enhance user experience and viscosity, thus increase their revenue. Unlike the past time when they are performing independently without concern for each other, there is growing needs for ICPs and ISPs to build collaborative connections, which will benefit both of them as well as users. There are also emerging operational models that reflect this connection. o Content based charging offers customized, application specific billing strategy compared with traditional flat rate or time/ volume based charging. o Application based traffic optimization, such as QoS guarantee and firewalling, also requires the knowledge of the type of the traffic. One of the challenges ISPs meet in data traffic operation is to perceive the traffic in a finer granularity. A traditionally widely used approach is to deploy content aware devices which are Fan & Deng Expires September 20, 2014 [Page 2] Internet-Draft CONET Problem Statement and Use Cases March 2014 specialized in identifying application information of the traffic flows using technics like DPI (Deep Packet Inspection) or DFI (Deep Flow Inspection). Because of the tentative and deductive nature, these devices have met precision and timeliness limitation in practical deployment. If an ICP can actively notify its characteristics to the network, traffic identification will be much more applicable and precise, and no dedicated identification devices are needed. 2. Problem Statement Current common approach to identify traffic flows of applications in a network is to rely on dedicated content aware devices. These devices not only parse fields on the IP and transport layers but also recognize application related information above transport layer. Content awareness ability mainly utilizes DPI function, which inspects characteristic signature (e.g. key string, binary sequence, etc.), and DFI function, which analyzes statistical characteristic and connection behavior of traffic flows, to identify application. However, there are limitations in deployment and operation of the ability. o Since both DPI and DFI are essentially deductive methods difficult to fully grasp the characteristics of applications, accuracy of application identification cannot be guaranteed. Error or omission is inevitable. o Internet applications are apt to change frequently, so are the characteristics of themselves. There will be a time latency to complete application traffic analysis and update signature database when a new application or version appears, which also contributes to the inaccuracy of identification. o Content aware devices usually act as a black box. There is no standard way in implementation or benchmarking. So the ability highly depends on vendors. Different boxes are likely to give different identification results to the same traffic. o Content aware functions require parsing the payload of packets, leading to very high device resource consumption. Built-in content aware function modules in network elements like GGSN/BRAS will affect the forwarding performance and thus impact data transmission. o Investment cost cannot be neglected. Sometimes the cost to identify the traffic is no less than that to forward the traffic. Operational cost of the additional identifying nodes is also an Fan & Deng Expires September 20, 2014 [Page 3] Internet-Draft CONET Problem Statement and Use Cases March 2014 important issue. More potential failure points and possible optical power split will affect network quality. Another simpler approach is to identify traffic by IP addresses. An example would be a white list of IP addresses of an application of the ICP, and network can match traffic with the list to pick the volume of the application. This approach will have limitations when dealing with more complex scenarios. o More granular traffic handling cannot be satisfied. If part of the application traffic or traffic of some of the users is to be treated separately, IP based identification is too coarse. For example, traffic for http://www.example.com/text/ and http:// www.example.com/video/ is likely to receive different treatment but target to the same IP address; traffic from two users to the same server is a similar case. o If cache/CDN is deployed in the network, then different users are likely to visit different addresses, and the addresses are likely to be different from the original addresses of ICPs. Managing the list will have to consider the IP addresses of caches and CDN nodes deployed. o Configuring the IP address list is not always extensible as the addresses may change, and sometimes it is not supposed to expose the addresses of ICPs. 3. Use Cases If there is a way for an application to actively notify its information to the network, passive inspection devices will not be needed. Bridging of application and network is also believed to be effective, precise and helpful in cooperation between ISPs and ICPs. Here we describe two use cases which benefit from active negotiation of application and network. 3.1. Content based charging Commonly used billing method for mobile subscribers, e.g. volume based charging, does not distinguish from the angle of applications. It introduces difficulty for users to use applications consuming large volume in this billing model. ICPs also have to strive for volume apart from preference and time of users. Content based charging takes content related information into account and enables smarter pricing strategy. Operators can place different prices for different types of traffic, and help ICPs build tight relationship with their users, e.g. wholesaling the data volume of an application Fan & Deng Expires September 20, 2014 [Page 4] Internet-Draft CONET Problem Statement and Use Cases March 2014 to its developer ICP so that users can use the application free of charge. An application intending to benefit from content based charging can notify its existence to the network and have its traffic charged in the desired way. The following diagram shows an architecture of content based charging in 3GPP mobile network. PCRF CG/BOSS +-----+ +-----+ | | | | +-----+---- ---+-----+ | \ / | \/ | /\ | / \ +-----+ +-----+---- ---+-----+ | |----------| |-----------| | +-----+ +-----+ +-----+ UE GGSN/P-GW ICP A typical process of content based charging for an application is as follows: 1. ICP applies for content based charging for its application to PCRF. Information notified may include application identifier, description of flows needing special charging (e.g. signature, 5 tuples), intended charging model (e.g. data volume of the application is free of charge), etc. 2. PCRF configures matching rules on GGSN/P-GW. 3. End user uses the application. 4. GGSN/P-GW receives and matches the traffic of the application, and provides charge records of the application to billing unit CG /BOSS. 3.2. QoS ability opening QoS ability opening is provided by the network to enable dynamic access acceleration, priority guarantee and other service differentiation for ICPs, and new application based QoS selling business for operators. QoS opening can be realized in mobile networks as well as fixed broadband networks. The following diagram depicts an architecture of open QoS ability in broadband access networks. Current QoS in Fan & Deng Expires September 20, 2014 [Page 5] Internet-Draft CONET Problem Statement and Use Cases March 2014 broadband access networks is usually circuit or user based, achieved by configuring policies on network nodes like an edge router, and is not dynamic, on-demand or application specific. If application characteristics are signaled to the network, network will be able to know the exact application information of the traffic, and thus perform QoS accordingly. By signaling characteristics, application can decide when and how to request the network to provide QoS for its traffic. Strategy Server +-----+ | | +-----+ | | | | +-----+ +-----+ +-----+ | |-----------| |---------| | +-----+ +-----+ +-----+ User Application BRAS Application Server A typical process of the application initiated QoS can be described as follows: 1. End user application initiates data traffic. The application may be a downloading service, online video service, etc. 2. Application decides that QoS is needed for its traffic, e.g. the user is logged as VIP. 3. Application signals information of the traffic needing QoS to the strategy server in the network. Information signaled may include application identifier, flow description (e.g. 5 tuples), subscribed QoS contract, etc. 4. Strategy server validates the request from application and the contract with the ICP, and sends corresponding configuration to forwarding devices (e.g. BRAS) to perform requested QoS. 3.3. Application experience enhancement There are many ICPs today providing internet based home products to users. For example, an internet TV box uses WiFi to connect the internet and provides video programs to users. ICPs wish to cooperate with ISPs providing the access service to improve the experience of their services, as access network is often congested due to extensive internet usage nowadays. But currently classifying Fan & Deng Expires September 20, 2014 [Page 6] Internet-Draft CONET Problem Statement and Use Cases March 2014 the traffic of the services is rather complex when the traffic is mixed with other normal traffic in a single pipe (e.g. WiFi). Collaboration of ICP and ISP can solve the problem. Authorization Server +-----+ | | +-----+ | | | | +-----+ +-----+ +-----+ | | ((( | |--------------| | +-----+ +-----+ +-----+ ICP Product HGW/MiFi ICP Server A typical process of this enhancement can be described as follows: 1. ICP product communicates with access gateway (e.g. HGW, MiFi) to request special treatment of its traffic. Information signaled may include product identifier, authorization token, desired treatment (e.g. high priority, bandwidth reservation), etc. 2. Access gateway forwards the information to the authorization server, and authorization server signals back the result. 3. Access gateway coordinates with backhaul network to tag and classify the traffic of the product (can be specified by the address of the product). 4. Informative References [PCC] 3GPP Technical Specification 23.203, , "Policy and charging control architecture", March 2012. [PCF] BBF STRAW BALLOT WT-134, , "Broadband Policy Control Framework (PCF)", February 2012. Authors' Addresses Peng Fan China Mobile 32 Xuanwumen West Street, Xicheng District Beijing 100053 P.R. China Email: fanpeng@chinamobile.com Fan & Deng Expires September 20, 2014 [Page 7] Internet-Draft CONET Problem Statement and Use Cases March 2014 Hui Deng China Mobile 32 Xuanwumen West Street, Xicheng District Beijing 100053 P.R. China Email: denghui@chinamobile.com Fan & Deng Expires September 20, 2014 [Page 8]