Internet Engineering Task Force S. Jiang Internet-Draft Huawei Technologies Co., Ltd Intended status: Informational H. Deng Expires: November 30, 2014 China Mobile F. Bari AT&T R. Zhang China Telecom S. Krishnan Ericsson May 29, 2014 Application Enabled COllaborative NETworking Gap Analysis draft-conet-aeon-gap-analysis-00 Abstract Identification and treatment of application flows have become more and more important for network operators. In order to efficiently distinguish ICPs' traffic, coordination between ISPs and ICPs is required. IP flow identification can be based on ICPs' traffic carrying some mutually agreed identifiers. This document analyzes the technical gap between the current network functions and required network capability to enable such functionality. 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 November 30, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. Jiang, et al. Expires November 30, 2014 [Page 1] Internet-Draft CONET/AEON Gap Analysis May 2014 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Overview of Technical Consideratins . . . . . . . . . . . . . 3 3. Traffic Identifiers . . . . . . . . . . . . . . . . . . . . . 3 4. Collaboration between ICPs and ISPs . . . . . . . . . . . . . 7 5. Identifying Traffics between End Users and Network . . . . . 8 6. Limitations of Existing Signaling Mechanisms . . . . . . . . 8 7. Efforts in Progress . . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 11. Change log [RFC Editor: Please remove] . . . . . . . . . . . 12 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 12.2. Informative References . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction While the Internet traffic is continually growing, more and more ICPs (Internet Content Providers) realize the essentiality and advantages of cooperating with ISPs (Internet Service Providers). In order to serve their users better, ICPs have an emerging requirement that the traffic of their products needs to be treated differently, both in traffic handling process as well as in traffic accounting process. Jiang, et al. Expires November 30, 2014 [Page 2] Internet-Draft CONET/AEON Gap Analysis May 2014 [I-D.conet-aeon-problem-statement] has described such problems and related requirements. The biggest technical challenge that network operators or the ISPs face is of distinguishing the traffic in finer granularity. Nowadays, DPI (Deep Packet Inspection) or DFI (Deep Flow Inspection) mechanisms have been widely used in identifying application information specific to individual IP flows. However, they are expensive both operationally and computationally. In many cases, they are also not able to interact with real-time network operations. An alternative approach would be that the traffic from ICPs carries traffic identifiers that the network entities of ISPs can recognize and act on. For that to properly work, the traffic identifers must be mutually understood by ISPs and ICPs. This document analyzes the technical gap between the current network functions and required network capability. 2. Overview of Technical Consideratins Overall, there are three technical aspects that need to be considered, as listed below. o A traffic identifier. o An ICP notify/negotiate traffic identifiers and the desired processing way regarding both traffic handling and traffic accounting with an ISP. The policies of traffic processing need to be propagated and corresponding network entities need to be configured within an ISP network. o Signaling/negotiation of traffic identifier by an end user host or application to/with network. Note: the application-level communication between ICP servers and their client applications on end user hosts, including dynamically deciding the traffic identifier that end user hosts may embed in packets, is out of scope. This document focuses on only the network layer and transport layer . 3. Traffic Identifiers The precondition for a traffic flow to be handled differently is that it can be recognized by the network entities. In this document, the field in data packet that is used to distinguish a traffic flow or a type/category of traffic flow is called traffic identifier. There are a few requirements for traffic identifiers: Jiang, et al. Expires November 30, 2014 [Page 3] Internet-Draft CONET/AEON Gap Analysis May 2014 o Traffic identifiers must be stable, at least for the lifetime of an IP flow. o Traffic identifiers should be easy to inspect by the network entities. o Traffic identifiers should accurately distinguish IP traffic flow or a type/category of traffic flow. o Traffic identifiers must be trustable and protected against tampering during transportation. o Some traffic identifiers may be aggregated in order to reduce the management complexity on stateful records/policies. o Some traffic identifiers may be dynamically decided just before the real traffic is generated. The decision of identifiers may dynamically involve ISPs, ICPs and end user devices. o Some traffic identifiers may not be set by the traffic initiators. A intermediate node, for example a CPE or an ingress router, may re-mark or set new traffic identifier based on its traffic recognition. o Some traffic identifiers may be meaningful across network administrative boundaries. 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 expected to change frequently, and so are their characteristics. There will be a time lag between a complete application traffic analysis and update of signature database when a new application or a new version appears, and this also contributes to the inaccuracy of identification. Jiang, et al. Expires November 30, 2014 [Page 4] Internet-Draft CONET/AEON Gap Analysis May 2014 o Content identification mechanisms are usually proprietary and act as a black box. There is no standard way in their implementation or a way of benchmarking. So the ability highly depends on vendors. Different boxes are likely to give different identification results to the same traffic. o Content identification functionality requires parsing the payload of IP packets, leading to very high use of computational resources. Built-in content identification function modules in network elements will therefore affect the forwarding performance and thus impact data transmission. o Investment costs cannot be neglected. Sometimes the cost to identify the traffic is no less than that of forwarding the traffic. Operational cost of the additional nodes is also an important issue. More potential failure points will also affect network quality. o Furthermore, the usage of TLS (Transport Layer Security, [RFC5246]) and HTTPS [RFC2818] is increasing the difficulties of DPI. 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 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, the real-time game traffic and video traffic for the same website are likely to receive different treatment but target to the same IP address; traffics from two users to the same server may also need to be distinguished. o If cache or CDN (Content Distribution Network) 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. There are also other traffic identifiers or components that may get used as traffic identifiers: Jiang, et al. Expires November 30, 2014 [Page 5] Internet-Draft CONET/AEON Gap Analysis May 2014 o IP addresses of end user devices. They are natural identifiers that can distinguish the communication nodes. However, one end user node would have many IP traffic flows. There is requirement to recognize only the traffics associated with certain ICPs. So, only IP addresses of end user devices are not sufficient. Furthermore, many end user devices may be assigned private IPv4 addresses. These addresses are replaced by public IPv4 addresses after NAT (Network Address Translator, [RFC3022]). o Port numbers. They are useful to distinguish flows/services from the same node. However, it cannot be used to identify network traffic independently. It must be used together with identifiers that distinguish nodes. o Flow labels [RFC6437]. It is only available in IPv6 traffic. It is changed for every flow. Like port numbers, flow labels cannot be used to identify network traffics independently. Normally, it is used as triple-tuple with source and destination address. Because it is encoded in the IPv6 fixed header, it is easier to recognize than port numbers. However, another disadvantage of flow label is that it is not protected, particularly, there is no mechanism to validate its integrity. o DiffServ Field (Differentiated Services Field, [RFC2474]). It was defined to identify the differentiated services that network should apply on the packets. It is the explicit result for network entities to apply different handling policies accordingly. However, the precondition DiffServ field can be used is that there is strong trust relatioship between the nodes that set DiffServ Field and network entities. Each of the above mentioned traffic identifiers have their own suitable use cases and possible limitations. For many scenarios, the combination of abovementioned traffic identifiers may be used. The 5-tuple (source IP address, destination IP address, source port number, destination port number, IP protocol number) is the most commonly used traffic identifier to identify a flow accurately in IP layer. However, 5-tuple itself is not tightly associated with upper-layer applications or contents. There are mapping gaps to use 5-tuple to identify traffics relevant to a certain ICP or its certain services. Another issue of 5-tuple is that 5-tuple cannot be easily aggregated. Managing numerous 5-tuple may be a big burden for ISPs. Furthermore, the existance of NATs makes the use of the 5-tuple difficult. Consequently, the traffic identifiers associated with IPv4 addresses become a very complicated management issue. Jiang, et al. Expires November 30, 2014 [Page 6] Internet-Draft CONET/AEON Gap Analysis May 2014 4. Collaboration between ICPs and ISPs Firstly, ICP needs to define traffic identifiers in consultation with ISP. The ICP defines the specific traffic identifiers, which may have multiple categories, and the desired policies associated with each traffic categories, in consultation with the ISP. Then the ISP network can apply these policies to actual network traffic. The notification process between ICPs and ISPs can be dynamic through a protocol/interface. In 3GPP (3rd Generation Partnership Project) mobile network, Rx interface [Rx-3GPP] has been defined to allow interaction between ICPs and ISPs using Diameter [RFC6733], and AF- Application-identifier AVP has also been defined to indicate the particular service that the AF (Application Function) service session belongs to. This information may be used by the PCRF (Policy and Charging Rule Function) to differentiate QoS for different application services. However, currently few ICPs have support for Diameter protocol. Considering ICP is more familiar with XML based protocol, 3GPP is working on the solutions for an XML based protocol (e.g. SOAP, Restful HTTP, etc.) over Rx interface between the AF and the PCRF [XML_AF_PCRF]. With in an ISP network, Traffic management policy must be propagated to network entities that actually handle traffics. In 3GPP mobile network, Gx interface [Gx-3GPP] has been defined to enable PCRF autonomically configures matching rules regarding to a certain traffic on GGSN/P-GW. BroadBand Forum has also defined the Broadband Policy Control Framework [BPCF] that meets the similar function of Rx and Gx interfaces in the fixed broadband networks. This model has two limitations as below: 1. Some ICPs may have one server address, but with different sub- content behind that server address. Because current PCRF only focus on 5-tuple traffic description, it may be difficult to support fine-grained traffic identification. 2. Because of lack of involvement from end user devices/ applications, it will be difficult and more complex to identify devices if they are behind NAT (they have NATed IPv4 addresses). Jiang, et al. Expires November 30, 2014 [Page 7] Internet-Draft CONET/AEON Gap Analysis May 2014 Another major issue is that this model is ISP-oriented. ICP traffics commonly cross multiple ISP networks. Hence, an ICP may have to work with multiple ISPs independently. The traffic handling across different administration domain may be different, giving the possibility that different ISPs may use different traffic identifiers and different policies. When there was a traffic issue, such as high latency or packet lost, it may be a challenge for the ICP to find out which network has problem. 5. Identifying Traffics between End Users and Network When an end user host or application initiates traffic towards ICP contents, it is possible that the content instead is retrieved from a cache/CDN that is deployed in the operator network. In that case, the traffic identifier provided from the end user host or application to the network is used to classify traffic. The traffic identifiers used by end user host or application: o may be authorized and assigned by the ICPs after application-level authentication or out-of-band authentication. Then, these traffic identifiers would be carried by packets. o may be dynamically decided by the negotiation between the end user host or application and the network. Out-of-band controlling policies, including network authentication and authorization, may also be notified/negotiated together. o may just describe the traffic characteristics, and leave the network to recognize them, then mapped into other traffic identifiers that have explicit meaning within the network. Currently, there are not many in-band mechanisms, where traffic identifiers that the end user devices/applications set up are carried within packets. In-band mechanisms allow packet traversal across administration domains, with the traffic getting identical handling. The precondition of in-band mechanisms is that the integrity of traffic identifiers can be validated by network entities. 6. Limitations of Existing Signaling Mechanisms The IETF has standardized several mechanisms involving explicit signaling between applications and the network that may be used to support visibility and differentiated network services workflows. These existing protocols were designed to serve their own purposes and scenarios. Unfortunately, none of these have experienced widespread deployment success, nor are they well suited for the Jiang, et al. Expires November 30, 2014 [Page 8] Internet-Draft CONET/AEON Gap Analysis May 2014 usages described previously. Existing signaling options include the following: o RSVP (Resource Reservation Protocol, [RFC2205]), a resource reservation setup protocol, is the original on-path signaling protocol standardized by the IETF. It is transported out-of-band and could be used to signal information about any transport protocol traffic (it currently supports TCP and UDP). Its original goal was to provide admission control. It is mainly used among network entities. Its requirement for explicit reservation of resources end to end proved too heavy for most network environments. Its success was further impacted by its reliance on router-alert, which often leads to RSVP packets being filtered by intervening networks, and by its requirement for access to a raw socket, something that is generally not available to applications running in user space. To date, more lightweight signaling workflows utilizing RSVP have not been standardized within the IETF. o NSIS (next Steps in Signaling, [RFC4080]) is the next iteration of RSVP-like signaling defined by the IETF. It focused on the same fundamental workflow as RSVP admission control as its main driver, and because it did not provide significant enough use-case benefits over RSVP, it has seen even less adoption than RSVP. o DiffServ [RFC4594] and VAN Tagging [IEEE-802.1Q] style packet marking can help provide QoS in some environments, but such markings are often modified or removed at various points in the network or when crossing network boundaries. There are additional limitations when using DiffServ with real-time communications applications, and the DART working group has been chartered to write a document that explains the limitations that exist with DiffServ when used with RTP in general as well in the specific RTCWeb use cases [I-D.ietf-rtcweb-use-cases-and-requirements]. o DHCP (Dynamic Host Configuration Protocol, [RFC2131], [RFC3315]) was designed to provide information, including assigning host IP address, from network to hosts. It is a one-way information provisioning protocol. It does not provide authentication and information protection function. o Radius (Remote Authentication Dial In User Service, [RFC2865]) and Diameter [RFC6733] provides an Authentication, Authorization and Accounting for network access. Jiang, et al. Expires November 30, 2014 [Page 9] Internet-Draft CONET/AEON Gap Analysis May 2014 7. Efforts in Progress Not surprisingly, there are several evolving proposals that aim to address the visibility and differentiated network services workflows where existing approaches are not sufficient. Protocol specific extensions are being defined, creating duplicate or inconsistent information models. This results in operational complexity and a need to convert information between protocols to leverage the best protocol option for each specific use case. Examples of evolving signaling options include the following: o STUN (Session Traversal Utilities for NAT, [RFC5389]) is an on- path, in-band signaling protocol that could be extended to provide signaling to on-path network devices. It provides an easily inspected packet signature, at least for transport protocols such as UDP. Through its extensions TURN [RFC5766] and ICE [RFC5245], it is becoming prevalent in application signaling driven by the initial use-case of providing NAT and firewall traversal capabilities and detecting local and remote candidates for peer- to-peer media sessions. The TRAM working group is chartered to update TURN and STUN to make them more suitable for WebRTC. o PCP (Port Control Protocol, [RFC6887]) provides a mechanism to describe a flow to the network. The primary driver for PCP is creating port mappings on NAT and firewall devices. When doing this, PCP pushes flow information from the host into the network (specifically to the network's NAT or firewall device), and receives information back from the network (from the NAT or firewall device). It is not meant to be used end-to-end but rather independently on one "edge" of a flow. o RESTCONF [I-D.ietf-netconf-restconf] is a REST-like protocol that provides a programmatic interface over HTTP for accessing data defined in YANG, using the datastores defined in NETCONF [RFC6241]. It is meant to provide a standard mechanism for web applications to access the configuration data, operational data, data-model specific protocol operations, and notification events within a networking device, in a modular and extensible manner. o I2RS (Interface to the Routing System) is a working group chartered to provide interfaces for management applications, network controllers, and user applications to make specific demands on the network. o ACTN (Abstraction and Control of Transport Networks) is a non- working group mailing list intended to enable discussion of the architecture, use-cases, and requirements that provide abstraction Jiang, et al. Expires November 30, 2014 [Page 10] Internet-Draft CONET/AEON Gap Analysis May 2014 and virtual control of transport networks to various applications/ clients. o Prefix coloring has been proposed for use in HOMENET and 6MAN working groups to provide differentiated services to applications based on IP address. o RMCAT (RTP Media Congestion Avoidance Techniques) has been chartered to address the lack of generally accepted congestion control mechanisms for interactive real-time media, which is often carried via sets of flows using RTP over UDP. Explicit exchanges of flow characteristics and congestion information between applications and the network could play an important role in such mechanisms. o TAPS (Transport Services) is an effort to create a working group to define transport services that are exposed to internet applications. A TAP enabled application identifies its needs of the locally available transports services via an API. Furthermore, the transport services of TAPS could benefit from this communication with the network. o SFC (Service Function Chaining) is a working group chartered to address issues associated with the deployment of service functions (e.g. firewalls, load balancers) in large-scale environments. Service function chaining is the definition and instantiation of an ordered set of instances of such service functions, and the subsequent "steering" of traffic flows through those service functions. 8. Security Considerations A trust relationship should be established among end users, ICPs and ISPs. The authentication and authorization for end user access should be as easy as possible. OAUTH protocol [RFC6749] & OpenID [OpenID] may be adopted. Traffic identifiers with packets should be protected against any tampering during transportation. The protocol used to notify/negotiate the traffic identifiers to/with network should be protected. 9. IANA Considerations This document includes no request to IANA. Jiang, et al. Expires November 30, 2014 [Page 11] Internet-Draft CONET/AEON Gap Analysis May 2014 10. Acknowledgements Valuable comments were received from Peng Fan, and Weihua Qiao. This document was produced using the xml2rfc tool [RFC2629]. 11. Change log [RFC Editor: Please remove] draft-conet-aeon-gap-analysis-00: original version, 2014-05-29. 12. References 12.1. Normative References [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, June 2005. [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, August 2006. Jiang, et al. Expires November 30, 2014 [Page 12] Internet-Draft CONET/AEON Gap Analysis May 2014 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011. [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, November 2011. [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, "Diameter Base Protocol", RFC 6733, October 2012. [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 6749, October 2012. [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 2013. 12.2. Informative References [BPCF] BroadBand Forum Technical Report 134, "Broadband Policy Control Framework", July 2012. [Gx-3GPP] 3GPP Work Item 13029, "Gx reference point for Policy and Charging Control", July 2008. [I-D.conet-aeon-problem-statement] Fan, P., Deng, H., Boucadair, M., Reddy, T., and C. Eckel, "Application Enabled Collaborative Networking: Problem Statement and Requirements", draft-conet-aeon-problem- statement-00 (work in progress), May 2014. Jiang, et al. Expires November 30, 2014 [Page 13] Internet-Draft CONET/AEON Gap Analysis May 2014 [I-D.ietf-netconf-restconf] Bierman, A., Bjorklund, M., Watsen, K., and R. Fernando, "RESTCONF Protocol", draft-ietf-netconf-restconf-00 (work in progress), March 2014. [I-D.ietf-rtcweb-use-cases-and-requirements] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- Time Communication Use-cases and Requirements", draft- ietf-rtcweb-use-cases-and-requirements-14 (work in progress), February 2014. [IEEE-802.1Q] IEEE 802.1Q, "IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks", 2005, . [OpenID] OpenID Foundation, "OpenID Authentication 2.0 - Final", December 2007, . [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [Rx-3GPP] 3GPP Technical Specification 29.214, "Policy and charging control over Rx reference point", July 2008. [XML_AF_PCRF] 3GPP Technical Report 29.817, "Study on eXtensible Markup Language (XML) based access of the Application Function (AF) to the Policy and Charging Rules Function (PCRF)", March 2014. Authors' Addresses Sheng Jiang Huawei Technologies Co., Ltd Q14, Huawei Campus, No.156 Beiqing Road Hai-Dian District, Beijing, 100095 P.R. China Email: jiangsheng@huawei.com Jiang, et al. Expires November 30, 2014 [Page 14] Internet-Draft CONET/AEON Gap Analysis May 2014 Hui Deng China Mobile Xuanwumenxi Ave. No.32 Beijing 100053 China Email: denghui@chinamobile.com Farooq Bari AT&T 7277 164th Ave NE Redmond WA 98052 USA Email: farooq.bari@att.com Rong Zhang China Telecom No.109 Zhongshandadao avenue Guangzhou 510630 China Email: zhangr@gsta.com Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada Phone: +1 514 345 7900 x42871 Email: suresh.krishnan@ericsson.com Jiang, et al. Expires November 30, 2014 [Page 15]