Cases Study- PCP Deployment in Mobile Network
draft-chen-pcp-mobile-deployment-00
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]