Cases Study- PCP Deployment in Mobile Network
draft-chen-pcp-mobile-deployment-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
---|---|---|---|
Authors | Gang Chen , Zhen Cao | ||
Last updated | 2012-03-05 | ||
RFC stream | (None) | ||
Formats | |||
Stream | Stream state | (No stream defined) | |
Consensus boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | I-D Exists | |
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-chen-pcp-mobile-deployment-00
Network Working Group G. Chen Internet-Draft Z. Cao Intended status: Informational China Mobile Expires: September 6, 2012 March 5, 2012 Cases Study- PCP Deployment in Mobile Network draft-chen-pcp-mobile-deployment-00 Abstract This memo provided two cases study, when PCP is deployed in mobile network. Some motivation of deployment PCP in mobile network was described and justification for each deployment case was stated. Corresponding to each mode, the document discussed some features to address operational issues. That might potentially cause some extension on PCP protocol level. Requirements Language 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 RFC 2119 [RFC2119]. 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 6, 2012. Copyright Notice Copyright (c) 2012 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 Chen & Cao Expires September 6, 2012 [Page 1] Internet-Draft PCP-Mobile March 2012 (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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statements . . . . . . . . . . . . . . . . . . . . . . 3 3. Case 1: PCP Client located on UE . . . . . . . . . . . . . . . 5 3.1. Deployment Description . . . . . . . . . . . . . . . . . . 5 3.2. PCP API Design . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Authentication Consideration . . . . . . . . . . . . . . . 6 4. Case 2: PCP Proxy located on MGW . . . . . . . . . . . . . . . 7 4.1. Deployment Description . . . . . . . . . . . . . . . . . . 7 4.2. PCP Whitelist/Blacklist Design . . . . . . . . . . . . . . 8 4.3. Authentication Consideration . . . . . . . . . . . . . . . 8 4.4. PCP Policy Implementation . . . . . . . . . . . . . . . . 8 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Chen & Cao Expires September 6, 2012 [Page 2] Internet-Draft PCP-Mobile March 2012 1. Introduction This document provides a PCP deployment case study , which reflects demands from optimization on application traffic in mobile environment. Traffic in a mobile network is becoming a complex mix from protocols, different application and user behaviors. Some applications offer always-on characteristics to users, like instant message applications. These kinds of applications are normally TCP/ IP-based. And, application flows require one long-lived TCP connection between clients and servers. The long-lived TCP connection has impacts on normal network behavior. Issues such as network resources and terminals battery consumption happened when there are frequent keepalive/notification message has been transmitted periodically. In order to mitigate the issues, PCP[I-D.ietf-pcp-base] could be a way to resolve the problems by managing how incoming packets are forwarded by upstream devices such as NAT64, NAT44, IPv6 and IPv4 firewall devices. The applicabilities for reducing keepalive messages have been described in PCP protocol, in which such optimization is one of use cases from protocol design purpose. This memo would elaborate deployment from operational planning perspectives. The intension of publishing the memo would like to sharing the thoughts for potential usages in mobile networks. The audiences could get the information for their possible deployment of NAT64 in future. Some new works required to PCP protocol might be derived from particular considerations. These works are expected to be documented in separated memo. 2. Problem Statements Understanding traffic features is essential for network protocol optimization and quality improvement. During the Instant services are deployed, keepalive transmitted from a client to servers is to prevent inactivity from disconnecting the channel. The scenario is depicted in Figure 1. MN Internet | +---------------+ +----------------+ +-+ +-----+ | +--|--+ +---+ | +----------+ | | | /|/ | RAN |---| PS Network | MGW |---- |FW |----| |APP Server| | +-+ +-----+ | +--|--+ +---+ | +----------+ | +---------------+ +----------------+ MN: Mobile Terminals RAN: Radio Access Network PS: Packet Switch MGW/FW:Mobile Gateway/Firewall Chen & Cao Expires September 6, 2012 [Page 3] Internet-Draft PCP-Mobile March 2012 Figure 1: Mobile Networks Scenario Radio access network would provide wireless connectivity to the MN. Packages are transmitted through Packet Switch Domain heading to MGW. MGW would bear the responsibilities of Address allocation, Routing and Transfer. The connection between MN and MGW normally is point- to-point link, on which MGW is default router for MN. Firewall could either be integrated with MGW or posited behind MGW as standalone. The traffic is finally destined to application servers, which manage subscriber information. The behaviors of keepalives messages would let several nodes to keep track of all connections that pass through them. Depending on frequent keepalive exchanges, following states remain alive. o States on FW/NAT: NAT mapping records for UDP/TCP would be refreshed before the information becoming staled. o States on MGW: IP allocation performed by PDP(Packet Data Protocol) process. GW reserve states of allocated IP address by monitoring passed packages. Keepalive messages would also make the PDP context is alive. o States on APPs servers: applications server manage online/offline states for subscriber. The transmission of keepalive stands for active users. Otherwise, application servers advertise offline information to online subscribers inform the statues changes. The maintenance on these states keeping is irreplaceable in some extents, because those heartbeat exchanges is a only way to hold these together. However, these frequent and short messages have side-effects on mobile networks. o Radio resource consumption. A dedicated air channel needs to be assigned to each keepalive message. Radio resource utilization is very low in the case. Significant keepalive messages might even led air resource depletion. o Terminal energy consumption. Mobile terminals are often "sleep" to extend battery life. Heartbeat message would prohibit such state changing to idle so as to oppose to energy saving. o Operational profits consumption. According to a statistics, 16% instant signalling message would consume 50%~70% radio resource. The traffic mode would break balance of operational payments. The PCP deployment cases proposed by this memo are trying to resolve above-mentioned issues. Meanwhile, the deployment architectures take Chen & Cao Expires September 6, 2012 [Page 4] Internet-Draft PCP-Mobile March 2012 the always online service requirements[I-D.cao-pcp-mobapp-online] into considerations, which would be interpreted in detailed in Section 3. 3. Case 1: PCP Client located on UE 3.1. Deployment Description The Figure2 depicted the deployment scenario, in which PCP client is installed on ME. PCP server is located with NAT/FW respectively. Available IP address/Port would be assigned to PCP client through PCP MAP/PEER signalling negotiation. Therefore, NAT binding states would be manipulated in a explicit way to reduce NAT keepalive frequency. PCP signalling could guarantee NAT states alive on Firewall. Regarding states on MGW and APP servers, additional works should be done to fit into a mobile architecture. +-----+ +-----+ | PCRF|-<--| AF |- - < - < - + MN +--|--+ +-----+ | Internet | +---------------| +--------|-------+ +-+ +-----+ | +--|--+ +---+ | +----------+ | | | /|/ | RAN |---| PS Network | MGW |---- |FW |----| |APP Server| | +-+ +-----+ | +--|--+ +---+ | +----------+ | /\ +---------------+ /\ +----------------+ |PCP Client |PCP Server Figure 2: Case 1 Study First off, APP server should track users states and synchronize online/offline information. Cancellation of keepalive message would led user states invisible. In PCP protocol spec[I-D.ietf-pcp-base] section 9.3, there is statement that PCP cannot do anything useful to reduce those keepalives. This memo recommended a way to optimize the application by integrating PCP capacities with always online application processes. To achieve that, PCP API design works should be done to provide application clients with explicit NAT binding information. After the awareness of session active duration, app clients could inform app servers the active behavior by extending app signalling. Such information could prolong time-out timers on the server side. The user states would align with NAT binding information. Regarding the requirement of maintaining status on MGW, it could take the Policy and Charging Control (PCC) advantage to execute a policy for specific PDP session. The Figure 2 also shown the link on such reaction chain, in which Policy And Charging Rules Function (PCRF) Chen & Cao Expires September 6, 2012 [Page 5] Internet-Draft PCP-Mobile March 2012 and Application Function (AF) are involved. Therein PCRF is responsible for authorizing and executing policy rules on MGW. AF is a functional element offering applications that require dynamic policy. The AF can be seen as bridging the gap between applications and how they affect node behaviour. The whole process is to let AF aware of PCP warranted time-slot and feedback such information to PCRF. Afterwards, PCRF could apply the policy to MGW for IP address maintenance. It should be noted that this part of work is out of the PCP work scope. Some particular features have been proposed in the case 1 to optimize operational experiences, which was described in following sub- sections. 3.2. PCP API Design In the case of PCP client located on a host (e.g. Mobile terminals) with various applications, it's desirable to package PCP functionalities as a capacity open to upper layer applications. That is not only to facilitate the coordination between PCP caller(i.e. applications) and client, but also help to optimize functionalities both for PCP and applications. The basic roles of PCP API is to provide applications with functions of triggering PCP requests and feedback PCP responds to apps. So, the application developers could code PCP as one of components to coordinate with other part of applications. For example, when the application is aware of reserved binding information on NAT, the client could report to servers to optimize heartbeat at application layer. Another benefit introducing PCP API is to hand failure cases, when a application or PCP client is broken accidentally. PCP API could eject an exception inform PCP server to delete related port binding in time depending on system calls. 3.3. Authentication Consideration It's hard to determine whether PCP requests is coming from registered users or malicious attacker. Since operator don't know the situations in wild. The authentication is necessary to defend PCP server. Some proper authentication mechanism fits into the mobile network. The problem of PCP authentication comes from the fact that the PCP client (device) and PCP server (FW) do not have trust relationship with each other. [I-D.wasserman-pcp-authentication] has some considerations on the PCP authentication, in which an EAP option is included in the PCP requests from the devices. In mobile network, provisioning of new credentials to mobile devices is a difficult tasks. Taking this into consideration, the integration with SIM Chen & Cao Expires September 6, 2012 [Page 6] Internet-Draft PCP-Mobile March 2012 authentication is one of these choices on the table. The other possible ways of PCP authentication include the use of open authentication capability such as 3GPP GAA (Generic Authentication Architecture) defined in 3GPP 33.220. So that, the PCP client can invoke the authentication ability provided by the operator. 4. Case 2: PCP Proxy located on MGW 4.1. Deployment Description Figure 3 depicted another deployment scenario, in which PCP client is installed on MGW and PCP server is located on NAT/FW. MGW takes role of third party on behalf of MEs to initiate PCP signalling. THIRD_PARTY Option should be carried in MAP and PEER opcodes to control a mapping for an ME. The applicabilities of THIRD_PARTY Option is justified by following reasons. o MGW and NAT/FW belong to "wallet garden" mode from operational perspectives. MGW could be treated as an operator-authorized node, which would facilitate the authorization process. o MGW is capable of verifying the present/absence of delegated MNs by monitoring MN states(e.g. sending Routing Area Update(RAU)/ Track Area Update(TAU) periodically). It could get rid of risks maintaining immortalized mappings even an ME has gone. +-----+ +-----+ | PCRF|->--| AF |- > - > - > + MN +--|--+ +-----+ |Internet | +---------------| +--------|-------+ +-+ +-----+ | +--|--+ +---+ | +----------+ | | | /|/ | RAN |---| PS Network | MGW |---- |FW |----| |APP Server| | +-+ +-----+ | +--|--+ +---+ | +----------+ | +---------------+ +----------------+ /\ /\ | | PCP Client PCP Server Figure 3: Case 2 Study The case also leveraged PCC framework, in which PCRF servers as a policy enforcement point. It could keep statues information on behalf of ME and assign policies to MGW. Such deployment consideration also benefits to maintaining PDP session states on MGW. PDP session could be informed with binding period records through internal state machine. And it would take corresponding action to hold the PDP session for an identical period. On the other hand, Chen & Cao Expires September 6, 2012 [Page 7] Internet-Draft PCP-Mobile March 2012 maintained time interval is sent to PCRF and forward to AF. APP server would be offered with a specific online character for user status management. Some particular features have been proposed in the case 2 to optimize operational experiences, which was described in following sub- sections. 4.2. PCP Whitelist/Blacklist Design PCP whitelist/blacklist feature is to prioritize incoming PCP requests message according to configured list. Using a "whitelist" in a generic sense means that PCP requests are not treated as high priority unless the source IP address of PCP request is contained in the whitelist. In contrast, using a "blacklist" means that all PCP requests are permitted to maintain IP/Port resource unless the source IP address is contained in the blacklist. The whitelist is comprised of several addresses and configured on PCP servers manually. These whitelist configuration contribute to differentiated service purposes. In the case of scarcity of IP/Port resources, PCP server would offer high priority to PCP requests, the packet source address of which is matched with a specific record in the list. Whitelist usage would potentially promote PCP requests sending from an operators trusted node, e.g. MGW, etc. A blacklist could protect PCP server from overloaded PCP requests process. A range of IP address subnet could be set in blacklist to rule out malicious attacks. When a PCP server receives a PCP request with source address falling into the blacklist, it MUST generate a error response. 4.3. Authentication Consideration Basically, the PCP requests from MGW will change the TCP/UDP binding for the MN. But considering the MGW is a trusted entity in the 3GPP domain, so the security consideration in this case could be relaxed to some extent. The MGW should make sure that the change of binding relationship on the FW. 4.4. PCP Policy Implementation PCP policy features provide a possibility for more fine-grained states management. Different PCP requests would be ranked to perform differentiated policies according to specific service features. In some cases, Service Level Agreement (SLA) would be signed to guarantee service delivery with QoS assurance. Such feature is useful to assign proper resource for each PCP request, which Chen & Cao Expires September 6, 2012 [Page 8] Internet-Draft PCP-Mobile March 2012 corresponding different kinds of services. The implementation of PCP policy should configure a policy /knowledge base on PCP server. Such policy configuration is made up with maximum resource guarantee represented with different indicator. Operators could treat PCP requests differently according to service categories, e.g. Gold service would admit to have unlimited ports resource and Silver service is only permitted to occupy pre- determinative ports (both on quantity and hold-up time). Correspondingly, PCP requests should be marked with different service tags. Such tags would be labeled depending on DPI functionalities or policy delivery from PCRF. In the case, THIRD_PARTY Option should extend a new field to indicate the service tag. The extension could be done in separated document is this requirement is accepted. 5. Conclusion PCP mechanism could be potentially adopted in different usage contexts. The deployment document could give audiences a explicit use case. Operators may benefit from such experiences sharing. It even becomes a guidance for future PCP deployment. There is recommendation to PCP WG to validate the inputs and indenfy issues from operational aspects. It is expected that proper document should be drafted to determine solutions or workarounds to those issues. 6. Security Considerations TBD 7. IANA Considerations This document makes no request of IANA. 8. Acknowledgements The authors would like to thank Ping Lin for her discussion and comments. 9. References Chen & Cao Expires September 6, 2012 [Page 9] Internet-Draft PCP-Mobile March 2012 9.1. Normative References [I-D.ietf-pcp-base] Cheshire, S., Boucadair, M., Selkirk, P., Wing, D., and R. Penno, "Port Control Protocol (PCP)", draft-ietf-pcp-base-23 (work in progress), February 2012. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References [I-D.cao-pcp-mobapp-online] Cao, Z., Chen, G., Deng, H., and T. Sun, "Requirements for Always Online Applications", draft-cao-pcp-mobapp-online-00 (work in progress), March 2011. [I-D.wasserman-pcp-authentication] Zhang, D., Wasserman, M., and S. Hartman, "Port Control Protocol (PCP) Authentication Mechanism", draft-wasserman-pcp-authentication-01 (work in progress), October 2011. Authors' Addresses Gang Chen China Mobile No.32 Xuanwumen West Street Xicheng District Beijing 100053 China Email: phdgang@gmail.com Zhen Cao China Mobile No.32 Xuanwumen West Street Xicheng District Beijing 100053 China Email: caozhen@chinamobile.com Chen & Cao Expires September 6, 2012 [Page 10]