Skip to main content

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]